Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rust: pwm: Fix potential memory leak on init error<br /> <br /> When initializing a PWM chip using pwmchip_alloc(), the allocated device<br /> owns an initial reference that must be released on all error paths.<br /> <br /> If __pinned_init() were to fail, the allocated pwm_chip would currently<br /> leak because the error path returns without calling pwmchip_put().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Require frozen map for calculating map hash<br /> <br /> Currently, bpf_map_get_info_by_fd calculates and caches the hash of the<br /> map regardless of the map&amp;#39;s frozen state.<br /> <br /> This leads to a TOCTOU bug where userspace can call<br /> BPF_OBJ_GET_INFO_BY_FD to cache the hash and then modify the map<br /> contents before freezing.<br /> <br /> Therefore, a trusted loader can be tricked into verifying the stale hash<br /> while loading the modified contents.<br /> <br /> Fix this by returning -EPERM if the map is not frozen when the hash is<br /> requested. This ensures the hash is only generated for the final,<br /> immutable state of the map.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: chips-media: wave5: Fix memory leak on codec_info allocation failure<br /> <br /> In wave5_vpu_open_enc() and wave5_vpu_open_dec(), a vpu instance is<br /> allocated via kzalloc(). If the subsequent allocation for inst-&gt;codec_info<br /> fails, the functions return -ENOMEM without freeing the previously<br /> allocated instance, causing a memory leak.<br /> <br /> Fix this by calling kfree() on the instance in this error path to ensure<br /> it is properly released.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovpn: fix possible use-after-free in ovpn_net_xmit<br /> <br /> When building the skb_list in ovpn_net_xmit, skb_share_check will free<br /> the original skb if it is shared. The current implementation continues<br /> to use the stale skb pointer for subsequent operations:<br /> - peer lookup,<br /> - skb_dst_drop (even though all segments produced by skb_gso_segment<br /> will have a dst attached),<br /> - ovpn_peer_stats_increment_tx.<br /> <br /> Fix this by moving the peer lookup and skb_dst_drop before segmentation<br /> so that the original skb is still valid when used. Return early if all<br /> segments fail skb_share_check and the list ends up empty.<br /> Also switch ovpn_peer_stats_increment_tx to use skb_list.next; the next<br /> patch fixes the stats logic.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mctp: ensure our nlmsg responses are initialised<br /> <br /> Syed Faraz Abrar (@farazsth98) from Zellic, and Pumpkin (@u1f383) from<br /> DEVCORE Research Team working with Trend Micro Zero Day Initiative<br /> report that a RTM_GETNEIGH will return uninitalised data in the pad<br /> bytes of the ndmsg data.<br /> <br /> Ensure we&amp;#39;re initialising the netlink data to zero, in the link, addr<br /> and neigh response messages.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: call ksmbd_vfs_kern_path_end_removing() on some error paths<br /> <br /> There are two places where ksmbd_vfs_kern_path_end_removing() needs to be<br /> called in order to balance what the corresponding successful call to<br /> ksmbd_vfs_kern_path_start_removing() has done, i.e. drop inode locks and<br /> put the taken references. Otherwise there might be potential deadlocks<br /> and unbalanced locks which are caught like:<br /> <br /> BUG: workqueue leaked lock or atomic: kworker/5:21/0x00000000/7596<br /> last function: handle_ksmbd_work<br /> 2 locks held by kworker/5:21/7596:<br /> #0: ffff8881051ae448 (sb_writers#3){.+.+}-{0:0}, at: ksmbd_vfs_kern_path_locked+0x142/0x660<br /> #1: ffff888130e966c0 (&amp;type-&gt;i_mutex_dir_key#3/1){+.+.}-{4:4}, at: ksmbd_vfs_kern_path_locked+0x17d/0x660<br /> CPU: 5 PID: 7596 Comm: kworker/5:21 Not tainted 6.1.162-00456-gc29b353f383b #138<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014<br /> Workqueue: ksmbd-io handle_ksmbd_work<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x44/0x5b<br /> process_one_work.cold+0x57/0x5c<br /> worker_thread+0x82/0x600<br /> kthread+0x153/0x190<br /> ret_from_fork+0x22/0x30<br /> <br /> <br /> Found by Linux Verification Center (linuxtesting.org).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: catc: enable basic endpoint checking<br /> <br /> catc_probe() fills three URBs with hardcoded endpoint pipes without<br /> verifying the endpoint descriptors:<br /> <br /> - usb_sndbulkpipe(usbdev, 1) and usb_rcvbulkpipe(usbdev, 1) for TX/RX<br /> - usb_rcvintpipe(usbdev, 2) for interrupt status<br /> <br /> A malformed USB device can present these endpoints with transfer types<br /> that differ from what the driver assumes.<br /> <br /> Add a catc_usb_ep enum for endpoint numbers, replacing magic constants<br /> throughout. Add usb_check_bulk_endpoints() and usb_check_int_endpoints()<br /> calls after usb_set_interface() to verify endpoint types before use,<br /> rejecting devices with mismatched descriptors at probe time.<br /> <br /> Similar to<br /> - commit 90b7f2961798 ("net: usb: rtl8150: enable basic endpoint checking")<br /> which fixed the issue in rtl8150.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Fix memory leak in GET_DATA_DIRECT_SYSFS_PATH handler<br /> <br /> The UVERBS_HANDLER(MLX5_IB_METHOD_GET_DATA_DIRECT_SYSFS_PATH) function<br /> allocates memory for the device path using kobject_get_path(). If the<br /> length of the device path exceeds the output buffer length, the function<br /> returns -ENOSPC but does not free the allocated memory, resulting in a<br /> memory leak.<br /> <br /> Add a kfree() call to the error path to ensure the allocated memory is<br /> properly freed.<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 /> 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.