Page 284 of 2516 results (0.018 seconds)

CVSS: -EPSS: 0%CPEs: 7EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: bpf: Protect against int overflow for stack access size This patch re-introduces protection against the size of access to stack memory being negative; the access size can appear negative as a result of overflowing its signed int representation. This should not actually happen, as there are other protections along the way, but we should protect against it anyway. One code path was missing such protections (fixed in the previous patch in the series), causing out-of-bounds array accesses in check_stack_range_initialized(). This patch causes the verification of a program with such a non-sensical access size to fail. This check used to exist in a more indirect way, but was inadvertendly removed in a833a17aeac7. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Protección contra desbordamiento int para el tamaño de acceso a la pila. • https://git.kernel.org/stable/c/afea95d319ccb4ad2060dece9ac5e2e364dec543 https://git.kernel.org/stable/c/02962684258eb53f414a8a59854767be526e6abb https://git.kernel.org/stable/c/b1d4d54d32ce6342f5faffe71bae736540ce7cb5 https://git.kernel.org/stable/c/08b91babccbb168353f8d43fea0ed28a4cad568c https://git.kernel.org/stable/c/a833a17aeac73b33f79433d7cee68d5cafd71e4f https://git.kernel.org/stable/c/1858b8a331937f3976d8482cd5f6e1f945294ad3 https://git.kernel.org/stable/c/9970e059af471478455f9534e8c3db82f8c5496d https://git.kernel.org/stable/c/37dc1718dc0c4392dbfcb9adec22a776e •

CVSS: -EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: selinux: avoid dereference of garbage after mount failure In case kern_mount() fails and returns an error pointer return in the error branch instead of continuing and dereferencing the error pointer. While on it drop the never read static variable selinuxfs_mount. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: selinux: evita la desreferenciación de basura después de un error de montaje En caso de que kern_mount() falle y devuelva un puntero de error en la rama de error en lugar de continuar y desreferenciar el puntero de error. Mientras está en él, suelte la variable estática nunca leída selinuxfs_mount. • https://git.kernel.org/stable/c/0619f0f5e36f12e100ef294f5980cfe7c93ff23e https://git.kernel.org/stable/c/477ed6789eb9f3f4d3568bb977f90c863c12724e https://git.kernel.org/stable/c/68784a5d01b8868ff85a7926676b6729715fff3c https://git.kernel.org/stable/c/37801a36b4d68892ce807264f784d818f8d0d39b http://www.openwall.com/lists/oss-security/2024/05/30/1 http://www.openwall.com/lists/oss-security/2024/05/30/2 •

CVSS: -EPSS: 0%CPEs: 9EXPL: 0

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: 0

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: 0

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') •