Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Take state lock for af_unix iter<br /> <br /> When a BPF iterator program updates a sockmap, there is a race condition in<br /> unix_stream_bpf_update_proto() where the `peer` pointer can become stale[1]<br /> during a state transition TCP_ESTABLISHED -&gt; TCP_CLOSE.<br /> <br /> CPU0 bpf CPU1 close<br /> -------- ----------<br /> // unix_stream_bpf_update_proto()<br /> sk_pair = unix_peer(sk)<br /> if (unlikely(!sk_pair))<br /> return -EINVAL;<br /> // unix_release_sock()<br /> skpair = unix_peer(sk);<br /> unix_peer(sk) = NULL;<br /> sock_put(skpair)<br /> sock_hold(sk_pair) // UaF<br /> <br /> More practically, this fix guarantees that the iterator program is<br /> consistently provided with a unix socket that remains stable during<br /> iterator execution.<br /> <br /> [1]:<br /> BUG: KASAN: slab-use-after-free in unix_stream_bpf_update_proto+0x155/0x490<br /> Write of size 4 at addr ffff8881178c9a00 by task test_progs/2231<br /> Call Trace:<br /> dump_stack_lvl+0x5d/0x80<br /> print_report+0x170/0x4f3<br /> kasan_report+0xe4/0x1c0<br /> kasan_check_range+0x125/0x200<br /> unix_stream_bpf_update_proto+0x155/0x490<br /> sock_map_link+0x71c/0xec0<br /> sock_map_update_common+0xbc/0x600<br /> sock_map_update_elem+0x19a/0x1f0<br /> bpf_prog_bbbf56096cdd4f01_selective_dump_unix+0x20c/0x217<br /> bpf_iter_run_prog+0x21e/0xae0<br /> bpf_iter_unix_seq_show+0x1e0/0x2a0<br /> bpf_seq_read+0x42c/0x10d0<br /> vfs_read+0x171/0xb20<br /> ksys_read+0xff/0x200<br /> do_syscall_64+0xf7/0x5e0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Allocated by task 2236:<br /> kasan_save_stack+0x30/0x50<br /> kasan_save_track+0x14/0x30<br /> __kasan_slab_alloc+0x63/0x80<br /> kmem_cache_alloc_noprof+0x1d5/0x680<br /> sk_prot_alloc+0x59/0x210<br /> sk_alloc+0x34/0x470<br /> unix_create1+0x86/0x8a0<br /> unix_stream_connect+0x318/0x15b0<br /> __sys_connect+0xfd/0x130<br /> __x64_sys_connect+0x72/0xd0<br /> do_syscall_64+0xf7/0x5e0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Freed by task 2236:<br /> kasan_save_stack+0x30/0x50<br /> kasan_save_track+0x14/0x30<br /> kasan_save_free_info+0x3b/0x70<br /> __kasan_slab_free+0x47/0x70<br /> kmem_cache_free+0x11c/0x590<br /> __sk_destruct+0x432/0x6e0<br /> unix_release_sock+0x9b3/0xf60<br /> unix_release+0x8a/0xf0<br /> __sock_release+0xb0/0x270<br /> sock_close+0x18/0x20<br /> __fput+0x36e/0xac0<br /> fput_close_sync+0xe5/0x1a0<br /> __x64_sys_close+0x7d/0xd0<br /> do_syscall_64+0xf7/0x5e0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Fix af_unix null-ptr-deref in proto update<br /> <br /> unix_stream_connect() sets sk_state (`WRITE_ONCE(sk-&gt;sk_state,<br /> TCP_ESTABLISHED)`) _before_ it assigns a peer (`unix_peer(sk) = newsk`).<br /> sk_state == TCP_ESTABLISHED makes sock_map_sk_state_allowed() believe that<br /> socket is properly set up, which would include having a defined peer. IOW,<br /> there&amp;#39;s a window when unix_stream_bpf_update_proto() can be called on<br /> socket which still has unix_peer(sk) == NULL.<br /> <br /> CPU0 bpf CPU1 connect<br /> -------- ------------<br /> <br /> WRITE_ONCE(sk-&gt;sk_state, TCP_ESTABLISHED)<br /> sock_map_sk_state_allowed(sk)<br /> ...<br /> sk_pair = unix_peer(sk)<br /> sock_hold(sk_pair)<br /> sock_hold(newsk)<br /> smp_mb__after_atomic()<br /> unix_peer(sk) = newsk<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000080<br /> RIP: 0010:unix_stream_bpf_update_proto+0xa0/0x1b0<br /> Call Trace:<br /> sock_map_link+0x564/0x8b0<br /> sock_map_update_common+0x6e/0x340<br /> sock_map_update_elem_sys+0x17d/0x240<br /> __sys_bpf+0x26db/0x3250<br /> __x64_sys_bpf+0x21/0x30<br /> do_syscall_64+0x6b/0x3a0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Initial idea was to move peer assignment _before_ the sk_state update[1],<br /> but that involved an additional memory barrier, and changing the hot path<br /> was rejected.<br /> Then a NULL check during proto update in unix_stream_bpf_update_proto() was<br /> considered[2], but the follow-up discussion[3] focused on the root cause,<br /> i.e. sockmap update taking a wrong lock. Or, more specifically, missing<br /> unix_state_lock()[4].<br /> In the end it was concluded that teaching sockmap about the af_unix locking<br /> would be unnecessarily complex[5].<br /> Complexity aside, since BPF_PROG_TYPE_SCHED_CLS and BPF_PROG_TYPE_SCHED_ACT<br /> are allowed to update sockmaps, sock_map_update_elem() taking the unix<br /> lock, as it is currently implemented in unix_state_lock():<br /> spin_lock(&amp;unix_sk(s)-&gt;lock), would be problematic. unix_state_lock() taken<br /> in a process context, followed by a softirq-context TC BPF program<br /> attempting to take the same spinlock -- deadlock[6].<br /> This way we circled back to the peer check idea[2].<br /> <br /> [1]: https://lore.kernel.org/netdev/ba5c50aa-1df4-40c2-ab33-a72022c5a32e@rbox.co/<br /> [2]: https://lore.kernel.org/netdev/20240610174906.32921-1-kuniyu@amazon.com/<br /> [3]: https://lore.kernel.org/netdev/7603c0e6-cd5b-452b-b710-73b64bd9de26@linux.dev/<br /> [4]: https://lore.kernel.org/netdev/CAAVpQUA+8GL_j63CaKb8hbxoL21izD58yr1NvhOhU=j+35+3og@mail.gmail.com/<br /> [5]: https://lore.kernel.org/bpf/CAAVpQUAHijOMext28Gi10dSLuMzGYh+jK61Ujn+fZ-wvcODR2A@mail.gmail.com/<br /> [6]: https://lore.kernel.org/bpf/dd043c69-4d03-46fe-8325-8f97101435cf@linux.dev/<br /> <br /> Summary of scenarios where af_unix/stream connect() may race a sockmap<br /> update:<br /> <br /> 1. connect() vs. bpf(BPF_MAP_UPDATE_ELEM), i.e. sock_map_update_elem_sys()<br /> <br /> Implemented NULL check is sufficient. Once assigned, socket peer won&amp;#39;t<br /> be released until socket fd is released. And that&amp;#39;s not an issue because<br /> sock_map_update_elem_sys() bumps fd refcnf.<br /> <br /> 2. connect() vs BPF program doing update<br /> <br /> Update restricted per verifier.c:may_update_sockmap() to<br /> <br /> BPF_PROG_TYPE_TRACING/BPF_TRACE_ITER<br /> BPF_PROG_TYPE_SOCK_OPS (bpf_sock_map_update() only)<br /> BPF_PROG_TYPE_SOCKET_FILTER<br /> BPF_PROG_TYPE_SCHED_CLS<br /> BPF_PROG_TYPE_SCHED_ACT<br /> BPF_PROG_TYPE_XDP<br /> BPF_PROG_TYPE_SK_REUSEPORT<br /> BPF_PROG_TYPE_FLOW_DISSECTOR<br /> BPF_PROG_TYPE_SK_LOOKUP<br /> <br /> Plus one more race to consider:<br /> <br /> CPU0 bpf CPU1 connect<br /> -------- ------------<br /> <br /> WRITE_ONCE(sk-&gt;sk_state, TCP_ESTABLISHED)<br /> sock_map_sk_state_allowed(sk)<br /> sock_hold(newsk)<br /> smp_mb__after_atomic()<br /> <br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Fix af_unix iter deadlock<br /> <br /> bpf_iter_unix_seq_show() may deadlock when lock_sock_fast() takes the fast<br /> path and the iter prog attempts to update a sockmap. Which ends up spinning<br /> at sock_map_update_elem()&amp;#39;s bh_lock_sock():<br /> <br /> WARNING: possible recursive locking detected<br /> test_progs/1393 is trying to acquire lock:<br /> ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: sock_map_update_elem+0xdb/0x1f0<br /> <br /> but task is already holding lock:<br /> ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: __lock_sock_fast+0x37/0xe0<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> <br /> CPU0<br /> ----<br /> lock(slock-AF_UNIX);<br /> lock(slock-AF_UNIX);<br /> <br /> *** DEADLOCK ***<br /> <br /> May be due to missing lock nesting notation<br /> <br /> 4 locks held by test_progs/1393:<br /> #0: ffff88814b59c790 (&amp;p-&gt;lock){+.+.}-{4:4}, at: bpf_seq_read+0x59/0x10d0<br /> #1: ffff88811ec25fd8 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: bpf_seq_read+0x42c/0x10d0<br /> #2: ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: __lock_sock_fast+0x37/0xe0<br /> #3: ffffffff85a6a7c0 (rcu_read_lock){....}-{1:3}, at: bpf_iter_run_prog+0x51d/0xb00<br /> <br /> Call Trace:<br /> dump_stack_lvl+0x5d/0x80<br /> print_deadlock_bug.cold+0xc0/0xce<br /> __lock_acquire+0x130f/0x2590<br /> lock_acquire+0x14e/0x2b0<br /> _raw_spin_lock+0x30/0x40<br /> sock_map_update_elem+0xdb/0x1f0<br /> bpf_prog_2d0075e5d9b721cd_dump_unix+0x55/0x4f4<br /> bpf_iter_run_prog+0x5b9/0xb00<br /> bpf_iter_unix_seq_show+0x1f7/0x2e0<br /> bpf_seq_read+0x42c/0x10d0<br /> vfs_read+0x171/0xb20<br /> ksys_read+0xff/0x200<br /> do_syscall_64+0x6b/0x3a0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix NULL deref in map_kptr_match_type for scalar regs<br /> <br /> Commit ab6c637ad027 ("bpf: Fix a bpf_kptr_xchg() issue with local<br /> kptr") refactored map_kptr_match_type() to branch on btf_is_kernel()<br /> before checking base_type(). A scalar register stored into a kptr<br /> slot has no btf, so the btf_is_kernel(reg-&gt;btf) call dereferences<br /> NULL.<br /> <br /> Move the base_type() != PTR_TO_BTF_ID guard before any reg-&gt;btf<br /> access.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i3c: master: renesas: Fix memory leak in renesas_i3c_i3c_xfers()<br /> <br /> The xfer structure allocated by renesas_i3c_alloc_xfer() was never freed<br /> in the renesas_i3c_i3c_xfers() function. Use the __free(kfree) cleanup<br /> attribute to automatically free the memory when the variable goes out of<br /> scope.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: fix missing run load for vcn0 in attr_data_get_block_locked()<br /> <br /> When a compressed or sparse attribute has its clusters frame-aligned,<br /> vcn is rounded down to the frame start using cmask, which can result<br /> in vcn != vcn0. In this case, vcn and vcn0 may reside in different<br /> attribute segments.<br /> <br /> The code already handles the case where vcn is in a different segment<br /> by loading its runs before allocation. However, it fails to load runs<br /> for vcn0 when vcn0 resides in a different segment than vcn. This causes<br /> run_lookup_entry() to return SPARSE_LCN for vcn0 since its segment was<br /> never loaded into the in-memory run list, triggering the WARN_ON(1).<br /> <br /> Fix this by adding a missing check for vcn0 after the existing vcn<br /> segment check. If vcn0 falls outside the current segment range<br /> [svcn, evcn1), find and load the attribute segment containing vcn0<br /> before performing the run lookup.<br /> <br /> The following scenario triggers the bug:<br /> attr_data_get_block_locked()<br /> vcn = vcn0 &amp; cmask

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: spacemit: ccu_mix: fix inverted condition in ccu_mix_trigger_fc()<br /> <br /> Fix inverted condition that skips frequency change trigger,<br /> causing kernel panics during cpufreq scaling.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: avoid reading already updated pages during GC<br /> <br /> We found the following issue during fuzz testing:<br /> <br /> page: refcount:3 mapcount:0 mapping:00000000b6e89c65 index:0x18b2dc pfn:0x161ba9<br /> memcg:f8ffff800e269c00<br /> aops:f2fs_meta_aops ino:2<br /> flags: 0x52880000000080a9(locked|waiters|uptodate|lru|private|zone=1|kasantag=0x4a)<br /> raw: 52880000000080a9 fffffffec6e17588 fffffffec0ccc088 a7ffff8067063618<br /> raw: 000000000018b2dc 0000000000000009 00000003ffffffff f8ffff800e269c00<br /> page dumped because: VM_BUG_ON_FOLIO(folio_test_uptodate(folio))<br /> page_owner tracks the page as allocated<br /> post_alloc_hook+0x58c/0x5ec<br /> prep_new_page+0x34/0x284<br /> get_page_from_freelist+0x2dcc/0x2e8c<br /> __alloc_pages_noprof+0x280/0x76c<br /> __folio_alloc_noprof+0x18/0xac<br /> __filemap_get_folio+0x6bc/0xdc4<br /> pagecache_get_page+0x3c/0x104<br /> do_garbage_collect+0x5c78/0x77a4<br /> f2fs_gc+0xd74/0x25f0<br /> gc_thread_func+0xb28/0x2930<br /> kthread+0x464/0x5d8<br /> ret_from_fork+0x10/0x20<br /> ------------[ cut here ]------------<br /> kernel BUG at mm/filemap.c:1563!<br /> folio_end_read+0x140/0x168<br /> f2fs_finish_read_bio+0x5c4/0xb80<br /> f2fs_read_end_io+0x64c/0x708<br /> bio_endio+0x85c/0x8c0<br /> blk_update_request+0x690/0x127c<br /> scsi_end_request+0x9c/0xb8c<br /> scsi_io_completion+0xf0/0x250<br /> scsi_finish_command+0x430/0x45c<br /> scsi_complete+0x178/0x6d4<br /> blk_mq_complete_request+0xcc/0x104<br /> scsi_done_internal+0x214/0x454<br /> scsi_done+0x24/0x34<br /> <br /> which is similar to the problem reported by syzbot:<br /> https://syzkaller.appspot.com/bug?extid=3686758660f980b402dc<br /> <br /> This case is consistent with the description in commit 9bf1a3f<br /> ("f2fs: avoid GC causing encrypted file corrupted"):<br /> Page 1 is moved from blkaddr A to blkaddr B by move_data_block, and after<br /> being written it is marked as uptodate. Then, Page 1 is moved from blkaddr<br /> B to blkaddr C, VM_BUG_ON_FOLIO was triggered in the endio initiated by<br /> ra_data_block.<br /> <br /> There is no need to read Page 1 again from blkaddr B, since it has already<br /> been updated. Therefore, avoid initiating I/O in this case.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix data loss caused by incorrect use of nat_entry flag<br /> <br /> Data loss can occur when fsync is performed on a newly created file<br /> (before any checkpoint has been written) concurrently with a checkpoint<br /> operation. The scenario is as follows:<br /> <br /> create &amp; write &amp; fsync &amp;#39;file A&amp;#39; write checkpoint<br /> - f2fs_do_sync_file // inline inode<br /> - f2fs_write_inode // inode folio is dirty<br /> - f2fs_write_checkpoint<br /> - f2fs_flush_merged_writes<br /> - f2fs_sync_node_pages<br /> - f2fs_flush_nat_entries<br /> - f2fs_fsync_node_pages // no dirty node<br /> - f2fs_need_inode_block_update // return false<br /> SPO and lost &amp;#39;file A&amp;#39;<br /> <br /> f2fs_flush_nat_entries() sets the IS_CHECKPOINTED and HAS_LAST_FSYNC<br /> flags for the nat_entry, but this does not mean that the checkpoint has<br /> actually completed successfully. However, f2fs_need_inode_block_update()<br /> checks these flags and incorrectly assumes that the checkpoint has<br /> finished.<br /> <br /> The root cause is that the semantics of IS_CHECKPOINTED and<br /> HAS_LAST_FSYNC are only guaranteed after the checkpoint write fully<br /> completes.<br /> <br /> This patch modifies f2fs_need_inode_block_update() to acquire the<br /> sbi-&gt;node_write lock before reading the nat_entry flags, ensuring that<br /> once IS_CHECKPOINTED and HAS_LAST_FSYNC are observed to be set, the<br /> checkpoint operation has already completed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> greybus: raw: fix use-after-free if write is called after disconnect<br /> <br /> If a user writes to the chardev after disconnect has been called, the<br /> kernel panics with the following trace (with<br /> CONFIG_INIT_ON_FREE_DEFAULT_ON=y):<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000218<br /> ...<br /> Call Trace:<br /> <br /> gb_operation_create_common+0x61/0x180<br /> gb_operation_create_flags+0x28/0xa0<br /> gb_operation_sync_timeout+0x6f/0x100<br /> raw_write+0x7b/0xc7 [gb_raw]<br /> vfs_write+0xcf/0x420<br /> ? task_mm_cid_work+0x136/0x220<br /> ksys_write+0x63/0xe0<br /> do_syscall_64+0xa4/0x290<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Disconnect calls gb_connection_destroy, which ends up freeing the<br /> connection object. When gb_operation_sync is called in the write file<br /> operations, its gets a freed connection as parameter and the kernel<br /> panics.<br /> <br /> The gb_connection_destroy cannot be moved out of the disconnect<br /> function, as the Greybus subsystem expect all connections belonging to a<br /> bundle to be destroyed when disconnect returns.<br /> <br /> To prevent this bug, use a rw lock to synchronize access between write<br /> and disconnect. This guarantees that the write function doesn&amp;#39;t try<br /> to use a disconnected connection.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: terminate the cached volume label after UTF-8 conversion<br /> <br /> ntfs_fill_super() loads the on-disk volume label with utf16s_to_utf8s()<br /> and stores the result in sbi-&gt;volume.label. The converted label is later<br /> exposed through ntfs3_label_show() using %s, but utf16s_to_utf8s() only<br /> returns the number of bytes written and does not add a trailing NUL.<br /> <br /> If the converted label fills the entire fixed buffer,<br /> ntfs3_label_show() can read past the end of sbi-&gt;volume.label while<br /> looking for a terminator.<br /> <br /> Terminate the cached label explicitly after a successful conversion and<br /> clamp the exact-full case to the last byte of the buffer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: dell-wmi-sysman: bound enumeration string aggregation<br /> <br /> populate_enum_data() aggregates firmware-provided value-modifier<br /> and possible-value strings into fixed 512-byte struct members.<br /> The current code bounds each individual source string but then<br /> appends every string and separator with raw strcat() and no<br /> remaining-space check.<br /> <br /> Switch the aggregation loops to a bounded append helper and<br /> reject enumeration packages whose combined strings do not fit<br /> in the destination buffers.<br /> <br /> [ij: add include]