Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_set_pipapo: prevent overflow in lookup table allocation<br /> <br /> When calculating the lookup table size, ensure the following<br /> multiplication does not overflow:<br /> <br /> - desc-&gt;field_len[] maximum value is U8_MAX multiplied by<br /> NFT_PIPAPO_GROUPS_PER_BYTE(f) that can be 2, worst case.<br /> - NFT_PIPAPO_BUCKETS(f-&gt;bb) is 2^8, worst case.<br /> - sizeof(unsigned long), from sizeof(*f-&gt;lt), lt in<br /> struct nft_pipapo_field.<br /> <br /> Then, use check_mul_overflow() to multiply by bucket size and then use<br /> check_add_overflow() to the alignment for avx2 (if needed). Finally, add<br /> lt_size_check_overflow() helper and use it to consolidate this.<br /> <br /> While at it, replace leftover allocation using the GFP_KERNEL to<br /> GFP_KERNEL_ACCOUNT for consistency, in pipapo_resize().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: zone: fix to avoid inconsistence in between SIT and SSA<br /> <br /> w/ below testcase, it will cause inconsistence in between SIT and SSA.<br /> <br /> create_null_blk 512 2 1024 1024<br /> mkfs.f2fs -m /dev/nullb0<br /> mount /dev/nullb0 /mnt/f2fs/<br /> touch /mnt/f2fs/file<br /> f2fs_io pinfile set /mnt/f2fs/file<br /> fallocate -l 4GiB /mnt/f2fs/file<br /> <br /> F2FS-fs (nullb0): Inconsistent segment (0) type [1, 0] in SSA and SIT<br /> CPU: 5 UID: 0 PID: 2398 Comm: fallocate Tainted: G O 6.13.0-rc1 #84<br /> Tainted: [O]=OOT_MODULE<br /> Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xb3/0xd0<br /> dump_stack+0x14/0x20<br /> f2fs_handle_critical_error+0x18c/0x220 [f2fs]<br /> f2fs_stop_checkpoint+0x38/0x50 [f2fs]<br /> do_garbage_collect+0x674/0x6e0 [f2fs]<br /> f2fs_gc_range+0x12b/0x230 [f2fs]<br /> f2fs_allocate_pinning_section+0x5c/0x150 [f2fs]<br /> f2fs_expand_inode_data+0x1cc/0x3c0 [f2fs]<br /> f2fs_fallocate+0x3c3/0x410 [f2fs]<br /> vfs_fallocate+0x15f/0x4b0<br /> __x64_sys_fallocate+0x4a/0x80<br /> x64_sys_call+0x15e8/0x1b80<br /> do_syscall_64+0x68/0x130<br /> entry_SYSCALL_64_after_hwframe+0x67/0x6f<br /> RIP: 0033:0x7f9dba5197ca<br /> F2FS-fs (nullb0): Stopped filesystem due to reason: 4<br /> <br /> The reason is f2fs_gc_range() may try to migrate block in curseg, however,<br /> its SSA block is not uptodate due to the last summary block data is still<br /> in cache of curseg.<br /> <br /> In this patch, we add a condition in f2fs_gc_range() to check whether<br /> section is opened or not, and skip block migration for opened section.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7915: Fix null-ptr-deref in mt7915_mmio_wed_init()<br /> <br /> devm_ioremap() returns NULL on error. Currently, mt7915_mmio_wed_init()<br /> does not check for this case, which results in a NULL pointer<br /> dereference.<br /> <br /> Prevent null pointer dereference in mt7915_mmio_wed_init().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7996: Fix null-ptr-deref in mt7996_mmio_wed_init()<br /> <br /> devm_ioremap() returns NULL on error. Currently, mt7996_mmio_wed_init()<br /> does not check for this case, which results in a NULL pointer<br /> dereference.<br /> <br /> Prevent null pointer dereference in mt7996_mmio_wed_init()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hisi_acc_vfio_pci: fix XQE dma address error<br /> <br /> The dma addresses of EQE and AEQE are wrong after migration and<br /> results in guest kernel-mode encryption services failure.<br /> Comparing the definition of hardware registers, we found that<br /> there was an error when the data read from the register was<br /> combined into an address. Therefore, the address combination<br /> sequence needs to be corrected.<br /> <br /> Even after fixing the above problem, we still have an issue<br /> where the Guest from an old kernel can get migrated to<br /> new kernel and may result in wrong data.<br /> <br /> In order to ensure that the address is correct after migration,<br /> if an old magic number is detected, the dma address needs to be<br /> updated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/cma: Fix hang when cma_netevent_callback fails to queue_work<br /> <br /> The cited commit fixed a crash when cma_netevent_callback was called for<br /> a cma_id while work on that id from a previous call had not yet started.<br /> The work item was re-initialized in the second call, which corrupted the<br /> work item currently in the work queue.<br /> <br /> However, it left a problem when queue_work fails (because the item is<br /> still pending in the work queue from a previous call). In this case,<br /> cma_id_put (which is called in the work handler) is therefore not<br /> called. This results in a userspace process hang (zombie process).<br /> <br /> Fix this by calling cma_id_put() if queue_work fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: aqc111: fix error handling of usbnet read calls<br /> <br /> Syzkaller, courtesy of syzbot, identified an error (see report [1]) in<br /> aqc111 driver, caused by incomplete sanitation of usb read calls&amp;#39;<br /> results. This problem is quite similar to the one fixed in commit<br /> 920a9fa27e78 ("net: asix: add proper error handling of usb read errors").<br /> <br /> For instance, usbnet_read_cmd() may read fewer than &amp;#39;size&amp;#39; bytes,<br /> even if the caller expected the full amount, and aqc111_read_cmd()<br /> will not check its result properly. As [1] shows, this may lead<br /> to MAC address in aqc111_bind() being only partly initialized,<br /> triggering KMSAN warnings.<br /> <br /> Fix the issue by verifying that the number of bytes read is<br /> as expected and not less.<br /> <br /> [1] Partial syzbot report:<br /> BUG: KMSAN: uninit-value in is_valid_ether_addr include/linux/etherdevice.h:208 [inline]<br /> BUG: KMSAN: uninit-value in usbnet_probe+0x2e57/0x4390 drivers/net/usb/usbnet.c:1830<br /> is_valid_ether_addr include/linux/etherdevice.h:208 [inline]<br /> usbnet_probe+0x2e57/0x4390 drivers/net/usb/usbnet.c:1830<br /> usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396<br /> call_driver_probe drivers/base/dd.c:-1 [inline]<br /> really_probe+0x4d1/0xd90 drivers/base/dd.c:658<br /> __driver_probe_device+0x268/0x380 drivers/base/dd.c:800<br /> ...<br /> <br /> Uninit was stored to memory at:<br /> dev_addr_mod+0xb0/0x550 net/core/dev_addr_lists.c:582<br /> __dev_addr_set include/linux/netdevice.h:4874 [inline]<br /> eth_hw_addr_set include/linux/etherdevice.h:325 [inline]<br /> aqc111_bind+0x35f/0x1150 drivers/net/usb/aqc111.c:717<br /> usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772<br /> usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396<br /> ...<br /> <br /> Uninit was stored to memory at:<br /> ether_addr_copy include/linux/etherdevice.h:305 [inline]<br /> aqc111_read_perm_mac drivers/net/usb/aqc111.c:663 [inline]<br /> aqc111_bind+0x794/0x1150 drivers/net/usb/aqc111.c:713<br /> usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772<br /> usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396<br /> call_driver_probe drivers/base/dd.c:-1 [inline]<br /> ...<br /> <br /> Local variable buf.i created at:<br /> aqc111_read_perm_mac drivers/net/usb/aqc111.c:656 [inline]<br /> aqc111_bind+0x221/0x1150 drivers/net/usb/aqc111.c:713<br /> usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Avoid using sk_socket after free when sending<br /> <br /> The sk-&gt;sk_socket is not locked or referenced in backlog thread, and<br /> during the call to skb_send_sock(), there is a race condition with<br /> the release of sk_socket. All types of sockets(tcp/udp/unix/vsock)<br /> will be affected.<br /> <br /> Race conditions:<br /> &amp;#39;&amp;#39;&amp;#39;<br /> CPU0 CPU1<br /> <br /> backlog::skb_send_sock<br /> sendmsg_unlocked<br /> sock_sendmsg<br /> sock_sendmsg_nosec<br /> close(fd):<br /> ...<br /> ops-&gt;release() -&gt; sock_map_close()<br /> sk_socket-&gt;ops = NULL<br /> free(socket)<br /> sock-&gt;ops-&gt;sendmsg<br /> ^<br /> panic here<br /> &amp;#39;&amp;#39;&amp;#39;<br /> <br /> The ref of psock become 0 after sock_map_close() executed.<br /> &amp;#39;&amp;#39;&amp;#39;<br /> void sock_map_close()<br /> {<br /> ...<br /> if (likely(psock)) {<br /> ...<br /> // !! here we remove psock and the ref of psock become 0<br /> sock_map_remove_links(sk, psock)<br /> psock = sk_psock_get(sk);<br /> if (unlikely(!psock))<br /> goto no_psock; work);

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath9k_htc: Abort software beacon handling if disabled<br /> <br /> A malicious USB device can send a WMI_SWBA_EVENTID event from an<br /> ath9k_htc-managed device before beaconing has been enabled. This causes<br /> a device-by-zero error in the driver, leading to either a crash or an<br /> out of bounds read.<br /> <br /> Prevent this by aborting the handling in ath9k_htc_swba() if beacons are<br /> not enabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phy: clear phydev-&gt;devlink when the link is deleted<br /> <br /> There is a potential crash issue when disabling and re-enabling the<br /> network port. When disabling the network port, phy_detach() calls<br /> device_link_del() to remove the device link, but it does not clear<br /> phydev-&gt;devlink, so phydev-&gt;devlink is not a NULL pointer. Then the<br /> network port is re-enabled, but if phy_attach_direct() fails before<br /> calling device_link_add(), the code jumps to the "error" label and<br /> calls phy_detach(). Since phydev-&gt;devlink retains the old value from<br /> the previous attach/detach cycle, device_link_del() uses the old value,<br /> which accesses a NULL pointer and causes a crash. The simplified crash<br /> log is as follows.<br /> <br /> [ 24.702421] Call trace:<br /> [ 24.704856] device_link_put_kref+0x20/0x120<br /> [ 24.709124] device_link_del+0x30/0x48<br /> [ 24.712864] phy_detach+0x24/0x168<br /> [ 24.716261] phy_attach_direct+0x168/0x3a4<br /> [ 24.720352] phylink_fwnode_phy_connect+0xc8/0x14c<br /> [ 24.725140] phylink_of_phy_connect+0x1c/0x34<br /> <br /> Therefore, phydev-&gt;devlink needs to be cleared when the device link is<br /> deleted.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> watchdog: lenovo_se30_wdt: Fix possible devm_ioremap() NULL pointer dereference in lenovo_se30_wdt_probe()<br /> <br /> devm_ioremap() returns NULL on error. Currently, lenovo_se30_wdt_probe()<br /> does not check for this case, which results in a NULL pointer<br /> dereference.<br /> <br /> Add NULL check after devm_ioremap() to prevent this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_packet: move notifier&amp;#39;s packet_dev_mc out of rcu critical section<br /> <br /> Syzkaller reports the following issue:<br /> <br /> BUG: sleeping function called from invalid context at kernel/locking/mutex.c:578<br /> __mutex_lock+0x106/0xe80 kernel/locking/mutex.c:746<br /> team_change_rx_flags+0x38/0x220 drivers/net/team/team_core.c:1781<br /> dev_change_rx_flags net/core/dev.c:9145 [inline]<br /> __dev_set_promiscuity+0x3f8/0x590 net/core/dev.c:9189<br /> netif_set_promiscuity+0x50/0xe0 net/core/dev.c:9201<br /> dev_set_promiscuity+0x126/0x260 net/core/dev_api.c:286 packet_dev_mc net/packet/af_packet.c:3698 [inline]<br /> packet_dev_mclist_delete net/packet/af_packet.c:3722 [inline]<br /> packet_notifier+0x292/0xa60 net/packet/af_packet.c:4247<br /> notifier_call_chain+0x1b3/0x3e0 kernel/notifier.c:85<br /> call_netdevice_notifiers_extack net/core/dev.c:2214 [inline]<br /> call_netdevice_notifiers net/core/dev.c:2228 [inline]<br /> unregister_netdevice_many_notify+0x15d8/0x2330 net/core/dev.c:11972<br /> rtnl_delete_link net/core/rtnetlink.c:3522 [inline]<br /> rtnl_dellink+0x488/0x710 net/core/rtnetlink.c:3564<br /> rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6955<br /> netlink_rcv_skb+0x219/0x490 net/netlink/af_netlink.c:2534<br /> <br /> Calling `PACKET_ADD_MEMBERSHIP` on an ops-locked device can trigger<br /> the `NETDEV_UNREGISTER` notifier, which may require disabling promiscuous<br /> and/or allmulti mode. Both of these operations require acquiring<br /> the netdev instance lock.<br /> <br /> Move the call to `packet_dev_mc` outside of the RCU critical section.<br /> The `mclist` modifications (add, del, flush, unregister) are protected by<br /> the RTNL, not the RCU. The RCU only protects the `sklist` and its<br /> associated `sks`. The delayed operation on the `mclist` entry remains<br /> within the RTNL.