Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: add bounds checking in get_max_inline_xattr_value_size()<br /> <br /> Normally the extended attributes in the inode body would have been<br /> checked when the inode is first opened, but if someone is writing to<br /> the block device while the file system is mounted, it&amp;#39;s possible for<br /> the inode table to get corrupted. Add bounds checking to avoid<br /> reading beyond the end of allocated memory if this happens.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Return the firmware result upon destroying QP/RQ<br /> <br /> Previously when destroying a QP/RQ, the result of the firmware<br /> destruction function was ignored and upper layers weren&amp;#39;t informed<br /> about the failure.<br /> Which in turn could lead to various problems since when upper layer<br /> isn&amp;#39;t aware of the failure it continues its operation thinking that the<br /> related QP/RQ was successfully destroyed while it actually wasn&amp;#39;t,<br /> which could lead to the below kernel WARN.<br /> <br /> Currently, we return the correct firmware destruction status to upper<br /> layers which in case of the RQ would be mlx5_ib_destroy_wq() which<br /> was already capable of handling RQ destruction failure or in case of<br /> a QP to destroy_qp_common(), which now would actually warn upon qp<br /> destruction failure.<br /> <br /> WARNING: CPU: 3 PID: 995 at drivers/infiniband/core/rdma_core.c:940 uverbs_destroy_ufile_hw+0xcb/0xe0 [ib_uverbs]<br /> Modules linked in: xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_umad ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core overlay mlx5_core fuse<br /> CPU: 3 PID: 995 Comm: python3 Not tainted 5.16.0-rc5+ #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:uverbs_destroy_ufile_hw+0xcb/0xe0 [ib_uverbs]<br /> Code: 41 5c 41 5d 41 5e e9 44 34 f0 e0 48 89 df e8 4c 77 ff ff 49 8b 86 10 01 00 00 48 85 c0 74 a1 4c 89 e7 ff d0 eb 9a 0f 0b eb c1 0b be 04 00 00 00 48 89 df e8 b6 f6 ff ff e9 75 ff ff ff 90 0f<br /> RSP: 0018:ffff8881533e3e78 EFLAGS: 00010287<br /> RAX: ffff88811b2cf3e0 RBX: ffff888106209700 RCX: 0000000000000000<br /> RDX: ffff888106209780 RSI: ffff8881533e3d30 RDI: ffff888109b101a0<br /> RBP: 0000000000000001 R08: ffff888127cb381c R09: 0de9890000000009<br /> R10: ffff888127cb3800 R11: 0000000000000000 R12: ffff888106209780<br /> R13: ffff888106209750 R14: ffff888100f20660 R15: 0000000000000000<br /> FS: 00007f8be353b740(0000) GS:ffff88852c980000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f8bd5b117c0 CR3: 000000012cd8a004 CR4: 0000000000370ea0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ib_uverbs_close+0x1a/0x90 [ib_uverbs]<br /> __fput+0x82/0x230<br /> task_work_run+0x59/0x90<br /> exit_to_user_mode_prepare+0x138/0x140<br /> syscall_exit_to_user_mode+0x1d/0x50<br /> ? __x64_sys_close+0xe/0x40<br /> do_syscall_64+0x4a/0x90<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7f8be3ae0abb<br /> Code: 03 00 00 00 0f 05 48 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 83 43 f9 ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 3d 00 f0 ff ff 77 35 44 89 c7 89 44 24 0c e8 c1 43 f9 ff 8b 44<br /> RSP: 002b:00007ffdb51909c0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003<br /> RAX: 0000000000000000 RBX: 0000557bb7f7c020 RCX: 00007f8be3ae0abb<br /> RDX: 0000557bb7c74010 RSI: 0000557bb7f14ca0 RDI: 0000000000000005<br /> RBP: 0000557bb7fbd598 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000293 R12: 0000557bb7fbd5b8<br /> R13: 0000557bb7fbd5a8 R14: 0000000000001000 R15: 0000557bb7f7c020<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: cdns3: Put the cdns set active part outside the spin lock<br /> <br /> The device may be scheduled during the resume process,<br /> so this cannot appear in atomic operations. Since<br /> pm_runtime_set_active will resume suppliers, put set<br /> active outside the spin lock, which is only used to<br /> protect the struct cdns data structure, otherwise the<br /> kernel will report the following warning:<br /> <br /> BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1163<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 651, name: sh<br /> preempt_count: 1, expected: 0<br /> RCU nest depth: 0, expected: 0<br /> CPU: 0 PID: 651 Comm: sh Tainted: G WC 6.1.20 #1<br /> Hardware name: Freescale i.MX8QM MEK (DT)<br /> Call trace:<br /> dump_backtrace.part.0+0xe0/0xf0<br /> show_stack+0x18/0x30<br /> dump_stack_lvl+0x64/0x80<br /> dump_stack+0x1c/0x38<br /> __might_resched+0x1fc/0x240<br /> __might_sleep+0x68/0xc0<br /> __pm_runtime_resume+0x9c/0xe0<br /> rpm_get_suppliers+0x68/0x1b0<br /> __pm_runtime_set_status+0x298/0x560<br /> cdns_resume+0xb0/0x1c0<br /> cdns3_controller_resume.isra.0+0x1e0/0x250<br /> cdns3_plat_resume+0x28/0x40

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/client: Fix memory leak in drm_client_modeset_probe<br /> <br /> When a new mode is set to modeset-&gt;mode, the previous mode should be freed.<br /> This fixes the following kmemleak report:<br /> <br /> drm_mode_duplicate+0x45/0x220 [drm]<br /> drm_client_modeset_probe+0x944/0xf50 [drm]<br /> __drm_fb_helper_initial_config_and_unlock+0xb4/0x2c0 [drm_kms_helper]<br /> drm_fbdev_client_hotplug+0x2bc/0x4d0 [drm_kms_helper]<br /> drm_client_register+0x169/0x240 [drm]<br /> ast_pci_probe+0x142/0x190 [ast]<br /> local_pci_probe+0xdc/0x180<br /> work_for_cpu_fn+0x4e/0xa0<br /> process_one_work+0x8b7/0x1540<br /> worker_thread+0x70a/0xed0<br /> kthread+0x29f/0x340<br /> ret_from_fork+0x1f/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ena: fix shift-out-of-bounds in exponential backoff<br /> <br /> The ENA adapters on our instances occasionally reset. Once recently<br /> logged a UBSAN failure to console in the process:<br /> <br /> UBSAN: shift-out-of-bounds in build/linux/drivers/net/ethernet/amazon/ena/ena_com.c:540:13<br /> shift exponent 32 is too large for 32-bit type &amp;#39;unsigned int&amp;#39;<br /> CPU: 28 PID: 70012 Comm: kworker/u72:2 Kdump: loaded not tainted 5.15.117<br /> Hardware name: Amazon EC2 c5d.9xlarge/, BIOS 1.0 10/16/2017<br /> Workqueue: ena ena_fw_reset_device [ena]<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x4a/0x63<br /> dump_stack+0x10/0x16<br /> ubsan_epilogue+0x9/0x36<br /> __ubsan_handle_shift_out_of_bounds.cold+0x61/0x10e<br /> ? __const_udelay+0x43/0x50<br /> ena_delay_exponential_backoff_us.cold+0x16/0x1e [ena]<br /> wait_for_reset_state+0x54/0xa0 [ena]<br /> ena_com_dev_reset+0xc8/0x110 [ena]<br /> ena_down+0x3fe/0x480 [ena]<br /> ena_destroy_device+0xeb/0xf0 [ena]<br /> ena_fw_reset_device+0x30/0x50 [ena]<br /> process_one_work+0x22b/0x3d0<br /> worker_thread+0x4d/0x3f0<br /> ? process_one_work+0x3d0/0x3d0<br /> kthread+0x12a/0x150<br /> ? set_kthread_struct+0x50/0x50<br /> ret_from_fork+0x22/0x30<br /> <br /> <br /> Apparently, the reset delays are getting so large they can trigger a<br /> UBSAN panic.<br /> <br /> Looking at the code, the current timeout is capped at 5000us. Using a<br /> base value of 100us, the current code will overflow after (1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Drivers: vmbus: Check for channel allocation before looking up relids<br /> <br /> relid2channel() assumes vmbus channel array to be allocated when called.<br /> However, in cases such as kdump/kexec, not all relids will be reset by the host.<br /> When the second kernel boots and if the guest receives a vmbus interrupt during<br /> vmbus driver initialization before vmbus_connect() is called, before it finishes,<br /> or if it fails, the vmbus interrupt service routine is called which in turn calls<br /> relid2channel() and can cause a null pointer dereference.<br /> <br /> Print a warning and error out in relid2channel() for a channel id that&amp;#39;s invalid<br /> in the second kernel.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: mediatek: mt8183: Add back SSPM related clocks<br /> <br /> This reverts commit 860690a93ef23b567f781c1b631623e27190f101.<br /> <br /> On the MT8183, the SSPM related clocks were removed claiming a lack of<br /> usage. This however causes some issues when the driver was converted to<br /> the new simple-probe mechanism. This mechanism allocates enough space<br /> for all the clocks defined in the clock driver, not the highest index<br /> in the DT binding. This leads to out-of-bound writes if their are holes<br /> in the DT binding or the driver (due to deprecated or unimplemented<br /> clocks). These errors can go unnoticed and cause memory corruption,<br /> leading to crashes in unrelated areas, or nothing at all. KASAN will<br /> detect them.<br /> <br /> Add the SSPM related clocks back to the MT8183 clock driver to fully<br /> implement the DT binding. The SSPM clocks are for the power management<br /> co-processor, and should never be turned off. They are marked as such.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: hda: fix a possible null-pointer dereference due to data race in snd_hdac_regmap_sync()<br /> <br /> The variable codec-&gt;regmap is often protected by the lock<br /> codec-&gt;regmap_lock when is accessed. However, it is accessed without<br /> holding the lock when is accessed in snd_hdac_regmap_sync():<br /> <br /> if (codec-&gt;regmap)<br /> <br /> In my opinion, this may be a harmful race, because if codec-&gt;regmap is<br /> set to NULL right after the condition is checked, a null-pointer<br /> dereference can occur in the called function regcache_sync():<br /> <br /> map-&gt;lock(map-&gt;lock_arg); --&gt; Line 360 in drivers/base/regmap/regcache.c<br /> <br /> To fix this possible null-pointer dereference caused by data race, the<br /> mutex_lock coverage is extended to protect the if statement as well as the<br /> function call to regcache_sync().<br /> <br /> [ Note: the lack of the regmap_lock itself is harmless for the current<br /> codec driver implementations, as snd_hdac_regmap_sync() is only for<br /> PM runtime resume that is prohibited during the codec probe.<br /> But the change makes the whole code more consistent, so it&amp;#39;s merged<br /> as is -- tiwai ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubifs: Free memory for tmpfile name<br /> <br /> When opening a ubifs tmpfile on an encrypted directory, function<br /> fscrypt_setup_filename allocates memory for the name that is to be<br /> stored in the directory entry, but after the name has been copied to the<br /> directory entry inode, the memory is not freed.<br /> <br /> When running kmemleak on it we see that it is registered as a leak. The<br /> report below is triggered by a simple program &amp;#39;tmpfile&amp;#39; just opening a<br /> tmpfile:<br /> <br /> unreferenced object 0xffff88810178f380 (size 32):<br /> comm "tmpfile", pid 509, jiffies 4294934744 (age 1524.742s)<br /> backtrace:<br /> __kmem_cache_alloc_node<br /> __kmalloc<br /> fscrypt_setup_filename<br /> ubifs_tmpfile<br /> vfs_tmpfile<br /> path_openat<br /> <br /> Free this memory after it has been copied to the inode.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwl3945: Add missing check for create_singlethread_workqueue<br /> <br /> Add the check for the return value of the create_singlethread_workqueue<br /> in order to avoid NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubifs: Fix memory leak in ubifs_sysfs_init()<br /> <br /> When insmod ubifs.ko, a kmemleak reported as below:<br /> <br /> unreferenced object 0xffff88817fb1a780 (size 8):<br /> comm "insmod", pid 25265, jiffies 4295239702 (age 100.130s)<br /> hex dump (first 8 bytes):<br /> 75 62 69 66 73 00 ff ff ubifs...<br /> backtrace:<br /> [] slab_post_alloc_hook+0x9c/0x3c0<br /> [] __kmalloc_track_caller+0x183/0x410<br /> [] kstrdup+0x3a/0x80<br /> [] kstrdup_const+0x66/0x80<br /> [] kvasprintf_const+0x155/0x190<br /> [] kobject_set_name_vargs+0x5b/0x150<br /> [] kobject_set_name+0xbb/0xf0<br /> [] do_one_initcall+0x14c/0x5a0<br /> [] do_init_module+0x1f0/0x660<br /> [] load_module+0x6d7e/0x7590<br /> [] __do_sys_finit_module+0x19f/0x230<br /> [] __x64_sys_finit_module+0x73/0xb0<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> When kset_register() failed, we should call kset_put to cleanup it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: vmw_balloon: fix memory leak with using debugfs_lookup()<br /> <br /> When calling debugfs_lookup() the result must have dput() called on it,<br /> otherwise the memory will leak over time. To make things simpler, just<br /> call debugfs_lookup_and_remove() instead which handles all of the logic at<br /> once.