Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: fix listxattr handling when the buffer is full<br /> <br /> [BUG]<br /> If an OCFS2 inode has both inline and block-based xattrs, listxattr()<br /> can return a size larger than the caller&amp;#39;s buffer when the inline names<br /> consume that buffer exactly.<br /> <br /> kernel BUG at mm/usercopy.c:102!<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI<br /> RIP: 0010:usercopy_abort+0xb7/0xd0 mm/usercopy.c:102<br /> Call Trace:<br /> __check_heap_object+0xe3/0x120 mm/slub.c:8243<br /> check_heap_object mm/usercopy.c:196 [inline]<br /> __check_object_size mm/usercopy.c:250 [inline]<br /> __check_object_size+0x5c5/0x780 mm/usercopy.c:215<br /> check_object_size include/linux/ucopysize.h:22 [inline]<br /> check_copy_size include/linux/ucopysize.h:59 [inline]<br /> copy_to_user include/linux/uaccess.h:219 [inline]<br /> listxattr+0xb0/0x170 fs/xattr.c:926<br /> filename_listxattr fs/xattr.c:958 [inline]<br /> path_listxattrat+0x137/0x320 fs/xattr.c:988<br /> __do_sys_listxattr fs/xattr.c:1001 [inline]<br /> __se_sys_listxattr fs/xattr.c:998 [inline]<br /> __x64_sys_listxattr+0x7f/0xd0 fs/xattr.c:998<br /> ...<br /> <br /> [CAUSE]<br /> Commit 936b8834366e ("ocfs2: Refactor xattr list and remove<br /> ocfs2_xattr_handler().") replaced the old per-handler list accounting<br /> with ocfs2_xattr_list_entry(), but it kept using size == 0 to detect<br /> probe mode.<br /> <br /> That assumption stops being true once ocfs2_listxattr() finishes the<br /> inline-xattr pass. If the inline names fill the caller buffer exactly,<br /> the block-xattr pass runs with a non-NULL buffer and a remaining size of<br /> zero. ocfs2_xattr_list_entry() then skips the bounds check, keeps<br /> counting block names, and returns a positive size larger than the<br /> supplied buffer.<br /> <br /> [FIX]<br /> Detect probe mode by testing whether the destination buffer pointer is<br /> NULL instead of whether the remaining size is zero.<br /> <br /> That restores the pre-refactor behavior and matches the OCFS2 getxattr<br /> helpers. Once the remaining buffer reaches zero while more names are<br /> left, the block-xattr pass now returns -ERANGE instead of reporting a<br /> size larger than the allocated list buffer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: validate bg_bits during freefrag scan<br /> <br /> [BUG]<br /> A crafted filesystem can trigger an out-of-bounds bitmap walk when<br /> OCFS2_IOC_INFO is issued with OCFS2_INFO_FL_NON_COHERENT.<br /> <br /> BUG: KASAN: use-after-free in instrument_atomic_read include/linux/instrumented.h:68 [inline]<br /> BUG: KASAN: use-after-free in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]<br /> BUG: KASAN: use-after-free in test_bit_le include/asm-generic/bitops/le.h:21 [inline]<br /> BUG: KASAN: use-after-free in ocfs2_info_freefrag_scan_chain fs/ocfs2/ioctl.c:495 [inline]<br /> BUG: KASAN: use-after-free in ocfs2_info_freefrag_scan_bitmap fs/ocfs2/ioctl.c:588 [inline]<br /> BUG: KASAN: use-after-free in ocfs2_info_handle_freefrag fs/ocfs2/ioctl.c:662 [inline]<br /> BUG: KASAN: use-after-free in ocfs2_info_handle_request+0x1c66/0x3370 fs/ocfs2/ioctl.c:754<br /> Read of size 8 at addr ffff888031bce000 by task syz.0.636/1435<br /> Call Trace:<br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0xbe/0x130 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0xd1/0x650 mm/kasan/report.c:482<br /> kasan_report+0xfb/0x140 mm/kasan/report.c:595<br /> check_region_inline mm/kasan/generic.c:186 [inline]<br /> kasan_check_range+0x11c/0x200 mm/kasan/generic.c:200<br /> __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31<br /> instrument_atomic_read include/linux/instrumented.h:68 [inline]<br /> _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]<br /> test_bit_le include/asm-generic/bitops/le.h:21 [inline]<br /> ocfs2_info_freefrag_scan_chain fs/ocfs2/ioctl.c:495 [inline]<br /> ocfs2_info_freefrag_scan_bitmap fs/ocfs2/ioctl.c:588 [inline]<br /> ocfs2_info_handle_freefrag fs/ocfs2/ioctl.c:662 [inline]<br /> ocfs2_info_handle_request+0x1c66/0x3370 fs/ocfs2/ioctl.c:754<br /> ocfs2_info_handle+0x18d/0x2a0 fs/ocfs2/ioctl.c:828<br /> ocfs2_ioctl+0x632/0x6e0 fs/ocfs2/ioctl.c:913<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:597 [inline]<br /> __se_sys_ioctl fs/ioctl.c:583 [inline]<br /> __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583<br /> ...<br /> <br /> [CAUSE]<br /> ocfs2_info_freefrag_scan_chain() uses on-disk bg_bits directly as the<br /> bitmap scan limit. The coherent path reads group descriptors through<br /> ocfs2_read_group_descriptor(), which validates the descriptor before<br /> use. The non-coherent path uses ocfs2_read_blocks_sync() instead and<br /> skips that validation, so an impossible bg_bits value can drive the<br /> bitmap walk past the end of the block.<br /> <br /> [FIX]<br /> Compute the bitmap capacity from the filesystem format with<br /> ocfs2_group_bitmap_size(), report descriptors whose bg_bits exceeds<br /> that limit, and clamp the scan to the computed capacity. This keeps the<br /> freefrag report going while avoiding reads beyond the buffer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: validate group add input before caching<br /> <br /> [BUG]<br /> OCFS2_IOC_GROUP_ADD can trigger a BUG_ON in<br /> ocfs2_set_new_buffer_uptodate():<br /> <br /> kernel BUG at fs/ocfs2/uptodate.c:509!<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI<br /> RIP: 0010:ocfs2_set_new_buffer_uptodate+0x194/0x1e0 fs/ocfs2/uptodate.c:509<br /> Code: ffffe88f 42b9fe4c 89e64889 dfe8b4df<br /> Call Trace:<br /> ocfs2_group_add+0x3f1/0x1510 fs/ocfs2/resize.c:507<br /> ocfs2_ioctl+0x309/0x6e0 fs/ocfs2/ioctl.c:887<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:597 [inline]<br /> __se_sys_ioctl fs/ioctl.c:583 [inline]<br /> __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583<br /> x64_sys_call+0x1144/0x26a0 arch/x86/include/generated/asm/syscalls_64.h:17<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0x93/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7bbfb55a966d<br /> <br /> [CAUSE]<br /> ocfs2_group_add() calls ocfs2_set_new_buffer_uptodate() on a<br /> user-controlled group block before ocfs2_verify_group_and_input()<br /> validates that block number. That helper is only valid for newly<br /> allocated metadata and asserts that the block is not already present in<br /> the chosen metadata cache. The code also uses INODE_CACHE(inode) even<br /> though the group descriptor belongs to main_bm_inode and later journal<br /> accesses use that cache context instead.<br /> <br /> [FIX]<br /> Validate the on-disk group descriptor before caching it, then add it to<br /> the metadata cache tracked by INODE_CACHE(main_bm_inode). Keep the<br /> validation failure path separate from the later cleanup path so we only<br /> remove the buffer from that cache after it has actually been inserted.<br /> This keeps the group buffer lifetime consistent across validation,<br /> journaling, and cleanup.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ima_fs: Correctly create securityfs files for unsupported hash algos<br /> <br /> ima_tpm_chip-&gt;allocated_banks[i].crypto_id is initialized to<br /> HASH_ALGO__LAST if the TPM algorithm is not supported. However there<br /> are places relying on the algorithm to be valid because it is accessed<br /> by hash_algo_name[].<br /> <br /> On 6.12.40 I observe the following read out-of-bounds in hash_algo_name:<br /> ==================================================================<br /> BUG: KASAN: global-out-of-bounds in create_securityfs_measurement_lists+0x396/0x440<br /> Read of size 8 at addr ffffffff83e18138 by task swapper/0/1<br /> <br /> CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.40 #3<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x61/0x90<br /> print_report+0xc4/0x580<br /> ? kasan_addr_to_slab+0x26/0x80<br /> ? create_securityfs_measurement_lists+0x396/0x440<br /> kasan_report+0xc2/0x100<br /> ? create_securityfs_measurement_lists+0x396/0x440<br /> create_securityfs_measurement_lists+0x396/0x440<br /> ima_fs_init+0xa3/0x300<br /> ima_init+0x7d/0xd0<br /> init_ima+0x28/0x100<br /> do_one_initcall+0xa6/0x3e0<br /> kernel_init_freeable+0x455/0x740<br /> kernel_init+0x24/0x1d0<br /> ret_from_fork+0x38/0x80<br /> ret_from_fork_asm+0x11/0x20<br /> <br /> <br /> The buggy address belongs to the variable:<br /> hash_algo_name+0xb8/0x420<br /> <br /> Memory state around the buggy address:<br /> ffffffff83e18000: 00 01 f9 f9 f9 f9 f9 f9 00 01 f9 f9 f9 f9 f9 f9<br /> ffffffff83e18080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> &gt;ffffffff83e18100: 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 00 05 f9 f9<br /> ^<br /> ffffffff83e18180: f9 f9 f9 f9 00 00 00 00 00 00 00 04 f9 f9 f9 f9<br /> ffffffff83e18200: 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9<br /> ==================================================================<br /> <br /> Seems like the TPM chip supports sha3_256, which isn&amp;#39;t yet in<br /> tpm_algorithms:<br /> tpm tpm0: TPM with unsupported bank algorithm 0x0027<br /> <br /> That&amp;#39;s TPM_ALG_SHA3_256 == 0x0027 from "Trusted Platform Module 2.0<br /> Library Part 2: Structures", page 51 [1].<br /> See also the related U-Boot algorithms update [2].<br /> <br /> Thus solve the problem by creating a file name with "_tpm_alg_"<br /> postfix if the crypto algorithm isn&amp;#39;t initialized.<br /> <br /> This is how it looks on the test machine (patch ported to v6.12 release):<br /> # ls -1 /sys/kernel/security/ima/<br /> ascii_runtime_measurements<br /> ascii_runtime_measurements_tpm_alg_27<br /> ascii_runtime_measurements_sha1<br /> ascii_runtime_measurements_sha256<br /> binary_runtime_measurements<br /> binary_runtime_measurements_tpm_alg_27<br /> binary_runtime_measurements_sha1<br /> binary_runtime_measurements_sha256<br /> policy<br /> runtime_measurements_count<br /> violations<br /> <br /> [1]: https://trustedcomputinggroup.org/wp-content/uploads/Trusted-Platform-Module-2.0-Library-Part-2-Version-184_pub.pdf<br /> [2]: https://lists.denx.de/pipermail/u-boot/2024-July/558835.html

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: usbhid: fix deadlock in hid_post_reset()<br /> <br /> You can build a USB device that includes a HID component<br /> and a storage or UAS component. The components can be reset<br /> only together. That means that hid_pre_reset() and hid_post_reset()<br /> are in the block IO error handling. Hence no memory allocation<br /> used in them may do block IO because the IO can deadlock<br /> on the mutex held while resetting a device and calling the<br /> interface drivers.<br /> Use GFP_NOIO for all allocations in them.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: Fix error pointer dereference<br /> <br /> The variable tps-&gt;partner is checked for an error pointer and then if it<br /> is, it sends an error message but does not return and then immediately<br /> dereferenced a few lines below:<br /> <br /> tps-&gt;partner = typec_register_partner(tps-&gt;port, &amp;desc);<br /> if (IS_ERR(tps-&gt;partner))<br /> dev_warn(tps-&gt;dev, "%s: failed to register partnet\n", __func__);<br /> <br /> if (desc.identity) {<br /> typec_partner_set_identity(tps-&gt;partner);<br /> cd321x-&gt;cur_partner_identity = st.partner_identity;<br /> }<br /> <br /> Add early return and fix spelling mistake in error message.<br /> <br /> Detected by Smatch:<br /> drivers/usb/typec/tipd/core.c:827 cd321x_update_work() error:<br /> &amp;#39;tps-&gt;partner&amp;#39; dereferencing possible ERR_PTR()

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: prevent uninitialized lcn caused by zero len<br /> <br /> syzbot reported a uninit-value in ntfs_iomap_begin [1].<br /> <br /> Since runs was not touched yet, run_lookup_entry() immediately fails<br /> and returns false, which makes the value of "*len" 0.<br /> Simultaneously, the new value and err value are also 0, causing the<br /> logic in attr_data_get_block_locked() to jump directly to ok, ultimately<br /> resulting in *lcn being triggered before it is set [1].<br /> <br /> In ntfs_iomap_begin(), the check for a 0 value in clen is moved forward<br /> to before updating lcn to avoid this [1].<br /> <br /> [1]<br /> BUG: KMSAN: uninit-value in ntfs_iomap_begin+0x8c0/0x1460 fs/ntfs3/inode.c:825<br /> ntfs_iomap_begin+0x8c0/0x1460 fs/ntfs3/inode.c:825<br /> iomap_iter+0x9b7/0x1540 fs/iomap/iter.c:110<br /> <br /> Local variable lcn created at:<br /> ntfs_iomap_begin+0x15d/0x1460 fs/ntfs3/inode.c:786

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Validate node_id in arena_alloc_pages()<br /> <br /> arena_alloc_pages() accepts a plain int node_id and forwards it through<br /> the entire allocation chain without any bounds checking.<br /> <br /> Validate node_id before passing it down the allocation chain in<br /> arena_alloc_pages().

*** 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.