Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> driver core: fix potential null-ptr-deref in device_add()<br /> <br /> I got the following null-ptr-deref report while doing fault injection test:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000058<br /> CPU: 2 PID: 278 Comm: 37-i2c-ds2482 Tainted: G B W N 6.1.0-rc3+<br /> RIP: 0010:klist_put+0x2d/0xd0<br /> Call Trace:<br /> <br /> klist_remove+0xf1/0x1c0<br /> device_release_driver_internal+0x196/0x210<br /> bus_remove_device+0x1bd/0x240<br /> device_add+0xd3d/0x1100<br /> w1_add_master_device+0x476/0x490 [wire]<br /> ds2482_probe+0x303/0x3e0 [ds2482]<br /> <br /> This is how it happened:<br /> <br /> w1_alloc_dev()<br /> // The dev-&gt;driver is set to w1_master_driver.<br /> memcpy(&amp;dev-&gt;dev, device, sizeof(struct device));<br /> device_add()<br /> bus_add_device()<br /> dpm_sysfs_add() // It fails, calls bus_remove_device.<br /> <br /> // error path<br /> bus_remove_device()<br /> // The dev-&gt;driver is not null, but driver is not bound.<br /> __device_release_driver()<br /> klist_remove(&amp;dev-&gt;p-&gt;knode_driver) driver is set, in the error path after calling bus_add_device()<br /> in device_add(), bus_remove_device() is called, then the device will be<br /> detached from driver. But device_bind_driver() is not called yet, so it<br /> causes null-ptr-deref while access the &amp;#39;knode_driver&amp;#39;. To fix this, set<br /> dev-&gt;driver to null in the error path before calling bus_remove_device().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: set __exception_irq_entry with __irq_entry as a default<br /> <br /> filter_irq_stacks() is supposed to cut entries which are related irq entries<br /> from its call stack.<br /> And in_irqentry_text() which is called by filter_irq_stacks()<br /> uses __irqentry_text_start/end symbol to find irq entries in callstack.<br /> <br /> But it doesn&amp;#39;t work correctly as without "CONFIG_FUNCTION_GRAPH_TRACER",<br /> arm64 kernel doesn&amp;#39;t include gic_handle_irq which is entry point of arm64 irq<br /> between __irqentry_text_start and __irqentry_text_end as we discussed in below link.<br /> https://lore.kernel.org/all/CACT4Y+aReMGLYua2rCLHgFpS9io5cZC04Q8GLs-uNmrn1ezxYQ@mail.gmail.com/#t<br /> <br /> This problem can makes unintentional deep call stack entries especially<br /> in KASAN enabled situation as below.<br /> <br /> [ 2479.383395]I[0:launcher-loader: 1719] Stack depot reached limit capacity<br /> [ 2479.383538]I[0:launcher-loader: 1719] WARNING: CPU: 0 PID: 1719 at lib/stackdepot.c:129 __stack_depot_save+0x464/0x46c<br /> [ 2479.385693]I[0:launcher-loader: 1719] pstate: 624000c5 (nZCv daIF +PAN -UAO +TCO -DIT -SSBS BTYPE=--)<br /> [ 2479.385724]I[0:launcher-loader: 1719] pc : __stack_depot_save+0x464/0x46c<br /> [ 2479.385751]I[0:launcher-loader: 1719] lr : __stack_depot_save+0x460/0x46c<br /> [ 2479.385774]I[0:launcher-loader: 1719] sp : ffffffc0080073c0<br /> [ 2479.385793]I[0:launcher-loader: 1719] x29: ffffffc0080073e0 x28: ffffffd00b78a000 x27: 0000000000000000<br /> [ 2479.385839]I[0:launcher-loader: 1719] x26: 000000000004d1dd x25: ffffff891474f000 x24: 00000000ca64d1dd<br /> [ 2479.385882]I[0:launcher-loader: 1719] x23: 0000000000000200 x22: 0000000000000220 x21: 0000000000000040<br /> [ 2479.385925]I[0:launcher-loader: 1719] x20: ffffffc008007440 x19: 0000000000000000 x18: 0000000000000000<br /> [ 2479.385969]I[0:launcher-loader: 1719] x17: 2065726568207475 x16: 000000000000005e x15: 2d2d2d2d2d2d2d20<br /> [ 2479.386013]I[0:launcher-loader: 1719] x14: 5d39313731203a72 x13: 00000000002f6b30 x12: 00000000002f6af8<br /> [ 2479.386057]I[0:launcher-loader: 1719] x11: 00000000ffffffff x10: ffffffb90aacf000 x9 : e8a74a6c16008800<br /> [ 2479.386101]I[0:launcher-loader: 1719] x8 : e8a74a6c16008800 x7 : 00000000002f6b30 x6 : 00000000002f6af8<br /> [ 2479.386145]I[0:launcher-loader: 1719] x5 : ffffffc0080070c8 x4 : ffffffd00b192380 x3 : ffffffd0092b313c<br /> [ 2479.386189]I[0:launcher-loader: 1719] x2 : 0000000000000001 x1 : 0000000000000004 x0 : 0000000000000022<br /> [ 2479.386231]I[0:launcher-loader: 1719] Call trace:<br /> [ 2479.386248]I[0:launcher-loader: 1719] __stack_depot_save+0x464/0x46c<br /> [ 2479.386273]I[0:launcher-loader: 1719] kasan_save_stack+0x58/0x70<br /> [ 2479.386303]I[0:launcher-loader: 1719] save_stack_info+0x34/0x138<br /> [ 2479.386331]I[0:launcher-loader: 1719] kasan_save_free_info+0x18/0x24<br /> [ 2479.386358]I[0:launcher-loader: 1719] ____kasan_slab_free+0x16c/0x170<br /> [ 2479.386385]I[0:launcher-loader: 1719] __kasan_slab_free+0x10/0x20<br /> [ 2479.386410]I[0:launcher-loader: 1719] kmem_cache_free+0x238/0x53c<br /> [ 2479.386435]I[0:launcher-loader: 1719] mempool_free_slab+0x1c/0x28<br /> [ 2479.386460]I[0:launcher-loader: 1719] mempool_free+0x7c/0x1a0<br /> [ 2479.386484]I[0:launcher-loader: 1719] bvec_free+0x34/0x80<br /> [ 2479.386514]I[0:launcher-loader: 1719] bio_free+0x60/0x98<br /> [ 2479.386540]I[0:launcher-loader: 1719] bio_put+0x50/0x21c<br /> [ 2479.386567]I[0:launcher-loader: 1719] f2fs_write_end_io+0x4ac/0x4d0<br /> [ 2479.386594]I[0:launcher-loader: 1719] bio_endio+0x2dc/0x300<br /> [ 2479.386622]I[0:launcher-loader: 1719] __dm_io_complete+0x324/0x37c<br /> [ 2479.386650]I[0:launcher-loader: 1719] dm_io_dec_pending+0x60/0xa4<br /> [ 2479.386676]I[0:launcher-loader: 1719] clone_endio+0xf8/0x2f0<br /> [ 2479.386700]I[0:launcher-loader: 1719] bio_endio+0x2dc/0x300<br /> [ 2479.386727]I[0:launcher-loader: 1719] blk_update_request+0x258/0x63c<br /> [ 2479.386754]I[0:launcher-loader: 1719] scsi_end_request+0x50/0x304<br /> [ 2479.386782]I[0:launcher-loader: 1719] scsi_io_completion+0x88/0x160<br /> [ 2479.386808]I[0:launcher-loader: 1719] scsi_finish_command+0x17c/0x194<br /> [ 2479.386833]I<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl/pmem: Fix nvdimm registration races<br /> <br /> A loop of the form:<br /> <br /> while true; do modprobe cxl_pci; modprobe -r cxl_pci; done<br /> <br /> ...fails with the following crash signature:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000040<br /> [..]<br /> RIP: 0010:cxl_internal_send_cmd+0x5/0xb0 [cxl_core]<br /> [..]<br /> Call Trace:<br /> <br /> cxl_pmem_ctl+0x121/0x240 [cxl_pmem]<br /> nvdimm_get_config_data+0xd6/0x1a0 [libnvdimm]<br /> nd_label_data_init+0x135/0x7e0 [libnvdimm]<br /> nvdimm_probe+0xd6/0x1c0 [libnvdimm]<br /> nvdimm_bus_probe+0x7a/0x1e0 [libnvdimm]<br /> really_probe+0xde/0x380<br /> __driver_probe_device+0x78/0x170<br /> driver_probe_device+0x1f/0x90<br /> __device_attach_driver+0x85/0x110<br /> bus_for_each_drv+0x7d/0xc0<br /> __device_attach+0xb4/0x1e0<br /> bus_probe_device+0x9f/0xc0<br /> device_add+0x445/0x9c0<br /> nd_async_device_register+0xe/0x40 [libnvdimm]<br /> async_run_entry_fn+0x30/0x130<br /> <br /> ...namely that the bottom half of async nvdimm device registration runs<br /> after the CXL has already torn down the context that cxl_pmem_ctl()<br /> needs. Unlike the ACPI NFIT case that benefits from launching multiple<br /> nvdimm device registrations in parallel from those listed in the table,<br /> CXL is already marked PROBE_PREFER_ASYNCHRONOUS. So provide for a<br /> synchronous registration path to preclude this scenario.

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