Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: xt_nfacct: don&amp;#39;t assume acct name is null-terminated<br /> <br /> BUG: KASAN: slab-out-of-bounds in .. lib/vsprintf.c:721<br /> Read of size 1 at addr ffff88801eac95c8 by task syz-executor183/5851<br /> [..]<br /> string+0x231/0x2b0 lib/vsprintf.c:721<br /> vsnprintf+0x739/0xf00 lib/vsprintf.c:2874<br /> [..]<br /> nfacct_mt_checkentry+0xd2/0xe0 net/netfilter/xt_nfacct.c:41<br /> xt_check_match+0x3d1/0xab0 net/netfilter/x_tables.c:523<br /> <br /> nfnl_acct_find_get() handles non-null input, but the error<br /> printk relied on its presence.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: davinci: Add NULL check in davinci_lpsc_clk_register()<br /> <br /> devm_kasprintf() returns NULL when memory allocation fails. Currently,<br /> davinci_lpsc_clk_register() does not check for this case, which results<br /> in a NULL pointer dereference.<br /> <br /> Add NULL check after devm_kasprintf() to prevent this issue and ensuring<br /> no resources are left allocated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: cpcap-charger: Fix null check for power_supply_get_by_name<br /> <br /> In the cpcap_usb_detect() function, the power_supply_get_by_name()<br /> function may return `NULL` instead of an error pointer.<br /> To prevent potential null pointer dereferences, Added a null check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio/pds: Fix missing detach_ioas op<br /> <br /> When CONFIG_IOMMUFD is enabled and a device is bound to the pds_vfio_pci<br /> driver, the following WARN_ON() trace is seen and probe fails:<br /> <br /> WARNING: CPU: 0 PID: 5040 at drivers/vfio/vfio_main.c:317 __vfio_register_dev+0x130/0x140 [vfio]<br /> <br /> pds_vfio_pci 0000:08:00.1: probe with driver pds_vfio_pci failed with error -22<br /> <br /> This is because the driver&amp;#39;s vfio_device_ops.detach_ioas isn&amp;#39;t set.<br /> <br /> Fix this by using the generic vfio_iommufd_physical_detach_ioas<br /> function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to trigger foreground gc during f2fs_map_blocks() in lfs mode<br /> <br /> w/ "mode=lfs" mount option, generic/299 will cause system panic as below:<br /> <br /> ------------[ cut here ]------------<br /> kernel BUG at fs/f2fs/segment.c:2835!<br /> Call Trace:<br /> <br /> f2fs_allocate_data_block+0x6f4/0xc50<br /> f2fs_map_blocks+0x970/0x1550<br /> f2fs_iomap_begin+0xb2/0x1e0<br /> iomap_iter+0x1d6/0x430<br /> __iomap_dio_rw+0x208/0x9a0<br /> f2fs_file_write_iter+0x6b3/0xfa0<br /> aio_write+0x15d/0x2e0<br /> io_submit_one+0x55e/0xab0<br /> __x64_sys_io_submit+0xa5/0x230<br /> do_syscall_64+0x84/0x2f0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0010:new_curseg+0x70f/0x720<br /> <br /> The root cause of we run out-of-space is: in f2fs_map_blocks(), f2fs may<br /> trigger foreground gc only if it allocates any physical block, it will be<br /> a little bit later when there is multiple threads writing data w/<br /> aio/dio/bufio method in parallel, since we always use OPU in lfs mode, so<br /> f2fs_map_blocks() does block allocations aggressively.<br /> <br /> In order to fix this issue, let&amp;#39;s give a chance to trigger foreground<br /> gc in prior to block allocation in f2fs_map_blocks().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vdpa/mlx5: Fix release of uninitialized resources on error path<br /> <br /> The commit in the fixes tag made sure that mlx5_vdpa_free()<br /> is the single entrypoint for removing the vdpa device resources<br /> added in mlx5_vdpa_dev_add(), even in the cleanup path of<br /> mlx5_vdpa_dev_add().<br /> <br /> This means that all functions from mlx5_vdpa_free() should be able to<br /> handle uninitialized resources. This was not the case though:<br /> mlx5_vdpa_destroy_mr_resources() and mlx5_cmd_cleanup_async_ctx()<br /> were not able to do so. This caused the splat below when adding<br /> a vdpa device without a MAC address.<br /> <br /> This patch fixes these remaining issues:<br /> <br /> - Makes mlx5_vdpa_destroy_mr_resources() return early if called on<br /> uninitialized resources.<br /> <br /> - Moves mlx5_cmd_init_async_ctx() early on during device addition<br /> because it can&amp;#39;t fail. This means that mlx5_cmd_cleanup_async_ctx()<br /> also can&amp;#39;t fail. To mirror this, move the call site of<br /> mlx5_cmd_cleanup_async_ctx() in mlx5_vdpa_free().<br /> <br /> An additional comment was added in mlx5_vdpa_free() to document<br /> the expectations of functions called from this context.<br /> <br /> Splat:<br /> <br /> mlx5_core 0000:b5:03.2: mlx5_vdpa_dev_add:3950:(pid 2306) warning: No mac address provisioned?<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 13 PID: 2306 at kernel/workqueue.c:4207 __flush_work+0x9a/0xb0<br /> [...]<br /> Call Trace:<br /> <br /> ? __try_to_del_timer_sync+0x61/0x90<br /> ? __timer_delete_sync+0x2b/0x40<br /> mlx5_vdpa_destroy_mr_resources+0x1c/0x40 [mlx5_vdpa]<br /> mlx5_vdpa_free+0x45/0x160 [mlx5_vdpa]<br /> vdpa_release_dev+0x1e/0x50 [vdpa]<br /> device_release+0x31/0x90<br /> kobject_cleanup+0x37/0x130<br /> mlx5_vdpa_dev_add+0x327/0x890 [mlx5_vdpa]<br /> vdpa_nl_cmd_dev_add_set_doit+0x2c1/0x4d0 [vdpa]<br /> genl_family_rcv_msg_doit+0xd8/0x130<br /> genl_family_rcv_msg+0x14b/0x220<br /> ? __pfx_vdpa_nl_cmd_dev_add_set_doit+0x10/0x10 [vdpa]<br /> genl_rcv_msg+0x47/0xa0<br /> ? __pfx_genl_rcv_msg+0x10/0x10<br /> netlink_rcv_skb+0x53/0x100<br /> genl_rcv+0x24/0x40<br /> netlink_unicast+0x27b/0x3b0<br /> netlink_sendmsg+0x1f7/0x430<br /> __sys_sendto+0x1fa/0x210<br /> ? ___pte_offset_map+0x17/0x160<br /> ? next_uptodate_folio+0x85/0x2b0<br /> ? percpu_counter_add_batch+0x51/0x90<br /> ? filemap_map_pages+0x515/0x660<br /> __x64_sys_sendto+0x20/0x30<br /> do_syscall_64+0x7b/0x2c0<br /> ? do_read_fault+0x108/0x220<br /> ? do_pte_missing+0x14a/0x3e0<br /> ? __handle_mm_fault+0x321/0x730<br /> ? count_memcg_events+0x13f/0x180<br /> ? handle_mm_fault+0x1fb/0x2d0<br /> ? do_user_addr_fault+0x20c/0x700<br /> ? syscall_exit_work+0x104/0x140<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7f0c25b0feca<br /> [...]<br /> ---[ end trace 0000000000000000 ]---