Page 422 of 3590 results (0.030 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: net: mana: Fix Rx DMA datasize and skb_over_panic mana_get_rxbuf_cfg() aligns the RX buffer's DMA datasize to be multiple of 64. So a packet slightly bigger than mtu+14, say 1536, can be received and cause skb_over_panic. Sample dmesg: [ 5325.237162] skbuff: skb_over_panic: text:ffffffffc043277a len:1536 put:1536 head:ff1100018b517000 data:ff1100018b517100 tail:0x700 end:0x6ea dev:<NULL> [ 5325.243689] ------------[ cut here ]------------ [ 5325.245748] kernel BUG at net/core/skbuff.c:192! [ 5325.247838] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 5325.258374] RIP: 0010:skb_panic+0x4f/0x60 [ 5325.302941] Call Trace: [ 5325.304389] <IRQ> [ 5325.315794] ? skb_panic+0x4f/0x60 [ 5325.317457] ? asm_exc_invalid_op+0x1f/0x30 [ 5325.319490] ? • https://git.kernel.org/stable/c/2fbbd712baf1c60996554326728bbdbef5616e12 https://git.kernel.org/stable/c/ca58927b00385005f488b6a9905ced7a4f719aad https://git.kernel.org/stable/c/05cb7c41fa1a7a7b2c2a6b81bbe7c67f5c11932b https://git.kernel.org/stable/c/c0de6ab920aafb56feab56058e46b688e694a246 •

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

CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0

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

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 •