Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ptp: Add a upper bound on max_vclocks<br /> <br /> syzbot reported WARNING in max_vclocks_store.<br /> <br /> This occurs when the argument max is too large for kcalloc to handle.<br /> <br /> Extend the guard to guard against values that are too large for<br /> kcalloc

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Disallow dirty tracking if incoherent page walk<br /> <br /> Dirty page tracking relies on the IOMMU atomically updating the dirty bit<br /> in the paging-structure entry. For this operation to succeed, the paging-<br /> structure memory must be coherent between the IOMMU and the CPU. In<br /> another word, if the iommu page walk is incoherent, dirty page tracking<br /> doesn&amp;#39;t work.<br /> <br /> The Intel VT-d specification, Section 3.10 "Snoop Behavior" states:<br /> <br /> "Remapping hardware encountering the need to atomically update A/EA/D bits<br /> in a paging-structure entry that is not snooped will result in a non-<br /> recoverable fault."<br /> <br /> To prevent an IOMMU from being incorrectly configured for dirty page<br /> tracking when it is operating in an incoherent mode, mark SSADS as<br /> supported only when both ecap_slads and ecap_smpwc are supported.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> coresight: Fix incorrect handling for return value of devm_kzalloc<br /> <br /> The return value of devm_kzalloc could be an null pointer,<br /> use "!desc.pdata" to fix incorrect handling return value<br /> of devm_kzalloc.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> coresight: trbe: Return NULL pointer for allocation failures<br /> <br /> When the TRBE driver fails to allocate a buffer, it currently returns<br /> the error code "-ENOMEM". However, the caller etm_setup_aux() only<br /> checks for a NULL pointer, so it misses the error. As a result, the<br /> driver continues and eventually causes a kernel panic.<br /> <br /> Fix this by returning a NULL pointer from arm_trbe_alloc_buffer() on<br /> allocation failures. This allows that the callers can properly handle<br /> the failure.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Fix race in do_task() when draining<br /> <br /> When do_task() exhausts its iteration budget (!ret), it sets the state<br /> to TASK_STATE_IDLE to reschedule, without a secondary check on the<br /> current task-&gt;state. This can overwrite the TASK_STATE_DRAINING state<br /> set by a concurrent call to rxe_cleanup_task() or rxe_disable_task().<br /> <br /> While state changes are protected by a spinlock, both rxe_cleanup_task()<br /> and rxe_disable_task() release the lock while waiting for the task to<br /> finish draining in the while(!is_done(task)) loop. The race occurs if<br /> do_task() hits its iteration limit and acquires the lock in this window.<br /> The cleanup logic may then proceed while the task incorrectly<br /> reschedules itself, leading to a potential use-after-free.<br /> <br /> This bug was introduced during the migration from tasklets to workqueues,<br /> where the special handling for the draining case was lost.<br /> <br /> Fix this by restoring the original pre-migration behavior. If the state is<br /> TASK_STATE_DRAINING when iterations are exhausted, set cont to 1 to<br /> force a new loop iteration. This allows the task to finish its work, so<br /> that a subsequent iteration can reach the switch statement and correctly<br /> transition the state to TASK_STATE_DRAINED, stopping the task as intended.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: hisilicon/qm - set NULL to qm-&gt;debug.qm_diff_regs<br /> <br /> When the initialization of qm-&gt;debug.acc_diff_reg fails,<br /> the probe process does not exit. However, after qm-&gt;debug.qm_diff_regs is<br /> freed, it is not set to NULL. This can lead to a double free when the<br /> remove process attempts to free it again. Therefore, qm-&gt;debug.qm_diff_regs<br /> should be set to NULL after it is freed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: comp - Use same definition of context alloc and free ops<br /> <br /> In commit 42d9f6c77479 ("crypto: acomp - Move scomp stream allocation<br /> code into acomp"), the crypto_acomp_streams struct was made to rely on<br /> having the alloc_ctx and free_ctx operations defined in the same order<br /> as the scomp_alg struct. But in that same commit, the alloc_ctx and<br /> free_ctx members of scomp_alg may be randomized by structure layout<br /> randomization, since they are contained in a pure ops structure<br /> (containing only function pointers). If the pointers within scomp_alg<br /> are randomized, but those in crypto_acomp_streams are not, then<br /> the order may no longer match. This fixes the problem by removing the<br /> union from scomp_alg so that both crypto_acomp_streams and scomp_alg<br /> will share the same definition of alloc_ctx and free_ctx, ensuring<br /> they will always have the same layout.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smc: Fix use-after-free in __pnet_find_base_ndev().<br /> <br /> syzbot reported use-after-free of net_device in __pnet_find_base_ndev(),<br /> which was called during connect(). [0]<br /> <br /> smc_pnet_find_ism_resource() fetches sk_dst_get(sk)-&gt;dev and passes<br /> down to pnet_find_base_ndev(), where RTNL is held. Then, UAF happened<br /> at __pnet_find_base_ndev() when the dev is first used.<br /> <br /> This means dev had already been freed before acquiring RTNL in<br /> pnet_find_base_ndev().<br /> <br /> While dev is going away, dst-&gt;dev could be swapped with blackhole_netdev,<br /> and the dev&amp;#39;s refcnt by dst will be released.<br /> <br /> We must hold dev&amp;#39;s refcnt before calling smc_pnet_find_ism_resource().<br /> <br /> Also, smc_pnet_find_roce_resource() has the same problem.<br /> <br /> Let&amp;#39;s use __sk_dst_get() and dst_dev_rcu() in the two functions.<br /> <br /> [0]:<br /> BUG: KASAN: use-after-free in __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926<br /> Read of size 1 at addr ffff888036bac33a by task syz.0.3632/18609<br /> <br /> CPU: 1 UID: 0 PID: 18609 Comm: syz.0.3632 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0xca/0x240 mm/kasan/report.c:482<br /> kasan_report+0x118/0x150 mm/kasan/report.c:595<br /> __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926<br /> pnet_find_base_ndev net/smc/smc_pnet.c:946 [inline]<br /> smc_pnet_find_ism_by_pnetid net/smc/smc_pnet.c:1103 [inline]<br /> smc_pnet_find_ism_resource+0xef/0x390 net/smc/smc_pnet.c:1154<br /> smc_find_ism_device net/smc/af_smc.c:1030 [inline]<br /> smc_find_proposal_devices net/smc/af_smc.c:1115 [inline]<br /> __smc_connect+0x372/0x1890 net/smc/af_smc.c:1545<br /> smc_connect+0x877/0xd90 net/smc/af_smc.c:1715<br /> __sys_connect_file net/socket.c:2086 [inline]<br /> __sys_connect+0x313/0x440 net/socket.c:2105<br /> __do_sys_connect net/socket.c:2111 [inline]<br /> __se_sys_connect net/socket.c:2108 [inline]<br /> __x64_sys_connect+0x7a/0x90 net/socket.c:2108<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f47cbf8eba9<br /> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f47ccdb1038 EFLAGS: 00000246 ORIG_RAX: 000000000000002a<br /> RAX: ffffffffffffffda RBX: 00007f47cc1d5fa0 RCX: 00007f47cbf8eba9<br /> RDX: 0000000000000010 RSI: 0000200000000280 RDI: 000000000000000b<br /> RBP: 00007f47cc011e19 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007f47cc1d6038 R14: 00007f47cc1d5fa0 R15: 00007ffc512f8aa8<br /> <br /> <br /> The buggy address belongs to the physical page:<br /> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888036bacd00 pfn:0x36bac<br /> flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)<br /> raw: 00fff00000000000 ffffea0001243d08 ffff8880b863fdc0 0000000000000000<br /> raw: ffff888036bacd00 0000000000000000 00000000ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> page_owner tracks the page as freed<br /> page last allocated via order 2, migratetype Unmovable, gfp_mask 0x446dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOWARN|__GFP_RETRY_MAYFAIL|__GFP_COMP), pid 16741, tgid 16741 (syz-executor), ts 343313197788, free_ts 380670750466<br /> set_page_owner include/linux/page_owner.h:32 [inline]<br /> post_alloc_hook+0x240/0x2a0 mm/page_alloc.c:1851<br /> prep_new_page mm/page_alloc.c:1859 [inline]<br /> get_page_from_freelist+0x21e4/0x22c0 mm/page_alloc.c:3858<br /> __alloc_frozen_pages_noprof+0x181/0x370 mm/page_alloc.c:5148<br /> alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2416<br /> ___kmalloc_large_node+0x5f/0x1b0 mm/slub.c:4317<br /> __kmalloc_large_node_noprof+0x18/0x90 mm/slub.c:4348<br /> __do_kmalloc_node mm/slub.c:4364 [inline]<br /> __kvmalloc_node<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RISC-V: KVM: Write hgatp register with valid mode bits<br /> <br /> According to the RISC-V Privileged Architecture Spec, when MODE=Bare<br /> is selected,software must write zero to the remaining fields of hgatp.<br /> <br /> We have detected the valid mode supported by the HW before, So using a<br /> valid mode to detect how many vmid bits are supported.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Squashfs: fix uninit-value in squashfs_get_parent<br /> <br /> Syzkaller reports a "KMSAN: uninit-value in squashfs_get_parent" bug.<br /> <br /> This is caused by open_by_handle_at() being called with a file handle<br /> containing an invalid parent inode number. In particular the inode number<br /> is that of a symbolic link, rather than a directory.<br /> <br /> Squashfs_get_parent() gets called with that symbolic link inode, and<br /> accesses the parent member field.<br /> <br /> unsigned int parent_ino = squashfs_i(inode)-&gt;parent;<br /> <br /> Because non-directory inodes in Squashfs do not have a parent value, this<br /> is uninitialised, and this causes an uninitialised value access.<br /> <br /> The fix is to initialise parent with the invalid inode 0, which will cause<br /> an EINVAL error to be returned.<br /> <br /> Regular inodes used to share the parent field with the block_list_start<br /> field. This is removed in this commit to enable the parent field to<br /> contain the invalid inode number 0.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Skip scalar adjustment for BPF_NEG if dst is a pointer<br /> <br /> In check_alu_op(), the verifier currently calls check_reg_arg() and<br /> adjust_scalar_min_max_vals() unconditionally for BPF_NEG operations.<br /> However, if the destination register holds a pointer, these scalar<br /> adjustments are unnecessary and potentially incorrect.<br /> <br /> This patch adds a check to skip the adjustment logic when the destination<br /> register contains a pointer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vhost: vringh: Modify the return value check<br /> <br /> The return value of copy_from_iter and copy_to_iter can&amp;#39;t be negative,<br /> check whether the copied lengths are equal.