Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm: fix a race condition in retrieve_deps<br /> <br /> There&amp;#39;s a race condition in the multipath target when retrieve_deps<br /> races with multipath_message calling dm_get_device and dm_put_device.<br /> retrieve_deps walks the list of open devices without holding any lock<br /> but multipath may add or remove devices to the list while it is<br /> running. The end result may be memory corruption or use-after-free<br /> memory access.<br /> <br /> See this description of a UAF with multipath_message():<br /> https://listman.redhat.com/archives/dm-devel/2022-October/052373.html<br /> <br /> Fix this bug by introducing a new rw semaphore "devices_lock". We grab<br /> devices_lock for read in retrieve_deps and we grab it for write in<br /> dm_get_device and dm_put_device.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: qat - fix out-of-bounds read<br /> <br /> When preparing an AER-CTR request, the driver copies the key provided by<br /> the user into a data structure that is accessible by the firmware.<br /> If the target device is QAT GEN4, the key size is rounded up by 16 since<br /> a rounded up size is expected by the device.<br /> If the key size is rounded up before the copy, the size used for copying<br /> the key might be bigger than the size of the region containing the key,<br /> causing an out-of-bounds read.<br /> <br /> Fix by doing the copy first and then update the keylen.<br /> <br /> This is to fix the following warning reported by KASAN:<br /> <br /> [ 138.150574] BUG: KASAN: global-out-of-bounds in qat_alg_skcipher_init_com.isra.0+0x197/0x250 [intel_qat]<br /> [ 138.150641] Read of size 32 at addr ffffffff88c402c0 by task cryptomgr_test/2340<br /> <br /> [ 138.150651] CPU: 15 PID: 2340 Comm: cryptomgr_test Not tainted 6.2.0-rc1+ #45<br /> [ 138.150659] Hardware name: Intel Corporation ArcherCity/ArcherCity, BIOS EGSDCRB1.86B.0087.D13.2208261706 08/26/2022<br /> [ 138.150663] Call Trace:<br /> [ 138.150668] <br /> [ 138.150922] kasan_check_range+0x13a/0x1c0<br /> [ 138.150931] memcpy+0x1f/0x60<br /> [ 138.150940] qat_alg_skcipher_init_com.isra.0+0x197/0x250 [intel_qat]<br /> [ 138.151006] qat_alg_skcipher_init_sessions+0xc1/0x240 [intel_qat]<br /> [ 138.151073] crypto_skcipher_setkey+0x82/0x160<br /> [ 138.151085] ? prepare_keybuf+0xa2/0xd0<br /> [ 138.151095] test_skcipher_vec_cfg+0x2b8/0x800

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: pci_endpoint_test: Free IRQs before removing the device<br /> <br /> In pci_endpoint_test_remove(), freeing the IRQs after removing the device<br /> creates a small race window for IRQs to be received with the test device<br /> memory already released, causing the IRQ handler to access invalid memory,<br /> resulting in an oops.<br /> <br /> Free the device IRQs before removing the device to avoid this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tpm: tpm_vtpm_proxy: fix a race condition in /dev/vtpmx creation<br /> <br /> /dev/vtpmx is made visible before &amp;#39;workqueue&amp;#39; is initialized, which can<br /> lead to a memory corruption in the worst case scenario.<br /> <br /> Address this by initializing &amp;#39;workqueue&amp;#39; as the very first step of the<br /> driver initialization.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: message: mptlan: Fix use after free bug in mptlan_remove() due to race condition<br /> <br /> mptlan_probe() calls mpt_register_lan_device() which initializes the<br /> &amp;priv-&gt;post_buckets_task workqueue. A call to<br /> mpt_lan_wake_post_buckets_task() will subsequently start the work.<br /> <br /> During driver unload in mptlan_remove() the following race may occur:<br /> <br /> CPU0 CPU1<br /> <br /> |mpt_lan_post_receive_buckets_work()<br /> mptlan_remove() |<br /> free_netdev() |<br /> kfree(dev); |<br /> |<br /> | dev-&gt;mtu<br /> | //use<br /> <br /> Fix this by finishing the work prior to cleaning up in mptlan_remove().<br /> <br /> [mkp: we really should remove mptlan instead of attempting to fix it]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix deadlock when converting an inline directory in nojournal mode<br /> <br /> In no journal mode, ext4_finish_convert_inline_dir() can self-deadlock<br /> by calling ext4_handle_dirty_dirblock() when it already has taken the<br /> directory lock. There is a similar self-deadlock in<br /> ext4_incvert_inline_data_nolock() for data files which we&amp;#39;ll fix at<br /> the same time.<br /> <br /> A simple reproducer demonstrating the problem:<br /> <br /> mke2fs -Fq -t ext2 -O inline_data -b 4k /dev/vdc 64<br /> mount -t ext4 -o dirsync /dev/vdc /vdc<br /> cd /vdc<br /> mkdir file0<br /> cd file0<br /> touch file0<br /> touch file1<br /> attr -s BurnSpaceInEA -V abcde .<br /> touch supercalifragilisticexpialidocious

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> samples/bpf: Fix buffer overflow in tcp_basertt<br /> <br /> Using sizeof(nv) or strlen(nv)+1 is correct.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovl: fix null pointer dereference in ovl_get_acl_rcu()<br /> <br /> Following process:<br /> P1 P2<br /> path_openat<br /> link_path_walk<br /> may_lookup<br /> inode_permission(rcu)<br /> ovl_permission<br /> acl_permission_check<br /> check_acl<br /> get_cached_acl_rcu<br /> ovl_get_inode_acl<br /> realinode = ovl_inode_real(ovl_inode)<br /> drop_cache<br /> __dentry_kill(ovl_dentry)<br /> iput(ovl_inode)<br /> ovl_destroy_inode(ovl_inode)<br /> dput(oi-&gt;__upperdentry)<br /> dentry_kill(upperdentry)<br /> dentry_unlink_inode<br /> upperdentry-&gt;d_inode = NULL<br /> ovl_inode_upper<br /> upperdentry = ovl_i_dentry_upper(ovl_inode)<br /> d_inode(upperdentry) // returns NULL<br /> IS_POSIXACL(realinode) // NULL pointer dereference<br /> , will trigger an null pointer dereference at realinode:<br /> [ 205.472797] BUG: kernel NULL pointer dereference, address:<br /> 0000000000000028<br /> [ 205.476701] CPU: 2 PID: 2713 Comm: ls Not tainted<br /> 6.3.0-12064-g2edfa098e750-dirty #1216<br /> [ 205.478754] RIP: 0010:do_ovl_get_acl+0x5d/0x300<br /> [ 205.489584] Call Trace:<br /> [ 205.489812] <br /> [ 205.490014] ovl_get_inode_acl+0x26/0x30<br /> [ 205.490466] get_cached_acl_rcu+0x61/0xa0<br /> [ 205.490908] generic_permission+0x1bf/0x4e0<br /> [ 205.491447] ovl_permission+0x79/0x1b0<br /> [ 205.491917] inode_permission+0x15e/0x2c0<br /> [ 205.492425] link_path_walk+0x115/0x550<br /> [ 205.493311] path_lookupat.isra.0+0xb2/0x200<br /> [ 205.493803] filename_lookup+0xda/0x240<br /> [ 205.495747] vfs_fstatat+0x7b/0xb0<br /> <br /> Fetch a reproducer in [Link].<br /> <br /> Use the helper ovl_i_path_realinode() to get realinode and then do<br /> non-nullptr checking.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: af9005: Fix null-ptr-deref in af9005_i2c_xfer<br /> <br /> In af9005_i2c_xfer, msg is controlled by user. When msg[i].buf<br /> is null and msg[i].len is zero, former checks on msg[i].buf would be<br /> passed. Malicious data finally reach af9005_i2c_xfer. If accessing<br /> msg[i].buf[0] without sanity check, null ptr deref would happen.<br /> We add check on msg[i].len to prevent crash.<br /> <br /> Similar commit:<br /> commit 0ed554fd769a<br /> ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/powernv/sriov: perform null check on iov before dereferencing iov<br /> <br /> Currently pointer iov is being dereferenced before the null check of iov<br /> which can lead to null pointer dereference errors. Fix this by moving the<br /> iov null check before the dereferencing.<br /> <br /> Detected using cppcheck static analysis:<br /> linux/arch/powerpc/platforms/powernv/pci-sriov.c:597:12: warning: Either<br /> the condition &amp;#39;!iov&amp;#39; is redundant or there is possible null pointer<br /> dereference: iov. [nullPointerRedundantCheck]<br /> num_vfs = iov-&gt;num_vfs;<br /> ^

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> refscale: Fix uninitalized use of wait_queue_head_t<br /> <br /> Running the refscale test occasionally crashes the kernel with the<br /> following error:<br /> <br /> [ 8569.952896] BUG: unable to handle page fault for address: ffffffffffffffe8<br /> [ 8569.952900] #PF: supervisor read access in kernel mode<br /> [ 8569.952902] #PF: error_code(0x0000) - not-present page<br /> [ 8569.952904] PGD c4b048067 P4D c4b049067 PUD c4b04b067 PMD 0<br /> [ 8569.952910] Oops: 0000 [#1] PREEMPT_RT SMP NOPTI<br /> [ 8569.952916] Hardware name: Dell Inc. PowerEdge R750/0WMWCR, BIOS 1.2.4 05/28/2021<br /> [ 8569.952917] RIP: 0010:prepare_to_wait_event+0x101/0x190<br /> :<br /> [ 8569.952940] Call Trace:<br /> [ 8569.952941] <br /> [ 8569.952944] ref_scale_reader+0x380/0x4a0 [refscale]<br /> [ 8569.952959] kthread+0x10e/0x130<br /> [ 8569.952966] ret_from_fork+0x1f/0x30<br /> [ 8569.952973] <br /> <br /> The likely cause is that init_waitqueue_head() is called after the call to<br /> the torture_create_kthread() function that creates the ref_scale_reader<br /> kthread. Although this init_waitqueue_head() call will very likely<br /> complete before this kthread is created and starts running, it is<br /> possible that the calling kthread will be delayed between the calls to<br /> torture_create_kthread() and init_waitqueue_head(). In this case, the<br /> new kthread will use the waitqueue head before it is properly initialized,<br /> which is not good for the kernel&amp;#39;s health and well-being.<br /> <br /> The above crash happened here:<br /> <br /> static inline void __add_wait_queue(...)<br /> {<br /> :<br /> if (!(wq-&gt;flags &amp; WQ_FLAG_PRIORITY))

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm flakey: don&amp;#39;t corrupt the zero page<br /> <br /> When we need to zero some range on a block device, the function<br /> __blkdev_issue_zero_pages submits a write bio with the bio vector pointing<br /> to the zero page. If we use dm-flakey with corrupt bio writes option, it<br /> will corrupt the content of the zero page which results in crashes of<br /> various userspace programs. Glibc assumes that memory returned by mmap is<br /> zeroed and it uses it for calloc implementation; if the newly mapped<br /> memory is not zeroed, calloc will return non-zeroed memory.<br /> <br /> Fix this bug by testing if the page is equal to ZERO_PAGE(0) and<br /> avoiding the corruption in this case.