Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: cancel dqi_sync_work before freeing oinfo<br /> <br /> ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the<br /> end, if error occurs after successfully reading global quota, it will<br /> trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled:<br /> <br /> ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c<br /> <br /> This reports that there is an active delayed work when freeing oinfo in<br /> error handling, so cancel dqi_sync_work first. BTW, return status instead<br /> of -1 when .read_file_info fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix index out of bounds in DCN30 color transformation<br /> <br /> This commit addresses a potential index out of bounds issue in the<br /> `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color<br /> management module. The issue could occur when the index &amp;#39;i&amp;#39; exceeds the<br /> number of transfer function points (TRANSFER_FUNC_POINTS).<br /> <br /> The fix adds a check to ensure &amp;#39;i&amp;#39; is within bounds before accessing the<br /> transfer function points. If &amp;#39;i&amp;#39; is out of bounds, the function returns<br /> false to indicate an error.<br /> <br /> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow &amp;#39;output_tf-&gt;tf_pts.red&amp;#39; 1025 tf_pts.green&amp;#39; 1025 tf_pts.blue&amp;#39; 1025

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/ncsi: Disable the ncsi work before freeing the associated structure<br /> <br /> The work function can run after the ncsi device is freed, resulting<br /> in use-after-free bugs or kernel panic.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: test for not too small csum_start in virtio_net_hdr_to_skb()<br /> <br /> syzbot was able to trigger this warning [1], after injecting a<br /> malicious packet through af_packet, setting skb-&gt;csum_start and thus<br /> the transport header to an incorrect value.<br /> <br /> We can at least make sure the transport header is after<br /> the end of the network header (with a estimated minimal size).<br /> <br /> [1]<br /> [ 67.873027] skb len=4096 headroom=16 headlen=14 tailroom=0<br /> mac=(-1,-1) mac_len=0 net=(16,-6) trans=10<br /> shinfo(txflags=0 nr_frags=1 gso(size=0 type=0 segs=0))<br /> csum(0xa start=10 offset=0 ip_summed=3 complete_sw=0 valid=0 level=0)<br /> hash(0x0 sw=0 l4=0) proto=0x0800 pkttype=0 iif=0<br /> priority=0x0 mark=0x0 alloc_cpu=10 vlan_all=0x0<br /> encapsulation=0 inner(proto=0x0000, mac=0, net=0, trans=0)<br /> [ 67.877172] dev name=veth0_vlan feat=0x000061164fdd09e9<br /> [ 67.877764] sk family=17 type=3 proto=0<br /> [ 67.878279] skb linear: 00000000: 00 00 10 00 00 00 00 00 0f 00 00 00 08 00<br /> [ 67.879128] skb frag: 00000000: 0e 00 07 00 00 00 28 00 08 80 1c 00 04 00 00 02<br /> [ 67.879877] skb frag: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 67.880647] skb frag: 00000020: 00 00 02 00 00 00 08 00 1b 00 00 00 00 00 00 00<br /> [ 67.881156] skb frag: 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 67.881753] skb frag: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 67.882173] skb frag: 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 67.882790] skb frag: 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 67.883171] skb frag: 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 67.883733] skb frag: 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 67.884206] skb frag: 00000090: 00 00 00 00 00 00 00 00 00 00 69 70 76 6c 61 6e<br /> [ 67.884704] skb frag: 000000a0: 31 00 00 00 00 00 00 00 00 00 2b 00 00 00 00 00<br /> [ 67.885139] skb frag: 000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 67.885677] skb frag: 000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 67.886042] skb frag: 000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 67.886408] skb frag: 000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 67.887020] skb frag: 000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [ 67.887384] skb frag: 00000100: 00 00<br /> [ 67.887878] ------------[ cut here ]------------<br /> [ 67.887908] offset (-6) &gt;= skb_headlen() (14)<br /> [ 67.888445] WARNING: CPU: 10 PID: 2088 at net/core/dev.c:3332 skb_checksum_help (net/core/dev.c:3332 (discriminator 2))<br /> [ 67.889353] Modules linked in: macsec macvtap macvlan hsr wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 libchacha poly1305_x86_64 dummy bridge sr_mod cdrom evdev pcspkr i2c_piix4 9pnet_virtio 9p 9pnet netfs<br /> [ 67.890111] CPU: 10 UID: 0 PID: 2088 Comm: b363492833 Not tainted 6.11.0-virtme #1011<br /> [ 67.890183] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 67.890309] RIP: 0010:skb_checksum_help (net/core/dev.c:3332 (discriminator 2))<br /> [ 67.891043] Call Trace:<br /> [ 67.891173] <br /> [ 67.891274] ? __warn (kernel/panic.c:741)<br /> [ 67.891320] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2))<br /> [ 67.891333] ? report_bug (lib/bug.c:180 lib/bug.c:219)<br /> [ 67.891348] ? handle_bug (arch/x86/kernel/traps.c:239)<br /> [ 67.891363] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1))<br /> [ 67.891372] ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)<br /> [ 67.891388] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2))<br /> [ 67.891399] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2))<br /> [ 67.891416] ip_do_fragment (net/ipv4/ip_output.c:777 (discriminator 1))<br /> [ 67.891448] ? __ip_local_out (./include/linux/skbuff.h:1146 ./include/net/l3mdev.h:196 ./include/net/l3mdev.h:213 ne<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice<br /> <br /> The km.state is not checked in driver&amp;#39;s delayed work. When<br /> xfrm_state_check_expire() is called, the state can be reset to<br /> XFRM_STATE_EXPIRED, even if it is XFRM_STATE_DEAD already. This<br /> happens when xfrm state is deleted, but not freed yet. As<br /> __xfrm_state_delete() is called again in xfrm timer, the following<br /> crash occurs.<br /> <br /> To fix this issue, skip xfrm_state_check_expire() if km.state is not<br /> XFRM_STATE_VALID.<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP<br /> CPU: 5 UID: 0 PID: 7448 Comm: kworker/u102:2 Not tainted 6.11.0-rc2+ #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> Workqueue: mlx5e_ipsec: eth%d mlx5e_ipsec_handle_sw_limits [mlx5_core]<br /> RIP: 0010:__xfrm_state_delete+0x3d/0x1b0<br /> Code: 0f 84 8b 01 00 00 48 89 fd c6 87 c8 00 00 00 05 48 8d bb 40 10 00 00 e8 11 04 1a 00 48 8b 95 b8 00 00 00 48 8b 85 c0 00 00 00 89 42 08 48 89 10 48 8b 55 10 48 b8 00 01 00 00 00 00 ad de 48<br /> RSP: 0018:ffff88885f945ec8 EFLAGS: 00010246<br /> RAX: dead000000000122 RBX: ffffffff82afa940 RCX: 0000000000000036<br /> RDX: dead000000000100 RSI: 0000000000000000 RDI: ffffffff82afb980<br /> RBP: ffff888109a20340 R08: ffff88885f945ea0 R09: 0000000000000000<br /> R10: 0000000000000000 R11: ffff88885f945ff8 R12: 0000000000000246<br /> R13: ffff888109a20340 R14: ffff88885f95f420 R15: ffff88885f95f400<br /> FS: 0000000000000000(0000) GS:ffff88885f940000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f2163102430 CR3: 00000001128d6001 CR4: 0000000000370eb0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? die_addr+0x33/0x90<br /> ? exc_general_protection+0x1a2/0x390<br /> ? asm_exc_general_protection+0x22/0x30<br /> ? __xfrm_state_delete+0x3d/0x1b0<br /> ? __xfrm_state_delete+0x2f/0x1b0<br /> xfrm_timer_handler+0x174/0x350<br /> ? __xfrm_state_delete+0x1b0/0x1b0<br /> __hrtimer_run_queues+0x121/0x270<br /> hrtimer_run_softirq+0x88/0xd0<br /> handle_softirqs+0xcc/0x270<br /> do_softirq+0x3c/0x50<br /> <br /> <br /> __local_bh_enable_ip+0x47/0x50<br /> mlx5e_ipsec_handle_sw_limits+0x7d/0x90 [mlx5_core]<br /> process_one_work+0x137/0x2d0<br /> worker_thread+0x28d/0x3a0<br /> ? rescuer_thread+0x480/0x480<br /> kthread+0xb8/0xe0<br /> ? kthread_park+0x80/0x80<br /> ret_from_fork+0x2d/0x50<br /> ? kthread_park+0x80/0x80<br /> ret_from_fork_asm+0x11/0x20<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gfs2: fix double destroy_workqueue error<br /> <br /> When gfs2_fill_super() fails, destroy_workqueue() is called within<br /> gfs2_gl_hash_clear(), and the subsequent code path calls<br /> destroy_workqueue() on the same work queue again.<br /> <br /> This issue can be fixed by setting the work queue pointer to NULL after<br /> the first destroy_workqueue() call and checking for a NULL pointer<br /> before attempting to destroy the work queue again.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: MGMT: Fix possible crash on mgmt_index_removed<br /> <br /> If mgmt_index_removed is called while there are commands queued on<br /> cmd_sync it could lead to crashes like the bellow trace:<br /> <br /> 0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc<br /> 0x0000053D: mgmt_pending_remove+0x18/0x58 [bluetooth]<br /> 0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108 [bluetooth]<br /> 0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth]<br /> <br /> So while handling mgmt_index_removed this attempts to dequeue<br /> commands passed as user_data to cmd_sync.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ppp: do not assume bh is held in ppp_channel_bridge_input()<br /> <br /> Networking receive path is usually handled from BH handler.<br /> However, some protocols need to acquire the socket lock, and<br /> packets might be stored in the socket backlog is the socket was<br /> owned by a user process.<br /> <br /> In this case, release_sock(), __release_sock(), and sk_backlog_rcv()<br /> might call the sk-&gt;sk_backlog_rcv() handler in process context.<br /> <br /> sybot caught ppp was not considering this case in<br /> ppp_channel_bridge_input() :<br /> <br /> WARNING: inconsistent lock state<br /> 6.11.0-rc7-syzkaller-g5f5673607153 #0 Not tainted<br /> --------------------------------<br /> inconsistent {SOFTIRQ-ON-W} -&gt; {IN-SOFTIRQ-W} usage.<br /> ksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] takes:<br /> ffff0000db7f11e0 (&amp;pch-&gt;downl){+.?.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline]<br /> ffff0000db7f11e0 (&amp;pch-&gt;downl){+.?.}-{2:2}, at: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline]<br /> ffff0000db7f11e0 (&amp;pch-&gt;downl){+.?.}-{2:2}, at: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304<br /> {SOFTIRQ-ON-W} state was registered at:<br /> lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759<br /> __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline]<br /> _raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154<br /> spin_lock include/linux/spinlock.h:351 [inline]<br /> ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline]<br /> ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304<br /> pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379<br /> sk_backlog_rcv include/net/sock.h:1111 [inline]<br /> __release_sock+0x1a8/0x3d8 net/core/sock.c:3004<br /> release_sock+0x68/0x1b8 net/core/sock.c:3558<br /> pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg net/socket.c:745 [inline]<br /> __sys_sendto+0x374/0x4f4 net/socket.c:2204<br /> __do_sys_sendto net/socket.c:2216 [inline]<br /> __se_sys_sendto net/socket.c:2212 [inline]<br /> __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212<br /> __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]<br /> invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49<br /> el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132<br /> do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151<br /> el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712<br /> el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730<br /> el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598<br /> irq event stamp: 282914<br /> hardirqs last enabled at (282914): [] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [inline]<br /> hardirqs last enabled at (282914): [] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194<br /> hardirqs last disabled at (282913): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline]<br /> hardirqs last disabled at (282913): [] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162<br /> softirqs last enabled at (282904): [] softirq_handle_end kernel/softirq.c:400 [inline]<br /> softirqs last enabled at (282904): [] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582<br /> softirqs last disabled at (282909): [] run_ksoftirqd+0x70/0x158 kernel/softirq.c:928<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> <br /> CPU0<br /> ----<br /> lock(&amp;pch-&gt;downl);<br /> <br /> lock(&amp;pch-&gt;downl);<br /> <br /> *** DEADLOCK ***<br /> <br /> 1 lock held by ksoftirqd/1/24:<br /> #0: ffff80008f74dfa0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x10/0x4c include/linux/rcupdate.h:325<br /> <br /> stack backtrace:<br /> CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024<br /> Call trace:<br /> dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:319<br /> show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:326<br /> __dump_sta<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: add more sanity checks to qdisc_pkt_len_init()<br /> <br /> One path takes care of SKB_GSO_DODGY, assuming<br /> skb-&gt;len is bigger than hdr_len.<br /> <br /> virtio_net_hdr_to_skb() does not fully dissect TCP headers,<br /> it only make sure it is at least 20 bytes.<br /> <br /> It is possible for an user to provide a malicious &amp;#39;GSO&amp;#39; packet,<br /> total length of 80 bytes.<br /> <br /> - 20 bytes of IPv4 header<br /> - 60 bytes TCP header<br /> - a small gso_size like 8<br /> <br /> virtio_net_hdr_to_skb() would declare this packet as a normal<br /> GSO packet, because it would see 40 bytes of payload,<br /> bigger than gso_size.<br /> <br /> We need to make detect this case to not underflow<br /> qdisc_skb_cb(skb)-&gt;pkt_len.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: avoid potential underflow in qdisc_pkt_len_init() with UFO<br /> <br /> After commit 7c6d2ecbda83 ("net: be more gentle about silly gso<br /> requests coming from user") virtio_net_hdr_to_skb() had sanity check<br /> to detect malicious attempts from user space to cook a bad GSO packet.<br /> <br /> Then commit cf9acc90c80ec ("net: virtio_net_hdr_to_skb: count<br /> transport header in UFO") while fixing one issue, allowed user space<br /> to cook a GSO packet with the following characteristic :<br /> <br /> IPv4 SKB_GSO_UDP, gso_size=3, skb-&gt;len = 28.<br /> <br /> When this packet arrives in qdisc_pkt_len_init(), we end up<br /> with hdr_len = 28 (IPv4 header + UDP header), matching skb-&gt;len<br /> <br /> Then the following sets gso_segs to 0 :<br /> <br /> gso_segs = DIV_ROUND_UP(skb-&gt;len - hdr_len,<br /> shinfo-&gt;gso_size);<br /> <br /> Then later we set qdisc_skb_cb(skb)-&gt;pkt_len to back to zero :/<br /> <br /> qdisc_skb_cb(skb)-&gt;pkt_len += (gso_segs - 1) * hdr_len;<br /> <br /> This leads to the following crash in fq_codel [1]<br /> <br /> qdisc_pkt_len_init() is best effort, we only want an estimation<br /> of the bytes sent on the wire, not crashing the kernel.<br /> <br /> This patch is fixing this particular issue, a following one<br /> adds more sanity checks for another potential bug.<br /> <br /> [1]<br /> [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [ 70.724561] #PF: supervisor read access in kernel mode<br /> [ 70.724561] #PF: error_code(0x0000) - not-present page<br /> [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0<br /> [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI<br /> [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991<br /> [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel<br /> [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49<br /> All code<br /> ========<br /> 0: 24 08 and $0x8,%al<br /> 2: 49 c1 e1 06 shl $0x6,%r9<br /> 6: 44 89 7c 24 18 mov %r15d,0x18(%rsp)<br /> b: 45 31 ed xor %r13d,%r13d<br /> e: 45 31 c0 xor %r8d,%r8d<br /> 11: 31 ff xor %edi,%edi<br /> 13: 89 44 24 14 mov %eax,0x14(%rsp)<br /> 17: 4c 03 8b 90 01 00 00 add 0x190(%rbx),%r9<br /> 1e: eb 04 jmp 0x24<br /> 20: 39 ca cmp %ecx,%edx<br /> 22: 73 37 jae 0x5b<br /> 24: 4d 8b 39 mov (%r9),%r15<br /> 27: 83 c7 01 add $0x1,%edi<br /> 2a:* 49 8b 17 mov (%r15),%rdx

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: Fix uaf in l2cap_connect<br /> <br /> [Syzbot reported]<br /> BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949<br /> Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54<br /> <br /> CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024<br /> Workqueue: hci2 hci_rx_work<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:93 [inline]<br /> dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119<br /> print_address_description mm/kasan/report.c:377 [inline]<br /> print_report+0xc3/0x620 mm/kasan/report.c:488<br /> kasan_report+0xd9/0x110 mm/kasan/report.c:601<br /> l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949<br /> l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline]<br /> l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline]<br /> l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline]<br /> l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825<br /> l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514<br /> hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline]<br /> hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028<br /> process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231<br /> process_scheduled_works kernel/workqueue.c:3312 [inline]<br /> worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389<br /> kthread+0x2c1/0x3a0 kernel/kthread.c:389<br /> ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br /> ...<br /> <br /> Freed by task 5245:<br /> kasan_save_stack+0x33/0x60 mm/kasan/common.c:47<br /> kasan_save_track+0x14/0x30 mm/kasan/common.c:68<br /> kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:579<br /> poison_slab_object+0xf7/0x160 mm/kasan/common.c:240<br /> __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256<br /> kasan_slab_free include/linux/kasan.h:184 [inline]<br /> slab_free_hook mm/slub.c:2256 [inline]<br /> slab_free mm/slub.c:4477 [inline]<br /> kfree+0x12a/0x3b0 mm/slub.c:4598<br /> l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline]<br /> kref_put include/linux/kref.h:65 [inline]<br /> l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline]<br /> l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802<br /> l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241<br /> hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline]<br /> hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265<br /> hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583<br /> abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917<br /> hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328<br /> process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231<br /> process_scheduled_works kernel/workqueue.c:3312 [inline]<br /> worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389<br /> kthread+0x2c1/0x3a0 kernel/kthread.c:389<br /> ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: prevent nf_skb_duplicated corruption<br /> <br /> syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write<br /> per-cpu variable nf_skb_duplicated in an unsafe way [1].<br /> <br /> Disabling preemption as hinted by the splat is not enough,<br /> we have to disable soft interrupts as well.<br /> <br /> [1]<br /> BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316<br /> caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87<br /> CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:93 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119<br /> check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49<br /> nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87<br /> nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30<br /> expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]<br /> nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288<br /> nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23<br /> nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]<br /> nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626<br /> nf_hook+0x2c4/0x450 include/linux/netfilter.h:269<br /> NF_HOOK_COND include/linux/netfilter.h:302 [inline]<br /> ip_output+0x185/0x230 net/ipv4/ip_output.c:433<br /> ip_local_out net/ipv4/ip_output.c:129 [inline]<br /> ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495<br /> udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981<br /> udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg+0x1a6/0x270 net/socket.c:745<br /> ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597<br /> ___sys_sendmsg net/socket.c:2651 [inline]<br /> __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737<br /> __do_sys_sendmmsg net/socket.c:2766 [inline]<br /> __se_sys_sendmmsg net/socket.c:2763 [inline]<br /> __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f4ce4f7def9<br /> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133<br /> RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9<br /> RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006<br /> RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68<br />