Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cgroup/dmem: avoid pool UAF<br /> <br /> An UAF issue was observed:<br /> <br /> BUG: KASAN: slab-use-after-free in page_counter_uncharge+0x65/0x150<br /> Write of size 8 at addr ffff888106715440 by task insmod/527<br /> <br /> CPU: 4 UID: 0 PID: 527 Comm: insmod 6.19.0-rc7-next-20260129+ #11<br /> Tainted: [O]=OOT_MODULE<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x82/0xd0<br /> kasan_report+0xca/0x100<br /> kasan_check_range+0x39/0x1c0<br /> page_counter_uncharge+0x65/0x150<br /> dmem_cgroup_uncharge+0x1f/0x260<br /> <br /> Allocated by task 527:<br /> <br /> Freed by task 0:<br /> <br /> The buggy address belongs to the object at ffff888106715400<br /> which belongs to the cache kmalloc-512 of size 512<br /> The buggy address is located 64 bytes inside of<br /> freed 512-byte region [ffff888106715400, ffff888106715600)<br /> <br /> The buggy address belongs to the physical page:<br /> <br /> Memory state around the buggy address:<br /> ffff888106715300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> ffff888106715380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> &gt;ffff888106715400: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ^<br /> ffff888106715480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ffff888106715500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> <br /> The issue occurs because a pool can still be held by a caller after its<br /> associated memory region is unregistered. The current implementation frees<br /> the pool even if users still hold references to it (e.g., before uncharge<br /> operations complete).<br /> <br /> This patch adds a reference counter to each pool, ensuring that a pool is<br /> only freed when its reference count drops to zero.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: Intel-thc-hid: Intel-thc: Add safety check for reading DMA buffer<br /> <br /> Add DMA buffer readiness check before reading DMA buffer to avoid<br /> unexpected NULL pointer accessing.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: imx: preserve error state in block data length handler<br /> <br /> When a block read returns an invalid length, zero or &gt;I2C_SMBUS_BLOCK_MAX,<br /> the length handler sets the state to IMX_I2C_STATE_FAILED. However,<br /> i2c_imx_master_isr() unconditionally overwrites this with<br /> IMX_I2C_STATE_READ_CONTINUE, causing an endless read loop that overruns<br /> buffers and crashes the system.<br /> <br /> Guard the state transition to preserve error states set by the length<br /> handler.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Don&amp;#39;t clobber irqfd routing type when deassigning irqfd<br /> <br /> When deassigning a KVM_IRQFD, don&amp;#39;t clobber the irqfd&amp;#39;s copy of the IRQ&amp;#39;s<br /> routing entry as doing so breaks kvm_arch_irq_bypass_del_producer() on x86<br /> and arm64, which explicitly look for KVM_IRQ_ROUTING_MSI. Instead, to<br /> handle a concurrent routing update, verify that the irqfd is still active<br /> before consuming the routing information. As evidenced by the x86 and<br /> arm64 bugs, and another bug in kvm_arch_update_irqfd_routing() (see below),<br /> clobbering the entry type without notifying arch code is surprising and<br /> error prone.<br /> <br /> As a bonus, checking that the irqfd is active provides a convenient<br /> location for documenting _why_ KVM must not consume the routing entry for<br /> an irqfd that is in the process of being deassigned: once the irqfd is<br /> deleted from the list (which happens *before* the eventfd is detached), it<br /> will no longer receive updates via kvm_irq_routing_update(), and so KVM<br /> could deliver an event using stale routing information (relative to<br /> KVM_SET_GSI_ROUTING returning to userspace).<br /> <br /> As an even better bonus, explicitly checking for the irqfd being active<br /> fixes a similar bug to the one the clobbering is trying to prevent: if an<br /> irqfd is deactivated, and then its routing is changed,<br /> kvm_irq_routing_update() won&amp;#39;t invoke kvm_arch_update_irqfd_routing()<br /> (because the irqfd isn&amp;#39;t in the list). And so if the irqfd is in bypass<br /> mode, IRQs will continue to be posted using the old routing information.<br /> <br /> As for kvm_arch_irq_bypass_del_producer(), clobbering the routing type<br /> results in KVM incorrectly keeping the IRQ in bypass mode, which is<br /> especially problematic on AMD as KVM tracks IRQs that are being posted to<br /> a vCPU in a list whose lifetime is tied to the irqfd.<br /> <br /> Without the help of KASAN to detect use-after-free, the most common<br /> sympton on AMD is a NULL pointer deref in amd_iommu_update_ga() due to<br /> the memory for irqfd structure being re-allocated and zeroed, resulting<br /> in irqfd-&gt;irq_bypass_data being NULL when read by<br /> avic_update_iommu_vcpu_affinity():<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000018<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 40cf2b9067 P4D 40cf2b9067 PUD 408362a067 PMD 0<br /> Oops: Oops: 0000 [#1] SMP<br /> CPU: 6 UID: 0 PID: 40383 Comm: vfio_irq_test<br /> Tainted: G U W O 6.19.0-smp--5dddc257e6b2-irqfd #31 NONE<br /> Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE<br /> Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025<br /> RIP: 0010:amd_iommu_update_ga+0x19/0xe0<br /> Call Trace:<br /> <br /> avic_update_iommu_vcpu_affinity+0x3d/0x90 [kvm_amd]<br /> __avic_vcpu_load+0xf4/0x130 [kvm_amd]<br /> kvm_arch_vcpu_load+0x89/0x210 [kvm]<br /> vcpu_load+0x30/0x40 [kvm]<br /> kvm_arch_vcpu_ioctl_run+0x45/0x620 [kvm]<br /> kvm_vcpu_ioctl+0x571/0x6a0 [kvm]<br /> __se_sys_ioctl+0x6d/0xb0<br /> do_syscall_64+0x6f/0x9d0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x46893b<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> <br /> If AVIC is inhibited when the irfd is deassigned, the bug will manifest as<br /> list corruption, e.g. on the next irqfd assignment.<br /> <br /> list_add corruption. next-&gt;prev should be prev (ffff8d474d5cd588),<br /> but was 0000000000000000. (next=ffff8d8658f86530).<br /> ------------[ cut here ]------------<br /> kernel BUG at lib/list_debug.c:31!<br /> Oops: invalid opcode: 0000 [#1] SMP<br /> CPU: 128 UID: 0 PID: 80818 Comm: vfio_irq_test<br /> Tainted: G U W O 6.19.0-smp--f19dc4d680ba-irqfd #28 NONE<br /> Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE<br /> Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025<br /> RIP: 0010:__list_add_valid_or_report+0x97/0xc0<br /> Call Trace:<br /> <br /> avic_pi_update_irte+0x28e/0x2b0 [kvm_amd]<br /> kvm_pi_update_irte+0xbf/0x190 [kvm]<br /> kvm_arch_irq_bypass_add_producer+0x72/0x90 [kvm]<br /> irq_bypass_register_consumer+0xcd/0x170 [irqbypa<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> procfs: avoid fetching build ID while holding VMA lock<br /> <br /> Fix PROCMAP_QUERY to fetch optional build ID only after dropping mmap_lock<br /> or per-VMA lock, whichever was used to lock VMA under question, to avoid<br /> deadlock reported by syzbot:<br /> <br /> -&gt; #1 (&amp;mm-&gt;mmap_lock){++++}-{4:4}:<br /> __might_fault+0xed/0x170<br /> _copy_to_iter+0x118/0x1720<br /> copy_page_to_iter+0x12d/0x1e0<br /> filemap_read+0x720/0x10a0<br /> blkdev_read_iter+0x2b5/0x4e0<br /> vfs_read+0x7f4/0xae0<br /> ksys_read+0x12a/0x250<br /> do_syscall_64+0xcb/0xf80<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> -&gt; #0 (&amp;sb-&gt;s_type-&gt;i_mutex_key#8){++++}-{4:4}:<br /> __lock_acquire+0x1509/0x26d0<br /> lock_acquire+0x185/0x340<br /> down_read+0x98/0x490<br /> blkdev_read_iter+0x2a7/0x4e0<br /> __kernel_read+0x39a/0xa90<br /> freader_fetch+0x1d5/0xa80<br /> __build_id_parse.isra.0+0xea/0x6a0<br /> do_procmap_query+0xd75/0x1050<br /> procfs_procmap_ioctl+0x7a/0xb0<br /> __x64_sys_ioctl+0x18e/0x210<br /> do_syscall_64+0xcb/0xf80<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> other info that might help us debug this:<br /> <br /> Possible unsafe locking scenario:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> rlock(&amp;mm-&gt;mmap_lock);<br /> lock(&amp;sb-&gt;s_type-&gt;i_mutex_key#8);<br /> lock(&amp;mm-&gt;mmap_lock);<br /> rlock(&amp;sb-&gt;s_type-&gt;i_mutex_key#8);<br /> <br /> *** DEADLOCK ***<br /> <br /> This seems to be exacerbated (as we haven&amp;#39;t seen these syzbot reports<br /> before that) by the recent:<br /> <br /> 777a8560fd29 ("lib/buildid: use __kernel_read() for sleepable context")<br /> <br /> To make this safe, we need to grab file refcount while VMA is still locked, but<br /> other than that everything is pretty straightforward. Internal build_id_parse()<br /> API assumes VMA is passed, but it only needs the underlying file reference, so<br /> just add another variant build_id_parse_file() that expects file passed<br /> directly.<br /> <br /> [akpm@linux-foundation.org: fix up kerneldoc]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: Fix ECMP sibling count mismatch when clearing RTF_ADDRCONF<br /> <br /> syzbot reported a kernel BUG in fib6_add_rt2node() when adding an IPv6<br /> route. [0]<br /> <br /> Commit f72514b3c569 ("ipv6: clear RA flags when adding a static<br /> route") introduced logic to clear RTF_ADDRCONF from existing routes<br /> when a static route with the same nexthop is added. However, this<br /> causes a problem when the existing route has a gateway.<br /> <br /> When RTF_ADDRCONF is cleared from a route that has a gateway, that<br /> route becomes eligible for ECMP, i.e. rt6_qualify_for_ecmp() returns<br /> true. The issue is that this route was never added to the<br /> fib6_siblings list.<br /> <br /> This leads to a mismatch between the following counts:<br /> <br /> - The sibling count computed by iterating fib6_next chain, which<br /> includes the newly ECMP-eligible route<br /> <br /> - The actual siblings in fib6_siblings list, which does not include<br /> that route<br /> <br /> When a subsequent ECMP route is added, fib6_add_rt2node() hits<br /> BUG_ON(sibling-&gt;fib6_nsiblings != rt-&gt;fib6_nsiblings) because the<br /> counts don&amp;#39;t match.<br /> <br /> Fix this by only clearing RTF_ADDRCONF when the existing route does<br /> not have a gateway. Routes without a gateway cannot qualify for ECMP<br /> anyway (rt6_qualify_for_ecmp() requires fib_nh_gw_family), so clearing<br /> RTF_ADDRCONF on them is safe and matches the original intent of the<br /> commit.<br /> <br /> [0]:<br /> kernel BUG at net/ipv6/ip6_fib.c:1217!<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN PTI<br /> CPU: 0 UID: 0 PID: 6010 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025<br /> RIP: 0010:fib6_add_rt2node+0x3433/0x3470 net/ipv6/ip6_fib.c:1217<br /> [...]<br /> Call Trace:<br /> <br /> fib6_add+0x8da/0x18a0 net/ipv6/ip6_fib.c:1532<br /> __ip6_ins_rt net/ipv6/route.c:1351 [inline]<br /> ip6_route_add+0xde/0x1b0 net/ipv6/route.c:3946<br /> ipv6_route_ioctl+0x35c/0x480 net/ipv6/route.c:4571<br /> inet6_ioctl+0x219/0x280 net/ipv6/af_inet6.c:577<br /> sock_do_ioctl+0xdc/0x300 net/socket.c:1245<br /> sock_ioctl+0x576/0x790 net/socket.c:1366<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:597 [inline]<br /> __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: fix oops due to invalid pointer for kfree() in parse_longname()<br /> <br /> This fixes a kernel oops when reading ceph snapshot directories (.snap),<br /> for example by simply running `ls /mnt/my_ceph/.snap`.<br /> <br /> The variable str is guarded by __free(kfree), but advanced by one for<br /> skipping the initial &amp;#39;_&amp;#39; in snapshot names. Thus, kfree() is called<br /> with an invalid pointer. This patch removes the need for advancing the<br /> pointer so kfree() is called with correct memory pointer.<br /> <br /> Steps to reproduce:<br /> <br /> 1. Create snapshots on a cephfs volume (I&amp;#39;ve 63 snaps in my testcase)<br /> <br /> 2. Add cephfs mount to fstab<br /> $ echo "samba-fileserver@.files=/volumes/datapool/stuff/3461082b-ecc9-4e82-8549-3fd2590d3fb6 /mnt/test/stuff ceph acl,noatime,_netdev 0 0" &gt;&gt; /etc/fstab<br /> <br /> 3. Reboot the system<br /> $ systemctl reboot<br /> <br /> 4. Check if it&amp;#39;s really mounted<br /> $ mount | grep stuff<br /> <br /> 5. List snapshots (expected 63 snapshots on my system)<br /> $ ls /mnt/test/stuff/.snap<br /> <br /> Now ls hangs forever and the kernel log shows the oops.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cgroup/dmem: fix NULL pointer dereference when setting max<br /> <br /> An issue was triggered:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> CPU: 15 UID: 0 PID: 658 Comm: bash Tainted: 6.19.0-rc6-next-2026012<br /> Tainted: [O]=OOT_MODULE<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),<br /> RIP: 0010:strcmp+0x10/0x30<br /> RSP: 0018:ffffc900017f7dc0 EFLAGS: 00000246<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff888107cd4358<br /> RDX: 0000000019f73907 RSI: ffffffff82cc381a RDI: 0000000000000000<br /> RBP: ffff8881016bef0d R08: 000000006c0e7145 R09: 0000000056c0e714<br /> R10: 0000000000000001 R11: ffff888107cd4358 R12: 0007ffffffffffff<br /> R13: ffff888101399200 R14: ffff888100fcb360 R15: 0007ffffffffffff<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 0000000105c79000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> dmemcg_limit_write.constprop.0+0x16d/0x390<br /> ? __pfx_set_resource_max+0x10/0x10<br /> kernfs_fop_write_iter+0x14e/0x200<br /> vfs_write+0x367/0x510<br /> ksys_write+0x66/0xe0<br /> do_syscall_64+0x6b/0x390<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7f42697e1887<br /> <br /> It was trriggered setting max without limitation, the command is like:<br /> "echo test/region0 &gt; dmem.max". To fix this issue, add check whether<br /> options is valid after parsing the region_name.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binder: fix UAF in binder_netlink_report()<br /> <br /> Oneway transactions sent to frozen targets via binder_proc_transaction()<br /> return a BR_TRANSACTION_PENDING_FROZEN error but they are still treated<br /> as successful since the target is expected to thaw at some point. It is<br /> then not safe to access &amp;#39;t&amp;#39; after BR_TRANSACTION_PENDING_FROZEN errors<br /> as the transaction could have been consumed by the now thawed target.<br /> <br /> This is the case for binder_netlink_report() which derreferences &amp;#39;t&amp;#39;<br /> after a pending frozen error, as pointed out by the following KASAN<br /> report:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in binder_netlink_report.isra.0+0x694/0x6c8<br /> Read of size 8 at addr ffff00000f98ba38 by task binder-util/522<br /> <br /> CPU: 4 UID: 0 PID: 522 Comm: binder-util Not tainted 6.19.0-rc6-00015-gc03e9c42ae8f #1 PREEMPT<br /> Hardware name: linux,dummy-virt (DT)<br /> Call trace:<br /> binder_netlink_report.isra.0+0x694/0x6c8<br /> binder_transaction+0x66e4/0x79b8<br /> binder_thread_write+0xab4/0x4440<br /> binder_ioctl+0x1fd4/0x2940<br /> [...]<br /> <br /> Allocated by task 522:<br /> __kmalloc_cache_noprof+0x17c/0x50c<br /> binder_transaction+0x584/0x79b8<br /> binder_thread_write+0xab4/0x4440<br /> binder_ioctl+0x1fd4/0x2940<br /> [...]<br /> <br /> Freed by task 488:<br /> kfree+0x1d0/0x420<br /> binder_free_transaction+0x150/0x234<br /> binder_thread_read+0x2d08/0x3ce4<br /> binder_ioctl+0x488/0x2940<br /> [...]<br /> ==================================================================<br /> <br /> Instead, make a transaction copy so the data can be safely accessed by<br /> binder_netlink_report() after a pending frozen error. While here, add a<br /> comment about not using t-&gt;buffer in binder_netlink_report().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mld: cancel mlo_scan_start_wk<br /> <br /> mlo_scan_start_wk is not canceled on disconnection. In fact, it is not<br /> canceled anywhere except in the restart cleanup, where we don&amp;#39;t really<br /> have to.<br /> <br /> This can cause an init-after-queue issue: if, for example, the work was<br /> queued and then drv_change_interface got executed.<br /> <br /> This can also cause use-after-free: if the work is executed after the<br /> vif is freed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (acpi_power_meter) Fix deadlocks related to acpi_power_meter_notify()<br /> <br /> The acpi_power_meter driver&amp;#39;s .notify() callback function,<br /> acpi_power_meter_notify(), calls hwmon_device_unregister() under a lock<br /> that is also acquired by callbacks in sysfs attributes of the device<br /> being unregistered which is prone to deadlocks between sysfs access and<br /> device removal.<br /> <br /> Address this by moving the hwmon device removal in<br /> acpi_power_meter_notify() outside the lock in question, but notice<br /> that doing it alone is not sufficient because two concurrent<br /> METER_NOTIFY_CONFIG notifications may be attempting to remove the<br /> same device at the same time. To prevent that from happening, add a<br /> new lock serializing the execution of the switch () statement in<br /> acpi_power_meter_notify(). For simplicity, it is a static mutex<br /> which should not be a problem from the performance perspective.<br /> <br /> The new lock also allows the hwmon_device_register_with_info()<br /> in acpi_power_meter_notify() to be called outside the inner lock<br /> because it prevents the other notifications handled by that function<br /> from manipulating the "resource" object while the hwmon device based<br /> on it is being registered. The sending of ACPI netlink messages from<br /> acpi_power_meter_notify() is serialized by the new lock too which<br /> generally helps to ensure that the order of handling firmware<br /> notifications is the same as the order of sending netlink messages<br /> related to them.<br /> <br /> In addition, notice that hwmon_device_register_with_info() may fail<br /> in which case resource-&gt;hwmon_dev will become an error pointer,<br /> so add checks to avoid attempting to unregister the hwmon device<br /> pointer to by it in that case to acpi_power_meter_notify() and<br /> acpi_power_meter_remove().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pmdomain: imx8m-blk-ctrl: fix out-of-range access of bc-&gt;domains<br /> <br /> Fix out-of-range access of bc-&gt;domains in imx8m_blk_ctrl_remove().