Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: fix the out-of-bounds nameoff handling for trailing dirents<br /> <br /> Currently we already have boundary-checks for nameoffs, but the trailing<br /> dirents are special since the namelens are calculated with strnlen()<br /> with unchecked nameoffs.<br /> <br /> If a crafted EROFS has a trailing dirent with nameoff &gt;= maxsize,<br /> maxsize - nameoff can underflow, causing strnlen() to read past the<br /> directory block.<br /> <br /> nameoff0 should also be verified to be a multiple of<br /> `sizeof(struct erofs_dirent)` as well [1].<br /> <br /> [1] https://sashiko.dev/#/patchset/20260416063511.3173774-1-hsiangkao%40linux.alibaba.com

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: atmel-tdes - fix DMA sync direction<br /> <br /> Before DMA output is consumed by the CPU, -&gt;dma_addr_out must be synced<br /> with dma_sync_single_for_cpu() instead of dma_sync_single_for_device().<br /> Using the wrong direction can return stale cache data on non-coherent<br /> platforms.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix rxkad crypto unalignment handling<br /> <br /> Fix handling of a packet with a misaligned crypto length. Also handle<br /> non-ENOMEM errors from decryption by aborting. Further, remove the<br /> WARN_ON_ONCE() so that it can&amp;#39;t be remotely triggered (a trace line can<br /> still be emitted).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mana_ib: Disable RX steering on RSS QP destroy<br /> <br /> When an RSS QP is destroyed (e.g. DPDK exit), mana_ib_destroy_qp_rss()<br /> destroys the RX WQ objects but does not disable vPort RX steering in<br /> firmware. This leaves stale steering configuration that still points to<br /> the destroyed RX objects.<br /> <br /> If traffic continues to arrive (e.g. peer VM is still transmitting) and<br /> the VF interface is subsequently brought up (mana_open), the firmware<br /> may deliver completions using stale CQ IDs from the old RX objects.<br /> These CQ IDs can be reused by the ethernet driver for new TX CQs,<br /> causing RX completions to land on TX CQs:<br /> <br /> WARNING: mana_poll_tx_cq+0x1b8/0x220 [mana] (is_sq == false)<br /> WARNING: mana_gd_process_eq_events+0x209/0x290 (cq_table lookup fails)<br /> <br /> Fix this by disabling vPort RX steering before destroying RX WQ objects.<br /> Note that mana_fence_rqs() cannot be used here because the fence<br /> completion is delivered on the CQ, which is polled by user-mode (e.g.<br /> DPDK) and not visible to the kernel driver.<br /> <br /> Refactor the disable logic into a shared mana_disable_vport_rx() in<br /> mana_en, exported for use by mana_ib, replacing the duplicate code.<br /> The ethernet driver&amp;#39;s mana_dealloc_queues() is also updated to call<br /> this common function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: fix resource leaks on device setup failure<br /> <br /> Make sure to call controller cleanup() if spi_setup() fails while<br /> registering a device to avoid leaking any resources allocated by<br /> setup().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0<br /> <br /> INVLPGA should cause a #UD when EFER.SVME is not set. Add a check to<br /> properly inject #UD when EFER.SVME=0.<br /> <br /> [sean: tag for stable@]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: nSVM: Raise #UD if unhandled VMMCALL isn&amp;#39;t intercepted by L1<br /> <br /> Explicitly synthesize a #UD for VMMCALL if L2 is active, L1 does NOT want<br /> to intercept VMMCALL, nested_svm_l2_tlb_flush_enabled() is true, and the<br /> hypercall is something other than one of the supported Hyper-V hypercalls.<br /> When all of the above conditions are met, KVM will intercept VMMCALL but<br /> never forward it to L1, i.e. will let L2 make hypercalls as if it were L1.<br /> <br /> The TLFS says a whole lot of nothing about this scenario, so go with the<br /> architectural behavior, which says that VMMCALL #UDs if it&amp;#39;s not<br /> intercepted.<br /> <br /> Opportunistically do a 2-for-1 stub trade by stub-ifying the new API<br /> instead of the helpers it uses. The last remaining "single" stub will<br /> soon be dropped as well.<br /> <br /> [sean: rewrite changelog and comment, tag for stable, remove defunct stubs]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: atmel-sha204a - Fix potential UAF and memory leak in remove path<br /> <br /> Unregister the hwrng to prevent new -&gt;read() calls and flush the Atmel<br /> I2C workqueue before teardown to prevent a potential UAF if a queued<br /> callback runs while the device is being removed.<br /> <br /> Drop the early return to ensure sysfs entries are removed and<br /> -&gt;hwrng.priv is freed, preventing a memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: ch341: fix memory leaks on probe failures<br /> <br /> Make sure to deregister the controller, disable pins, and kill and free<br /> the RX URB on probe failures to mirror disconnect and avoid memory<br /> leaks and use-after-free.<br /> <br /> Also add an explicit URB kill on disconnect for symmetry (even if that<br /> is not strictly required as USB core would have stopped it in the<br /> current setup).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (powerz) Fix missing usb_kill_urb() on signal interrupt<br /> <br /> wait_for_completion_interruptible_timeout() returns -ERESTARTSYS when<br /> interrupted. This needs to abort the URB and return an error. No data<br /> has been received from the device so any reads from the transfer<br /> buffer are invalid.<br /> <br /> The original code tests !ret, which only catches the timeout case (0).<br /> On signal delivery (-ERESTARTSYS), !ret is false so the function skips<br /> usb_kill_urb() and falls through to read from the unfilled transfer<br /> buffer.<br /> <br /> Fix by capturing the return value into a long (matching the function<br /> return type) and handling signal (negative) and timeout (zero) cases<br /> with separate checks that both call usb_kill_urb() before returning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntfs3: add buffer boundary checks to run_unpack()<br /> <br /> run_unpack() checks `run_buf

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: nSVM: Avoid clearing VMCB_LBR in vmcb12<br /> <br /> svm_copy_lbrs() always marks VMCB_LBR dirty in the destination VMCB.<br /> However, nested_svm_vmexit() uses it to copy LBRs to vmcb12, and<br /> clearing clean bits in vmcb12 is not architecturally defined.<br /> <br /> Move vmcb_mark_dirty() to callers and drop it for vmcb12.<br /> <br /> This also facilitates incoming refactoring that does not pass the entire<br /> VMCB to svm_copy_lbrs().