Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: avoid using multiple devices with different type<br /> <br /> For multiple devices, both primary and extra devices should be the<br /> same type. `erofs_init_device` has already guaranteed that if the<br /> primary is a file-backed device, extra devices should also be<br /> regular files.<br /> <br /> However, if the primary is a block device while the extra device<br /> is a file-backed device, `erofs_init_device` will get an ENOTBLK,<br /> which is not treated as an error in `erofs_fc_get_tree`, and that<br /> leads to an UAF:<br /> <br /> erofs_fc_get_tree<br /> get_tree_bdev_flags(erofs_fc_fill_super)<br /> erofs_read_superblock<br /> erofs_init_device // sbi-&gt;dif0 is not inited yet,<br /> // return -ENOTBLK<br /> deactivate_locked_super<br /> free(sbi)<br /> if (err is -ENOTBLK)<br /> sbi-&gt;dif0.file = filp_open() // sbi UAF<br /> <br /> So if -ENOTBLK is hitted in `erofs_init_device`, it means the<br /> primary device must be a block device, and the extra device<br /> is not a block device. The error can be converted to -EINVAL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw88: fix the &amp;#39;para&amp;#39; buffer size to avoid reading out of bounds<br /> <br /> Set the size to 6 instead of 2, since &amp;#39;para&amp;#39; array is passed to<br /> &amp;#39;rtw_fw_bt_wifi_control(rtwdev, para[0], &amp;para[1])&amp;#39;, which reads<br /> 5 bytes:<br /> <br /> void rtw_fw_bt_wifi_control(struct rtw_dev *rtwdev, u8 op_code, u8 *data)<br /> {<br /> ...<br /> SET_BT_WIFI_CONTROL_DATA1(h2c_pkt, *data);<br /> SET_BT_WIFI_CONTROL_DATA2(h2c_pkt, *(data + 1));<br /> ...<br /> SET_BT_WIFI_CONTROL_DATA5(h2c_pkt, *(data + 4));<br /> <br /> Detected using the static analysis tool - Svace.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: bcm: rpi: Add NULL check in raspberrypi_clk_register()<br /> <br /> devm_kasprintf() returns NULL when memory allocation fails. Currently,<br /> raspberrypi_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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Fix error flow upon firmware failure for RQ destruction<br /> <br /> Upon RQ destruction if the firmware command fails which is the<br /> last resource to be destroyed some SW resources were already cleaned<br /> regardless of the failure.<br /> <br /> Now properly rollback the object to its original state upon such failure.<br /> <br /> In order to avoid a use-after free in case someone tries to destroy the<br /> object again, which results in the following kernel trace:<br /> refcount_t: underflow; use-after-free.<br /> WARNING: CPU: 0 PID: 37589 at lib/refcount.c:28 refcount_warn_saturate+0xf4/0x148<br /> Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) rfkill mlx5_core(OE) mlxdevm(OE) ib_uverbs(OE) ib_core(OE) psample mlxfw(OE) mlx_compat(OE) macsec tls pci_hyperv_intf sunrpc vfat fat virtio_net net_failover failover fuse loop nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce virtio_console virtio_gpu virtio_blk virtio_dma_buf virtio_mmio dm_mirror dm_region_hash dm_log dm_mod xpmem(OE)<br /> CPU: 0 UID: 0 PID: 37589 Comm: python3 Kdump: loaded Tainted: G OE ------- --- 6.12.0-54.el10.aarch64 #1<br /> Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE<br /> Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015<br /> pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : refcount_warn_saturate+0xf4/0x148<br /> lr : refcount_warn_saturate+0xf4/0x148<br /> sp : ffff80008b81b7e0<br /> x29: ffff80008b81b7e0 x28: ffff000133d51600 x27: 0000000000000001<br /> x26: 0000000000000000 x25: 00000000ffffffea x24: ffff00010ae80f00<br /> x23: ffff00010ae80f80 x22: ffff0000c66e5d08 x21: 0000000000000000<br /> x20: ffff0000c66e0000 x19: ffff00010ae80340 x18: 0000000000000006<br /> x17: 0000000000000000 x16: 0000000000000020 x15: ffff80008b81b37f<br /> x14: 0000000000000000 x13: 2e656572662d7265 x12: ffff80008283ef78<br /> x11: ffff80008257efd0 x10: ffff80008283efd0 x9 : ffff80008021ed90<br /> x8 : 0000000000000001 x7 : 00000000000bffe8 x6 : c0000000ffff7fff<br /> x5 : ffff0001fb8e3408 x4 : 0000000000000000 x3 : ffff800179993000<br /> x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000133d51600<br /> Call trace:<br /> refcount_warn_saturate+0xf4/0x148<br /> mlx5_core_put_rsc+0x88/0xa0 [mlx5_ib]<br /> mlx5_core_destroy_rq_tracked+0x64/0x98 [mlx5_ib]<br /> mlx5_ib_destroy_wq+0x34/0x80 [mlx5_ib]<br /> ib_destroy_wq_user+0x30/0xc0 [ib_core]<br /> uverbs_free_wq+0x28/0x58 [ib_uverbs]<br /> destroy_hw_idr_uobject+0x34/0x78 [ib_uverbs]<br /> uverbs_destroy_uobject+0x48/0x240 [ib_uverbs]<br /> __uverbs_cleanup_ufile+0xd4/0x1a8 [ib_uverbs]<br /> uverbs_destroy_ufile_hw+0x48/0x120 [ib_uverbs]<br /> ib_uverbs_close+0x2c/0x100 [ib_uverbs]<br /> __fput+0xd8/0x2f0<br /> __fput_sync+0x50/0x70<br /> __arm64_sys_close+0x40/0x90<br /> invoke_syscall.constprop.0+0x74/0xd0<br /> do_el0_svc+0x48/0xe8<br /> el0_svc+0x44/0x1d0<br /> el0t_64_sync_handler+0x120/0x130<br /> el0t_64_sync+0x1a4/0x1a8

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: fix to do sanity check on sbi-&gt;total_valid_block_count<br /> <br /> syzbot reported a f2fs bug as below:<br /> <br /> ------------[ cut here ]------------<br /> kernel BUG at fs/f2fs/f2fs.h:2521!<br /> RIP: 0010:dec_valid_block_count+0x3b2/0x3c0 fs/f2fs/f2fs.h:2521<br /> Call Trace:<br /> f2fs_truncate_data_blocks_range+0xc8c/0x11a0 fs/f2fs/file.c:695<br /> truncate_dnode+0x417/0x740 fs/f2fs/node.c:973<br /> truncate_nodes+0x3ec/0xf50 fs/f2fs/node.c:1014<br /> f2fs_truncate_inode_blocks+0x8e3/0x1370 fs/f2fs/node.c:1197<br /> f2fs_do_truncate_blocks+0x840/0x12b0 fs/f2fs/file.c:810<br /> f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/file.c:838<br /> f2fs_truncate+0x417/0x720 fs/f2fs/file.c:888<br /> f2fs_setattr+0xc4f/0x12f0 fs/f2fs/file.c:1112<br /> notify_change+0xbca/0xe90 fs/attr.c:552<br /> do_truncate+0x222/0x310 fs/open.c:65<br /> handle_truncate fs/namei.c:3466 [inline]<br /> do_open fs/namei.c:3849 [inline]<br /> path_openat+0x2e4f/0x35d0 fs/namei.c:4004<br /> do_filp_open+0x284/0x4e0 fs/namei.c:4031<br /> do_sys_openat2+0x12b/0x1d0 fs/open.c:1429<br /> do_sys_open fs/open.c:1444 [inline]<br /> __do_sys_creat fs/open.c:1522 [inline]<br /> __se_sys_creat fs/open.c:1516 [inline]<br /> __x64_sys_creat+0x124/0x170 fs/open.c:1516<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/syscall_64.c:94<br /> <br /> The reason is: in fuzzed image, sbi-&gt;total_valid_block_count is<br /> inconsistent w/ mapped blocks indexed by inode, so, we should<br /> not trigger panic for such case, instead, let&amp;#39;s print log and<br /> set fsck flag.

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