Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fsnotify: do not generate ACCESS/MODIFY events on child for special files<br /> <br /> inotify/fanotify do not allow users with no read access to a file to<br /> subscribe to events (e.g. IN_ACCESS/IN_MODIFY), but they do allow the<br /> same user to subscribe for watching events on children when the user<br /> has access to the parent directory (e.g. /dev).<br /> <br /> Users with no read access to a file but with read access to its parent<br /> directory can still stat the file and see if it was accessed/modified<br /> via atime/mtime change.<br /> <br /> The same is not true for special files (e.g. /dev/null). Users will not<br /> generally observe atime/mtime changes when other users read/write to<br /> special files, only when someone sets atime/mtime via utimensat().<br /> <br /> Align fsnotify events with this stat behavior and do not generate<br /> ACCESS/MODIFY events to parent watchers on read/write of special files.<br /> The events are still generated to parent watchers on utimensat(). This<br /> closes some side-channels that could be possibly used for information<br /> exfiltration [1].<br /> <br /> [1] https://snee.la/pdf/pubs/file-notification-attacks.pdf

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/handshake: duplicate handshake cancellations leak socket<br /> <br /> When a handshake request is cancelled it is removed from the<br /> handshake_net-&gt;hn_requests list, but it is still present in the<br /> handshake_rhashtbl until it is destroyed.<br /> <br /> If a second cancellation request arrives for the same handshake request,<br /> then remove_pending() will return false... and assuming<br /> HANDSHAKE_F_REQ_COMPLETED isn&amp;#39;t set in req-&gt;hr_flags, we&amp;#39;ll continue<br /> processing through the out_true label, where we put another reference on<br /> the sock and a refcount underflow occurs.<br /> <br /> This can happen for example if a handshake times out - particularly if<br /> the SUNRPC client sends the AUTH_TLS probe to the server but doesn&amp;#39;t<br /> follow it up with the ClientHello due to a problem with tlshd. When the<br /> timeout is hit on the server, the server will send a FIN, which triggers<br /> a cancellation request via xs_reset_transport(). When the timeout is<br /> hit on the client, another cancellation request happens via<br /> xs_tls_handshake_sync().<br /> <br /> Add a test_and_set_bit(HANDSHAKE_F_REQ_COMPLETED) in the pending cancel<br /> path so duplicate cancels can be detected.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: don&amp;#39;t log conflicting inode if it&amp;#39;s a dir moved in the current transaction<br /> <br /> We can&amp;#39;t log a conflicting inode if it&amp;#39;s a directory and it was moved<br /> from one parent directory to another parent directory in the current<br /> transaction, as this can result an attempt to have a directory with<br /> two hard links during log replay, one for the old parent directory and<br /> another for the new parent directory.<br /> <br /> The following scenario triggers that issue:<br /> <br /> 1) We have directories "dir1" and "dir2" created in a past transaction.<br /> Directory "dir1" has inode A as its parent directory;<br /> <br /> 2) We move "dir1" to some other directory;<br /> <br /> 3) We create a file with the name "dir1" in directory inode A;<br /> <br /> 4) We fsync the new file. This results in logging the inode of the new file<br /> and the inode for the directory "dir1" that was previously moved in the<br /> current transaction. So the log tree has the INODE_REF item for the<br /> new location of "dir1";<br /> <br /> 5) We move the new file to some other directory. This results in updating<br /> the log tree to included the new INODE_REF for the new location of the<br /> file and removes the INODE_REF for the old location. This happens<br /> during the rename when we call btrfs_log_new_name();<br /> <br /> 6) We fsync the file, and that persists the log tree changes done in the<br /> previous step (btrfs_log_new_name() only updates the log tree in<br /> memory);<br /> <br /> 7) We have a power failure;<br /> <br /> 8) Next time the fs is mounted, log replay happens and when processing<br /> the inode for directory "dir1" we find a new INODE_REF and add that<br /> link, but we don&amp;#39;t remove the old link of the inode since we have<br /> not logged the old parent directory of the directory inode "dir1".<br /> <br /> As a result after log replay finishes when we trigger writeback of the<br /> subvolume tree&amp;#39;s extent buffers, the tree check will detect that we have<br /> a directory a hard link count of 2 and we get a mount failure.<br /> The errors and stack traces reported in dmesg/syslog are like this:<br /> <br /> [ 3845.729764] BTRFS info (device dm-0): start tree-log replay<br /> [ 3845.730304] page: refcount:3 mapcount:0 mapping:000000005c8a3027 index:0x1d00 pfn:0x11510c<br /> [ 3845.731236] memcg:ffff9264c02f4e00<br /> [ 3845.731751] aops:btree_aops [btrfs] ino:1<br /> [ 3845.732300] flags: 0x17fffc00000400a(uptodate|private|writeback|node=0|zone=2|lastcpupid=0x1ffff)<br /> [ 3845.733346] raw: 017fffc00000400a 0000000000000000 dead000000000122 ffff9264d978aea8<br /> [ 3845.734265] raw: 0000000000001d00 ffff92650e6d4738 00000003ffffffff ffff9264c02f4e00<br /> [ 3845.735305] page dumped because: eb page dump<br /> [ 3845.735981] BTRFS critical (device dm-0): corrupt leaf: root=5 block=30408704 slot=6 ino=257, invalid nlink: has 2 expect no more than 1 for dir<br /> [ 3845.737786] BTRFS info (device dm-0): leaf 30408704 gen 10 total ptrs 17 free space 14881 owner 5<br /> [ 3845.737789] BTRFS info (device dm-0): refs 4 lock_owner 0 current 30701<br /> [ 3845.737792] item 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160<br /> [ 3845.737794] inode generation 3 transid 9 size 16 nbytes 16384<br /> [ 3845.737795] block group 0 mode 40755 links 1 uid 0 gid 0<br /> [ 3845.737797] rdev 0 sequence 2 flags 0x0<br /> [ 3845.737798] atime 1764259517.0<br /> [ 3845.737800] ctime 1764259517.572889464<br /> [ 3845.737801] mtime 1764259517.572889464<br /> [ 3845.737802] otime 1764259517.0<br /> [ 3845.737803] item 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12<br /> [ 3845.737805] index 0 name_len 2<br /> [ 3845.737807] item 2 key (256 DIR_ITEM 2363071922) itemoff 16077 itemsize 34<br /> [ 3845.737808] location key (257 1 0) type 2<br /> [ 3845.737810] transid 9 data_len 0 name_len 4<br /> [ 3845.737811] item 3 key (256 DIR_ITEM 2676584006) itemoff 16043 itemsize 34<br /> [ 3845.737813] location key (258 1 0) type 2<br /> [ 3845.737814] transid 9 data_len 0 name_len 4<br /> [ 3845.737815] item 4 key (256 DIR_INDEX 2) itemoff 16009 itemsize 34<br /> [ 3845.737816] location key (257 1 0) type 2<br /> [<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Avoid unregistering PSP twice<br /> <br /> PSP is unregistered twice in:<br /> _mlx5e_remove -&gt; mlx5e_psp_unregister<br /> mlx5e_nic_cleanup -&gt; mlx5e_psp_unregister<br /> <br /> This leads to a refcount underflow in some conditions:<br /> ------------[ cut here ]------------<br /> refcount_t: underflow; use-after-free.<br /> WARNING: CPU: 2 PID: 1694 at lib/refcount.c:28 refcount_warn_saturate+0xd8/0xe0<br /> [...]<br /> mlx5e_psp_unregister+0x26/0x50 [mlx5_core]<br /> mlx5e_nic_cleanup+0x26/0x90 [mlx5_core]<br /> mlx5e_remove+0xe6/0x1f0 [mlx5_core]<br /> auxiliary_bus_remove+0x18/0x30<br /> device_release_driver_internal+0x194/0x1f0<br /> bus_remove_device+0xc6/0x130<br /> device_del+0x159/0x3c0<br /> mlx5_rescan_drivers_locked+0xbc/0x2a0 [mlx5_core]<br /> [...]<br /> <br /> Do not directly remove psp from the _mlx5e_remove path, the PSP cleanup<br /> happens as part of profile cleanup.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: phy: fsl-usb: Fix use-after-free in delayed work during device removal<br /> <br /> The delayed work item otg_event is initialized in fsl_otg_conf() and<br /> scheduled under two conditions:<br /> 1. When a host controller binds to the OTG controller.<br /> 2. When the USB ID pin state changes (cable insertion/removal).<br /> <br /> A race condition occurs when the device is removed via fsl_otg_remove():<br /> the fsl_otg instance may be freed while the delayed work is still pending<br /> or executing. This leads to use-after-free when the work function<br /> fsl_otg_event() accesses the already freed memory.<br /> <br /> The problematic scenario:<br /> <br /> (detach thread) | (delayed work)<br /> fsl_otg_remove() |<br /> kfree(fsl_otg_dev) //FREE| fsl_otg_event()<br /> | og = container_of(...) //USE<br /> | og-&gt; //USE<br /> <br /> Fix this by calling disable_delayed_work_sync() in fsl_otg_remove()<br /> before deallocating the fsl_otg structure. This ensures the delayed work<br /> is properly canceled and completes execution prior to memory deallocation.<br /> <br /> This bug was identified through static analysis.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/hsr: fix NULL pointer dereference in prp_get_untagged_frame()<br /> <br /> prp_get_untagged_frame() calls __pskb_copy() to create frame-&gt;skb_std<br /> but doesn&amp;#39;t check if the allocation failed. If __pskb_copy() returns<br /> NULL, skb_clone() is called with a NULL pointer, causing a crash:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]<br /> CPU: 0 UID: 0 PID: 5625 Comm: syz.1.18 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> RIP: 0010:skb_clone+0xd7/0x3a0 net/core/skbuff.c:2041<br /> Code: 03 42 80 3c 20 00 74 08 4c 89 f7 e8 23 29 05 f9 49 83 3e 00 0f 85 a0 01 00 00 e8 94 dd 9d f8 48 8d 6b 7e 49 89 ee 49 c1 ee 03 0f b6 04 26 84 c0 0f 85 d1 01 00 00 44 0f b6 7d 00 41 83 e7 0c<br /> RSP: 0018:ffffc9000d00f200 EFLAGS: 00010207<br /> RAX: ffffffff892235a1 RBX: 0000000000000000 RCX: ffff88803372a480<br /> RDX: 0000000000000000 RSI: 0000000000000820 RDI: 0000000000000000<br /> RBP: 000000000000007e R08: ffffffff8f7d0f77 R09: 1ffffffff1efa1ee<br /> R10: dffffc0000000000 R11: fffffbfff1efa1ef R12: dffffc0000000000<br /> R13: 0000000000000820 R14: 000000000000000f R15: ffff88805144cc00<br /> FS: 0000555557f6d500(0000) GS:ffff88808d72f000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000555581d35808 CR3: 000000005040e000 CR4: 0000000000352ef0<br /> Call Trace:<br /> <br /> hsr_forward_do net/hsr/hsr_forward.c:-1 [inline]<br /> hsr_forward_skb+0x1013/0x2860 net/hsr/hsr_forward.c:741<br /> hsr_handle_frame+0x6ce/0xa70 net/hsr/hsr_slave.c:84<br /> __netif_receive_skb_core+0x10b9/0x4380 net/core/dev.c:5966<br /> __netif_receive_skb_one_core net/core/dev.c:6077 [inline]<br /> __netif_receive_skb+0x72/0x380 net/core/dev.c:6192<br /> netif_receive_skb_internal net/core/dev.c:6278 [inline]<br /> netif_receive_skb+0x1cb/0x790 net/core/dev.c:6337<br /> tun_rx_batched+0x1b9/0x730 drivers/net/tun.c:1485<br /> tun_get_user+0x2b65/0x3e90 drivers/net/tun.c:1953<br /> tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1999<br /> new_sync_write fs/read_write.c:593 [inline]<br /> vfs_write+0x5c9/0xb30 fs/read_write.c:686<br /> ksys_write+0x145/0x250 fs/read_write.c:738<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f0449f8e1ff<br /> Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 f9 92 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 4c 93 02 00 48<br /> RSP: 002b:00007ffd7ad94c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 00007f044a1e5fa0 RCX: 00007f0449f8e1ff<br /> RDX: 000000000000003e RSI: 0000200000000500 RDI: 00000000000000c8<br /> RBP: 00007ffd7ad94d20 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 000000000000003e R11: 0000000000000293 R12: 0000000000000001<br /> R13: 00007f044a1e5fa0 R14: 00007f044a1e5fa0 R15: 0000000000000003<br /> <br /> <br /> Add a NULL check immediately after __pskb_copy() to handle allocation<br /> failures gracefully.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: ti_am335x_tsc - fix off-by-one error in wire_order validation<br /> <br /> The current validation &amp;#39;wire_order[i] &gt; ARRAY_SIZE(config_pins)&amp;#39; allows<br /> wire_order[i] to equal ARRAY_SIZE(config_pins), which causes out-of-bounds<br /> access when used as index in &amp;#39;config_pins[wire_order[i]]&amp;#39;.<br /> <br /> Since config_pins has 4 elements (indices 0-3), the valid range for<br /> wire_order should be 0-3. Fix the off-by-one error by using &gt;= instead<br /> of &gt; in the validation check.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/deadline: only set free_cpus for online runqueues<br /> <br /> Commit 16b269436b72 ("sched/deadline: Modify cpudl::free_cpus<br /> to reflect rd-&gt;online") introduced the cpudl_set/clear_freecpu<br /> functions to allow the cpu_dl::free_cpus mask to be manipulated<br /> by the deadline scheduler class rq_on/offline callbacks so the<br /> mask would also reflect this state.<br /> <br /> Commit 9659e1eeee28 ("sched/deadline: Remove cpu_active_mask<br /> from cpudl_find()") removed the check of the cpu_active_mask to<br /> save some processing on the premise that the cpudl::free_cpus<br /> mask already reflected the runqueue online state.<br /> <br /> Unfortunately, there are cases where it is possible for the<br /> cpudl_clear function to set the free_cpus bit for a CPU when the<br /> deadline runqueue is offline. When this occurs while a CPU is<br /> connected to the default root domain the flag may retain the bad<br /> state after the CPU has been unplugged. Later, a different CPU<br /> that is transitioning through the default root domain may push a<br /> deadline task to the powered down CPU when cpudl_find sees its<br /> free_cpus bit is set. If this happens the task will not have the<br /> opportunity to run.<br /> <br /> One example is outlined here:<br /> https://lore.kernel.org/lkml/20250110233010.2339521-1-opendmb@gmail.com<br /> <br /> Another occurs when the last deadline task is migrated from a<br /> CPU that has an offlined runqueue. The dequeue_task member of<br /> the deadline scheduler class will eventually call cpudl_clear<br /> and set the free_cpus bit for the CPU.<br /> <br /> This commit modifies the cpudl_clear function to be aware of the<br /> online state of the deadline runqueue so that the free_cpus mask<br /> can be updated appropriately.<br /> <br /> It is no longer necessary to manage the mask outside of the<br /> cpudl_set/clear functions so the cpudl_set/clear_freecpu<br /> functions are removed. In addition, since the free_cpus mask is<br /> now only updated under the cpudl lock the code was changed to<br /> use the non-atomic __cpumask functions.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: Reset t_task_cdb pointer in error case<br /> <br /> If allocation of cmd-&gt;t_task_cdb fails, it remains NULL but is later<br /> dereferenced in the &amp;#39;err&amp;#39; path.<br /> <br /> In case of error, reset NULL t_task_cdb value to point at the default<br /> fixed-size buffer.<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 /> inet: frags: flush pending skbs in fqdir_pre_exit()<br /> <br /> We have been seeing occasional deadlocks on pernet_ops_rwsem since<br /> September in NIPA. The stuck task was usually modprobe (often loading<br /> a driver like ipvlan), trying to take the lock as a Writer.<br /> lockdep does not track readers for rwsems so the read wasn&amp;#39;t obvious<br /> from the reports.<br /> <br /> On closer inspection the Reader holding the lock was conntrack looping<br /> forever in nf_conntrack_cleanup_net_list(). Based on past experience<br /> with occasional NIPA crashes I looked thru the tests which run before<br /> the crash and noticed that the crash follows ip_defrag.sh. An immediate<br /> red flag. Scouring thru (de)fragmentation queues reveals skbs sitting<br /> around, holding conntrack references.<br /> <br /> The problem is that since conntrack depends on nf_defrag_ipv6,<br /> nf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first its<br /> netns exit hooks run _after_ conntrack&amp;#39;s netns exit hook.<br /> <br /> Flush all fragment queue SKBs during fqdir_pre_exit() to release<br /> conntrack references before conntrack cleanup runs. Also flush<br /> the queues in timer expiry handlers when they discover fqdir-&gt;dead<br /> is set, in case packet sneaks in while we&amp;#39;re running the pre_exit<br /> flush.<br /> <br /> The commit under Fixes is not exactly the culprit, but I think<br /> previously the timer firing would eventually unblock the spinning<br /> conntrack.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en: Fix XDP_TX path<br /> <br /> For XDP_TX action in bnxt_rx_xdp(), clearing of the event flags is not<br /> correct. __bnxt_poll_work() -&gt; bnxt_rx_pkt() -&gt; bnxt_rx_xdp() may be<br /> looping within NAPI and some event flags may be set in earlier<br /> iterations. In particular, if BNXT_TX_EVENT is set earlier indicating<br /> some XDP_TX packets are ready and pending, it will be cleared if it is<br /> XDP_TX action again. Normally, we will set BNXT_TX_EVENT again when we<br /> successfully call __bnxt_xmit_xdp(). But if the TX ring has no more<br /> room, the flag will not be set. This will cause the TX producer to be<br /> ahead but the driver will not hit the TX doorbell.<br /> <br /> For multi-buf XDP_TX, there is no need to clear the event flags and set<br /> BNXT_AGG_EVENT. The BNXT_AGG_EVENT flag should have been set earlier in<br /> bnxt_rx_pkt().<br /> <br /> The visible symptom of this is that the RX ring associated with the<br /> TX XDP ring will eventually become empty and all packets will be dropped.<br /> Because this condition will cause the driver to not refill the RX ring<br /> seeing that the TX ring has forever pending XDP_TX packets.<br /> <br /> The fix is to only clear BNXT_RX_EVENT when we have successfully<br /> called __bnxt_xmit_xdp().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid updating compression context during writeback<br /> <br /> Bai, Shuangpeng reported a bug as below:<br /> <br /> Oops: divide error: 0000 [#1] SMP KASAN PTI<br /> CPU: 0 UID: 0 PID: 11441 Comm: syz.0.46 Not tainted 6.17.0 #1 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> RIP: 0010:f2fs_all_cluster_page_ready+0x106/0x550 fs/f2fs/compress.c:857<br /> Call Trace:<br /> <br /> f2fs_write_cache_pages fs/f2fs/data.c:3078 [inline]<br /> __f2fs_write_data_pages fs/f2fs/data.c:3290 [inline]<br /> f2fs_write_data_pages+0x1c19/0x3600 fs/f2fs/data.c:3317<br /> do_writepages+0x38e/0x640 mm/page-writeback.c:2634<br /> filemap_fdatawrite_wbc mm/filemap.c:386 [inline]<br /> __filemap_fdatawrite_range mm/filemap.c:419 [inline]<br /> file_write_and_wait_range+0x2ba/0x3e0 mm/filemap.c:794<br /> f2fs_do_sync_file+0x6e6/0x1b00 fs/f2fs/file.c:294<br /> generic_write_sync include/linux/fs.h:3043 [inline]<br /> f2fs_file_write_iter+0x76e/0x2700 fs/f2fs/file.c:5259<br /> new_sync_write fs/read_write.c:593 [inline]<br /> vfs_write+0x7e9/0xe00 fs/read_write.c:686<br /> ksys_write+0x19d/0x2d0 fs/read_write.c:738<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xf7/0x470 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> The bug was triggered w/ below race condition:<br /> <br /> fsync setattr ioctl<br /> - f2fs_do_sync_file<br /> - file_write_and_wait_range<br /> - f2fs_write_cache_pages<br /> : inode is non-compressed<br /> : cc.cluster_size =<br /> F2FS_I(inode)-&gt;i_cluster_size = 0<br /> - tag_pages_for_writeback<br /> - f2fs_setattr<br /> - truncate_setsize<br /> - f2fs_truncate<br /> - f2fs_fileattr_set<br /> - f2fs_setflags_common<br /> - set_compress_context<br /> : F2FS_I(inode)-&gt;i_cluster_size = 4<br /> : set_inode_flag(inode, FI_COMPRESSED_FILE)<br /> - f2fs_compressed_file<br /> : return true<br /> - f2fs_all_cluster_page_ready<br /> : "pgidx % cc-&gt;cluster_size" trigger dividing 0 issue<br /> <br /> Let&amp;#39;s change as below to fix this issue:<br /> - introduce a new atomic type variable .writeback in structure f2fs_inode_info<br /> to track the number of threads which calling f2fs_write_cache_pages().<br /> - use .i_sem lock to protect .writeback update.<br /> - check .writeback before update compression context in f2fs_setflags_common()<br /> to avoid race w/ -&gt;writepages.