Vulnerabilities

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 /> 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 ]

Incorrect access control in Himalaya Xiaoya nano smart speaker rom_version 1.6.96 allows a remote attacker to have an unspecified impact.

Buffer Overflow vulnerability in host-host NEUQ_board v.1.0 allows a remote attacker to cause a denial of service via the password.h component.

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: can: j1939: enhanced error handling for tightly received RTS messages in xtp_rx_rts_session_new<br /> <br /> This patch enhances error handling in scenarios with RTS (Request to<br /> Send) messages arriving closely. It replaces the less informative WARN_ON_ONCE<br /> backtraces with a new error handling method. This provides clearer error<br /> messages and allows for the early termination of problematic sessions.<br /> Previously, sessions were only released at the end of j1939_xtp_rx_rts().<br /> <br /> Potentially this could be reproduced with something like:<br /> testj1939 -r vcan0:0x80 &amp;<br /> while true; do<br /> # send first RTS<br /> cansend vcan0 18EC8090#1014000303002301;<br /> # send second RTS<br /> cansend vcan0 18EC8090#1014000303002301;<br /> # send abort<br /> cansend vcan0 18EC8090#ff00000000002301;<br /> done

Magento-lts is a long-term support alternative to Magento Community Edition (CE). This XSS vulnerability affects the design/header/welcome, design/header/logo_src, design/header/logo_src_small, and design/header/logo_alt system configs.They are intended to enable admins to set a text in the two cases, and to define an image url for the other two cases.<br /> But because of previously missing escaping allowed to input arbitrary html and as a consequence also arbitrary JavaScript. The problem is patched with Version 20.10.1 or higher.

tgstation-server is a production scale tool for BYOND server management. Prior to 6.8.0, low permission users using the "Set .dme Path" privilege could potentially set malicious .dme files existing on the host machine to be compiled and executed. These .dme files could be uploaded via tgstation-server (requiring a separate, isolated privilege) or some other means. A server configured to execute in BYOND&amp;#39;s trusted security level (requiring a third separate, isolated privilege OR being set by another user) could lead to this escalating into remote code execution via BYOND&amp;#39;s shell() proc. The ability to execute this kind of attack is a known side effect of having privileged TGS users, but normally requires multiple privileges with known weaknesses. This vector is not intentional as it does not require control over the where deployment code is sourced from and _may_ not require remote write access to an instance&amp;#39;s `Configuration` directory. This problem is fixed in versions 6.8.0 and above.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-fabrics: use reserved tag for reg read/write command<br /> <br /> In some scenarios, if too many commands are issued by nvme command in<br /> the same time by user tasks, this may exhaust all tags of admin_q. If<br /> a reset (nvme reset or IO timeout) occurs before these commands finish,<br /> reconnect routine may fail to update nvme regs due to insufficient tags,<br /> which will cause kernel hang forever. In order to workaround this issue,<br /> maybe we can let reg_read32()/reg_read64()/reg_write32() use reserved<br /> tags. This maybe safe for nvmf:<br /> <br /> 1. For the disable ctrl path, we will not issue connect command<br /> 2. For the enable ctrl / fw activate path, since connect and reg_xx()<br /> are called serially.<br /> <br /> So the reserved tags may still be enough while reg_xx() use reserved tags.