Vulnerabilities

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]

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.

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: Protect against send buffer overflow in NFSv3 READ<br /> <br /> Since before the git era, NFSD has conserved the number of pages<br /> held by each nfsd thread by combining the RPC receive and send<br /> buffers into a single array of pages. This works because there are<br /> no cases where an operation needs a large RPC Call message and a<br /> large RPC Reply at the same time.<br /> <br /> Once an RPC Call has been received, svc_process() updates<br /> svc_rqst::rq_res to describe the part of rq_pages that can be<br /> used for constructing the Reply. This means that the send buffer<br /> (rq_res) shrinks when the received RPC record containing the RPC<br /> Call is large.<br /> <br /> A client can force this shrinkage on TCP by sending a correctly-<br /> formed RPC Call header contained in an RPC record that is<br /> excessively large. The full maximum payload size cannot be<br /> constructed in that case.

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

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.

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.

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.

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()

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.

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

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.