Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: ipu6: Fix RPM reference leak in probe error paths<br /> <br /> Several error paths in ipu6_pci_probe() were jumping directly to<br /> out_ipu6_bus_del_devices without releasing the runtime PM reference.<br /> Add pm_runtime_put_sync() before cleaning up other resources.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: pci: validate release report content before using for RTL8922DE<br /> <br /> The commit 957eda596c76<br /> ("wifi: rtw89: pci: validate sequence number of TX release report")<br /> does validation on existing chips, which somehow a release report of SKB<br /> becomes malformed. As no clear cause found, add rules ahead for RTL8922DE<br /> to avoid crash if it happens.

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 /> clk: rs9: Reserve 8 struct clk_hw slots for for 9FGV0841<br /> <br /> The 9FGV0841 has 8 outputs and registers 8 struct clk_hw, make sure<br /> there are 8 slots for those newly registered clk_hw pointers, else<br /> there is going to be out of bounds write when pointers 4..7 are set<br /> into struct rs9_driver_data .clk_dif[4..7] field.<br /> <br /> Since there are other structure members past this struct clk_hw<br /> pointer array, writing to .clk_dif[4..7] fields corrupts both<br /> the struct rs9_driver_data content and data around it, sometimes<br /> without crashing the kernel. However, the kernel does surely<br /> crash when the driver is unbound or during suspend.<br /> <br /> Fix this, increase the struct clk_hw pointer array size to the<br /> maximum output count of 9FGV0841, which is the biggest chip that<br /> is supported by this driver.

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 /> 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().