Page 9 of 3596 results (0.024 seconds)

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

27 Dec 2024 — In the Linux kernel, the following vulnerability has been resolved: net: lapb: increase LAPB_HEADER_LEN It is unclear if net/lapb code is supposed to be ready for 8021q. We can at least avoid crashes like the following : skbuff: skb_under_panic: text:ffffffff8aabe1f6 len:24 put:20 head:ffff88802824a400 data:ffff88802824a3fe tail:0x16 end:0x140 dev:nr0.2 ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 5508 Com... • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 •

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

27 Dec 2024 — In the Linux kernel, the following vulnerability has been resolved: net: defer final 'struct net' free in netns dismantle Ilya reported a slab-use-after-free in dst_destroy [1] Issue is in xfrm6_net_init() and xfrm4_net_init() : They copy xfrm[46]_dst_ops_template into net->xfrm.xfrm[46]_dst_ops. But net structure might be freed before all the dst callbacks are called. So when dst_destroy() calls later : if (dst->ops->destroy) dst->ops->destroy(dst); dst->ops points to the old net->xfrm.xfrm[46]_dst_ops, wh... • https://git.kernel.org/stable/c/a8a572a6b5f2a79280d6e302cb3c1cb1fbaeb3e8 •

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

27 Dec 2024 — In the Linux kernel, the following vulnerability has been resolved: ALSA: control: Avoid WARN() for symlink errors Using WARN() for showing the error of symlink creations don't give more information than telling that something goes wrong, since the usual code path is a lregister callback from each control element creation. More badly, the use of WARN() rather confuses fuzzer as if it were serious issues. This patch downgrades the warning messages to use the normal dev_err() instead of WARN(). For making it ... • https://git.kernel.org/stable/c/a135dfb5de1501327895729b4f513370d2555b4d •

CVSS: 9.0EPSS: 0%CPEs: 2EXPL: 0

27 Dec 2024 — In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix aggregation ID mask to prevent oops on 5760X chips The 5760X (P7) chip's HW GRO/LRO interface is very similar to that of the previous generation (5750X or P5). However, the aggregation ID fields in the completion structures on P7 have been redefined from 16 bits to 12 bits. The freed up 4 bits are redefined for part of the metadata such as the VLAN ID. The aggregation ID mask was not modified when adding support for P7 chips. I... • https://git.kernel.org/stable/c/13d2d3d381ee9844f89bd436ab0f44204660027e •

CVSS: 8.5EPSS: 0%CPEs: 4EXPL: 0

27 Dec 2024 — In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: do not defer rule destruction via call_rcu nf_tables_chain_destroy can sleep, it can't be used from call_rcu callbacks. Moreover, nf_tables_rule_release() is only safe for error unwinding, while transaction mutex is held and the to-be-desroyed rule was not exposed to either dataplane or dumps, as it deactives+frees without the required synchronize_rcu() in-between. nft_rule_expr_deactivate() callbacks will change ->use... • https://git.kernel.org/stable/c/bfd05c68e4c6320304e9f371ffa356b6e4b9cc53 •

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

27 Dec 2024 — In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: Fix using rcu_read_(un)lock while iterating The usage of rcu_read_(un)lock while inside list_for_each_entry_rcu is not safe since for the most part entries fetched this way shall be treated as rcu_dereference: Note that the value returned by rcu_dereference() is valid only within the enclosing RCU read-side critical section [1]_. For example, the following is **not** legal:: rcu_read_lock(); p = rcu_dereference(head.ne... • https://git.kernel.org/stable/c/a0bfde167b506423111ddb8cd71930497a40fc54 •

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

27 Dec 2024 — In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btmtk: avoid UAF in btmtk_process_coredump hci_devcd_append may lead to the release of the skb, so it cannot be accessed once it is called. ================================================================== BUG: KASAN: slab-use-after-free in btmtk_process_coredump+0x2a7/0x2d0 [btmtk] Read of size 4 at addr ffff888033cfabb0 by task kworker/0:3/82 CPU: 0 PID: 82 Comm: kworker/0:3 Tainted: G U 6.6.40-lockdep-03464-g1d8b4eb3060e #1 b... • https://git.kernel.org/stable/c/0b70151328781a89c89e4cf3fae21fc0e98d869e •

CVSS: 7.8EPSS: 0%CPEs: 2EXPL: 0

27 Dec 2024 — In the Linux kernel, the following vulnerability has been resolved: drm/xe/reg_sr: Remove register pool That pool implementation doesn't really work: if the krealloc happens to move the memory and return another address, the entries in the xarray become invalid, leading to use-after-free later: BUG: KASAN: slab-use-after-free in xe_reg_sr_apply_mmio+0x570/0x760 [xe] Read of size 4 at addr ffff8881244b2590 by task modprobe/2753 Allocated by task 2753: kasan_save_stack+0x39/0x70 kasan_save_track+0x14/0x40 kas... • https://git.kernel.org/stable/c/dd08ebf6c3525a7ea2186e636df064ea47281987 •

CVSS: 7.8EPSS: 0%CPEs: 11EXPL: 0

27 Dec 2024 — In the Linux kernel, the following vulnerability has been resolved: can: hi311x: hi3110_can_ist(): fix potential use-after-free The commit a22bd630cfff ("can: hi311x: do not report txerr and rxerr during bus-off") removed the reporting of rxerr and txerr even in case of correct operation (i. e. not bus-off). The error count information added to the CAN frame after netif_rx() is a potential use after free, since there is no guarantee that the skb is in the same state. It might be freed or reused. Fix the iss... • https://git.kernel.org/stable/c/a22bd630cfff496b270211745536e50e98eb3a45 •

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

27 Dec 2024 — In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: fix LED ID check in led_tg_check() Syzbot has reported the following BUG detected by KASAN: BUG: KASAN: slab-out-of-bounds in strlen+0x58/0x70 Read of size 1 at addr ffff8881022da0c8 by task repro/5879 ... Call Trace: <TASK> dump_stack_lvl+0x241/0x360 ? __pfx_dump_stack_lvl+0x10/0x10 ? __pfx__printk+0x10/0x10 ? _printk+0xd5/0x120 ? __virt_addr_valid+0x183/0x530 ? • https://git.kernel.org/stable/c/268cb38e1802db560c73167e643f14a3dcb4b07c •