Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: use smc_lgr_list.lock to protect smc_lgr_list.list iterate in smcr_port_add<br /> <br /> While doing smcr_port_add, there maybe linkgroup add into or delete<br /> from smc_lgr_list.list at the same time, which may result kernel crash.<br /> So, use smc_lgr_list.lock to protect smc_lgr_list.list iterate in<br /> smcr_port_add.<br /> <br /> The crash calltrace show below:<br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] SMP NOPTI<br /> CPU: 0 PID: 559726 Comm: kworker/0:92 Kdump: loaded Tainted: G<br /> Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 449e491 04/01/2014<br /> Workqueue: events smc_ib_port_event_work [smc]<br /> RIP: 0010:smcr_port_add+0xa6/0xf0 [smc]<br /> RSP: 0000:ffffa5a2c8f67de0 EFLAGS: 00010297<br /> RAX: 0000000000000001 RBX: ffff9935e0650000 RCX: 0000000000000000<br /> RDX: 0000000000000010 RSI: ffff9935e0654290 RDI: ffff9935c8560000<br /> RBP: 0000000000000000 R08: 0000000000000000 R09: ffff9934c0401918<br /> R10: 0000000000000000 R11: ffffffffb4a5c278 R12: ffff99364029aae4<br /> R13: ffff99364029aa00 R14: 00000000ffffffed R15: ffff99364029ab08<br /> FS: 0000000000000000(0000) GS:ffff994380600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 0000000f06a10003 CR4: 0000000002770ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> smc_ib_port_event_work+0x18f/0x380 [smc]<br /> process_one_work+0x19b/0x340<br /> worker_thread+0x30/0x370<br /> ? process_one_work+0x340/0x340<br /> kthread+0x114/0x130<br /> ? __kthread_cancel_work+0x50/0x50<br /> ret_from_fork+0x1f/0x30

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: at91-pio4: check return value of devm_kasprintf()<br /> <br /> devm_kasprintf() returns a pointer to dynamically allocated memory.<br /> Pointer could be NULL in case allocation fails. Check pointer validity.<br /> Identified with coccinelle (kmerr.cocci script).<br /> <br /> Depends-on: 1c4e5c470a56 ("pinctrl: at91: use devm_kasprintf() to avoid potential leaks")<br /> Depends-on: 5a8f9cf269e8 ("pinctrl: at91-pio4: use proper format specifier for unsigned int")

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86/amd: pmc: Fix memory leak in amd_pmc_stb_debugfs_open_v2()<br /> <br /> Function amd_pmc_stb_debugfs_open_v2() may be called when the STB<br /> debug mechanism enabled.<br /> <br /> When amd_pmc_send_cmd() fails, the &amp;#39;buf&amp;#39; needs to be released.

*** Pendiente de traducción *** 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().

*** Pendiente de traducción *** 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---

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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]

*** Pendiente de traducción *** 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