CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-35902 – net/rds: fix possible cp null dereference
https://notcve.org/view.php?id=CVE-2024-35902
In the Linux kernel, the following vulnerability has been resolved: net/rds: fix possible cp null dereference cp might be null, calling cp->cp_conn would produce null dereference [Simon Horman adds:] Analysis: * cp is a parameter of __rds_rdma_map and is not reassigned. * The following call-sites pass a NULL cp argument to __rds_rdma_map() - rds_get_mr() - rds_get_mr_for_dest * Prior to the code above, the following assumes that cp may be NULL (which is indicative, but could itself be unnecessary) trans_private = rs->rs_transport->get_mr( sg, nents, rs, &mr->r_key, cp ? cp->cp_conn : NULL, args->vec.addr, args->vec.bytes, need_odp ? ODP_ZEROBASED : ODP_NOT_NEEDED); * The code modified by this patch is guarded by IS_ERR(trans_private), where trans_private is assigned as per the previous point in this analysis. The only implementation of get_mr that I could locate is rds_ib_get_mr() which can return an ERR_PTR if the conn (4th) argument is NULL. * ret is set to PTR_ERR(trans_private). rds_ib_get_mr can return ERR_PTR(-ENODEV) if the conn (4th) argument is NULL. Thus ret may be -ENODEV in which case the code in question will execute. Conclusion: * cp may be NULL at the point where this patch adds a check; this patch does seem to address a possible bug En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/rds: corrige la posible desreferencia nula de cp cp podría ser nulo, llamar a cp->cp_conn produciría una desreferencia nula [Simon Horman agrega:] Análisis: * cp es un parámetro de __rds_rdma_map y no es reasignado. * Los siguientes sitios de llamadas pasan un argumento cp NULL a __rds_rdma_map() - rds_get_mr() - rds_get_mr_for_dest * Antes del código anterior, lo siguiente supone que cp puede ser NULL (lo cual es indicativo, pero podría ser innecesario) trans_private = rs ->rs_transport->get_mr( sg, nents, rs, &mr->r_key, cp ? cp->cp_conn : NULL, args->vec.addr, args->vec.bytes, need_odp ? ODP_ZEROBASED : ODP_NOT_NEEDED); * El código modificado por este parche está custodiado por IS_ERR(trans_private), donde trans_private se asigna según el punto anterior de este análisis. • https://git.kernel.org/stable/c/786854141057751bc08eb26f1b02e97c1631c8f4 https://git.kernel.org/stable/c/997efea2bf3a4adb96c306b9ad6a91442237bf5b https://git.kernel.org/stable/c/9dfc15a10dfd44f8ff7f27488651cb5be6af83c2 https://git.kernel.org/stable/c/b562ebe21ed9adcf42242797dd6cb75beef12bf0 https://git.kernel.org/stable/c/998fd719e6d6468b930ac0c44552ea9ff8b07b80 https://git.kernel.org/stable/c/2b505d05280739ce31d5708da840f42df827cb85 https://git.kernel.org/stable/c/c055fc00c07be1f0df7375ab0036cebd1106ed38 https://git.kernel.org/stable/c/907761307469adecb02461a14120e9a18 •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-35900 – netfilter: nf_tables: reject new basechain after table flag update
https://notcve.org/view.php?id=CVE-2024-35900
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: reject new basechain after table flag update When dormant flag is toggled, hooks are disabled in the commit phase by iterating over current chains in table (existing and new). The following configuration allows for an inconsistent state: add table x add chain x y { type filter hook input priority 0; } add table x { flags dormant; } add chain x w { type filter hook input priority 1; } which triggers the following warning when trying to unregister chain w which is already unregistered. [ 127.322252] WARNING: CPU: 7 PID: 1211 at net/netfilter/core.c:50 1 __nf_unregister_net_hook+0x21a/0x260 [...] [ 127.322519] Call Trace: [ 127.322521] <TASK> [ 127.322524] ? __warn+0x9f/0x1a0 [ 127.322531] ? __nf_unregister_net_hook+0x21a/0x260 [ 127.322537] ? report_bug+0x1b1/0x1e0 [ 127.322545] ? handle_bug+0x3c/0x70 [ 127.322552] ? • https://git.kernel.org/stable/c/e10f661adc556c4969c70ddaddf238bffdaf1e87 https://git.kernel.org/stable/c/d9c4da8cb74e8ee6e58a064a3573aa37acf6c935 https://git.kernel.org/stable/c/179d9ba5559a756f4322583388b3213fe4e391b0 https://git.kernel.org/stable/c/41bad13c0e8a5a2b47a7472cced922555372daab https://git.kernel.org/stable/c/7b6fba6918714afee3e17796113ccab636255c7b https://git.kernel.org/stable/c/8ba81dca416adf82fc5a2a23abc1a8cc02ad32fb https://git.kernel.org/stable/c/745cf6a843896cdac8766c74379300ed73c78830 https://git.kernel.org/stable/c/420132bee3d0136b7fba253a597b098fe •
CVSS: 6.1EPSS: 0%CPEs: 7EXPL: 0CVE-2024-35899 – netfilter: nf_tables: flush pending destroy work before exit_net release
https://notcve.org/view.php?id=CVE-2024-35899
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: flush pending destroy work before exit_net release Similar to 2c9f0293280e ("netfilter: nf_tables: flush pending destroy work before netlink notifier") to address a race between exit_net and the destroy workqueue. The trace below shows an element to be released via destroy workqueue while exit_net path (triggered via module removal) has already released the set that is used in such transaction. [ 1360.547789] BUG: KASAN: slab-use-after-free in nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.547861] Read of size 8 at addr ffff888140500cc0 by task kworker/4:1/152465 [ 1360.547870] CPU: 4 PID: 152465 Comm: kworker/4:1 Not tainted 6.8.0+ #359 [ 1360.547882] Workqueue: events nf_tables_trans_destroy_work [nf_tables] [ 1360.547984] Call Trace: [ 1360.547991] <TASK> [ 1360.547998] dump_stack_lvl+0x53/0x70 [ 1360.548014] print_report+0xc4/0x610 [ 1360.548026] ? __virt_addr_valid+0xba/0x160 [ 1360.548040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 1360.548054] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548176] kasan_report+0xae/0xe0 [ 1360.548189] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548312] nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548447] ? • https://git.kernel.org/stable/c/0935d558840099b3679c67bb7468dc78fcbad940 https://git.kernel.org/stable/c/f4e14695fe805eb0f0cb36e0ad6a560b9f985e86 https://git.kernel.org/stable/c/46c4481938e2ca62343b16ea83ab28f4c1733d31 https://git.kernel.org/stable/c/f7e3c88cc2a977c2b9a8aa52c1ce689e7b394e49 https://git.kernel.org/stable/c/4e8447a9a3d367b5065a0b7abe101da6e0037b6e https://git.kernel.org/stable/c/333b5085522cf1898d5a0d92616046b414f631a7 https://git.kernel.org/stable/c/d2c9eb19fc3b11caebafde4c30a76a49203d18a6 https://git.kernel.org/stable/c/24cea9677025e0de419989ecb692acd4b • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35898 – netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get()
https://notcve.org/view.php?id=CVE-2024-35898
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get() nft_unregister_flowtable_type() within nf_flow_inet_module_exit() can concurrent with __nft_flowtable_type_get() within nf_tables_newflowtable(). And thhere is not any protection when iterate over nf_tables_flowtables list in __nft_flowtable_type_get(). Therefore, there is pertential data-race of nf_tables_flowtables list entry. Use list_for_each_entry_rcu() to iterate over nf_tables_flowtables list in __nft_flowtable_type_get(), and use rcu_read_lock() in the caller nft_flowtable_type_get() to protect the entire type query process. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: nf_tables: corrige una posible ejecución de datos en __nft_flowtable_type_get() nft_unregister_flowtable_type() dentro de nf_flow_inet_module_exit() puede coincidir con __nft_flowtable_type_get() dentro de nf_tables_newflowtable(). Y no hay ninguna protección cuando se itera sobre la lista nf_tables_flowtables en __nft_flowtable_type_get(). Por lo tanto, existe una posible ejecución de datos de la entrada de la lista nf_tables_flowtables. • https://git.kernel.org/stable/c/3b49e2e94e6ebb8b23d0955d9e898254455734f8 https://git.kernel.org/stable/c/69d1fe14a680042ec913f22196b58e2c8ff1b007 https://git.kernel.org/stable/c/a347bc8e6251eaee4b619da28020641eb5b0dd77 https://git.kernel.org/stable/c/940d41caa71f0d3a52df2fde5fada524a993e331 https://git.kernel.org/stable/c/2485bcfe05ee3cf9ca8923a94fa2e456924c79c8 https://git.kernel.org/stable/c/9b5b7708ec2be21dd7ef8ca0e3abe4ae9f3b083b https://git.kernel.org/stable/c/8b891153b2e4dc0ca9d9dab8f619d49c740813df https://git.kernel.org/stable/c/e684b1674fd1ca4361812a491242ae871 •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-35897 – netfilter: nf_tables: discard table flag update with pending basechain deletion
https://notcve.org/view.php?id=CVE-2024-35897
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: discard table flag update with pending basechain deletion Hook unregistration is deferred to the commit phase, same occurs with hook updates triggered by the table dormant flag. When both commands are combined, this results in deleting a basechain while leaving its hook still registered in the core. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: nf_tables: descartar actualización del indicador de tabla con eliminación pendiente de la cadena base. La cancelación del registro del gancho se difiere hasta la fase de confirmación; lo mismo ocurre con las actualizaciones del gancho activadas por el indicador inactivo de la tabla. Cuando se combinan ambos comandos, esto da como resultado la eliminación de una cadena base y deja su gancho aún registrado en el núcleo. • https://git.kernel.org/stable/c/e10f661adc556c4969c70ddaddf238bffdaf1e87 https://git.kernel.org/stable/c/d9c4da8cb74e8ee6e58a064a3573aa37acf6c935 https://git.kernel.org/stable/c/179d9ba5559a756f4322583388b3213fe4e391b0 https://git.kernel.org/stable/c/9a3b90904d8a072287480eed4c3ece4b99d64f78 https://git.kernel.org/stable/c/b58d0ac35f6d75ec1db8650a29dfd6f292c11362 https://git.kernel.org/stable/c/6cbbe1ba76ee7e674a86abd43009b083a45838cb https://git.kernel.org/stable/c/2aeb805a1bcd5f27c8c0d1a9d4d653f16d1506f4 https://git.kernel.org/stable/c/9627fd0c6ea1c446741a33e67bc5709c5 •