Vulnerabilidades

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

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: fix oops during encryption<br /> <br /> When running xfstests against Azure the following oops occurred on an<br /> arm64 system<br /> <br /> Unable to handle kernel write to read-only memory at virtual address<br /> ffff0001221cf000<br /> Mem abort info:<br /> ESR = 0x9600004f<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x0f: level 3 permission fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x0000004f<br /> CM = 0, WnR = 1<br /> swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000294f3000<br /> [ffff0001221cf000] pgd=18000001ffff8003, p4d=18000001ffff8003,<br /> pud=18000001ff82e003, pmd=18000001ff71d003, pte=00600001221cf787<br /> Internal error: Oops: 9600004f [#1] PREEMPT SMP<br /> ...<br /> pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--)<br /> pc : __memcpy+0x40/0x230<br /> lr : scatterwalk_copychunks+0xe0/0x200<br /> sp : ffff800014e92de0<br /> x29: ffff800014e92de0 x28: ffff000114f9de80 x27: 0000000000000008<br /> x26: 0000000000000008 x25: ffff800014e92e78 x24: 0000000000000008<br /> x23: 0000000000000001 x22: 0000040000000000 x21: ffff000000000000<br /> x20: 0000000000000001 x19: ffff0001037c4488 x18: 0000000000000014<br /> x17: 235e1c0d6efa9661 x16: a435f9576b6edd6c x15: 0000000000000058<br /> x14: 0000000000000001 x13: 0000000000000008 x12: ffff000114f2e590<br /> x11: ffffffffffffffff x10: 0000040000000000 x9 : ffff8000105c3580<br /> x8 : 2e9413b10000001a x7 : 534b4410fb86b005 x6 : 534b4410fb86b005<br /> x5 : ffff0001221cf008 x4 : ffff0001037c4490 x3 : 0000000000000001<br /> x2 : 0000000000000008 x1 : ffff0001037c4488 x0 : ffff0001221cf000<br /> Call trace:<br /> __memcpy+0x40/0x230<br /> scatterwalk_map_and_copy+0x98/0x100<br /> crypto_ccm_encrypt+0x150/0x180<br /> crypto_aead_encrypt+0x2c/0x40<br /> crypt_message+0x750/0x880<br /> smb3_init_transform_rq+0x298/0x340<br /> smb_send_rqst.part.11+0xd8/0x180<br /> smb_send_rqst+0x3c/0x100<br /> compound_send_recv+0x534/0xbc0<br /> smb2_query_info_compound+0x32c/0x440<br /> smb2_set_ea+0x438/0x4c0<br /> cifs_xattr_set+0x5d4/0x7c0<br /> <br /> This is because in scatterwalk_copychunks(), we attempted to write to<br /> a buffer (@sign) that was allocated in the stack (vmalloc area) by<br /> crypt_message() and thus accessing its remaining 8 (x2) bytes ended up<br /> crossing a page boundary.<br /> <br /> To simply fix it, we could just pass @sign kmalloc&amp;#39;d from<br /> crypt_message() and then we&amp;#39;re done. Luckily, we don&amp;#39;t seem to pass<br /> any other vmalloc&amp;#39;d buffers in smb_rqst::rq_iov...<br /> <br /> Instead, let&amp;#39;s map the correct pages and offsets from vmalloc buffers<br /> as well in cifs_sg_set_buf() and then avoiding such oopses.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> floppy: Fix memory leak in do_floppy_init()<br /> <br /> A memory leak was reported when floppy_alloc_disk() failed in<br /> do_floppy_init().<br /> <br /> unreferenced object 0xffff888115ed25a0 (size 8):<br /> comm "modprobe", pid 727, jiffies 4295051278 (age 25.529s)<br /> hex dump (first 8 bytes):<br /> 00 ac 67 5b 81 88 ff ff ..g[....<br /> backtrace:<br /> [] __kmalloc_node+0x4c/0xc0<br /> [] blk_mq_realloc_tag_set_tags.part.0+0x6f/0x180<br /> [] blk_mq_alloc_tag_set+0x573/0x1130<br /> [] 0xffffffffc06b8b08<br /> [] do_one_initcall+0xd0/0x4f0<br /> [] do_init_module+0x1a4/0x680<br /> [] load_module+0x6249/0x7110<br /> [] __do_sys_finit_module+0x140/0x200<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> unreferenced object 0xffff88810fc30540 (size 32):<br /> comm "modprobe", pid 727, jiffies 4295051278 (age 25.529s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] __kmalloc_node+0x4c/0xc0<br /> [] blk_mq_alloc_tag_set+0x393/0x1130<br /> [] 0xffffffffc06b8b08<br /> [] do_one_initcall+0xd0/0x4f0<br /> [] do_init_module+0x1a4/0x680<br /> [] load_module+0x6249/0x7110<br /> [] __do_sys_finit_module+0x140/0x200<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> If the floppy_alloc_disk() failed, disks of current drive will not be set,<br /> thus the lastest allocated set-&gt;tag cannot be freed in the error handling<br /> path. A simple call graph shown as below:<br /> <br /> floppy_module_init()<br /> floppy_init()<br /> do_floppy_init()<br /> for (drive = 0; drive tag allocated<br /> floppy_alloc_disk()<br /> blk_mq_alloc_disk() # error occurred, disks failed to allocated<br /> <br /> -&gt;out_put_disk:<br /> for (drive = 0; drive tag leaked<br /> <br /> Fix this problem by free the set-&gt;tag of current drive before jump to<br /> error handling path.<br /> <br /> [efremov: added stable list, changed title]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rapidio: fix possible name leaks when rio_add_device() fails<br /> <br /> Patch series "rapidio: fix three possible memory leaks".<br /> <br /> This patchset fixes three name leaks in error handling.<br /> - patch #1 fixes two name leaks while rio_add_device() fails.<br /> - patch #2 fixes a name leak while rio_register_mport() fails.<br /> <br /> <br /> This patch (of 2):<br /> <br /> If rio_add_device() returns error, the name allocated by dev_set_name()<br /> need be freed. It should use put_device() to give up the reference in the<br /> error path, so that the name can be freed in kobject_cleanup(), and the<br /> &amp;#39;rdev&amp;#39; can be freed in rio_release_dev().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: avoid hci_dev_test_and_set_flag() in mgmt_init_hdev()<br /> <br /> syzbot is again reporting attempt to cancel uninitialized work<br /> at mgmt_index_removed() [1], for setting of HCI_MGMT flag from<br /> mgmt_init_hdev() from hci_mgmt_cmd() from hci_sock_sendmsg() can<br /> race with testing of HCI_MGMT flag from mgmt_index_removed() from<br /> hci_sock_bind() due to lack of serialization via hci_dev_lock().<br /> <br /> Since mgmt_init_hdev() is called with mgmt_chan_list_lock held, we can<br /> safely split hci_dev_test_and_set_flag() into hci_dev_test_flag() and<br /> hci_dev_set_flag(). Thus, in order to close this race, set HCI_MGMT flag<br /> after INIT_DELAYED_WORK() completed.<br /> <br /> This is a local fix based on mgmt_chan_list_lock. Lack of serialization<br /> via hci_dev_lock() might be causing different race conditions somewhere<br /> else. But a global fix based on hci_dev_lock() should deserve a future<br /> patch.