Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/zcrx: fix post open error handling<br /> <br /> Closing a queue doesn&amp;#39;t guarantee that all associated page pools are<br /> terminated right away, let the refcounting do the work instead of<br /> releasing the zcrx ctx directly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: xscale: Check for PTP support properly<br /> <br /> In ixp4xx_get_ts_info() ixp46x_ptp_find() is called<br /> unconditionally despite this feature only existing on<br /> ixp46x, leading to the following splat from tcpdump:<br /> <br /> root@OpenWrt:~# tcpdump -vv -X -i eth0<br /> (...)<br /> Unable to handle kernel NULL pointer dereference at virtual address<br /> 00000238 when read<br /> (...)<br /> Call trace:<br /> ptp_clock_index from ixp46x_ptp_find+0x1c/0x38<br /> ixp46x_ptp_find from ixp4xx_get_ts_info+0x4c/0x64<br /> ixp4xx_get_ts_info from __ethtool_get_ts_info+0x90/0x108<br /> __ethtool_get_ts_info from __dev_ethtool+0xa00/0x2648<br /> __dev_ethtool from dev_ethtool+0x160/0x234<br /> dev_ethtool from dev_ioctl+0x2cc/0x460<br /> dev_ioctl from sock_ioctl+0x1ec/0x524<br /> sock_ioctl from sys_ioctl+0x51c/0xa94<br /> sys_ioctl from ret_fast_syscall+0x0/0x44<br /> (...)<br /> Segmentation fault<br /> <br /> Check for ixp46x in ixp46x_ptp_find() before trying to set up<br /> PTP to avoid this.<br /> <br /> To avoid altering the returned error code from ixp4xx_hwtstamp_set()<br /> which before this patch was -EOPNOTSUPP, we return -EOPNOTSUPP<br /> from ixp4xx_hwtstamp_set() if ixp46x_ptp_find() fails no matter<br /> the error code. The helper function ixp46x_ptp_find() helper<br /> returns -ENODEV.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: fix reflink preserve cleanup issue<br /> <br /> commit c06c303832ec ("ocfs2: fix xattr array entry __counted_by error")<br /> doesn&amp;#39;t handle all cases and the cleanup job for preserved xattr entries<br /> still has bug:<br /> - the &amp;#39;last&amp;#39; pointer should be shifted by one unit after cleanup<br /> an array entry.<br /> - current code logic doesn&amp;#39;t cleanup the first entry when xh_count is 1.<br /> <br /> Note, commit c06c303832ec is also a bug fix for 0fe9b66c65f3.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/buddy: Prevent BUG_ON by validating rounded allocation<br /> <br /> When DRM_BUDDY_CONTIGUOUS_ALLOCATION is set, the requested size is<br /> rounded up to the next power-of-two via roundup_pow_of_two().<br /> Similarly, for non-contiguous allocations with large min_block_size,<br /> the size is aligned up via round_up(). Both operations can produce a<br /> rounded size that exceeds mm-&gt;size, which later triggers<br /> BUG_ON(order &gt; mm-&gt;max_order).<br /> <br /> Example scenarios:<br /> - 9G CONTIGUOUS allocation on 10G VRAM memory:<br /> roundup_pow_of_two(9G) = 16G &gt; 10G<br /> - 9G allocation with 8G min_block_size on 10G VRAM memory:<br /> round_up(9G, 8G) = 16G &gt; 10G<br /> <br /> Fix this by checking the rounded size against mm-&gt;size. For<br /> non-contiguous or range allocations where size &gt; mm-&gt;size is invalid,<br /> return -EINVAL immediately. For contiguous allocations without range<br /> restrictions, allow the request to fall through to the existing<br /> __alloc_contig_try_harder() fallback.<br /> <br /> This ensures invalid user input returns an error or uses the fallback<br /> path instead of hitting BUG_ON.<br /> <br /> v2: (Matt A)<br /> - Add Fixes, Cc stable, and Closes tags for context

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3: gadget: Move vbus draw to workqueue context<br /> <br /> Currently dwc3_gadget_vbus_draw() can be called from atomic<br /> context, which in turn invokes power-supply-core APIs. And<br /> some these PMIC APIs have operations that may sleep, leading<br /> to kernel panic.<br /> <br /> Fix this by moving the vbus_draw into a workqueue context.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> EFI/CPER: don&amp;#39;t dump the entire memory region<br /> <br /> The current logic at cper_print_fw_err() doesn&amp;#39;t check if the<br /> error record length is big enough to handle offset. On a bad firmware,<br /> if the ofset is above the actual record, length -= offset will<br /> underflow, making it dump the entire memory.<br /> <br /> The end result can be:<br /> <br /> - the logic taking a lot of time dumping large regions of memory;<br /> - data disclosure due to the memory dumps;<br /> - an OOPS, if it tries to dump an unmapped memory region.<br /> <br /> Fix it by checking if the section length is too small before doing<br /> a hex dump.<br /> <br /> [ rjw: Subject tweaks ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: fix 22000 series SMEM parsing<br /> <br /> If the firmware were to report three LMACs (which doesn&amp;#39;t<br /> exist in hardware) then using "fwrt-&gt;smem_cfg.lmac[2]" is<br /> an overrun of the array. Reject such and use IWL_FW_CHECK<br /> instead of WARN_ON in this function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: always flush state and policy upon NETDEV_UNREGISTER event<br /> <br /> syzbot is reporting that "struct xfrm_state" refcount is leaking.<br /> <br /> unregister_netdevice: waiting for netdevsim0 to become free. Usage count = 2<br /> ref_tracker: netdev@ffff888052f24618 has 1/1 users at<br /> __netdev_tracker_alloc include/linux/netdevice.h:4400 [inline]<br /> netdev_tracker_alloc include/linux/netdevice.h:4412 [inline]<br /> xfrm_dev_state_add+0x3a5/0x1080 net/xfrm/xfrm_device.c:316<br /> xfrm_state_construct net/xfrm/xfrm_user.c:986 [inline]<br /> xfrm_add_sa+0x34ff/0x5fa0 net/xfrm/xfrm_user.c:1022<br /> xfrm_user_rcv_msg+0x58e/0xc00 net/xfrm/xfrm_user.c:3507<br /> netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2550<br /> xfrm_netlink_rcv+0x71/0x90 net/xfrm/xfrm_user.c:3529<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]<br /> netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1344<br /> netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1894<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg net/socket.c:742 [inline]<br /> ____sys_sendmsg+0xa5d/0xc30 net/socket.c:2592<br /> ___sys_sendmsg+0x134/0x1d0 net/socket.c:2646<br /> __sys_sendmsg+0x16d/0x220 net/socket.c:2678<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> This is because commit d77e38e612a0 ("xfrm: Add an IPsec hardware<br /> offloading API") implemented xfrm_dev_unregister() as no-op despite<br /> xfrm_dev_state_add() from xfrm_state_construct() acquires a reference<br /> to "struct net_device".<br /> I guess that that commit expected that NETDEV_DOWN event is fired before<br /> NETDEV_UNREGISTER event fires, and also assumed that xfrm_dev_state_add()<br /> is called only if (dev-&gt;features &amp; NETIF_F_HW_ESP) != 0.<br /> <br /> Sabrina Dubroca identified steps to reproduce the same symptoms as below.<br /> <br /> echo 0 &gt; /sys/bus/netdevsim/new_device<br /> dev=$(ls -1 /sys/bus/netdevsim/devices/netdevsim0/net/)<br /> ip xfrm state add src 192.168.13.1 dst 192.168.13.2 proto esp \<br /> spi 0x1000 mode tunnel aead &amp;#39;rfc4106(gcm(aes))&amp;#39; $key 128 \<br /> offload crypto dev $dev dir out<br /> ethtool -K $dev esp-hw-offload off<br /> echo 0 &gt; /sys/bus/netdevsim/del_device<br /> <br /> Like these steps indicate, the NETIF_F_HW_ESP bit can be cleared after<br /> xfrm_dev_state_add() acquired a reference to "struct net_device".<br /> Also, xfrm_dev_state_add() does not check for the NETIF_F_HW_ESP bit<br /> when acquiring a reference to "struct net_device".<br /> <br /> Commit 03891f820c21 ("xfrm: handle NETDEV_UNREGISTER for xfrm device")<br /> re-introduced the NETDEV_UNREGISTER event to xfrm_dev_event(), but that<br /> commit for unknown reason chose to share xfrm_dev_down() between the<br /> NETDEV_DOWN event and the NETDEV_UNREGISTER event.<br /> I guess that that commit missed the behavior in the previous paragraph.<br /> <br /> Therefore, we need to re-introduce xfrm_dev_unregister() in order to<br /> release the reference to "struct net_device" by unconditionally flushing<br /> state and policy.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: fix interlaced plain identification for encoded extents<br /> <br /> Only plain data whose start position and on-disk physical length are<br /> both aligned to the block size should be classified as interlaced<br /> plain extents. Otherwise, it must be treated as shifted plain extents.<br /> <br /> This issue was found by syzbot using a crafted compressed image<br /> containing plain extents with unaligned physical lengths, which can<br /> cause OOB read in z_erofs_transform_plain().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udplite: Fix null-ptr-deref in __udp_enqueue_schedule_skb().<br /> <br /> syzbot reported null-ptr-deref of udp_sk(sk)-&gt;udp_prod_queue. [0]<br /> <br /> Since the cited commit, udp_lib_init_sock() can fail, as can<br /> udp_init_sock() and udpv6_init_sock().<br /> <br /> Let&amp;#39;s handle the error in udplite_sk_init() and udplitev6_sk_init().<br /> <br /> [0]:<br /> BUG: KASAN: null-ptr-deref in instrument_atomic_read include/linux/instrumented.h:82 [inline]<br /> BUG: KASAN: null-ptr-deref in atomic_read include/linux/atomic/atomic-instrumented.h:32 [inline]<br /> BUG: KASAN: null-ptr-deref in __udp_enqueue_schedule_skb+0x151/0x1480 net/ipv4/udp.c:1719<br /> Read of size 4 at addr 0000000000000008 by task syz.2.18/2944<br /> <br /> CPU: 1 UID: 0 PID: 2944 Comm: syz.2.18 Not tainted syzkaller #0 PREEMPTLAZY<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120<br /> kasan_report+0xa2/0xe0 mm/kasan/report.c:595<br /> check_region_inline mm/kasan/generic.c:-1 [inline]<br /> kasan_check_range+0x264/0x2c0 mm/kasan/generic.c:200<br /> instrument_atomic_read include/linux/instrumented.h:82 [inline]<br /> atomic_read include/linux/atomic/atomic-instrumented.h:32 [inline]<br /> __udp_enqueue_schedule_skb+0x151/0x1480 net/ipv4/udp.c:1719<br /> __udpv6_queue_rcv_skb net/ipv6/udp.c:795 [inline]<br /> udpv6_queue_rcv_one_skb+0xa2e/0x1ad0 net/ipv6/udp.c:906<br /> udp6_unicast_rcv_skb+0x227/0x380 net/ipv6/udp.c:1064<br /> ip6_protocol_deliver_rcu+0xe17/0x1540 net/ipv6/ip6_input.c:438<br /> ip6_input_finish+0x191/0x350 net/ipv6/ip6_input.c:489<br /> NF_HOOK+0x354/0x3f0 include/linux/netfilter.h:318<br /> ip6_input+0x16c/0x2b0 net/ipv6/ip6_input.c:500<br /> NF_HOOK+0x354/0x3f0 include/linux/netfilter.h:318<br /> __netif_receive_skb_one_core net/core/dev.c:6149 [inline]<br /> __netif_receive_skb+0xd3/0x370 net/core/dev.c:6262<br /> process_backlog+0x4d6/0x1160 net/core/dev.c:6614<br /> __napi_poll+0xae/0x320 net/core/dev.c:7678<br /> napi_poll net/core/dev.c:7741 [inline]<br /> net_rx_action+0x60d/0xdc0 net/core/dev.c:7893<br /> handle_softirqs+0x209/0x8d0 kernel/softirq.c:622<br /> do_softirq+0x52/0x90 kernel/softirq.c:523<br /> <br /> <br /> __local_bh_enable_ip+0xe7/0x120 kernel/softirq.c:450<br /> local_bh_enable include/linux/bottom_half.h:33 [inline]<br /> rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline]<br /> __dev_queue_xmit+0x109c/0x2dc0 net/core/dev.c:4856<br /> __ip6_finish_output net/ipv6/ip6_output.c:-1 [inline]<br /> ip6_finish_output+0x158/0x4e0 net/ipv6/ip6_output.c:219<br /> NF_HOOK_COND include/linux/netfilter.h:307 [inline]<br /> ip6_output+0x342/0x580 net/ipv6/ip6_output.c:246<br /> ip6_send_skb+0x1d7/0x3c0 net/ipv6/ip6_output.c:1984<br /> udp_v6_send_skb+0x9a5/0x1770 net/ipv6/udp.c:1442<br /> udp_v6_push_pending_frames+0xa2/0x140 net/ipv6/udp.c:1469<br /> udpv6_sendmsg+0xfe0/0x2830 net/ipv6/udp.c:1759<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg+0xe5/0x270 net/socket.c:742<br /> __sys_sendto+0x3eb/0x580 net/socket.c:2206<br /> __do_sys_sendto net/socket.c:2213 [inline]<br /> __se_sys_sendto net/socket.c:2209 [inline]<br /> __x64_sys_sendto+0xde/0x100 net/socket.c:2209<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xd2/0xf20 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7f67b4d9c629<br /> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 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 e8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f67b5c98028 EFLAGS: 00000246 ORIG_RAX: 000000000000002c<br /> RAX: ffffffffffffffda RBX: 00007f67b5015fa0 RCX: 00007f67b4d9c629<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003<br /> RBP: 00007f67b4e32b39 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000040000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007f67b5016038 R14: 00007f67b5015fa0 R15: 00007ffe3cb66dd8<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/bitmap: fix GPF in write_page caused by resize race<br /> <br /> A General Protection Fault occurs in write_page() during array resize:<br /> RIP: 0010:write_page+0x22b/0x3c0 [md_mod]<br /> <br /> This is a use-after-free race between bitmap_daemon_work() and<br /> __bitmap_resize(). The daemon iterates over `bitmap-&gt;storage.filemap`<br /> without locking, while the resize path frees that storage via<br /> md_bitmap_file_unmap(). `quiesce()` does not stop the md thread,<br /> allowing concurrent access to freed pages.<br /> <br /> Fix by holding `mddev-&gt;bitmap_info.mutex` during the bitmap update.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: tegra-video: Fix memory leak in __tegra_channel_try_format()<br /> <br /> The state object allocated by __v4l2_subdev_state_alloc() must be freed<br /> with __v4l2_subdev_state_free() when it is no longer needed.<br /> <br /> In __tegra_channel_try_format(), two error paths return directly after<br /> v4l2_subdev_call() fails, without freeing the allocated &amp;#39;sd_state&amp;#39;<br /> object. This violates the requirement and causes a memory leak.<br /> <br /> Fix this by introducing a cleanup label and using goto statements in the<br /> error paths to ensure that __v4l2_subdev_state_free() is always called<br /> before the function returns.