Vulnerabilities

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bcachefs: Fix sb_field_downgrade validation<br /> <br /> - bch2_sb_downgrade_validate() wasn&amp;#39;t checking for a downgrade entry<br /> extending past the end of the superblock section<br /> <br /> - for_each_downgrade_entry() is used in to_text() and needs to work on<br /> malformed input; it also was missing a check for a field extending<br /> past the end of the section

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 /> 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 /> 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 /> 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 /> cachefiles: Set object to close if ondemand_id