Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: Revert "scsi: qla2xxx: Perform lockless command completion in abort path"<br /> <br /> This reverts commit 0367076b0817d5c75dfb83001ce7ce5c64d803a9.<br /> <br /> The commit being reverted added code to __qla2x00_abort_all_cmds() to<br /> call sp-&gt;done() without holding a spinlock. But unlike the older code<br /> below it, this new code failed to check sp-&gt;cmd_type and just assumed<br /> TYPE_SRB, which results in a jump to an invalid pointer in target-mode<br /> with TYPE_TGT_CMD:<br /> <br /> qla2xxx [0000:65:00.0]-d034:8: qla24xx_do_nack_work create sess success<br /> 0000000009f7a79b<br /> qla2xxx [0000:65:00.0]-5003:8: ISP System Error - mbx1=1ff5h mbx2=10h<br /> mbx3=0h mbx4=0h mbx5=191h mbx6=0h mbx7=0h.<br /> qla2xxx [0000:65:00.0]-d01e:8: -&gt; fwdump no buffer<br /> qla2xxx [0000:65:00.0]-f03a:8: qla_target(0): System error async event<br /> 0x8002 occurred<br /> qla2xxx [0000:65:00.0]-00af:8: Performing ISP error recovery -<br /> ha=0000000058183fda.<br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> PF: supervisor instruction fetch in kernel mode<br /> PF: error_code(0x0010) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0010 [#1] SMP<br /> CPU: 2 PID: 9446 Comm: qla2xxx_8_dpc Tainted: G O 6.1.133 #1<br /> Hardware name: Supermicro Super Server/X11SPL-F, BIOS 4.2 12/15/2023<br /> RIP: 0010:0x0<br /> Code: Unable to access opcode bytes at 0xffffffffffffffd6.<br /> RSP: 0018:ffffc90001f93dc8 EFLAGS: 00010206<br /> RAX: 0000000000000282 RBX: 0000000000000355 RCX: ffff88810d16a000<br /> RDX: ffff88810dbadaa8 RSI: 0000000000080000 RDI: ffff888169dc38c0<br /> RBP: ffff888169dc38c0 R08: 0000000000000001 R09: 0000000000000045<br /> R10: ffffffffa034bdf0 R11: 0000000000000000 R12: ffff88810800bb40<br /> R13: 0000000000001aa8 R14: ffff888100136610 R15: ffff8881070f7400<br /> FS: 0000000000000000(0000) GS:ffff88bf80080000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffffffffffffd6 CR3: 000000010c8ff006 CR4: 00000000003706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? __die+0x4d/0x8b<br /> ? page_fault_oops+0x91/0x180<br /> ? trace_buffer_unlock_commit_regs+0x38/0x1a0<br /> ? exc_page_fault+0x391/0x5e0<br /> ? asm_exc_page_fault+0x22/0x30<br /> __qla2x00_abort_all_cmds+0xcb/0x3e0 [qla2xxx_scst]<br /> qla2x00_abort_all_cmds+0x50/0x70 [qla2xxx_scst]<br /> qla2x00_abort_isp_cleanup+0x3b7/0x4b0 [qla2xxx_scst]<br /> qla2x00_abort_isp+0xfd/0x860 [qla2xxx_scst]<br /> qla2x00_do_dpc+0x581/0xa40 [qla2xxx_scst]<br /> kthread+0xa8/0xd0<br /> <br /> <br /> Then commit 4475afa2646d ("scsi: qla2xxx: Complete command early within<br /> lock") added the spinlock back, because not having the lock caused a<br /> race and a crash. But qla2x00_abort_srb() in the switch below already<br /> checks for qla2x00_chip_is_down() and handles it the same way, so the<br /> code above the switch is now redundant and still buggy in target-mode.<br /> Remove it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: dvb-usb: dtv5100: fix out-of-bounds in dtv5100_i2c_msg()<br /> <br /> rlen value is a user-controlled value, but dtv5100_i2c_msg() does not<br /> check the size of the rlen value. Therefore, if it is set to a value<br /> larger than sizeof(st-&gt;data), an out-of-bounds vuln occurs for st-&gt;data.<br /> <br /> Therefore, we need to add proper range checking to prevent this vuln.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: xattr: fix null pointer deref in ext4_raw_inode()<br /> <br /> If ext4_get_inode_loc() fails (e.g. if it returns -EFSCORRUPTED),<br /> iloc.bh will remain set to NULL. Since ext4_xattr_inode_dec_ref_all()<br /> lacks error checking, this will lead to a null pointer dereference<br /> in ext4_raw_inode(), called right after ext4_get_inode_loc().<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fuse: fix readahead reclaim deadlock<br /> <br /> Commit e26ee4efbc79 ("fuse: allocate ff-&gt;release_args only if release is<br /> needed") skips allocating ff-&gt;release_args if the server does not<br /> implement open. However in doing so, fuse_prepare_release() now skips<br /> grabbing the reference on the inode, which makes it possible for an<br /> inode to be evicted from the dcache while there are inflight readahead<br /> requests. This causes a deadlock if the server triggers reclaim while<br /> servicing the readahead request and reclaim attempts to evict the inode<br /> of the file being read ahead. Since the folio is locked during<br /> readahead, when reclaim evicts the fuse inode and fuse_evict_inode()<br /> attempts to remove all folios associated with the inode from the page<br /> cache (truncate_inode_pages_range()), reclaim will block forever waiting<br /> for the lock since readahead cannot relinquish the lock because it is<br /> itself blocked in reclaim:<br /> <br /> &gt;&gt;&gt; stack_trace(1504735)<br /> folio_wait_bit_common (mm/filemap.c:1308:4)<br /> folio_lock (./include/linux/pagemap.h:1052:3)<br /> truncate_inode_pages_range (mm/truncate.c:336:10)<br /> fuse_evict_inode (fs/fuse/inode.c:161:2)<br /> evict (fs/inode.c:704:3)<br /> dentry_unlink_inode (fs/dcache.c:412:3)<br /> __dentry_kill (fs/dcache.c:615:3)<br /> shrink_kill (fs/dcache.c:1060:12)<br /> shrink_dentry_list (fs/dcache.c:1087:3)<br /> prune_dcache_sb (fs/dcache.c:1168:2)<br /> super_cache_scan (fs/super.c:221:10)<br /> do_shrink_slab (mm/shrinker.c:435:9)<br /> shrink_slab (mm/shrinker.c:626:10)<br /> shrink_node (mm/vmscan.c:5951:2)<br /> shrink_zones (mm/vmscan.c:6195:3)<br /> do_try_to_free_pages (mm/vmscan.c:6257:3)<br /> do_swap_page (mm/memory.c:4136:11)<br /> handle_pte_fault (mm/memory.c:5562:10)<br /> handle_mm_fault (mm/memory.c:5870:9)<br /> do_user_addr_fault (arch/x86/mm/fault.c:1338:10)<br /> handle_page_fault (arch/x86/mm/fault.c:1481:3)<br /> exc_page_fault (arch/x86/mm/fault.c:1539:2)<br /> asm_exc_page_fault+0x22/0x27<br /> <br /> Fix this deadlock by allocating ff-&gt;release_args and grabbing the<br /> reference on the inode when preparing the file for release even if the<br /> server does not implement open. The inode reference will be dropped when<br /> the last reference on the fuse file is dropped (see fuse_file_put() -&gt;<br /> fuse_release_end()).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ublk: fix deadlock when reading partition table<br /> <br /> When one process(such as udev) opens ublk block device (e.g., to read<br /> the partition table via bdev_open()), a deadlock[1] can occur:<br /> <br /> 1. bdev_open() grabs disk-&gt;open_mutex<br /> 2. The process issues read I/O to ublk backend to read partition table<br /> 3. In __ublk_complete_rq(), blk_update_request() or blk_mq_end_request()<br /> runs bio-&gt;bi_end_io() callbacks<br /> 4. If this triggers fput() on file descriptor of ublk block device, the<br /> work may be deferred to current task&amp;#39;s task work (see fput() implementation)<br /> 5. This eventually calls blkdev_release() from the same context<br /> 6. blkdev_release() tries to grab disk-&gt;open_mutex again<br /> 7. Deadlock: same task waiting for a mutex it already holds<br /> <br /> The fix is to run blk_update_request() and blk_mq_end_request() with bottom<br /> halves disabled. This forces blkdev_release() to run in kernel work-queue<br /> context instead of current task work context, and allows ublk server to make<br /> forward progress, and avoids the deadlock.<br /> <br /> [axboe: rewrite comment in ublk]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: vfs: fix race on m_flags in vfs_cache<br /> <br /> ksmbd maintains delete-on-close and pending-delete state in<br /> ksmbd_inode-&gt;m_flags. In vfs_cache.c this field is accessed under<br /> inconsistent locking: some paths read and modify m_flags under<br /> ci-&gt;m_lock while others do so without taking the lock at all.<br /> <br /> Examples:<br /> <br /> - ksmbd_query_inode_status() and __ksmbd_inode_close() use<br /> ci-&gt;m_lock when checking or updating m_flags.<br /> - ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(),<br /> ksmbd_clear_inode_pending_delete() and ksmbd_fd_set_delete_on_close()<br /> used to read and modify m_flags without ci-&gt;m_lock.<br /> <br /> This creates a potential data race on m_flags when multiple threads<br /> open, close and delete the same file concurrently. In the worst case<br /> delete-on-close and pending-delete bits can be lost or observed in an<br /> inconsistent state, leading to confusing delete semantics (files that<br /> stay on disk after delete-on-close, or files that disappear while still<br /> in use).<br /> <br /> Fix it by:<br /> <br /> - Making ksmbd_query_inode_status() look at m_flags under ci-&gt;m_lock<br /> after dropping inode_hash_lock.<br /> - Adding ci-&gt;m_lock protection to all helpers that read or modify<br /> m_flags (ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(),<br /> ksmbd_clear_inode_pending_delete(), ksmbd_fd_set_delete_on_close()).<br /> - Keeping the existing ci-&gt;m_lock protection in __ksmbd_inode_close(),<br /> and moving the actual unlink/xattr removal outside the lock.<br /> <br /> This unifies the locking around m_flags and removes the data race while<br /> preserving the existing delete-on-close behaviour.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Disallow toggling KVM_MEM_GUEST_MEMFD on an existing memslot<br /> <br /> Reject attempts to disable KVM_MEM_GUEST_MEMFD on a memslot that was<br /> initially created with a guest_memfd binding, as KVM doesn&amp;#39;t support<br /> toggling KVM_MEM_GUEST_MEMFD on existing memslots. KVM prevents enabling<br /> KVM_MEM_GUEST_MEMFD, but doesn&amp;#39;t prevent clearing the flag.<br /> <br /> Failure to reject the new memslot results in a use-after-free due to KVM<br /> not unbinding from the guest_memfd instance. Unbinding on a FLAGS_ONLY<br /> change is easy enough, and can/will be done as a hardening measure (in<br /> anticipation of KVM supporting dirty logging on guest_memfd at some point),<br /> but fixing the use-after-free would only address the immediate symptom.<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in kvm_gmem_release+0x362/0x400 [kvm]<br /> Write of size 8 at addr ffff8881111ae908 by task repro/745<br /> <br /> CPU: 7 UID: 1000 PID: 745 Comm: repro Not tainted 6.18.0-rc6-115d5de2eef3-next-kasan #3 NONE<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x51/0x60<br /> print_report+0xcb/0x5c0<br /> kasan_report+0xb4/0xe0<br /> kvm_gmem_release+0x362/0x400 [kvm]<br /> __fput+0x2fa/0x9d0<br /> task_work_run+0x12c/0x200<br /> do_exit+0x6ae/0x2100<br /> do_group_exit+0xa8/0x230<br /> __x64_sys_exit_group+0x3a/0x50<br /> x64_sys_call+0x737/0x740<br /> do_syscall_64+0x5b/0x900<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x7f581f2eac31<br /> <br /> <br /> Allocated by task 745 on cpu 6 at 9.746971s:<br /> kasan_save_stack+0x20/0x40<br /> kasan_save_track+0x13/0x50<br /> __kasan_kmalloc+0x77/0x90<br /> kvm_set_memory_region.part.0+0x652/0x1110 [kvm]<br /> kvm_vm_ioctl+0x14b0/0x3290 [kvm]<br /> __x64_sys_ioctl+0x129/0x1a0<br /> do_syscall_64+0x5b/0x900<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> Freed by task 745 on cpu 6 at 9.747467s:<br /> kasan_save_stack+0x20/0x40<br /> kasan_save_track+0x13/0x50<br /> __kasan_save_free_info+0x37/0x50<br /> __kasan_slab_free+0x3b/0x60<br /> kfree+0xf5/0x440<br /> kvm_set_memslot+0x3c2/0x1160 [kvm]<br /> kvm_set_memory_region.part.0+0x86a/0x1110 [kvm]<br /> kvm_vm_ioctl+0x14b0/0x3290 [kvm]<br /> __x64_sys_ioctl+0x129/0x1a0<br /> do_syscall_64+0x5b/0x900<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> svcrdma: use rc_pageoff for memcpy byte offset<br /> <br /> svc_rdma_copy_inline_range added rc_curpage (page index) to the page<br /> base instead of the byte offset rc_pageoff. Use rc_pageoff so copies<br /> land within the current page.<br /> <br /> Found by ZeroPath (https://zeropath.com)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: iris: Add sanity check for stop streaming<br /> <br /> Add sanity check in iris_vb2_stop_streaming. If inst-&gt;state is<br /> already IRIS_INST_ERROR, we should skip the stream_off operation<br /> because it would still send packets to the firmware.<br /> <br /> In iris_kill_session, inst-&gt;state is set to IRIS_INST_ERROR and<br /> session_close is executed, which will kfree(inst_hfi_gen2-&gt;packet).<br /> If stop_streaming is called afterward, it will cause a crash.<br /> <br /> [bod: remove qcom from patch title]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipvs: fix ipv4 null-ptr-deref in route error path<br /> <br /> The IPv4 code path in __ip_vs_get_out_rt() calls dst_link_failure()<br /> without ensuring skb-&gt;dev is set, leading to a NULL pointer dereference<br /> in fib_compute_spec_dst() when ipv4_link_failure() attempts to send<br /> ICMP destination unreachable messages.<br /> <br /> The issue emerged after commit ed0de45a1008 ("ipv4: recompile ip options<br /> in ipv4_link_failure") started calling __ip_options_compile() from<br /> ipv4_link_failure(). This code path eventually calls fib_compute_spec_dst()<br /> which dereferences skb-&gt;dev. An attempt was made to fix the NULL skb-&gt;dev<br /> dereference in commit 0113d9c9d1cc ("ipv4: fix null-deref in<br /> ipv4_link_failure"), but it only addressed the immediate dev_net(skb-&gt;dev)<br /> dereference by using a fallback device. The fix was incomplete because<br /> fib_compute_spec_dst() later in the call chain still accesses skb-&gt;dev<br /> directly, which remains NULL when IPVS calls dst_link_failure().<br /> <br /> The crash occurs when:<br /> 1. IPVS processes a packet in NAT mode with a misconfigured destination<br /> 2. Route lookup fails in __ip_vs_get_out_rt() before establishing a route<br /> 3. The error path calls dst_link_failure(skb) with skb-&gt;dev == NULL<br /> 4. ipv4_link_failure() → ipv4_send_dest_unreach() →<br /> __ip_options_compile() → fib_compute_spec_dst()<br /> 5. fib_compute_spec_dst() dereferences NULL skb-&gt;dev<br /> <br /> Apply the same fix used for IPv6 in commit 326bf17ea5d4 ("ipvs: fix<br /> ipv6 route unreach panic"): set skb-&gt;dev from skb_dst(skb)-&gt;dev before<br /> calling dst_link_failure().<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000328-0x000000000000032f]<br /> CPU: 1 PID: 12732 Comm: syz.1.3469 Not tainted 6.6.114 #2<br /> RIP: 0010:__in_dev_get_rcu include/linux/inetdevice.h:233<br /> RIP: 0010:fib_compute_spec_dst+0x17a/0x9f0 net/ipv4/fib_frontend.c:285<br /> Call Trace:<br /> <br /> spec_dst_fill net/ipv4/ip_options.c:232<br /> spec_dst_fill net/ipv4/ip_options.c:229<br /> __ip_options_compile+0x13a1/0x17d0 net/ipv4/ip_options.c:330<br /> ipv4_send_dest_unreach net/ipv4/route.c:1252<br /> ipv4_link_failure+0x702/0xb80 net/ipv4/route.c:1265<br /> dst_link_failure include/net/dst.h:437<br /> __ip_vs_get_out_rt+0x15fd/0x19e0 net/netfilter/ipvs/ip_vs_xmit.c:412<br /> ip_vs_nat_xmit+0x1d8/0xc80 net/netfilter/ipvs/ip_vs_xmit.c:764

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: fix filename leak in __io_openat_prep()<br /> <br /> __io_openat_prep() allocates a struct filename using getname(). However,<br /> for the condition of the file being installed in the fixed file table as<br /> well as having O_CLOEXEC flag set, the function returns early. At that<br /> point, the request doesn&amp;#39;t have REQ_F_NEED_CLEANUP flag set. Due to this,<br /> the memory for the newly allocated struct filename is not cleaned up,<br /> causing a memory leak.<br /> <br /> Fix this by setting the REQ_F_NEED_CLEANUP for the request just after the<br /> successful getname() call, so that when the request is torn down, the<br /> filename will be cleaned up, along with other resources needing cleanup.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: ets: Remove drr class from the active list if it changes to strict<br /> <br /> Whenever a user issues an ets qdisc change command, transforming a<br /> drr class into a strict one, the ets code isn&amp;#39;t checking whether that<br /> class was in the active list and removing it. This means that, if a<br /> user changes a strict class (which was in the active list) back to a drr<br /> one, that class will be added twice to the active list [1].<br /> <br /> Doing so with the following commands:<br /> <br /> tc qdisc add dev lo root handle 1: ets bands 2 strict 1<br /> tc qdisc add dev lo parent 1:2 handle 20: \<br /> tbf rate 8bit burst 100b latency 1s<br /> tc filter add dev lo parent 1: basic classid 1:2<br /> ping -c1 -W0.01 -s 56 127.0.0.1<br /> tc qdisc change dev lo root handle 1: ets bands 2 strict 2<br /> tc qdisc change dev lo root handle 1: ets bands 2 strict 1<br /> ping -c1 -W0.01 -s 56 127.0.0.1<br /> <br /> Will trigger the following splat with list debug turned on:<br /> <br /> [ 59.279014][ T365] ------------[ cut here ]------------<br /> [ 59.279452][ T365] list_add double add: new=ffff88801d60e350, prev=ffff88801d60e350, next=ffff88801d60e2c0.<br /> [ 59.280153][ T365] WARNING: CPU: 3 PID: 365 at lib/list_debug.c:35 __list_add_valid_or_report+0x17f/0x220<br /> [ 59.280860][ T365] Modules linked in:<br /> [ 59.281165][ T365] CPU: 3 UID: 0 PID: 365 Comm: tc Not tainted 6.18.0-rc7-00105-g7e9f13163c13-dirty #239 PREEMPT(voluntary)<br /> [ 59.281977][ T365] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011<br /> [ 59.282391][ T365] RIP: 0010:__list_add_valid_or_report+0x17f/0x220<br /> [ 59.282842][ T365] Code: 89 c6 e8 d4 b7 0d ff 90 0f 0b 90 90 31 c0 e9 31 ff ff ff 90 48 c7 c7 e0 a0 22 9f 48 89 f2 48 89 c1 4c 89 c6 e8 b2 b7 0d ff 90 0b 90 90 31 c0 e9 0f ff ff ff 48 89 f7 48 89 44 24 10 4c 89 44<br /> ...<br /> [ 59.288812][ T365] Call Trace:<br /> [ 59.289056][ T365] <br /> [ 59.289224][ T365] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 59.289546][ T365] ets_qdisc_change+0xd2b/0x1e80<br /> [ 59.289891][ T365] ? __lock_acquire+0x7e7/0x1be0<br /> [ 59.290223][ T365] ? __pfx_ets_qdisc_change+0x10/0x10<br /> [ 59.290546][ T365] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 59.290898][ T365] ? __mutex_trylock_common+0xda/0x240<br /> [ 59.291228][ T365] ? __pfx___mutex_trylock_common+0x10/0x10<br /> [ 59.291655][ T365] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 59.291993][ T365] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 59.292313][ T365] ? trace_contention_end+0xc8/0x110<br /> [ 59.292656][ T365] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 59.293022][ T365] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 59.293351][ T365] tc_modify_qdisc+0x63a/0x1cf0<br /> <br /> Fix this by always checking and removing an ets class from the active list<br /> when changing it to strict.<br /> <br /> [1] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/tree/net/sched/sch_ets.c?id=ce052b9402e461a9aded599f5b47e76bc727f7de#n663