Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/idle: mark arch_cpu_idle() noinstr<br /> <br /> linux-next commit ("cpuidle: tracing: Warn about !rcu_is_watching()")<br /> adds a new warning which hits on s390&amp;#39;s arch_cpu_idle() function:<br /> <br /> RCU not on for: arch_cpu_idle+0x0/0x28<br /> WARNING: CPU: 2 PID: 0 at include/linux/trace_recursion.h:162 arch_ftrace_ops_list_func+0x24c/0x258<br /> Modules linked in:<br /> CPU: 2 PID: 0 Comm: swapper/2 Not tainted 6.2.0-rc6-next-20230202 #4<br /> Hardware name: IBM 8561 T01 703 (z/VM 7.3.0)<br /> Krnl PSW : 0404d00180000000 00000000002b55c0 (arch_ftrace_ops_list_func+0x250/0x258)<br /> R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3<br /> Krnl GPRS: c0000000ffffbfff 0000000080000002 0000000000000026 0000000000000000<br /> 0000037ffffe3a28 0000037ffffe3a20 0000000000000000 0000000000000000<br /> 0000000000000000 0000000000f4acf6 00000000001044f0 0000037ffffe3cb0<br /> 0000000000000000 0000000000000000 00000000002b55bc 0000037ffffe3bb8<br /> Krnl Code: 00000000002b55b0: c02000840051 larl %r2,0000000001335652<br /> 00000000002b55b6: c0e5fff512d1 brasl %r14,0000000000157b58<br /> #00000000002b55bc: af000000 mc 0,0<br /> &gt;00000000002b55c0: a7f4ffe7 brc 15,00000000002b558e<br /> 00000000002b55c4: 0707 bcr 0,%r7<br /> 00000000002b55c6: 0707 bcr 0,%r7<br /> 00000000002b55c8: eb6ff0480024 stmg %r6,%r15,72(%r15)<br /> 00000000002b55ce: b90400ef lgr %r14,%r15<br /> Call Trace:<br /> [] arch_ftrace_ops_list_func+0x250/0x258<br /> ([] arch_ftrace_ops_list_func+0x24c/0x258)<br /> [] ftrace_common+0x1c/0x20<br /> [] arch_cpu_idle+0x6/0x28<br /> [] default_idle_call+0x76/0x128<br /> [] do_idle+0xf4/0x1b0<br /> [] cpu_startup_entry+0x36/0x40<br /> [] smp_start_secondary+0x140/0x150<br /> [] restart_int_handler+0x6e/0x90<br /> <br /> Mark arch_cpu_idle() noinstr like all other architectures with<br /> CONFIG_ARCH_WANTS_NO_INSTR (should) have it to fix this.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm: don&amp;#39;t attempt to queue IO under RCU protection<br /> <br /> dm looks up the table for IO based on the request type, with an<br /> assumption that if the request is marked REQ_NOWAIT, it&amp;#39;s fine to<br /> attempt to submit that IO while under RCU read lock protection. This<br /> is not OK, as REQ_NOWAIT just means that we should not be sleeping<br /> waiting on other IO, it does not mean that we can&amp;#39;t potentially<br /> schedule.<br /> <br /> A simple test case demonstrates this quite nicely:<br /> <br /> int main(int argc, char *argv[])<br /> {<br /> struct iovec iov;<br /> int fd;<br /> <br /> fd = open("/dev/dm-0", O_RDONLY | O_DIRECT);<br /> posix_memalign(&amp;iov.iov_base, 4096, 4096);<br /> iov.iov_len = 4096;<br /> preadv2(fd, &amp;iov, 1, 0, RWF_NOWAIT);<br /> return 0;<br /> }<br /> <br /> which will instantly spew:<br /> <br /> BUG: sleeping function called from invalid context at include/linux/sched/mm.h:306<br /> in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 5580, name: dm-nowait<br /> preempt_count: 0, expected: 0<br /> RCU nest depth: 1, expected: 0<br /> INFO: lockdep is turned off.<br /> CPU: 7 PID: 5580 Comm: dm-nowait Not tainted 6.6.0-rc1-g39956d2dcd81 #132<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x11d/0x1b0<br /> __might_resched+0x3c3/0x5e0<br /> ? preempt_count_sub+0x150/0x150<br /> mempool_alloc+0x1e2/0x390<br /> ? mempool_resize+0x7d0/0x7d0<br /> ? lock_sync+0x190/0x190<br /> ? lock_release+0x4b7/0x670<br /> ? internal_get_user_pages_fast+0x868/0x2d40<br /> bio_alloc_bioset+0x417/0x8c0<br /> ? bvec_alloc+0x200/0x200<br /> ? internal_get_user_pages_fast+0xb8c/0x2d40<br /> bio_alloc_clone+0x53/0x100<br /> dm_submit_bio+0x27f/0x1a20<br /> ? lock_release+0x4b7/0x670<br /> ? blk_try_enter_queue+0x1a0/0x4d0<br /> ? dm_dax_direct_access+0x260/0x260<br /> ? rcu_is_watching+0x12/0xb0<br /> ? blk_try_enter_queue+0x1cc/0x4d0<br /> __submit_bio+0x239/0x310<br /> ? __bio_queue_enter+0x700/0x700<br /> ? kvm_clock_get_cycles+0x40/0x60<br /> ? ktime_get+0x285/0x470<br /> submit_bio_noacct_nocheck+0x4d9/0xb80<br /> ? should_fail_request+0x80/0x80<br /> ? preempt_count_sub+0x150/0x150<br /> ? lock_release+0x4b7/0x670<br /> ? __bio_add_page+0x143/0x2d0<br /> ? iov_iter_revert+0x27/0x360<br /> submit_bio_noacct+0x53e/0x1b30<br /> submit_bio_wait+0x10a/0x230<br /> ? submit_bio_wait_endio+0x40/0x40<br /> __blkdev_direct_IO_simple+0x4f8/0x780<br /> ? blkdev_bio_end_io+0x4c0/0x4c0<br /> ? stack_trace_save+0x90/0xc0<br /> ? __bio_clone+0x3c0/0x3c0<br /> ? lock_release+0x4b7/0x670<br /> ? lock_sync+0x190/0x190<br /> ? atime_needs_update+0x3bf/0x7e0<br /> ? timestamp_truncate+0x21b/0x2d0<br /> ? inode_owner_or_capable+0x240/0x240<br /> blkdev_direct_IO.part.0+0x84a/0x1810<br /> ? rcu_is_watching+0x12/0xb0<br /> ? lock_release+0x4b7/0x670<br /> ? blkdev_read_iter+0x40d/0x530<br /> ? reacquire_held_locks+0x4e0/0x4e0<br /> ? __blkdev_direct_IO_simple+0x780/0x780<br /> ? rcu_is_watching+0x12/0xb0<br /> ? __mark_inode_dirty+0x297/0xd50<br /> ? preempt_count_add+0x72/0x140<br /> blkdev_read_iter+0x2a4/0x530<br /> do_iter_readv_writev+0x2f2/0x3c0<br /> ? generic_copy_file_range+0x1d0/0x1d0<br /> ? fsnotify_perm.part.0+0x25d/0x630<br /> ? security_file_permission+0xd8/0x100<br /> do_iter_read+0x31b/0x880<br /> ? import_iovec+0x10b/0x140<br /> vfs_readv+0x12d/0x1a0<br /> ? vfs_iter_read+0xb0/0xb0<br /> ? rcu_is_watching+0x12/0xb0<br /> ? rcu_is_watching+0x12/0xb0<br /> ? lock_release+0x4b7/0x670<br /> do_preadv+0x1b3/0x260<br /> ? do_readv+0x370/0x370<br /> __x64_sys_preadv2+0xef/0x150<br /> do_syscall_64+0x39/0xb0<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7f5af41ad806<br /> Code: 41 54 41 89 fc 55 44 89 c5 53 48 89 cb 48 83 ec 18 80 3d e4 dd 0d 00 00 74 7a 45 89 c1 49 89 ca 45 31 c0 b8 47 01 00 00 0f 05 3d 00 f0 ff ff 0f 87 be 00 00 00 48 85 c0 79 4a 48 8b 0d da 55<br /> RSP: 002b:00007ffd3145c7f0 EFLAGS: 00000246 ORIG_RAX: 0000000000000147<br /> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5af41ad806<br /> RDX: 0000000000000001 RSI: 00007ffd3145c850 RDI: 0000000000000003<br /> RBP: 0000000000000008 R08: 0000000000000000 R09: 0000000000000008<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000003<br /> R13: 00007ffd3145c850 R14: 000055f5f0431dd8 R15: 0000000000000001<br /> <br /> <br /> where in fact it is<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: correct grp validation in ext4_mb_good_group<br /> <br /> Group corruption check will access memory of grp and will trigger kernel<br /> crash if grp is NULL. So do NULL check before corruption check.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfs: fix missing hfs_bnode_get() in __hfs_bnode_create<br /> <br /> Syzbot found a kernel BUG in hfs_bnode_put():<br /> <br /> kernel BUG at fs/hfs/bnode.c:466!<br /> invalid opcode: 0000 [#1] PREEMPT SMP KASAN<br /> CPU: 0 PID: 3634 Comm: kworker/u4:5 Not tainted 6.1.0-rc7-syzkaller-00190-g97ee9d1c1696 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022<br /> Workqueue: writeback wb_workfn (flush-7:0)<br /> RIP: 0010:hfs_bnode_put+0x46f/0x480 fs/hfs/bnode.c:466<br /> Code: 8a 80 ff e9 73 fe ff ff 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c a0 fe ff ff 48 89 df e8 db 8a 80 ff e9 93 fe ff ff e8 a1 68 2c ff 0b e8 9a 68 2c ff 0f 0b 0f 1f 84 00 00 00 00 00 55 41 57 41 56<br /> RSP: 0018:ffffc90003b4f258 EFLAGS: 00010293<br /> RAX: ffffffff825e318f RBX: 0000000000000000 RCX: ffff8880739dd7c0<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: ffffc90003b4f430 R08: ffffffff825e2d9b R09: ffffed10045157d1<br /> R10: ffffed10045157d1 R11: 1ffff110045157d0 R12: ffff8880228abe80<br /> R13: ffff88807016c000 R14: dffffc0000000000 R15: ffff8880228abe00<br /> FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fa6ebe88718 CR3: 000000001e93d000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> hfs_write_inode+0x1bc/0xb40<br /> write_inode fs/fs-writeback.c:1440 [inline]<br /> __writeback_single_inode+0x4d6/0x670 fs/fs-writeback.c:1652<br /> writeback_sb_inodes+0xb3b/0x18f0 fs/fs-writeback.c:1878<br /> __writeback_inodes_wb+0x125/0x420 fs/fs-writeback.c:1949<br /> wb_writeback+0x440/0x7b0 fs/fs-writeback.c:2054<br /> wb_check_start_all fs/fs-writeback.c:2176 [inline]<br /> wb_do_writeback fs/fs-writeback.c:2202 [inline]<br /> wb_workfn+0x827/0xef0 fs/fs-writeback.c:2235<br /> process_one_work+0x877/0xdb0 kernel/workqueue.c:2289<br /> worker_thread+0xb14/0x1330 kernel/workqueue.c:2436<br /> kthread+0x266/0x300 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306<br /> <br /> <br /> The BUG_ON() is triggered at here:<br /> <br /> /* Dispose of resources used by a node */<br /> void hfs_bnode_put(struct hfs_bnode *node)<br /> {<br /> if (node) {<br /> <br /> BUG_ON(!atomic_read(&amp;node-&gt;refcnt));

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to do sanity check on direct node in truncate_dnode()<br /> <br /> syzbot reports below bug:<br /> <br /> BUG: KASAN: slab-use-after-free in f2fs_truncate_data_blocks_range+0x122a/0x14c0 fs/f2fs/file.c:574<br /> Read of size 4 at addr ffff88802a25c000 by task syz-executor148/5000<br /> <br /> CPU: 1 PID: 5000 Comm: syz-executor148 Not tainted 6.4.0-rc7-syzkaller-00041-ge660abd551f1 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106<br /> print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351<br /> print_report mm/kasan/report.c:462 [inline]<br /> kasan_report+0x11c/0x130 mm/kasan/report.c:572<br /> f2fs_truncate_data_blocks_range+0x122a/0x14c0 fs/f2fs/file.c:574<br /> truncate_dnode+0x229/0x2e0 fs/f2fs/node.c:944<br /> f2fs_truncate_inode_blocks+0x64b/0xde0 fs/f2fs/node.c:1154<br /> f2fs_do_truncate_blocks+0x4ac/0xf30 fs/f2fs/file.c:721<br /> f2fs_truncate_blocks+0x7b/0x300 fs/f2fs/file.c:749<br /> f2fs_truncate.part.0+0x4a5/0x630 fs/f2fs/file.c:799<br /> f2fs_truncate include/linux/fs.h:825 [inline]<br /> f2fs_setattr+0x1738/0x2090 fs/f2fs/file.c:1006<br /> notify_change+0xb2c/0x1180 fs/attr.c:483<br /> do_truncate+0x143/0x200 fs/open.c:66<br /> handle_truncate fs/namei.c:3295 [inline]<br /> do_open fs/namei.c:3640 [inline]<br /> path_openat+0x2083/0x2750 fs/namei.c:3791<br /> do_filp_open+0x1ba/0x410 fs/namei.c:3818<br /> do_sys_openat2+0x16d/0x4c0 fs/open.c:1356<br /> do_sys_open fs/open.c:1372 [inline]<br /> __do_sys_creat fs/open.c:1448 [inline]<br /> __se_sys_creat fs/open.c:1442 [inline]<br /> __x64_sys_creat+0xcd/0x120 fs/open.c:1442<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> The root cause is, inodeA references inodeB via inodeB&amp;#39;s ino, once inodeA<br /> is truncated, it calls truncate_dnode() to truncate data blocks in inodeB&amp;#39;s<br /> node page, it traverse mapping data from node-&gt;i.i_addr[0] to<br /> node-&gt;i.i_addr[ADDRS_PER_BLOCK() - 1], result in out-of-boundary access.<br /> <br /> This patch fixes to add sanity check on dnode page in truncate_dnode(),<br /> so that, it can help to avoid triggering such issue, and once it encounters<br /> such issue, it will record newly introduced ERROR_INVALID_NODE_REFERENCE<br /> error into superblock, later fsck can detect such issue and try repairing.<br /> <br /> Also, it removes f2fs_truncate_data_blocks() for cleanup due to the<br /> function has only one caller, and uses f2fs_truncate_data_blocks_range()<br /> instead.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb-storage: alauda: Fix uninit-value in alauda_check_media()<br /> <br /> Syzbot got KMSAN to complain about access to an uninitialized value in<br /> the alauda subdriver of usb-storage:<br /> <br /> BUG: KMSAN: uninit-value in alauda_transport+0x462/0x57f0<br /> drivers/usb/storage/alauda.c:1137<br /> CPU: 0 PID: 12279 Comm: usb-storage Not tainted 5.3.0-rc7+ #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS<br /> Google 01/01/2011<br /> Call Trace:<br /> __dump_stack lib/dump_stack.c:77 [inline]<br /> dump_stack+0x191/0x1f0 lib/dump_stack.c:113<br /> kmsan_report+0x13a/0x2b0 mm/kmsan/kmsan_report.c:108<br /> __msan_warning+0x73/0xe0 mm/kmsan/kmsan_instr.c:250<br /> alauda_check_media+0x344/0x3310 drivers/usb/storage/alauda.c:460<br /> <br /> The problem is that alauda_check_media() doesn&amp;#39;t verify that its USB<br /> transfer succeeded before trying to use the received data. What<br /> should happen if the transfer fails isn&amp;#39;t entirely clear, but a<br /> reasonably conservative approach is to pretend that no media is<br /> present.<br /> <br /> A similar problem exists in a usb_stor_dbg() call in<br /> alauda_get_media_status(). In this case, when an error occurs the<br /> call is redundant, because usb_stor_ctrl_transfer() already will print<br /> a debugging message.<br /> <br /> Finally, unrelated to the uninitialized memory access, is the fact<br /> that alauda_check_media() performs DMA to a buffer on the stack.<br /> Fortunately usb-storage provides a general purpose DMA-able buffer for<br /> uses like this. We&amp;#39;ll use it instead.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid5-cache: fix a deadlock in r5l_exit_log()<br /> <br /> Commit b13015af94cf ("md/raid5-cache: Clear conf-&gt;log after finishing<br /> work") introduce a new problem:<br /> <br /> // caller hold reconfig_mutex<br /> r5l_exit_log<br /> flush_work(&amp;log-&gt;disable_writeback_work)<br /> r5c_disable_writeback_async<br /> wait_event<br /> /*<br /> * conf-&gt;log is not NULL, and mddev_trylock()<br /> * will fail, wait_event() can never pass.<br /> */<br /> conf-&gt;log = NULL<br /> <br /> Fix this problem by setting &amp;#39;config-&gt;log&amp;#39; to NULL before wake_up() as it<br /> used to be, so that wait_event() from r5c_disable_writeback_async() can<br /> exist. In the meantime, move forward md_unregister_thread() so that<br /> null-ptr-deref this commit fixed can still be fixed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: fix workqueue leak on bind errors<br /> <br /> Make sure to destroy the workqueue also in case of early errors during<br /> bind (e.g. a subcomponent failing to bind).<br /> <br /> Since commit c3b790ea07a1 ("drm: Manage drm_mode_config_init with<br /> drmm_") the mode config will be freed when the drm device is released<br /> also when using the legacy interface, but add an explicit cleanup for<br /> consistency and to facilitate backporting.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/525093/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iavf: use internal state to free traffic IRQs<br /> <br /> If the system tries to close the netdev while iavf_reset_task() is<br /> running, __LINK_STATE_START will be cleared and netif_running() will<br /> return false in iavf_reinit_interrupt_scheme(). This will result in<br /> iavf_free_traffic_irqs() not being called and a leak as follows:<br /> <br /> [7632.489326] remove_proc_entry: removing non-empty directory &amp;#39;irq/999&amp;#39;, leaking at least &amp;#39;iavf-enp24s0f0v0-TxRx-0&amp;#39;<br /> [7632.490214] WARNING: CPU: 0 PID: 10 at fs/proc/generic.c:718 remove_proc_entry+0x19b/0x1b0<br /> <br /> is shown when pci_disable_msix() is later called. Fix by using the<br /> internal adapter state. The traffic IRQs will always exist if<br /> state == __IAVF_RUNNING.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dp: Drop aux devices together with DP controller<br /> <br /> Using devres to depopulate the aux bus made sure that upon a probe<br /> deferral the EDP panel device would be destroyed and recreated upon next<br /> attempt.<br /> <br /> But the struct device which the devres is tied to is the DPUs<br /> (drm_dev-&gt;dev), which may be happen after the DP controller is torn<br /> down.<br /> <br /> Indications of this can be seen in the commonly seen EDID-hexdump full<br /> of zeros in the log, or the occasional/rare KASAN fault where the<br /> panel&amp;#39;s attempt to read the EDID information causes a use after free on<br /> DP resources.<br /> <br /> It&amp;#39;s tempting to move the devres to the DP controller&amp;#39;s struct device,<br /> but the resources used by the device(s) on the aux bus are explicitly<br /> torn down in the error path. The KASAN-reported use-after-free also<br /> remains, as the DP aux "module" explicitly frees its devres-allocated<br /> memory in this code path.<br /> <br /> As such, explicitly depopulate the aux bus in the error path, and in the<br /> component unbind path, to avoid these issues.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/542163/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-core: fix memory leak in dhchap_secret_store<br /> <br /> Free dhchap_secret in nvme_ctrl_dhchap_secret_store() before we return<br /> fix following kmemleack:-<br /> <br /> unreferenced object 0xffff8886376ea800 (size 64):<br /> comm "check", pid 22048, jiffies 4344316705 (age 92.199s)<br /> hex dump (first 32 bytes):<br /> 44 48 48 43 2d 31 3a 30 30 3a 6e 78 72 35 4b 67 DHHC-1:00:nxr5Kg<br /> 75 58 34 75 6f 41 78 73 4a 61 34 63 2f 68 75 4c uX4uoAxsJa4c/huL<br /> backtrace:<br /> [] __kmalloc+0x4b/0x130<br /> [] nvme_ctrl_dhchap_secret_store+0x8f/0x160 [nvme_core]<br /> [] kernfs_fop_write_iter+0x12b/0x1c0<br /> [] vfs_write+0x2ba/0x3c0<br /> [] ksys_write+0x5f/0xe0<br /> [] do_syscall_64+0x3b/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> unreferenced object 0xffff8886376eaf00 (size 64):<br /> comm "check", pid 22048, jiffies 4344316736 (age 92.168s)<br /> hex dump (first 32 bytes):<br /> 44 48 48 43 2d 31 3a 30 30 3a 6e 78 72 35 4b 67 DHHC-1:00:nxr5Kg<br /> 75 58 34 75 6f 41 78 73 4a 61 34 63 2f 68 75 4c uX4uoAxsJa4c/huL<br /> backtrace:<br /> [] __kmalloc+0x4b/0x130<br /> [] nvme_ctrl_dhchap_secret_store+0x8f/0x160 [nvme_core]<br /> [] kernfs_fop_write_iter+0x12b/0x1c0<br /> [] vfs_write+0x2ba/0x3c0<br /> [] ksys_write+0x5f/0xe0<br /> [] do_syscall_64+0x3b/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x72/0xdc

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netlink: annotate accesses to nlk-&gt;cb_running<br /> <br /> Both netlink_recvmsg() and netlink_native_seq_show() read<br /> nlk-&gt;cb_running locklessly. Use READ_ONCE() there.<br /> <br /> Add corresponding WRITE_ONCE() to netlink_dump() and<br /> __netlink_dump_start()<br /> <br /> syzbot reported:<br /> BUG: KCSAN: data-race in __netlink_dump_start / netlink_recvmsg<br /> <br /> write to 0xffff88813ea4db59 of 1 bytes by task 28219 on cpu 0:<br /> __netlink_dump_start+0x3af/0x4d0 net/netlink/af_netlink.c:2399<br /> netlink_dump_start include/linux/netlink.h:308 [inline]<br /> rtnetlink_rcv_msg+0x70f/0x8c0 net/core/rtnetlink.c:6130<br /> netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2577<br /> rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6192<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]<br /> netlink_unicast+0x56f/0x640 net/netlink/af_netlink.c:1365<br /> netlink_sendmsg+0x665/0x770 net/netlink/af_netlink.c:1942<br /> sock_sendmsg_nosec net/socket.c:724 [inline]<br /> sock_sendmsg net/socket.c:747 [inline]<br /> sock_write_iter+0x1aa/0x230 net/socket.c:1138<br /> call_write_iter include/linux/fs.h:1851 [inline]<br /> new_sync_write fs/read_write.c:491 [inline]<br /> vfs_write+0x463/0x760 fs/read_write.c:584<br /> ksys_write+0xeb/0x1a0 fs/read_write.c:637<br /> __do_sys_write fs/read_write.c:649 [inline]<br /> __se_sys_write fs/read_write.c:646 [inline]<br /> __x64_sys_write+0x42/0x50 fs/read_write.c:646<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> read to 0xffff88813ea4db59 of 1 bytes by task 28222 on cpu 1:<br /> netlink_recvmsg+0x3b4/0x730 net/netlink/af_netlink.c:2022<br /> sock_recvmsg_nosec+0x4c/0x80 net/socket.c:1017<br /> ____sys_recvmsg+0x2db/0x310 net/socket.c:2718<br /> ___sys_recvmsg net/socket.c:2762 [inline]<br /> do_recvmmsg+0x2e5/0x710 net/socket.c:2856<br /> __sys_recvmmsg net/socket.c:2935 [inline]<br /> __do_sys_recvmmsg net/socket.c:2958 [inline]<br /> __se_sys_recvmmsg net/socket.c:2951 [inline]<br /> __x64_sys_recvmmsg+0xe2/0x160 net/socket.c:2951<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> value changed: 0x00 -&gt; 0x01