Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: parsers: Fix memory leak in mtd_parser_tplink_safeloader_parse()<br /> <br /> The function mtd_parser_tplink_safeloader_parse() allocates buf via<br /> mtd_parser_tplink_safeloader_read_table(). If the allocation for<br /> parts[idx].name fails inside the loop, the code jumps to the err_free<br /> label without freeing buf, leading to a memory leak.<br /> <br /> Fix this by freeing the temporary buffer buf in the err_free label.<br /> <br /> Compile tested only. Issue found using a prototype static analysis tool<br /> and code review.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "hwmon: (ibmpex) fix use-after-free in high/low store"<br /> <br /> This reverts commit 6946c726c3f4c36f0f049e6f97e88c510b15f65d.<br /> <br /> Jean Delvare points out that the patch does not completely<br /> fix the reported problem, that it in fact introduces a<br /> (new) race condition, and that it may actually not be needed in<br /> the first place.<br /> <br /> Various AI reviews agree. Specific and relevant AI feedback:<br /> <br /> "<br /> This reordering sets the driver data to NULL before removing the sensor<br /> attributes in the loop below.<br /> <br /> ibmpex_show_sensor() retrieves this driver data via dev_get_drvdata() but<br /> does not check if it is NULL before dereferencing it to access<br /> data-&gt;sensors[].<br /> <br /> If a userspace process reads a sensor file (like temp1_input) while this<br /> delete function is running, could it race with the dev_set_drvdata(...,<br /> NULL) call here and crash in ibmpex_show_sensor()?<br /> <br /> Would it be safer to keep the original order where device_remove_file() is<br /> called before clearing the driver data? device_remove_file() should wait<br /> for any active sysfs callbacks to complete, which might already prevent the<br /> use-after-free this patch intends to fix.<br /> "<br /> <br /> Revert the offending patch. If it can be shown that the originally reported<br /> alleged race condition does indeed exist, it can always be re-introduced<br /> with a complete fix.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bridge: mcast: always update mdb_n_entries for vlan contexts<br /> <br /> syzbot triggered a warning[1] about the number of mdb entries in a context.<br /> It turned out that there are multiple ways to trigger that warning today<br /> (some got added during the years), the root cause of the problem is that<br /> the increase is done conditionally, and over the years these different<br /> conditions increased so there were new ways to trigger the warning, that is<br /> to do a decrease which wasn&amp;#39;t paired with a previous increase.<br /> <br /> For example one way to trigger it is with flush:<br /> $ ip l add br0 up type bridge vlan_filtering 1 mcast_snooping 1<br /> $ ip l add dumdum up master br0 type dummy<br /> $ bridge mdb add dev br0 port dumdum grp 239.0.0.1 permanent vid 1<br /> $ ip link set dev br0 down<br /> $ ip link set dev br0 type bridge mcast_vlan_snooping 1<br /> ^^^^ this will enable snooping, but will not update mdb_n_entries<br /> because in __br_multicast_enable_port_ctx() we check !netif_running<br /> $ bridge mdb flush dev br0<br /> ^^^ this will trigger the warning because it will delete the pg which<br /> we added above, which will try to decrease mdb_n_entries<br /> <br /> Fix the problem by removing the conditional increase and always keep the<br /> count up-to-date while the vlan exists. In order to do that we have to<br /> first initialize it on port-vlan context creation, and then always increase<br /> or decrease the value regardless of mcast options. To keep the current<br /> behaviour we have to enforce the mdb limit only if the context is port&amp;#39;s or<br /> if the port-vlan&amp;#39;s mcast snooping is enabled.<br /> <br /> [1]<br /> ------------[ cut here ]------------<br /> n == 0<br /> WARNING: net/bridge/br_multicast.c:718 at br_multicast_port_ngroups_dec_one net/bridge/br_multicast.c:718 [inline], CPU#0: syz.4.4607/22043<br /> WARNING: net/bridge/br_multicast.c:718 at br_multicast_port_ngroups_dec net/bridge/br_multicast.c:771 [inline], CPU#0: syz.4.4607/22043<br /> WARNING: net/bridge/br_multicast.c:718 at br_multicast_del_pg+0x1bbe/0x1e20 net/bridge/br_multicast.c:825, CPU#0: syz.4.4607/22043<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 22043 Comm: syz.4.4607 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026<br /> RIP: 0010:br_multicast_port_ngroups_dec_one net/bridge/br_multicast.c:718 [inline]<br /> RIP: 0010:br_multicast_port_ngroups_dec net/bridge/br_multicast.c:771 [inline]<br /> RIP: 0010:br_multicast_del_pg+0x1bbe/0x1e20 net/bridge/br_multicast.c:825<br /> Code: 41 5f 5d e9 04 7a 48 f7 e8 3f 73 5c f7 90 0f 0b 90 e9 cf fd ff ff e8 31 73 5c f7 90 0f 0b 90 e9 16 fd ff ff e8 23 73 5c f7 90 0b 90 e9 60 fd ff ff e8 15 73 5c f7 eb 05 e8 0e 73 5c f7 48 8b<br /> RSP: 0018:ffffc9000c207220 EFLAGS: 00010293<br /> RAX: ffffffff8a68042d RBX: ffff88807c6f1800 RCX: ffff888066e90000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: 0000000000000000 R08: ffff888066e90000 R09: 000000000000000c<br /> R10: 000000000000000c R11: 0000000000000000 R12: ffff8880303ef800<br /> R13: dffffc0000000000 R14: ffff888050eb11c4 R15: 1ffff1100a1d6238<br /> FS: 00007fa45921b6c0(0000) GS:ffff8881256f5000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fa4591f9ff8 CR3: 0000000081df2000 CR4: 00000000003526f0<br /> Call Trace:<br /> <br /> br_mdb_flush_pgs net/bridge/br_mdb.c:1525 [inline]<br /> br_mdb_flush net/bridge/br_mdb.c:1544 [inline]<br /> br_mdb_del_bulk+0x5e2/0xb20 net/bridge/br_mdb.c:1561<br /> rtnl_mdb_del+0x48a/0x640 net/core/rtnetlink.c:-1<br /> rtnetlink_rcv_msg+0x77e/0xbe0 net/core/rtnetlink.c:6967<br /> netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2550<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]<br /> netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1344<br /> netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1894<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg net/socket.c:742 [inline]<br /> ____sys_sendmsg+0xa68/0xad0 net/socket.c:2592<br /> ___sys_sendmsg+0x2a5/0x360 net/socke<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix dirtyclusters double decrement on fs shutdown<br /> <br /> fstests test generic/388 occasionally reproduces a warning in<br /> ext4_put_super() associated with the dirty clusters count:<br /> <br /> WARNING: CPU: 7 PID: 76064 at fs/ext4/super.c:1324 ext4_put_super+0x48c/0x590 [ext4]<br /> <br /> Tracing the failure shows that the warning fires due to an<br /> s_dirtyclusters_counter value of -1. IOW, this appears to be a<br /> spurious decrement as opposed to some sort of leak. Further tracing<br /> of the dirty cluster count deltas and an LLM scan of the resulting<br /> output identified the cause as a double decrement in the error path<br /> between ext4_mb_mark_diskspace_used() and the caller<br /> ext4_mb_new_blocks().<br /> <br /> First, note that generic/388 is a shutdown vs. fsstress test and so<br /> produces a random set of operations and shutdown injections. In the<br /> problematic case, the shutdown triggers an error return from the<br /> ext4_handle_dirty_metadata() call(s) made from<br /> ext4_mb_mark_context(). The changed value is non-zero at this point,<br /> so ext4_mb_mark_diskspace_used() does not exit after the error<br /> bubbles up from ext4_mb_mark_context(). Instead, the former<br /> decrements both cluster counters and returns the error up to<br /> ext4_mb_new_blocks(). The latter falls into the !ar-&gt;len out path<br /> which decrements the dirty clusters counter a second time, creating<br /> the inconsistency.<br /> <br /> To avoid this problem and simplify ownership of the cluster<br /> reservation in this codepath, lift the counter reduction to a single<br /> place in the caller. This makes it more clear that<br /> ext4_mb_new_blocks() is responsible for acquiring cluster<br /> reservation (via ext4_claim_free_clusters()) in the !delalloc case<br /> as well as releasing it, regardless of whether it ends up consumed<br /> or returned due to failure.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/rt: Skip currently executing CPU in rto_next_cpu()<br /> <br /> CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound<br /> RT task, and a CFS task stuck in kernel space. When other CPUs switch from<br /> RT to non-RT tasks, RT load balancing (LB) is triggered; with<br /> HAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution<br /> of rto_push_irq_work_func. During push_rt_task on CPU0,<br /> if next_task-&gt;prio donor-&gt;prio, resched_curr() sets NEED_RESCHED<br /> and after the push operation completes, CPU0 calls rto_next_cpu().<br /> Since only CPU0 is overloaded in this scenario, rto_next_cpu() should<br /> ideally return -1 (no further IPI needed).<br /> <br /> However, multiple CPUs invoking tell_cpu_to_push() during LB increments<br /> rd-&gt;rto_loop_next. Even when rd-&gt;rto_cpu is set to -1, the mismatch between<br /> rd-&gt;rto_loop and rd-&gt;rto_loop_next forces rto_next_cpu() to restart its<br /> search from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory<br /> &amp;&amp; rt_nr_total &gt; 1), it gets reselected, causing CPU0 to queue irq_work to<br /> itself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and<br /> other CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop,<br /> which triggers a CPU hardlockup due to continuous self-interrupts.<br /> <br /> The trigging scenario is as follows:<br /> <br /> cpu0 cpu1 cpu2<br /> pull_rt_task<br /> tell_cpu_to_push<br />

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovpn: tcp - don&amp;#39;t deref NULL sk_socket member after tcp_close()<br /> <br /> When deleting a peer in case of keepalive expiration, the peer is<br /> removed from the OpenVPN hashtable and is temporary inserted in a<br /> "release list" for further processing.<br /> <br /> This happens in:<br /> ovpn_peer_keepalive_work()<br /> unlock_ovpn(release_list)<br /> <br /> This processing includes detaching from the socket being used to<br /> talk to this peer, by restoring its original proto and socket<br /> ops/callbacks.<br /> <br /> In case of TCP it may happen that, while the peer is sitting in<br /> the release list, userspace decides to close the socket.<br /> This will result in a concurrent execution of:<br /> <br /> tcp_close(sk)<br /> __tcp_close(sk)<br /> sock_orphan(sk)<br /> sk_set_socket(sk, NULL)<br /> <br /> The last function call will set sk-&gt;sk_socket to NULL.<br /> <br /> When the releasing routine is resumed, ovpn_tcp_socket_detach()<br /> will attempt to dereference sk-&gt;sk_socket to restore its original<br /> ops member. This operation will crash due to sk-&gt;sk_socket being NULL.<br /> <br /> Fix this race condition by testing-and-accessing<br /> sk-&gt;sk_socket atomically under sk-&gt;sk_callback_lock.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipvs: do not keep dest_dst if dev is going down<br /> <br /> There is race between the netdev notifier ip_vs_dst_event()<br /> and the code that caches dst with dev that is going down.<br /> As the FIB can be notified for the closed device after our<br /> handler finishes, it is possible valid route to be returned<br /> and cached resuling in a leaked dev reference until the dest<br /> is not removed.<br /> <br /> To prevent new dest_dst to be attached to dest just after the<br /> handler dropped the old one, add a netif_running() check<br /> to make sure the notifier handler is not currently running<br /> for device that is closing.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: sbs-battery: Fix use-after-free in power_supply_changed()<br /> <br /> Using the `devm_` variant for requesting IRQ _before_ the `devm_`<br /> variant for allocating/registering the `power_supply` handle, means that<br /> the `power_supply` handle will be deallocated/unregistered _before_ the<br /> interrupt handler (since `devm_` naturally deallocates in reverse<br /> allocation order). This means that during removal, there is a race<br /> condition where an interrupt can fire just _after_ the `power_supply`<br /> handle has been freed, *but* just _before_ the corresponding<br /> unregistration of the IRQ handler has run.<br /> <br /> This will lead to the IRQ handler calling `power_supply_changed()` with<br /> a freed `power_supply` handle. Which usually crashes the system or<br /> otherwise silently corrupts the memory...<br /> <br /> Note that there is a similar situation which can also happen during<br /> `probe()`; the possibility of an interrupt firing _before_ registering<br /> the `power_supply` handle. This would then lead to the nasty situation<br /> of using the `power_supply` handle *uninitialized* in<br /> `power_supply_changed()`.<br /> <br /> Fix this racy use-after-free by making sure the IRQ is requested _after_<br /> the registration of the `power_supply` handle. Keep the old behavior of<br /> just printing a warning in case of any failures during the IRQ request<br /> and finishing the probe successfully.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fat: avoid parent link count underflow in rmdir<br /> <br /> Corrupted FAT images can leave a directory inode with an incorrect<br /> i_nlink (e.g. 2 even though subdirectories exist). rmdir then<br /> unconditionally calls drop_nlink(dir) and can drive i_nlink to 0,<br /> triggering the WARN_ON in drop_nlink().<br /> <br /> Add a sanity check in vfat_rmdir() and msdos_rmdir(): only drop the<br /> parent link count when it is at least 3, otherwise report a filesystem<br /> error.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: don&amp;#39;t cache extent during splitting extent<br /> <br /> Caching extents during the splitting process is risky, as it may result<br /> in stale extents remaining in the status tree. Moreover, in most cases,<br /> the corresponding extent block entries are likely already cached before<br /> the split happens, making caching here not particularly useful.<br /> <br /> Assume we have an unwritten extent, and then DIO writes the first half.<br /> <br /> [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent<br /> [UUUUUUUUUUUUUUUU] extent status tree<br /> || ----&gt; dio write this range<br /> <br /> First, when ext4_split_extent_at() splits this extent, it truncates the<br /> existing extent and then inserts a new one. During this process, this<br /> extent status entry may be shrunk, and calls to ext4_find_extent() and<br /> ext4_cache_extents() may occur, which could potentially insert the<br /> truncated range as a hole into the extent status tree. After the split<br /> is completed, this hole is not replaced with the correct status.<br /> <br /> [UUUUUUU|UUUUUUUU] on-disk extent U: unwritten extent<br /> [UUUUUUU|HHHHHHHH] extent status tree H: hole<br /> <br /> Then, the outer calling functions will not correct this remaining hole<br /> extent either. Finally, if we perform a delayed buffer write on this<br /> latter part, it will re-insert the delayed extent and cause an error in<br /> space accounting.<br /> <br /> In adition, if the unwritten extent cache is not shrunk during the<br /> splitting, ext4_cache_extents() also conflicts with existing extents<br /> when caching extents. In the future, we will add checks when caching<br /> extents, which will trigger a warning. Therefore, Do not cache extents<br /> that are being split.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: cdns3: fix role switching during resume<br /> <br /> If the role change while we are suspended, the cdns3 driver switches to the<br /> new mode during resume. However, switching to host mode in this context<br /> causes a NULL pointer dereference.<br /> <br /> The host role&amp;#39;s start() operation registers a xhci-hcd device, but its<br /> probe is deferred while we are in the resume path. The host role&amp;#39;s resume()<br /> operation assumes the xhci-hcd device is already probed, which is not the<br /> case, leading to the dereference. Since the start() operation of the new<br /> role is already called, the resume operation can be skipped.<br /> <br /> So skip the resume operation for the new role if a role switch occurs<br /> during resume. Once the resume sequence is complete, the xhci-hcd device<br /> can be probed in case of host mode.<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000208<br /> Mem abort info:<br /> ...<br /> Data abort info:<br /> ...<br /> [0000000000000208] pgd=0000000000000000, p4d=0000000000000000<br /> Internal error: Oops: 0000000096000004 [#1] SMP<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 146 Comm: sh Not tainted<br /> 6.19.0-rc7-00013-g6e64f4aabfae-dirty #135 PREEMPT<br /> Hardware name: Texas Instruments J7200 EVM (DT)<br /> pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : usb_hcd_is_primary_hcd+0x0/0x1c<br /> lr : cdns_host_resume+0x24/0x5c<br /> ...<br /> Call trace:<br /> usb_hcd_is_primary_hcd+0x0/0x1c (P)<br /> cdns_resume+0x6c/0xbc<br /> cdns3_controller_resume.isra.0+0xe8/0x17c<br /> cdns3_plat_resume+0x18/0x24<br /> platform_pm_resume+0x2c/0x68<br /> dpm_run_callback+0x90/0x248<br /> device_resume+0x100/0x24c<br /> dpm_resume+0x190/0x2ec<br /> dpm_resume_end+0x18/0x34<br /> suspend_devices_and_enter+0x2b0/0xa44<br /> pm_suspend+0x16c/0x5fc<br /> state_store+0x80/0xec<br /> kobj_attr_store+0x18/0x2c<br /> sysfs_kf_write+0x7c/0x94<br /> kernfs_fop_write_iter+0x130/0x1dc<br /> vfs_write+0x240/0x370<br /> ksys_write+0x70/0x108<br /> __arm64_sys_write+0x1c/0x28<br /> invoke_syscall+0x48/0x10c<br /> el0_svc_common.constprop.0+0x40/0xe0<br /> do_el0_svc+0x1c/0x28<br /> el0_svc+0x34/0x108<br /> el0t_64_sync_handler+0xa0/0xe4<br /> el0t_64_sync+0x198/0x19c<br /> Code: 52800003 f9407ca5 d63f00a0 17ffffe4 (f9410401)<br /> ---[ end trace 0000000000000000 ]---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Fix race condition in QP timer handlers<br /> <br /> I encontered the following warning:<br /> WARNING: drivers/infiniband/sw/rxe/rxe_task.c:249 at rxe_sched_task+0x1c8/0x238 [rdma_rxe], CPU#0: swapper/0/0<br /> ...<br /> libsha1 [last unloaded: ip6_udp_tunnel]<br /> CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G C 6.19.0-rc5-64k-v8+ #37 PREEMPT<br /> Tainted: [C]=CRAP<br /> Hardware name: Raspberry Pi 4 Model B Rev 1.2<br /> Call trace:<br /> rxe_sched_task+0x1c8/0x238 [rdma_rxe] (P)<br /> retransmit_timer+0x130/0x188 [rdma_rxe]<br /> call_timer_fn+0x68/0x4d0<br /> __run_timers+0x630/0x888<br /> ...<br /> WARNING: drivers/infiniband/sw/rxe/rxe_task.c:38 at rxe_sched_task+0x1c0/0x238 [rdma_rxe], CPU#0: swapper/0/0<br /> ...<br /> WARNING: drivers/infiniband/sw/rxe/rxe_task.c:111 at do_work+0x488/0x5c8 [rdma_rxe], CPU#3: kworker/u17:4/93400<br /> ...<br /> refcount_t: underflow; use-after-free.<br /> WARNING: lib/refcount.c:28 at refcount_warn_saturate+0x138/0x1a0, CPU#3: kworker/u17:4/93400<br /> <br /> The issue is caused by a race condition between retransmit_timer() and<br /> rxe_destroy_qp, leading to the Queue Pair&amp;#39;s (QP) reference count dropping<br /> to zero during timer handler execution.<br /> <br /> It seems this warning is harmless because rxe_qp_do_cleanup() will flush<br /> all pending timers and requests.<br /> <br /> Example of flow causing the issue:<br /> <br /> CPU0 CPU1<br /> retransmit_timer() {<br /> spin_lock_irqsave<br /> rxe_destroy_qp()<br /> __rxe_cleanup()<br /> __rxe_put() // qp-&gt;ref_count decrease to 0<br /> rxe_qp_do_cleanup() {<br /> if (qp-&gt;valid) {<br /> rxe_sched_task() {<br /> WARN_ON(rxe_read(task-&gt;qp) valid = 0<br /> spin_unlock_irqrestore<br /> }<br /> <br /> Ensure the QP&amp;#39;s reference count is maintained and its validity is checked<br /> within the timer callbacks by adding calls to rxe_get(qp) and corresponding<br /> rxe_put(qp) after use.