Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64/fpsimd: Discard stale CPU state when handling SME traps<br /> <br /> The logic for handling SME traps manipulates saved FPSIMD/SVE/SME state<br /> incorrectly, and a race with preemption can result in a task having<br /> TIF_SME set and TIF_FOREIGN_FPSTATE clear even though the live CPU state<br /> is stale (e.g. with SME traps enabled). This can result in warnings from<br /> do_sme_acc() where SME traps are not expected while TIF_SME is set:<br /> <br /> | /* With TIF_SME userspace shouldn&amp;#39;t generate any traps */<br /> | if (test_and_set_thread_flag(TIF_SME))<br /> | WARN_ON(1);<br /> <br /> This is very similar to the SVE issue we fixed in commit:<br /> <br /> 751ecf6afd6568ad ("arm64/sve: Discard stale CPU state when handling SVE traps")<br /> <br /> The race can occur when the SME trap handler is preempted before and<br /> after manipulating the saved FPSIMD/SVE/SME state, starting and ending on<br /> the same CPU, e.g.<br /> <br /> | void do_sme_acc(unsigned long esr, struct pt_regs *regs)<br /> | {<br /> | // Trap on CPU 0 with TIF_SME clear, SME traps enabled<br /> | // task-&gt;fpsimd_cpu is 0.<br /> | // per_cpu_ptr(&amp;fpsimd_last_state, 0) is task.<br /> |<br /> | ...<br /> |<br /> | // Preempted; migrated from CPU 0 to CPU 1.<br /> | // TIF_FOREIGN_FPSTATE is set.<br /> |<br /> | get_cpu_fpsimd_context();<br /> |<br /> | /* With TIF_SME userspace shouldn&amp;#39;t generate any traps */<br /> | if (test_and_set_thread_flag(TIF_SME))<br /> | WARN_ON(1);<br /> |<br /> | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {<br /> | unsigned long vq_minus_one =<br /> | sve_vq_from_vl(task_get_sme_vl(current)) - 1;<br /> | sme_set_vq(vq_minus_one);<br /> |<br /> | fpsimd_bind_task_to_cpu();<br /> | }<br /> |<br /> | put_cpu_fpsimd_context();<br /> |<br /> | // Preempted; migrated from CPU 1 to CPU 0.<br /> | // task-&gt;fpsimd_cpu is still 0<br /> | // If per_cpu_ptr(&amp;fpsimd_last_state, 0) is still task then:<br /> | // - Stale HW state is reused (with SME traps enabled)<br /> | // - TIF_FOREIGN_FPSTATE is cleared<br /> | // - A return to userspace skips HW state restore<br /> | }<br /> <br /> Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set<br /> by calling fpsimd_flush_task_state() to detach from the saved CPU<br /> state. This ensures that a subsequent context switch will not reuse the<br /> stale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the<br /> new state to be reloaded from memory prior to a return to userspace.<br /> <br /> Note: this was originallly posted as [1].<br /> <br /> [ Rutland: rewrite commit message ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: handle hdr_first_de() return value<br /> <br /> The hdr_first_de() function returns a pointer to a struct NTFS_DE. This<br /> pointer may be NULL. To handle the NULL error effectively, it is important<br /> to implement an error handler. This will help manage potential errors<br /> consistently.<br /> <br /> Additionally, error handling for the return value already exists at other<br /> points where this function is called.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

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