Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ata: libata-core: Fix double free on error<br /> <br /> If e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jump<br /> to the err_out label, which will call devres_release_group().<br /> devres_release_group() will trigger a call to ata_host_release().<br /> ata_host_release() calls kfree(host), so executing the kfree(host) in<br /> ata_host_alloc() will lead to a double free:<br /> <br /> kernel BUG at mm/slub.c:553!<br /> Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014<br /> RIP: 0010:kfree+0x2cf/0x2f0<br /> Code: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da<br /> RSP: 0018:ffffc90000f377f0 EFLAGS: 00010246<br /> RAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320<br /> RDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0<br /> RBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000<br /> R10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780<br /> R13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006<br /> FS: 00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __die_body.cold+0x19/0x27<br /> ? die+0x2e/0x50<br /> ? do_trap+0xca/0x110<br /> ? do_error_trap+0x6a/0x90<br /> ? kfree+0x2cf/0x2f0<br /> ? exc_invalid_op+0x50/0x70<br /> ? kfree+0x2cf/0x2f0<br /> ? asm_exc_invalid_op+0x1a/0x20<br /> ? ata_host_alloc+0xf5/0x120 [libata]<br /> ? ata_host_alloc+0xf5/0x120 [libata]<br /> ? kfree+0x2cf/0x2f0<br /> ata_host_alloc+0xf5/0x120 [libata]<br /> ata_host_alloc_pinfo+0x14/0xa0 [libata]<br /> ahci_init_one+0x6c9/0xd20 [ahci]<br /> <br /> Ensure that we will not call kfree(host) twice, by performing the kfree()<br /> only if the devres_open_group() call failed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: mcp251xfd: fix infinite loop when xmit fails<br /> <br /> When the mcp251xfd_start_xmit() function fails, the driver stops<br /> processing messages, and the interrupt routine does not return,<br /> running indefinitely even after killing the running application.<br /> <br /> Error messages:<br /> [ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16<br /> [ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3).<br /> ... and repeat forever.<br /> <br /> The issue can be triggered when multiple devices share the same SPI<br /> interface. And there is concurrent access to the bus.<br /> <br /> The problem occurs because tx_ring-&gt;head increments even if<br /> mcp251xfd_start_xmit() fails. Consequently, the driver skips one TX<br /> package while still expecting a response in<br /> mcp251xfd_handle_tefif_one().<br /> <br /> Resolve the issue by starting a workqueue to write the tx obj<br /> synchronously if err = -EBUSY. In case of another error, decrement<br /> tx_ring-&gt;head, remove skb from the echo stack, and drop the message.<br /> <br /> [mkl: use more imperative wording in patch description]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes<br /> <br /> In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is<br /> assigned to mode, which will lead to a possible NULL pointer dereference<br /> on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode().<br /> Add a check to avoid null pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/gt: Fix potential UAF by revoke of fence registers<br /> <br /> CI has been sporadically reporting the following issue triggered by<br /> igt@i915_selftest@live@hangcheck on ADL-P and similar machines:<br /> <br /> [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence<br /> ...<br /> [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled<br /> [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled<br /> [414.070354] Unable to pin Y-tiled fence; err:-4<br /> [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&amp;fence-&gt;active))<br /> ...<br /> [ 609.603992] ------------[ cut here ]------------<br /> [ 609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301!<br /> [ 609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G U W 6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1<br /> [ 609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023<br /> [ 609.604010] Workqueue: i915 __i915_gem_free_work [i915]<br /> [ 609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915]<br /> ...<br /> [ 609.604271] Call Trace:<br /> [ 609.604273] <br /> ...<br /> [ 609.604716] __i915_vma_evict+0x2e9/0x550 [i915]<br /> [ 609.604852] __i915_vma_unbind+0x7c/0x160 [i915]<br /> [ 609.604977] force_unbind+0x24/0xa0 [i915]<br /> [ 609.605098] i915_vma_destroy+0x2f/0xa0 [i915]<br /> [ 609.605210] __i915_gem_object_pages_fini+0x51/0x2f0 [i915]<br /> [ 609.605330] __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915]<br /> [ 609.605440] process_scheduled_works+0x351/0x690<br /> ...<br /> <br /> In the past, there were similar failures reported by CI from other IGT<br /> tests, observed on other platforms.<br /> <br /> Before commit 63baf4f3d587 ("drm/i915/gt: Only wait for GPU activity<br /> before unbinding a GGTT fence"), i915_vma_revoke_fence() was waiting for<br /> idleness of vma-&gt;active via fence_update(). That commit introduced<br /> vma-&gt;fence-&gt;active in order for the fence_update() to be able to wait<br /> selectively on that one instead of vma-&gt;active since only idleness of<br /> fence registers was needed. But then, another commit 0d86ee35097a<br /> ("drm/i915/gt: Make fence revocation unequivocal") replaced the call to<br /> fence_update() in i915_vma_revoke_fence() with only fence_write(), and<br /> also added that GEM_BUG_ON(!i915_active_is_idle(&amp;fence-&gt;active)) in front.<br /> No justification was provided on why we might then expect idleness of<br /> vma-&gt;fence-&gt;active without first waiting on it.<br /> <br /> The issue can be potentially caused by a race among revocation of fence<br /> registers on one side and sequential execution of signal callbacks invoked<br /> on completion of a request that was using them on the other, still<br /> processed in parallel to revocation of those fence registers. Fix it by<br /> waiting for idleness of vma-&gt;fence-&gt;active in i915_vma_revoke_fence().<br /> <br /> (cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: avoid using null object of framebuffer<br /> <br /> Instead of using state-&gt;fb-&gt;obj[0] directly, get object from framebuffer<br /> by calling drm_gem_fb_get_obj() and return error code when object is<br /> null to avoid using null object of framebuffer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes<br /> <br /> In nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is<br /> assigned to mode, which will lead to a possible NULL pointer dereference<br /> on failure of drm_mode_duplicate(). Add a check to avoid npd.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI/MSI: Fix UAF in msi_capability_init<br /> <br /> KFENCE reports the following UAF:<br /> <br /> BUG: KFENCE: use-after-free read in __pci_enable_msi_range+0x2c0/0x488<br /> <br /> Use-after-free read at 0x0000000024629571 (in kfence-#12):<br /> __pci_enable_msi_range+0x2c0/0x488<br /> pci_alloc_irq_vectors_affinity+0xec/0x14c<br /> pci_alloc_irq_vectors+0x18/0x28<br /> <br /> kfence-#12: 0x0000000008614900-0x00000000e06c228d, size=104, cache=kmalloc-128<br /> <br /> allocated by task 81 on cpu 7 at 10.808142s:<br /> __kmem_cache_alloc_node+0x1f0/0x2bc<br /> kmalloc_trace+0x44/0x138<br /> msi_alloc_desc+0x3c/0x9c<br /> msi_domain_insert_msi_desc+0x30/0x78<br /> msi_setup_msi_desc+0x13c/0x184<br /> __pci_enable_msi_range+0x258/0x488<br /> pci_alloc_irq_vectors_affinity+0xec/0x14c<br /> pci_alloc_irq_vectors+0x18/0x28<br /> <br /> freed by task 81 on cpu 7 at 10.811436s:<br /> msi_domain_free_descs+0xd4/0x10c<br /> msi_domain_free_locked.part.0+0xc0/0x1d8<br /> msi_domain_alloc_irqs_all_locked+0xb4/0xbc<br /> pci_msi_setup_msi_irqs+0x30/0x4c<br /> __pci_enable_msi_range+0x2a8/0x488<br /> pci_alloc_irq_vectors_affinity+0xec/0x14c<br /> pci_alloc_irq_vectors+0x18/0x28<br /> <br /> Descriptor allocation done in:<br /> __pci_enable_msi_range<br /> msi_capability_init<br /> msi_setup_msi_desc<br /> msi_insert_msi_desc<br /> msi_domain_insert_msi_desc<br /> msi_alloc_desc<br /> ...<br /> <br /> Freed in case of failure in __msi_domain_alloc_locked()<br /> __pci_enable_msi_range<br /> msi_capability_init<br /> pci_msi_setup_msi_irqs<br /> msi_domain_alloc_irqs_all_locked<br /> msi_domain_alloc_locked<br /> __msi_domain_alloc_locked =&gt; fails<br /> msi_domain_free_locked<br /> ...<br /> <br /> That failure propagates back to pci_msi_setup_msi_irqs() in<br /> msi_capability_init() which accesses the descriptor for unmasking in the<br /> error exit path.<br /> <br /> Cure it by copying the descriptor and using the copy for the error exit path<br /> unmask operation.<br /> <br /> [ tglx: Massaged change log ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: atm: cxacru: fix endpoint checking in cxacru_bind()<br /> <br /> Syzbot is still reporting quite an old issue [1] that occurs due to<br /> incomplete checking of present usb endpoints. As such, wrong<br /> endpoints types may be used at urb sumbitting stage which in turn<br /> triggers a warning in usb_submit_urb().<br /> <br /> Fix the issue by verifying that required endpoint types are present<br /> for both in and out endpoints, taking into account cmd endpoint type.<br /> <br /> Unfortunately, this patch has not been tested on real hardware.<br /> <br /> [1] Syzbot report:<br /> usb 1-1: BOGUS urb xfer, pipe 1 != type 3<br /> WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502<br /> Modules linked in:<br /> CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> Workqueue: usb_hub_wq hub_event<br /> RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502<br /> ...<br /> Call Trace:<br /> cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649<br /> cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760<br /> cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209<br /> usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055<br /> cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363<br /> usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396<br /> call_driver_probe drivers/base/dd.c:517 [inline]<br /> really_probe+0x23c/0xcd0 drivers/base/dd.c:595<br /> __driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747<br /> driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777<br /> __device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894<br /> bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427<br /> __device_attach+0x228/0x4a0 drivers/base/dd.c:965<br /> bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487<br /> device_add+0xc2f/0x2180 drivers/base/core.c:3354<br /> usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170<br /> usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238<br /> usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ata: libata-core: Fix null pointer dereference on error<br /> <br /> If the ata_port_alloc() call in ata_host_alloc() fails,<br /> ata_host_release() will get called.<br /> <br /> However, the code in ata_host_release() tries to free ata_port struct<br /> members unconditionally, which can lead to the following:<br /> <br /> BUG: unable to handle page fault for address: 0000000000003990<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 10 PID: 594 Comm: (udev-worker) Not tainted 6.10.0-rc5 #44<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014<br /> RIP: 0010:ata_host_release.cold+0x2f/0x6e [libata]<br /> Code: e4 4d 63 f4 44 89 e2 48 c7 c6 90 ad 32 c0 48 c7 c7 d0 70 33 c0 49 83 c6 0e 41<br /> RSP: 0018:ffffc90000ebb968 EFLAGS: 00010246<br /> RAX: 0000000000000041 RBX: ffff88810fb52e78 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: ffff88813b3218c0 RDI: ffff88813b3218c0<br /> RBP: ffff88810fb52e40 R08: 0000000000000000 R09: 6c65725f74736f68<br /> R10: ffffc90000ebb738 R11: 73692033203a746e R12: 0000000000000004<br /> R13: 0000000000000000 R14: 0000000000000011 R15: 0000000000000006<br /> FS: 00007f6cc55b9980(0000) GS:ffff88813b300000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000003990 CR3: 00000001122a2000 CR4: 0000000000750ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __die_body.cold+0x19/0x27<br /> ? page_fault_oops+0x15a/0x2f0<br /> ? exc_page_fault+0x7e/0x180<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? ata_host_release.cold+0x2f/0x6e [libata]<br /> ? ata_host_release.cold+0x2f/0x6e [libata]<br /> release_nodes+0x35/0xb0<br /> devres_release_group+0x113/0x140<br /> ata_host_alloc+0xed/0x120 [libata]<br /> ata_host_alloc_pinfo+0x14/0xa0 [libata]<br /> ahci_init_one+0x6c9/0xd20 [ahci]<br /> <br /> Do not access ata_port struct members unconditionally.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix netfs_page_mkwrite() to check folio-&gt;mapping is valid<br /> <br /> Fix netfs_page_mkwrite() to check that folio-&gt;mapping is valid once it has<br /> taken the folio lock (as filemap_page_mkwrite() does). Without this,<br /> generic/247 occasionally oopses with something like the following:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> <br /> RIP: 0010:trace_event_raw_event_netfs_folio+0x61/0xc0<br /> ...<br /> Call Trace:<br /> <br /> ? __die_body+0x1a/0x60<br /> ? page_fault_oops+0x6e/0xa0<br /> ? exc_page_fault+0xc2/0xe0<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? trace_event_raw_event_netfs_folio+0x61/0xc0<br /> trace_netfs_folio+0x39/0x40<br /> netfs_page_mkwrite+0x14c/0x1d0<br /> do_page_mkwrite+0x50/0x90<br /> do_pte_missing+0x184/0x200<br /> __handle_mm_fault+0x42d/0x500<br /> handle_mm_fault+0x121/0x1f0<br /> do_user_addr_fault+0x23e/0x3c0<br /> exc_page_fault+0xc2/0xe0<br /> asm_exc_page_fault+0x22/0x30<br /> <br /> This is due to the invalidate_inode_pages2_range() issued at the end of the<br /> DIO write interfering with the mmap&amp;#39;d writes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl/region: Avoid null pointer dereference in region lookup<br /> <br /> cxl_dpa_to_region() looks up a region based on a memdev and DPA.<br /> It wrongly assumes an endpoint found mapping the DPA is also of<br /> a fully assembled region. When not true it leads to a null pointer<br /> dereference looking up the region name.<br /> <br /> This appears during testing of region lookup after a failure to<br /> assemble a BIOS defined region or if the lookup raced with the<br /> assembly of the BIOS defined region.<br /> <br /> Failure to clean up BIOS defined regions that fail assembly is an<br /> issue in itself and a fix to that problem will alleviate some of<br /> the impact. It will not alleviate the race condition so let&amp;#39;s harden<br /> this path.<br /> <br /> The behavior change is that the kernel oops due to a null pointer<br /> dereference is replaced with a dev_dbg() message noting that an<br /> endpoint was mapped.<br /> <br /> Additional comments are added so that future users of this function<br /> can more clearly understand what it provides.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl/mem: Fix no cxl_nvd during pmem region auto-assembling<br /> <br /> When CXL subsystem is auto-assembling a pmem region during cxl<br /> endpoint port probing, always hit below calltrace.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000078<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> RIP: 0010:cxl_pmem_region_probe+0x22e/0x360 [cxl_pmem]<br /> Call Trace:<br /> <br /> ? __die+0x24/0x70<br /> ? page_fault_oops+0x82/0x160<br /> ? do_user_addr_fault+0x65/0x6b0<br /> ? exc_page_fault+0x7d/0x170<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? cxl_pmem_region_probe+0x22e/0x360 [cxl_pmem]<br /> ? cxl_pmem_region_probe+0x1ac/0x360 [cxl_pmem]<br /> cxl_bus_probe+0x1b/0x60 [cxl_core]<br /> really_probe+0x173/0x410<br /> ? __pfx___device_attach_driver+0x10/0x10<br /> __driver_probe_device+0x80/0x170<br /> driver_probe_device+0x1e/0x90<br /> __device_attach_driver+0x90/0x120<br /> bus_for_each_drv+0x84/0xe0<br /> __device_attach+0xbc/0x1f0<br /> bus_probe_device+0x90/0xa0<br /> device_add+0x51c/0x710<br /> devm_cxl_add_pmem_region+0x1b5/0x380 [cxl_core]<br /> cxl_bus_probe+0x1b/0x60 [cxl_core]<br /> <br /> The cxl_nvd of the memdev needs to be available during the pmem region<br /> probe. Currently the cxl_nvd is registered after the endpoint port probe.<br /> The endpoint probe, in the case of autoassembly of regions, can cause a<br /> pmem region probe requiring the not yet available cxl_nvd. Adjust the<br /> sequence so this dependency is met.<br /> <br /> This requires adding a port parameter to cxl_find_nvdimm_bridge() that<br /> can be used to query the ancestor root port. The endpoint port is not<br /> yet available, but will share a common ancestor with its parent, so<br /> start the query from there instead.