Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: aloop: Fix peer runtime UAF during format-change stop<br /> <br /> loopback_check_format() may stop the capture side when playback starts<br /> with parameters that no longer match a running capture stream. Commit<br /> 826af7fa62e3 ("ALSA: aloop: Fix racy access at PCM trigger") moved<br /> the peer lookup under cable-&gt;lock, but the actual snd_pcm_stop() still<br /> runs after dropping that lock.<br /> <br /> A concurrent close can clear the capture entry from cable-&gt;streams[] and<br /> detach or free its runtime while the playback trigger path still holds a<br /> stale peer substream pointer.<br /> <br /> Keep a per-cable count of in-flight peer stops before dropping<br /> cable-&gt;lock, and make free_cable() wait for those stops before<br /> detaching the runtime. This preserves the existing behavior while<br /> making the peer runtime lifetime explicit.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: acomp - fix wrong pointer stored by acomp_save_req()<br /> <br /> acomp_save_req() stores &amp;req-&gt;chain in req-&gt;base.data. When<br /> acomp_reqchain_done() is invoked on asynchronous completion, it receives<br /> &amp;req-&gt;chain as the data argument but casts it directly to struct<br /> acomp_req. Since data points to the chain member, all subsequent field<br /> accesses are at a wrong offset, resulting in memory corruption.<br /> <br /> The issue occurs when an asynchronous hardware implementation, such as<br /> the QAT driver, completes a request that uses the DMA virtual address<br /> interface (e.g. acomp_request_set_src_dma()). This combination causes<br /> crypto_acomp_compress() to enter the acomp_do_req_chain() path, which<br /> sets acomp_reqchain_done() as the completion callback via<br /> acomp_save_req().<br /> <br /> With KASAN enabled, this manifests as a general protection fault in<br /> acomp_reqchain_done():<br /> <br /> general protection fault, probably for non-canonical address 0xe000040000000000<br /> KASAN: probably user-memory-access in range [0x0000400000000000-0x0000400000000007]<br /> RIP: 0010:acomp_reqchain_done+0x15b/0x4e0<br /> Call Trace:<br /> <br /> qat_comp_alg_callback+0x5d/0xa0 [intel_qat]<br /> adf_ring_response_handler+0x376/0x8b0 [intel_qat]<br /> adf_response_handler+0x60/0x170 [intel_qat]<br /> tasklet_action_common+0x223/0x820<br /> handle_softirqs+0x1ab/0x640<br /> <br /> <br /> Fix this by storing the request itself in req-&gt;base.data instead of<br /> &amp;req-&gt;chain, so that acomp_reqchain_done() receives the correct pointer.<br /> Simplify acomp_restore_req() accordingly to access req-&gt;chain directly.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: split transactions in dio completion to avoid credit exhaustion<br /> <br /> During ocfs2 dio operations, JBD2 may report warnings via following<br /> call trace:<br /> ocfs2_dio_end_io_write<br /> ocfs2_mark_extent_written<br /> ocfs2_change_extent_flag<br /> ocfs2_split_extent<br /> ocfs2_try_to_merge_extent<br /> ocfs2_extend_rotate_transaction<br /> ocfs2_extend_trans<br /> jbd2__journal_restart<br /> start_this_handle<br /> output: JBD2: kworker/6:2 wants too many credits credits:5450 rsv_credits:0 max:5449<br /> <br /> To prevent exceeding the credits limit, modify ocfs2_dio_end_io_write() to<br /> handle extents in a batch of transaction.<br /> <br /> Additionally, relocate ocfs2_del_inode_from_orphan(). The orphan inode<br /> should only be removed from the orphan list after the extent tree update<br /> is complete. This ensures that if a crash occurs in the middle of extent<br /> tree updates, we won&amp;#39;t leave stale blocks beyond EOF.<br /> <br /> This patch also changes the logic for updating the inode size and removing<br /> orphan, making it similar to ext4_dio_write_end_io(). Both operations are<br /> performed only when everything looks good.<br /> <br /> Finally, thanks to Jans and Joseph for providing the bug fix prototype and<br /> suggestions.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rbd: fix null-ptr-deref when device_add_disk() fails<br /> <br /> do_rbd_add() publishes the device with device_add() before calling<br /> device_add_disk(). If device_add_disk() fails after device_add()<br /> succeeds, the error path calls rbd_free_disk() directly and then later<br /> falls through to rbd_dev_device_release(), which calls rbd_free_disk()<br /> again. This double teardown can leave blk-mq cleanup operating on<br /> invalid state and trigger a null-ptr-deref in<br /> __blk_mq_free_map_and_rqs(), reached from blk_mq_free_tag_set().<br /> <br /> Fix this by following the normal remove ordering: call device_del()<br /> before rbd_dev_device_release() when device_add_disk() fails after<br /> device_add(). That keeps the teardown sequence consistent and avoids<br /> re-entering disk cleanup through the wrong path.<br /> <br /> The bug was first flagged by an experimental analysis tool we are<br /> developing for kernel memory-management bugs while analyzing<br /> v6.13-rc1. The tool is still under development and is not yet publicly<br /> available.<br /> <br /> We reproduced the bug on v7.0 with a real Ceph backend and a QEMU x86_64<br /> guest booted with KASAN and CONFIG_FAILSLAB enabled. The reproducer<br /> confines failslab injections to the __add_disk() range and injects<br /> fail-nth while mapping an RBD image through<br /> /sys/bus/rbd/add_single_major.<br /> <br /> On the unpatched kernel, fail-nth=4 reliably triggered the fault:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> CPU: 0 UID: 0 PID: 273 Comm: bash Not tainted 7.0.0-01247-gd60bc1401583 #6 PREEMPT(lazy)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014<br /> RIP: 0010:__blk_mq_free_map_and_rqs+0x8c/0x240<br /> Code: 00 00 48 8b 6b 60 41 89 f4 49 c1 e4 03 4c 01 e5 45 85 ed 0f 85 0a 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 e9 48 c1 e9 03 3c 01 00 0f 85 31 01 00 00 4c 8b 6d 00 4d 85 ed 0f 84 e2 00 00<br /> RSP: 0018:ff1100000ab0fac8 EFLAGS: 00000246<br /> RAX: dffffc0000000000 RBX: ff1100000c4806a0 RCX: 0000000000000000<br /> RDX: 0000000000000002 RSI: 0000000000000000 RDI: ff1100000c4806f4<br /> RBP: 0000000000000000 R08: 0000000000000001 R09: ffe21c000189001b<br /> R10: ff1100000c4800df R11: ff1100006cf37be0 R12: 0000000000000000<br /> R13: 0000000000000000 R14: ff1100000c480700 R15: ff1100000c480004<br /> FS: 00007f0fbe8fe740(0000) GS:ff110000e5851000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fe53473b2e0 CR3: 0000000012eef000 CR4: 00000000007516f0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> blk_mq_free_tag_set+0x77/0x460<br /> do_rbd_add+0x1446/0x2b80<br /> ? __pfx_do_rbd_add+0x10/0x10<br /> ? lock_acquire+0x18c/0x300<br /> ? find_held_lock+0x2b/0x80<br /> ? sysfs_file_kobj+0xb6/0x1b0<br /> ? __pfx_sysfs_kf_write+0x10/0x10<br /> kernfs_fop_write_iter+0x2f4/0x4a0<br /> vfs_write+0x98e/0x1000<br /> ? expand_files+0x51f/0x850<br /> ? __pfx_vfs_write+0x10/0x10<br /> ksys_write+0xf2/0x1d0<br /> ? __pfx_ksys_write+0x10/0x10<br /> do_syscall_64+0x115/0x690<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f0fbea15907<br /> Code: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24<br /> RSP: 002b:00007ffe22346ea8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 0000000000000058 RCX: 00007f0fbea15907<br /> RDX: 0000000000000058 RSI: 0000563ace6c0ef0 RDI: 0000000000000001<br /> RBP: 0000563ace6c0ef0 R08: 0000563ace6c0ef0 R09: 6b6435726d694141<br /> R10: 5250337279762f78 R11: 0000000000000246 R12: 0000000000000058<br /> R13: 00007f0fbeb1c780 R14: ff1100000c480700 R15: ff1100000c480004<br /> <br /> <br /> With this fix applied, rerunning the reproducer over fail-nth=1..256<br /> yields no KASAN reports.<br /> <br /> [ idryomov: rename err_out_device_del -&gt; err_out_device ]

*** Pendiente de traducción *** 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

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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).

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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().

*** Pendiente de traducción *** 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@]

*** Pendiente de traducción *** 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]

*** Pendiente de traducción *** 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.