Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfsplus: remove mutex_lock check in hfsplus_free_extents<br /> <br /> Syzbot reported an issue in hfsplus filesystem:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 4400 at fs/hfsplus/extents.c:346<br /> hfsplus_free_extents+0x700/0xad0<br /> Call Trace:<br /> <br /> hfsplus_file_truncate+0x768/0xbb0 fs/hfsplus/extents.c:606<br /> hfsplus_write_begin+0xc2/0xd0 fs/hfsplus/inode.c:56<br /> cont_expand_zero fs/buffer.c:2383 [inline]<br /> cont_write_begin+0x2cf/0x860 fs/buffer.c:2446<br /> hfsplus_write_begin+0x86/0xd0 fs/hfsplus/inode.c:52<br /> generic_cont_expand_simple+0x151/0x250 fs/buffer.c:2347<br /> hfsplus_setattr+0x168/0x280 fs/hfsplus/inode.c:263<br /> notify_change+0xe38/0x10f0 fs/attr.c:420<br /> do_truncate+0x1fb/0x2e0 fs/open.c:65<br /> do_sys_ftruncate+0x2eb/0x380 fs/open.c:193<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> To avoid deadlock, Commit 31651c607151 ("hfsplus: avoid deadlock<br /> on file truncation") unlock extree before hfsplus_free_extents(),<br /> and add check wheather extree is locked in hfsplus_free_extents().<br /> <br /> However, when operations such as hfsplus_file_release,<br /> hfsplus_setattr, hfsplus_unlink, and hfsplus_get_block are executed<br /> concurrently in different files, it is very likely to trigger the<br /> WARN_ON, which will lead syzbot and xfstest to consider it as an<br /> abnormality.<br /> <br /> The comment above this warning also describes one of the easy<br /> triggering situations, which can easily trigger and cause<br /> xfstest&amp;syzbot to report errors.<br /> <br /> [task A] [task B]<br /> -&gt;hfsplus_file_release<br /> -&gt;hfsplus_file_truncate<br /> -&gt;hfs_find_init<br /> -&gt;mutex_lock<br /> -&gt;mutex_unlock<br /> -&gt;hfsplus_write_begin<br /> -&gt;hfsplus_get_block<br /> -&gt;hfsplus_file_extend<br /> -&gt;hfsplus_ext_read_extent<br /> -&gt;hfs_find_init<br /> -&gt;mutex_lock<br /> -&gt;hfsplus_free_extents<br /> WARN_ON(mutex_is_locked) !!!<br /> <br /> Several threads could try to lock the shared extents tree.<br /> And warning can be triggered in one thread when another thread<br /> has locked the tree. This is the wrong behavior of the code and<br /> we need to remove the warning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Disable migration in nf_hook_run_bpf().<br /> <br /> syzbot reported that the netfilter bpf prog can be called without<br /> migration disabled in xmit path.<br /> <br /> Then the assertion in __bpf_prog_run() fails, triggering the splat<br /> below. [0]<br /> <br /> Let&amp;#39;s use bpf_prog_run_pin_on_cpu() in nf_hook_run_bpf().<br /> <br /> [0]:<br /> BUG: assuming non migratable context at ./include/linux/filter.h:703<br /> in_atomic(): 0, irqs_disabled(): 0, migration_disabled() 0 pid: 5829, name: sshd-session<br /> 3 locks held by sshd-session/5829:<br /> #0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1667 [inline]<br /> #0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x20/0x50 net/ipv4/tcp.c:1395<br /> #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline]<br /> #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline]<br /> #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: __ip_queue_xmit+0x69/0x26c0 net/ipv4/ip_output.c:470<br /> #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline]<br /> #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline]<br /> #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: nf_hook+0xb2/0x680 include/linux/netfilter.h:241<br /> CPU: 0 UID: 0 PID: 5829 Comm: sshd-session Not tainted 6.16.0-rc6-syzkaller-00002-g155a3c003e55 #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120<br /> __cant_migrate kernel/sched/core.c:8860 [inline]<br /> __cant_migrate+0x1c7/0x250 kernel/sched/core.c:8834<br /> __bpf_prog_run include/linux/filter.h:703 [inline]<br /> bpf_prog_run include/linux/filter.h:725 [inline]<br /> nf_hook_run_bpf+0x83/0x1e0 net/netfilter/nf_bpf_link.c:20<br /> nf_hook_entry_hookfn include/linux/netfilter.h:157 [inline]<br /> nf_hook_slow+0xbb/0x200 net/netfilter/core.c:623<br /> nf_hook+0x370/0x680 include/linux/netfilter.h:272<br /> NF_HOOK_COND include/linux/netfilter.h:305 [inline]<br /> ip_output+0x1bc/0x2a0 net/ipv4/ip_output.c:433<br /> dst_output include/net/dst.h:459 [inline]<br /> ip_local_out net/ipv4/ip_output.c:129 [inline]<br /> __ip_queue_xmit+0x1d7d/0x26c0 net/ipv4/ip_output.c:527<br /> __tcp_transmit_skb+0x2686/0x3e90 net/ipv4/tcp_output.c:1479<br /> tcp_transmit_skb net/ipv4/tcp_output.c:1497 [inline]<br /> tcp_write_xmit+0x1274/0x84e0 net/ipv4/tcp_output.c:2838<br /> __tcp_push_pending_frames+0xaf/0x390 net/ipv4/tcp_output.c:3021<br /> tcp_push+0x225/0x700 net/ipv4/tcp.c:759<br /> tcp_sendmsg_locked+0x1870/0x42b0 net/ipv4/tcp.c:1359<br /> tcp_sendmsg+0x2e/0x50 net/ipv4/tcp.c:1396<br /> inet_sendmsg+0xb9/0x140 net/ipv4/af_inet.c:851<br /> sock_sendmsg_nosec net/socket.c:712 [inline]<br /> __sock_sendmsg net/socket.c:727 [inline]<br /> sock_write_iter+0x4aa/0x5b0 net/socket.c:1131<br /> new_sync_write fs/read_write.c:593 [inline]<br /> vfs_write+0x6c7/0x1150 fs/read_write.c:686<br /> ksys_write+0x1f8/0x250 fs/read_write.c:738<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7fe7d365d407<br /> Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff<br /> RSP:

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btusb: Fix potential NULL dereference on kmalloc failure<br /> <br /> Avoid potential NULL pointer dereference by checking the return value of<br /> kmalloc and handling allocation failure properly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: fix WARN_ON for monitor mode on some devices<br /> <br /> On devices without WANT_MONITOR_VIF (and probably without<br /> channel context support) we get a WARN_ON for changing the<br /> per-link setting of a monitor interface.<br /> <br /> Since we already skip AP_VLAN interfaces and MONITOR with<br /> WANT_MONITOR_VIF and/or NO_VIRTUAL_MONITOR should update<br /> the settings, catch this in the link change code instead<br /> of the warning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: avoid NULL dereference when RX problematic packet on unsupported 6 GHz band<br /> <br /> With a quite rare chance, RX report might be problematic to make SW think<br /> a packet is received on 6 GHz band even if the chip does not support 6 GHz<br /> band actually. Since SW won&amp;#39;t initialize stuffs for unsupported bands, NULL<br /> dereference will happen then in the sequence, rtw89_vif_rx_stats_iter() -&gt;<br /> rtw89_core_cancel_6ghz_probe_tx(). So, add a check to avoid it.<br /> <br /> The following is a crash log for this case.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000032<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 1 PID: 1907 Comm: irq/131-rtw89_p Tainted: G U 6.6.56-05896-g89f5fb0eb30b #1 (HASH:1400 4)<br /> Hardware name: Google Telith/Telith, BIOS Google_Telith.15217.747.0 11/12/2024<br /> RIP: 0010:rtw89_vif_rx_stats_iter+0xd2/0x310 [rtw89_core]<br /> Code: 4c 89 7d c8 48 89 55 c0 49 8d 44 24 02 48 89 45 b8 45 31 ff eb 11<br /> 41 c6 45 3a 01 41 b7 01 4d 8b 6d 00 4d 39 f5 74 42 8b 43 10 33 45<br /> 32 0f b7 4b 14 66 41 33 4d 36 0f b7 c9 09 c1 74 d8 4d 85<br /> RSP: 0018:ffff9f3080138ca0 EFLAGS: 00010246<br /> RAX: 00000000b8bf5770 RBX: ffff91b5e8c639c0 RCX: 0000000000000011<br /> RDX: ffff91b582de1be8 RSI: 0000000000000000 RDI: ffff91b5e8c639e6<br /> RBP: ffff9f3080138d00 R08: 0000000000000000 R09: 0000000000000000<br /> R10: ffff91b59de70000 R11: ffffffffc069be50 R12: ffff91b5e8c639e4<br /> R13: 0000000000000000 R14: ffff91b5828020b8 R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffff91b8efa40000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000032 CR3: 00000002bf838000 CR4: 0000000000750ee0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __die_body+0x68/0xb0<br /> ? page_fault_oops+0x379/0x3e0<br /> ? exc_page_fault+0x4f/0xa0<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? __pfx_rtw89_vif_rx_stats_iter+0x10/0x10 [rtw89_core (HASH:1400 5)]<br /> ? rtw89_vif_rx_stats_iter+0xd2/0x310 [rtw89_core (HASH:1400 5)]<br /> __iterate_interfaces+0x59/0x110 [mac80211 (HASH:1400 6)]<br /> ? __pfx_rtw89_vif_rx_stats_iter+0x10/0x10 [rtw89_core (HASH:1400 5)]<br /> ? __pfx_rtw89_vif_rx_stats_iter+0x10/0x10 [rtw89_core (HASH:1400 5)]<br /> ieee80211_iterate_active_interfaces_atomic+0x36/0x50 [mac80211 (HASH:1400 6)]<br /> rtw89_core_rx_to_mac80211+0xfd/0x1b0 [rtw89_core (HASH:1400 5)]<br /> rtw89_core_rx+0x43a/0x980 [rtw89_core (HASH:1400 5)]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac()<br /> <br /> Callers of wdev_chandef() must hold the wiphy mutex.<br /> <br /> But the worker cfg80211_propagate_cac_done_wk() never takes the lock.<br /> Which triggers the warning below with the mesh_peer_connected_dfs<br /> test from hostapd and not (yet) released mac80211 code changes:<br /> <br /> WARNING: CPU: 0 PID: 495 at net/wireless/chan.c:1552 wdev_chandef+0x60/0x165<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 495 Comm: kworker/u4:2 Not tainted 6.14.0-rc5-wt-g03960e6f9d47 #33 13c287eeabfe1efea01c0bcc863723ab082e17cf<br /> Workqueue: cfg80211 cfg80211_propagate_cac_done_wk<br /> Stack:<br /> 00000000 00000001 ffffff00 6093267c<br /> 00000000 6002ec30 6d577c50 60037608<br /> 00000000 67e8d108 6063717b 00000000<br /> Call Trace:<br /> [] ? _printk+0x0/0x98<br /> [] show_stack+0x10e/0x11a<br /> [] ? _printk+0x0/0x98<br /> [] dump_stack_lvl+0x71/0xb8<br /> [] ? wdev_chandef+0x60/0x165<br /> [] dump_stack+0x1e/0x20<br /> [] __warn+0x101/0x20f<br /> [] warn_slowpath_fmt+0xe3/0x15d<br /> [] ? mark_lock.part.0+0x0/0x4ec<br /> [] ? __this_cpu_preempt_check+0x0/0x16<br /> [] ? mark_held_locks+0x5a/0x6e<br /> [] ? warn_slowpath_fmt+0x0/0x15d<br /> [] ? unblock_signals+0x3a/0xe7<br /> [] ? um_set_signals+0x2d/0x43<br /> [] ? __this_cpu_preempt_check+0x0/0x16<br /> [] ? lock_is_held_type+0x207/0x21f<br /> [] wdev_chandef+0x60/0x165<br /> [] regulatory_propagate_dfs_state+0x247/0x43f<br /> [] ? um_set_signals+0x0/0x43<br /> [] cfg80211_propagate_cac_done_wk+0x3a/0x4a<br /> [] process_scheduled_works+0x3bc/0x60e<br /> [] ? move_linked_works+0x4d/0x81<br /> [] ? assign_work+0x0/0xaa<br /> [] worker_thread+0x220/0x2dc<br /> [] ? set_pf_worker+0x0/0x57<br /> [] ? to_kthread+0x0/0x43<br /> [] kthread+0x2d3/0x2e2<br /> [] ? worker_thread+0x0/0x2dc<br /> [] ? calculate_sigpending+0x0/0x56<br /> [] new_thread_handler+0x4a/0x64<br /> irq event stamp: 614611<br /> hardirqs last enabled at (614621): [] __up_console_sem+0x82/0xaf<br /> hardirqs last disabled at (614630): [] __up_console_sem+0x43/0xaf<br /> softirqs last enabled at (614268): [] __ieee80211_wake_queue+0x933/0x985<br /> softirqs last disabled at (614266): [] __ieee80211_wake_queue+0x643/0x985

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: reject TDLS operations when station is not associated<br /> <br /> syzbot triggered a WARN in ieee80211_tdls_oper() by sending<br /> NL80211_TDLS_ENABLE_LINK immediately after NL80211_CMD_CONNECT,<br /> before association completed and without prior TDLS setup.<br /> <br /> This left internal state like sdata-&gt;u.mgd.tdls_peer uninitialized,<br /> leading to a WARN_ON() in code paths that assumed it was valid.<br /> <br /> Reject the operation early if not in station mode or not associated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Check device memory pointer before usage<br /> <br /> Add a NULL check before accessing device memory to prevent a crash if<br /> dev-&gt;dm allocation in mlx5_init_once() fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: add a retry logic in net6_rt_notify()<br /> <br /> inet6_rt_notify() can be called under RCU protection only.<br /> This means the route could be changed concurrently<br /> and rt6_fill_node() could return -EMSGSIZE.<br /> <br /> Re-size the skb when this happens and retry, removing<br /> one WARN_ON() that syzbot was able to trigger:<br /> <br /> WARNING: CPU: 3 PID: 6291 at net/ipv6/route.c:6342 inet6_rt_notify+0x475/0x4b0 net/ipv6/route.c:6342<br /> Modules linked in:<br /> CPU: 3 UID: 0 PID: 6291 Comm: syz.0.77 Not tainted 6.16.0-rc7-syzkaller #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> RIP: 0010:inet6_rt_notify+0x475/0x4b0 net/ipv6/route.c:6342<br /> Code: fc ff ff e8 6d 52 ea f7 e9 47 fc ff ff 48 8b 7c 24 08 4c 89 04 24 e8 5a 52 ea f7 4c 8b 04 24 e9 94 fd ff ff e8 9c fe 84 f7 90 0b 90 e9 bd fd ff ff e8 6e 52 ea f7 e9 bb fb ff ff 48 89 df e8<br /> RSP: 0018:ffffc900035cf1d8 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: ffffc900035cf540 RCX: ffffffff8a36e790<br /> RDX: ffff88802f7e8000 RSI: ffffffff8a36e9d4 RDI: 0000000000000005<br /> RBP: ffff88803c230f00 R08: 0000000000000005 R09: 00000000ffffffa6<br /> R10: 00000000ffffffa6 R11: 0000000000000001 R12: 00000000ffffffa6<br /> R13: 0000000000000900 R14: ffff888032ea4100 R15: 0000000000000000<br /> FS: 00007fac7b89a6c0(0000) GS:ffff8880d6a20000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fac7b899f98 CR3: 0000000034b3f000 CR4: 0000000000352ef0<br /> Call Trace:<br /> <br /> ip6_route_mpath_notify+0xde/0x280 net/ipv6/route.c:5356<br /> ip6_route_multipath_add+0x1181/0x1bd0 net/ipv6/route.c:5536<br /> inet6_rtm_newroute+0xe4/0x1a0 net/ipv6/route.c:5647<br /> rtnetlink_rcv_msg+0x95e/0xe90 net/core/rtnetlink.c:6944<br /> netlink_rcv_skb+0x155/0x420 net/netlink/af_netlink.c:2552<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]<br /> netlink_unicast+0x58d/0x850 net/netlink/af_netlink.c:1346<br /> netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1896<br /> sock_sendmsg_nosec net/socket.c:712 [inline]<br /> __sock_sendmsg net/socket.c:727 [inline]<br /> ____sys_sendmsg+0xa95/0xc70 net/socket.c:2566<br /> ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinmux: fix race causing mux_owner NULL with active mux_usecount<br /> <br /> commit 5a3e85c3c397 ("pinmux: Use sequential access to access<br /> desc-&gt;pinmux data") tried to address the issue when two client of the<br /> same gpio calls pinctrl_select_state() for the same functionality, was<br /> resulting in NULL pointer issue while accessing desc-&gt;mux_owner.<br /> However, issue was not completely fixed due to the way it was handled<br /> and it can still result in the same NULL pointer.<br /> <br /> The issue occurs due to the following interleaving:<br /> <br /> cpu0 (process A) cpu1 (process B)<br /> <br /> pin_request() { pin_free() {<br /> <br /> mutex_lock()<br /> desc-&gt;mux_usecount--; //becomes 0<br /> ..<br /> mutex_unlock()<br /> <br /> mutex_lock(desc-&gt;mux)<br /> desc-&gt;mux_usecount++; // becomes 1<br /> desc-&gt;mux_owner = owner;<br /> mutex_unlock(desc-&gt;mux)<br /> <br /> mutex_lock(desc-&gt;mux)<br /> desc-&gt;mux_owner = NULL;<br /> mutex_unlock(desc-&gt;mux)<br /> <br /> This sequence leads to a state where the pin appears to be in use<br /> (`mux_usecount == 1`) but has no owner (`mux_owner == NULL`), which can<br /> cause NULL pointer on next pin_request on the same pin.<br /> <br /> Ensure that updates to mux_usecount and mux_owner are performed<br /> atomically under the same lock. Only clear mux_owner when mux_usecount<br /> reaches zero and no new owner has been assigned.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: spacemit: mark K1 pll1_d8 as critical<br /> <br /> The pll1_d8 clock is enabled by the boot loader, and is ultimately a<br /> parent for numerous clocks, including those used by APB and AXI buses.<br /> Guodong Xu discovered that this clock got disabled while responding to<br /> getting -EPROBE_DEFER when requesting a reset controller.<br /> <br /> The needed clock (CLK_DMA, along with its parents) had already been<br /> enabled. To respond to the probe deferral return, the CLK_DMA clock<br /> was disabled, and this led to parent clocks also reducing their enable<br /> count. When the enable count for pll1_d8 was decremented it became 0,<br /> which caused it to be disabled. This led to a system hang.<br /> <br /> Marking that clock critical resolves this by preventing it from being<br /> disabled.<br /> <br /> Define a new macro CCU_FACTOR_GATE_DEFINE() to allow clock flags to<br /> be supplied for a CCU_FACTOR_GATE clock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rv: Use strings in da monitors tracepoints<br /> <br /> Using DA monitors tracepoints with KASAN enabled triggers the following<br /> warning:<br /> <br /> BUG: KASAN: global-out-of-bounds in do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0<br /> Read of size 32 at addr ffffffffaada8980 by task ...<br /> Call Trace:<br /> <br /> [...]<br /> do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0<br /> ? __pfx_do_trace_event_raw_event_event_da_monitor+0x10/0x10<br /> ? trace_event_sncid+0x83/0x200<br /> trace_event_sncid+0x163/0x200<br /> [...]<br /> The buggy address belongs to the variable:<br /> automaton_snep+0x4e0/0x5e0<br /> <br /> This is caused by the tracepoints reading 32 bytes __array instead of<br /> __string from the automata definition. Such strings are literals and<br /> reading 32 bytes ends up in out of bound memory accesses (e.g. the next<br /> automaton&amp;#39;s data in this case).<br /> The error is harmless as, while printing the string, we stop at the null<br /> terminator, but it should still be fixed.<br /> <br /> Use the __string facilities while defining the tracepoints to avoid<br /> reading out of bound memory.