Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix use-after-free of nilfs_root in dirtying inodes via iput<br /> <br /> During unmount process of nilfs2, nothing holds nilfs_root structure after<br /> nilfs2 detaches its writer in nilfs_detach_log_writer(). Previously,<br /> nilfs_evict_inode() could cause use-after-free read for nilfs_root if<br /> inodes are left in "garbage_list" and released by nilfs_dispose_list at<br /> the end of nilfs_detach_log_writer(), and this bug was fixed by commit<br /> 9b5a04ac3ad9 ("nilfs2: fix use-after-free bug of nilfs_root in<br /> nilfs_evict_inode()").<br /> <br /> However, it turned out that there is another possibility of UAF in the<br /> call path where mark_inode_dirty_sync() is called from iput():<br /> <br /> nilfs_detach_log_writer()<br /> nilfs_dispose_list()<br /> iput()<br /> mark_inode_dirty_sync()<br /> __mark_inode_dirty()<br /> nilfs_dirty_inode()<br /> __nilfs_mark_inode_dirty()<br /> nilfs_load_inode_block() --&gt; causes UAF of nilfs_root struct<br /> <br /> This can happen after commit 0ae45f63d4ef ("vfs: add support for a<br /> lazytime mount option"), which changed iput() to call<br /> mark_inode_dirty_sync() on its final reference if i_state has I_DIRTY_TIME<br /> flag and i_nlink is non-zero.<br /> <br /> This issue appears after commit 28a65b49eb53 ("nilfs2: do not write dirty<br /> data after degenerating to read-only") when using the syzbot reproducer,<br /> but the issue has potentially existed before.<br /> <br /> Fix this issue by adding a "purging flag" to the nilfs structure, setting<br /> that flag while disposing the "garbage_list" and checking it in<br /> __nilfs_mark_inode_dirty().<br /> <br /> Unlike commit 9b5a04ac3ad9 ("nilfs2: fix use-after-free bug of nilfs_root<br /> in nilfs_evict_inode()"), this patch does not rely on ns_writer to<br /> determine whether to skip operations, so as not to break recovery on<br /> mount. The nilfs_salvage_orphan_logs routine dirties the buffer of<br /> salvaged data before attaching the log writer, so changing<br /> __nilfs_mark_inode_dirty() to skip the operation when ns_writer is NULL<br /> will cause recovery write to fail. The purpose of using the cleanup-only<br /> flag is to allow for narrowing of such conditions.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hns: fix possible memory leak in hnae_ae_register()<br /> <br /> Inject fault while probing module, if device_register() fails,<br /> but the refcount of kobject is not decreased to 0, the name<br /> allocated in dev_set_name() is leaked. Fix this by calling<br /> put_device(), so that name can be freed in callback function<br /> kobject_cleanup().<br /> <br /> unreferenced object 0xffff00c01aba2100 (size 128):<br /> comm "systemd-udevd", pid 1259, jiffies 4294903284 (age 294.152s)<br /> hex dump (first 32 bytes):<br /> 68 6e 61 65 30 00 00 00 18 21 ba 1a c0 00 ff ff hnae0....!......<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] slab_post_alloc_hook+0xa0/0x3e0<br /> [] __kmem_cache_alloc_node+0x164/0x2b0<br /> [] __kmalloc_node_track_caller+0x6c/0x390<br /> [] kvasprintf+0x8c/0x118<br /> [] kvasprintf_const+0x60/0xc8<br /> [] kobject_set_name_vargs+0x3c/0xc0<br /> [] dev_set_name+0x7c/0xa0<br /> [] hnae_ae_register+0xcc/0x190 [hnae]<br /> [] hns_dsaf_ae_init+0x9c/0x108 [hns_dsaf]<br /> [] hns_dsaf_probe+0x548/0x748 [hns_dsaf]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_set_rbtree: fix overlap expiration walk<br /> <br /> The lazy gc on insert that should remove timed-out entries fails to release<br /> the other half of the interval, if any.<br /> <br /> Can be reproduced with tests/shell/testcases/sets/0044interval_overlap_0<br /> in nftables.git and kmemleak enabled kernel.<br /> <br /> Second bug is the use of rbe_prev vs. prev pointer.<br /> If rbe_prev() returns NULL after at least one iteration, rbe_prev points<br /> to element that is not an end interval, hence it should not be removed.<br /> <br /> Lastly, check the genmask of the end interval if this is active in the<br /> current generation.

*** Pendiente de traducción *** Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix null-ptr-deref in ext4_write_info<br /> <br /> I caught a null-ptr-deref bug as follows:<br /> ==================================================================<br /> KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f]<br /> CPU: 1 PID: 1589 Comm: umount Not tainted 5.10.0-02219-dirty #339<br /> RIP: 0010:ext4_write_info+0x53/0x1b0<br /> [...]<br /> Call Trace:<br /> dquot_writeback_dquots+0x341/0x9a0<br /> ext4_sync_fs+0x19e/0x800<br /> __sync_filesystem+0x83/0x100<br /> sync_filesystem+0x89/0xf0<br /> generic_shutdown_super+0x79/0x3e0<br /> kill_block_super+0xa1/0x110<br /> deactivate_locked_super+0xac/0x130<br /> deactivate_super+0xb6/0xd0<br /> cleanup_mnt+0x289/0x400<br /> __cleanup_mnt+0x16/0x20<br /> task_work_run+0x11c/0x1c0<br /> exit_to_user_mode_prepare+0x203/0x210<br /> syscall_exit_to_user_mode+0x5b/0x3a0<br /> do_syscall_64+0x59/0x70<br /> entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> ==================================================================<br /> <br /> Above issue may happen as follows:<br /> -------------------------------------<br /> exit_to_user_mode_prepare<br /> task_work_run<br /> __cleanup_mnt<br /> cleanup_mnt<br /> deactivate_super<br /> deactivate_locked_super<br /> kill_block_super<br /> generic_shutdown_super<br /> shrink_dcache_for_umount<br /> dentry = sb-&gt;s_root<br /> sb-&gt;s_root = NULL s_op-&gt;sync_fs &gt; ext4_sync_fs<br /> dquot_writeback_dquots<br /> sb-&gt;dq_op-&gt;write_info &gt; ext4_write_info<br /> ext4_journal_start(d_inode(sb-&gt;s_root), EXT4_HT_QUOTA, 2)<br /> d_inode(sb-&gt;s_root)<br /> s_root-&gt;d_inode

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: init quota for &amp;#39;old.inode&amp;#39; in &amp;#39;ext4_rename&amp;#39;<br /> <br /> Syzbot found the following issue:<br /> ext4_parse_param: s_want_extra_isize=128<br /> ext4_inode_info_init: s_want_extra_isize=32<br /> ext4_rename: old.inode=ffff88823869a2c8 old.dir=ffff888238699828 new.inode=ffff88823869d7e8 new.dir=ffff888238699828<br /> __ext4_mark_inode_dirty: inode=ffff888238699828 ea_isize=32 want_ea_size=128<br /> __ext4_mark_inode_dirty: inode=ffff88823869a2c8 ea_isize=32 want_ea_size=128<br /> ext4_xattr_block_set: inode=ffff88823869a2c8<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 13 PID: 2234 at fs/ext4/xattr.c:2070 ext4_xattr_block_set.cold+0x22/0x980<br /> Modules linked in:<br /> RIP: 0010:ext4_xattr_block_set.cold+0x22/0x980<br /> RSP: 0018:ffff888227d3f3b0 EFLAGS: 00010202<br /> RAX: 0000000000000001 RBX: ffff88823007a000 RCX: 0000000000000000<br /> RDX: 0000000000000a03 RSI: 0000000000000040 RDI: ffff888230078178<br /> RBP: 0000000000000000 R08: 000000000000002c R09: ffffed1075c7df8e<br /> R10: ffff8883ae3efc6b R11: ffffed1075c7df8d R12: 0000000000000000<br /> R13: ffff88823869a2c8 R14: ffff8881012e0460 R15: dffffc0000000000<br /> FS: 00007f350ac1f740(0000) GS:ffff8883ae200000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f350a6ed6a0 CR3: 0000000237456000 CR4: 00000000000006e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? ext4_xattr_set_entry+0x3b7/0x2320<br /> ? ext4_xattr_block_set+0x0/0x2020<br /> ? ext4_xattr_set_entry+0x0/0x2320<br /> ? ext4_xattr_check_entries+0x77/0x310<br /> ? ext4_xattr_ibody_set+0x23b/0x340<br /> ext4_xattr_move_to_block+0x594/0x720<br /> ext4_expand_extra_isize_ea+0x59a/0x10f0<br /> __ext4_expand_extra_isize+0x278/0x3f0<br /> __ext4_mark_inode_dirty.cold+0x347/0x410<br /> ext4_rename+0xed3/0x174f<br /> vfs_rename+0x13a7/0x2510<br /> do_renameat2+0x55d/0x920<br /> __x64_sys_rename+0x7d/0xb0<br /> do_syscall_64+0x3b/0xa0<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> As &amp;#39;ext4_rename&amp;#39; will modify &amp;#39;old.inode&amp;#39; ctime and mark inode dirty,<br /> which may trigger expand &amp;#39;extra_isize&amp;#39; and allocate block. If inode<br /> didn&amp;#39;t init quota will lead to warning. To solve above issue, init<br /> &amp;#39;old.inode&amp;#39; firstly in &amp;#39;ext4_rename&amp;#39;.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: rtsx_usb_sdmmc: fix return value check of mmc_add_host()<br /> <br /> mmc_add_host() may return error, if we ignore its return value, the memory<br /> that allocated in mmc_alloc_host() will be leaked and it will lead a kernel<br /> crash because of deleting not added device in the remove path.<br /> <br /> So fix this by checking the return value and calling mmc_free_host() in the<br /> error path, besides, led_classdev_unregister() and pm_runtime_disable() also<br /> need be called.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: Fix a memory leak in an error handling path<br /> <br /> If this memdup_user() call fails, the memory allocated in a previous call<br /> a few lines above should be freed. Otherwise it leaks.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: tifm: fix possible memory leak in tifm_7xx1_switch_media()<br /> <br /> If device_register() returns error in tifm_7xx1_switch_media(),<br /> name of kobject which is allocated in dev_set_name() called in device_add()<br /> is leaked.<br /> <br /> Never directly free @dev after calling device_register(), even<br /> if it returned an error! Always use put_device() to give up the<br /> reference initialized.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: iscsi: Fix a race condition between login_work and the login thread<br /> <br /> In case a malicious initiator sends some random data immediately after a<br /> login PDU; the iscsi_target_sk_data_ready() callback will schedule the<br /> login_work and, at the same time, the negotiation may end without clearing<br /> the LOGIN_FLAGS_INITIAL_PDU flag (because no additional PDU exchanges are<br /> required to complete the login).<br /> <br /> The login has been completed but the login_work function will find the<br /> LOGIN_FLAGS_INITIAL_PDU flag set and will never stop from rescheduling<br /> itself; at this point, if the initiator drops the connection, the<br /> iscsit_conn structure will be freed, login_work will dereference a released<br /> socket structure and the kernel crashes.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000230<br /> PF: supervisor write access in kernel mode<br /> PF: error_code(0x0002) - not-present page<br /> Workqueue: events iscsi_target_do_login_rx [iscsi_target_mod]<br /> RIP: 0010:_raw_read_lock_bh+0x15/0x30<br /> Call trace:<br /> iscsi_target_do_login_rx+0x75/0x3f0 [iscsi_target_mod]<br /> process_one_work+0x1e8/0x3c0<br /> <br /> Fix this bug by forcing login_work to stop after the login has been<br /> completed and the socket callbacks have been restored.<br /> <br /> Add a comment to clearify the return values of iscsi_target_do_login()

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix xid leak in cifs_create()<br /> <br /> If the cifs already shutdown, we should free the xid before return,<br /> otherwise, the xid will be leaked.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: vimc: Fix wrong function called when vimc_init() fails<br /> <br /> In vimc_init(), when platform_driver_register(&amp;vimc_pdrv) fails,<br /> platform_driver_unregister(&amp;vimc_pdrv) is wrongly called rather than<br /> platform_device_unregister(&amp;vimc_pdev), which causes kernel warning:<br /> <br /> Unexpected driver unregister!<br /> WARNING: CPU: 1 PID: 14517 at drivers/base/driver.c:270 driver_unregister+0x8f/0xb0<br /> RIP: 0010:driver_unregister+0x8f/0xb0<br /> Call Trace:<br /> <br /> vimc_init+0x7d/0x1000 [vimc]<br /> do_one_initcall+0xd0/0x4e0<br /> do_init_module+0x1cf/0x6b0<br /> load_module+0x65c2/0x7820