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 /> bpf, sockmap: Fix panic when calling skb_linearize<br /> <br /> The panic can be reproduced by executing the command:<br /> ./bench sockmap -c 2 -p 1 -a --rx-verdict-ingress --rx-strp 100000<br /> <br /> Then a kernel panic was captured:<br /> &amp;#39;&amp;#39;&amp;#39;<br /> [ 657.460555] kernel BUG at net/core/skbuff.c:2178!<br /> [ 657.462680] Tainted: [W]=WARN<br /> [ 657.463287] Workqueue: events sk_psock_backlog<br /> ...<br /> [ 657.469610] <br /> [ 657.469738] ? die+0x36/0x90<br /> [ 657.469916] ? do_trap+0x1d0/0x270<br /> [ 657.470118] ? pskb_expand_head+0x612/0xf40<br /> [ 657.470376] ? pskb_expand_head+0x612/0xf40<br /> [ 657.470620] ? do_error_trap+0xa3/0x170<br /> [ 657.470846] ? pskb_expand_head+0x612/0xf40<br /> [ 657.471092] ? handle_invalid_op+0x2c/0x40<br /> [ 657.471335] ? pskb_expand_head+0x612/0xf40<br /> [ 657.471579] ? exc_invalid_op+0x2d/0x40<br /> [ 657.471805] ? asm_exc_invalid_op+0x1a/0x20<br /> [ 657.472052] ? pskb_expand_head+0xd1/0xf40<br /> [ 657.472292] ? pskb_expand_head+0x612/0xf40<br /> [ 657.472540] ? lock_acquire+0x18f/0x4e0<br /> [ 657.472766] ? find_held_lock+0x2d/0x110<br /> [ 657.472999] ? __pfx_pskb_expand_head+0x10/0x10<br /> [ 657.473263] ? __kmalloc_cache_noprof+0x5b/0x470<br /> [ 657.473537] ? __pfx___lock_release.isra.0+0x10/0x10<br /> [ 657.473826] __pskb_pull_tail+0xfd/0x1d20<br /> [ 657.474062] ? __kasan_slab_alloc+0x4e/0x90<br /> [ 657.474707] sk_psock_skb_ingress_enqueue+0x3bf/0x510<br /> [ 657.475392] ? __kasan_kmalloc+0xaa/0xb0<br /> [ 657.476010] sk_psock_backlog+0x5cf/0xd70<br /> [ 657.476637] process_one_work+0x858/0x1a20<br /> &amp;#39;&amp;#39;&amp;#39;<br /> <br /> The panic originates from the assertion BUG_ON(skb_shared(skb)) in<br /> skb_linearize(). A previous commit(see Fixes tag) introduced skb_get()<br /> to avoid race conditions between skb operations in the backlog and skb<br /> release in the recvmsg path. However, this caused the panic to always<br /> occur when skb_linearize is executed.<br /> <br /> The "--rx-strp 100000" parameter forces the RX path to use the strparser<br /> module which aggregates data until it reaches 100KB before calling sockmap<br /> logic. The 100KB payload exceeds MAX_MSG_FRAGS, triggering skb_linearize.<br /> <br /> To fix this issue, just move skb_get into sk_psock_skb_ingress_enqueue.<br /> <br /> &amp;#39;&amp;#39;&amp;#39;<br /> sk_psock_backlog:<br /> sk_psock_handle_skb<br /> skb_get(skb)

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 /> 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 /> 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 /> 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 /> 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 /> backlight: pm8941: Add NULL check in wled_configure()<br /> <br /> devm_kasprintf() returns NULL when memory allocation fails. Currently,<br /> wled_configure() does not check for this case, which results in a NULL<br /> pointer dereference.<br /> <br /> Add NULL check after devm_kasprintf() to prevent this issue.

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.