drm/msm: RCU-free the scheduler-containing ring and VM objects

In the Linux kernel, the following vulnerability has been resolved: drm/msm: RCU-free the scheduler-containing ring and VM objects Both struct msm_ringbuffer and struct msm_gem_vm embed a struct drm_gpu_scheduler. msm_ringbuffer_destroy() and the VM free callback msm_gem_vm_free() call drm_sched_fini() on the embedded scheduler and then free the containing object with plain kfree(). drm_sched_fence_get_timeline_name() returns fence->sched->name, and the scheduler fence keeps a .release callback so it is not ops-detached on signalling. A finished fence exported to userspace (the submit out-fence, or a VM_BIND fence, via sync_file / drm_syncobj) keeps pointing at the embedded scheduler after the ring/VM is freed, so a later get_timeline_name() -- reachable unprivileged through SYNC_IOC_FILE_INFO -- dereferences freed slab memory (KASAN slab-use-after-free read). Per the dma-fence lifetime contract the exporter must keep the data backing a signalled fence alive for an RCU grace period. Free the scheduler-containing objects with kfree_rcu() instead of kfree(). Patchwork: https://patchwork.freedesktop.org/patch/750234/

Expired pointer dereference in the MigTD's virtio-vsock implementation for the Intel(R) TDX Migration Trust Domain (MigTD) within Ring 0: Hypervisor may allow an escalation of privilege and information disclosure. System software adversary with a privileged user combined with a low complexity attack may enable escalation of privilege. This result may potentially occur via local access when attack requirements are not present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (high), integrity (high) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts.

Use of out-of-range pointer offset in the MigTD's virtio-vsock implementation for the Intel(R) TDX Migration Trust Domain (MigTD) within Ring 0: Hypervisor may allow an escalation of privilege. System software adversary with a privileged user combined with a low complexity attack may enable escalation of privilege. This result may potentially occur via local access when attack requirements are not present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (high), integrity (high) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts.

Untrusted pointer dereference in the FirmwareWakingVector for the Intel(R) Slim Bootloader within Ring 0: Bare Metal OS may allow an escalation of privilege. System software adversary with a privileged user combined with a low complexity attack may enable escalation of privilege. This result may potentially occur via local access when attack requirements are not present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (high), integrity (high) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts.

Untrusted pointer dereference for some Hyperscan before version v5.4.2.1 within Ring 3: User Applications may allow a denial of service. Unprivileged software adversary with an unauthenticated user combined with a low complexity attack may enable denial of service. This result may potentially occur via local access when attack requirements are present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (none), integrity (low) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts.

ksmbd: hold a connection reference for each session channel

In the Linux kernel, the following vulnerability has been resolved: ksmbd: hold a connection reference for each session channel ksmbd_session_unregister() removes a session from the global and per- connection tables before dropping the table reference. A concurrent reference holder can keep the session and its channel list alive after those removals. Connection cleanup can no longer find the unpublished session to remove its channels. Since a channel only stores a raw conn pointer, the connection can be freed while another session reference holder is still accessing it, for example during SMB3.1.1 binding or a procfs read. Take a connection reference when registering a channel and release it on insertion failure, channel removal, or final session destruction. Keep the channels and signing keys until the session is destroyed so a response can still be signed after the session has been unregistered.

Use-after-free in the Audio/Video component

Use-after-free in the Audio/Video component. This vulnerability was fixed in Firefox ESR 115.45.

ACPI: NFIT: core: Fix acpi_nfit_init() error cleanup

In the Linux kernel, the following vulnerability has been resolved: ACPI: NFIT: core: Fix acpi_nfit_init() error cleanup If acpi_nfit_init() fails after adding the acpi_desc object to the acpi_descs list, that object is never removed from that list because the acpi_nfit_shutdown() devm action is not added for the NFIT device in that case. Next, the acpi_nfit_init() failure causes acpi_nfit_probe() to fail, the acpi_desc object is freed, and a dangling pointer is left behind in the acpi_descs. Any subsequent ACPI Machine Check Exception will trigger nfit_handle_mce() which iterates over acpi_descs and so a use-after-free will occur. Moreover, if acpi_nfit_probe() returns 0 after installing a notify handler for the NFIT device and without allocating the acpi_desc object and setting the NFIT device's driver data pointer, the acpi_desc object will be allocated by acpi_nfit_update_notify() and acpi_nfit_init() will be called to initialize it. Regardless of whether or not acpi_nfit_init() fails in that case, the acpi_nfit_shutdown() devm action is not added for the NFIT device and acpi_desc is never removed from the acpi_descs list. If the acpi_desc object is freed subsequently on driver removal, any subsequent ACPI MCE will lead to a use-after-free like in the previous case. To address the first issue mentioned above, make acpi_nfit_probe() call acpi_nfit_shutdown() directly on acpi_nfit_init() failures and to address the other one, add a remove callback to the driver and make it call acpi_nfit_shutdown(). Also, since it is now possible to pass NULL to acpi_nfit_shutdown() or the acpi_desc object passed to it may not have been initialized, add checks against NULL for acpi_desc and its nvdimm_bus field to that function and make acpi_nfit_unregister() clear the latter after unregistering the NVDIMM bus.

libexpat: libexpat: Memory corruption vulnerability allows arbitrary code execution or denial of service

libexpat before 2.8.4 lacks handler call depth tracking with custom encoding callbacks. Thus, a use-after-free can occur. NOTE: this is similar to CVE-2026-50219, CVE-2026-56131 and CVE-2026-56412.

libssh2 - Free of Uninitialized Pointer in publickey List Cleanup

libssh2 through 1.11.1 grows its publickey list with SSH2_REALLOC but does not zero-initialize new entries before parsing populates them, so a parse failure reaching the cleanup path leaves libssh2_publickey_list_free operating on an uninitialized entry. A malicious SSH server offering the publickey subsystem can use a malformed response to make cleanup free an uninitialized, attacker-influenceable attrs pointer in a connecting libssh2 client.

libexpat: libexpat: Use-after-free vulnerability due to improper handling of XML CDATA sections

libexpat before 2.8.2 does not consider XML_TOK_DATA_CHARS in doCdataSection and thus lacks handler call depth tracking for various calls from within handlers in cases of a policy violation. Thus, a use-after-free can occur. NOTE: this issue exists because of an incomplete fix for CVE-2026-50219.

expat: libexpat: Arbitrary Code Execution via Heap-based Buffer Overflow

In libexpat before 2.8.2, there is a heap-based buffer overflow in doProlog in xmlparse.c because scaffold backing array reallocation is mishandled when there is data-structure sharing across parsers.

i2c: core: fix adapter registration race

In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix adapter registration race Adapters can be looked up based on their id using i2c_get_adapter() which takes a reference to the embedded struct device. Make sure that the adapter (including its struct device) has been initialised before adding it to the IDR to avoid accessing uninitialised data which could, for example, lead to NULL-pointer dereferences or use-after-free. Note that the i2c-dev chardev, which is registered from a bus notifier, currently uses i2c_get_adapter() so the adapter needs to be added to the IDR before registration.

Sssd: use-after-free crash in sssd' 'sssd_pam' process

A flaw was found in sssd. When authenticating with a YubiKey, the SSSD PAM responder can crash due to a use-after-free vulnerability, where a memory pointer is incorrectly handled. A local attacker could exploit this flaw by manipulating smartcard or YubiKey contents, leading to a denial of service that disrupts authentication. This vulnerability also presents a potential for privilege escalation, although it is difficult to exploit.

Altair: DOM-based XSS via attacker-controlled script URLs in the iframe sandbox

Altair is a GraphQL client for all platforms. From 7.2.4 until 8.5.8, packages/altair-iframe-sandbox/src/main.ts reads plugin_sandbox_opts from the iframe-sandbox query string and passes attacker-controlled scriptUrls to injectScript() in packages/altair-core/src/utils/inject.ts, which creates script elements in the page. The intended parent iframe flow places the page in an iframe with sandbox allow-scripts and without allow-same-origin, but direct navigation to a crafted iframe-sandbox URL omits that isolation and executes the supplied script in the origin serving Altair. Exploitation requires a victim to open the crafted URL, and the resulting script can access script-readable storage and make same-origin requests according to the deployment's authentication and cookie controls. This issue is fixed in version 8.5.8.

FreeRDP before 3.33.0 Use-After-Free via Stale Brush Cache Pointer

FreeRDP before 3.33.0 contains a heap use-after-free vulnerability in update_gdi_patblt(), update_gdi_polygon_cb() and update_gdi_mem3blt() that retain stale brush cache pointers. A malicious RDP server can resend CACHE_BRUSH to the same slot then send PATBLT, causing clients to read freed heap memory, disclosing data or crashing.

Xtensa MMU userspace: uninitialized thread page-table pointer leads to out-of-bounds supervisor-mode writes

The Xtensa MMU userspace port never initialized the per-thread page-table pointer thread->arch.ptables during thread setup, while arch_mem_domain_thread_add() in arch/xtensa/core/ptables.c uses a non-NULL value of that field as its "this thread is migrating from another memory domain" predicate. For a thread whose struct k_thread backing memory is not zeroed, the field holds stale data and the kernel takes the migration branch, passing that stale value to reset_region() as the base of a level-1 page table. The equivalent field on x86 is explicitly cleared in z_x86_userspace_prepare_thread() for exactly this reason; the Xtensa port adopted the predicate without the initialization. The condition is reachable from an unprivileged user-mode thread on a build with CONFIG_XTENSA_MMU, CONFIG_USERSPACE and dynamically allocated kernel objects. k_object_alloc(K_OBJ_THREAD) is a system call and allocates the thread object from the caller's resource pool without zeroing it, and the k_thread_create() verifier accepts such an object while forcing the K_USER option, so the migration branch is taken whenever the recycled heap bytes at that offset are non-zero. Because a user thread can also allocate, fill and free other kernel objects from the same heap, the stale bytes are groomable rather than merely random. Walking the bogus table in region_map_update() performs an unguarded index into l2_page_tables_counter[], may copy from and write through the attacker-influenceable level-1 base in dup_l2_table_if_needed(), and finally writes a page-table entry through a second pointer read out of that memory — once per page of the new thread's stack. The result is out-of-bounds reads and writes executed in supervisor mode, ranging from an immediate kernel panic (observed as Xtensa EXCAUSE 13 on Intel ADSP DSP firmware with user threads) to corruption of kernel memory and escape from the user-mode sandbox.

liboqs: Uninitialized function-pointer dereference in OQS_KEM_encaps_derand for NTRU KEMs

liboqs is a C-language cryptographic library that provides implementations of post-quantum cryptography algorithms. Prior to 0.16.0, OQS_KEM_encaps_derand can dereference an uninitialized encaps_derand function pointer when called on NTRU-HPS-2048-509, NTRU-HPS-2048-677, NTRU-HPS-4096-821, NTRU-HPS-4096-1229, NTRU-HRSS-701, or NTRU-HRSS-1373. The affected NTRU constructors omit the OQS_KEM.encaps_derand member because those schemes do not support derandomized encapsulation, OQS_KEM objects are allocated without zero initialization, and the wrapper in src/kem/kem.c checks only that the OQS_KEM pointer is non-null before calling through the residual heap value. An application is affected only if it instantiates one of those six NTRU KEMs and invokes OQS_KEM_encaps_derand on it. The supported impact is a calling-process crash and denial of service. This issue is fixed in version 0.16.0.

IRISPowerscan Insufficient restriction of untrusted scripts allows arbitrary code execution

IRISPowerscan insufficiently restrict the use of untrusted scripts. An authenticated user with access to script functionality can import or modify scripts that are executed by the application, potentially resulting in arbitrary code execution in the security context of the Windows user running IRISPowerscan.

Inverted memory-permission check in the RTIO syscall verifier allows a user-mode thread to read and write arbitrary kernel memory

The RTIO submission-queue verifier rtio_vrfy_sqe() in subsys/rtio/rtio_syscalls.c (subsys/rtio/rtio_handlers.c before v4.3.0) accumulated the results of K_SYSCALL_MEMORY() into its valid_sqe flag with &=. That macro returns nonzero on failure (it is built on K_SYSCALL_VERIFY_MSG(), which yields !(expr)), so every buffer permission check contributed the opposite of its result. A submission whose tx.buf, rx.buf or txrx.tx_buf/txrx.rx_buf pointer was not accessible to the calling thread was accepted, while a legitimate, thread-owned buffer caused the calling thread to be killed with a kernel oops. The verifier runs on behalf of the rtio_sqe_copy_in_get_handles() system call (also reached through the inline rtio_sqe_copy_in() wrapper), so it is driven directly by untrusted user-mode input on any image built with CONFIG_USERSPACE. A user thread that has been granted an RTIO context and an rtio_iodev object — the intended usage of RTIO userspace support, established via rtio_access_grant() — can submit an SQE whose buffer pointer and length name arbitrary kernel memory; the object check on sqe->iodev is unaffected and still passes, and the crafted SQE is forwarded to the bus driver unchanged. Downstream consumers dereference the pointer with supervisor privilege. The generic I2C and I3C RTIO fallback handlers (drivers/i2c/i2c_rtio_default.c, drivers/i3c/i3c_rtio_default.c) copy sqe.rx.buf/sqe.tx.buf into struct i2c_msg and call i2c_transfer(), and the vendor SPI/I2C RTIO drivers behave equivalently. An RTIO_OP_RX submission therefore has peripheral data written into kernel memory of the attacker's choosing (arbitrary kernel write), an RTIO_OP_TX submission clocks kernel memory out over the bus (kernel memory disclosure), and a pointer to unmapped memory faults the kernel. This is a full escape from the user-mode isolation boundary that CONFIG_USERSPACE exists to enforce. The defect was masked for years because the in-tree user-mode RTIO tests only exercise RTIO_OP_NOP and mempool-backed reads, neither of which reaches the affected checks. The fix negates each K_SYSCALL_MEMORY() result and additionally validates the TXRX transmit buffer read-only, matching the SPI, I2C and I3C handlers.