| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
x86/mm/pat: Allocate split page tables as kernel page tables
A PTE is allocated directly without going through the standard page table
allocation routines (such as pte_alloc_one_kernel()) when the CPA code
splits a large page (__split_large_page()).
This means the page table constructor is never called nor is the page table
marked as a kernel page table.
The former results in the folio associated with the page table not being
marked as a page table (__pagetable_ctor() is never called thus neither is
__folio_set_pgtable()) nor are statistics updated to reflect
it (lruvec_stat_add_folio() is never called).
The latter issue of failing to mark the page table as a kernel page
table (ptdesc_set_kernel() is never called) is far more problematic.
Since commit:
5ba2f0a15564 ("mm: introduce deferred freeing for kernel page tables")
kernel page table freeing has been batched and since the
subsequent commit:
e37d5a2d60a3 ("iommu/sva: invalidate stale IOTLB entries for kernel address space")
IOTLB cache entries for kernel page tables have been invalidated upon
being freed.
Since split page tables are freed without this invalidation, the IOTLB
can contain stale entries for them.
Resolve the issue by using the ordinary PTE allocation API at split time.
This results in these kernel page tables invoking a page table constructor,
and thus requires a page table destructor.
Destructors are not always present, like for early allocated direct map
page tables). Conditionally call pagetable_dtor_free() if the PG_table
folio flag for the ptdesc is set, otherwise we free the page table via
pagetable_free().
Regardless of which path is taken page tables marked as kernel page tables,
which now includes split page tables, take the correct route through
pagetable_free_kernel().
There is a user-visible side effect in that split page tables will appear
in nr_page_table_pages in /proc/vmstat (as do other kernel page tables
allocated after early boot), however this is a positive change.
This issue started being markedly problematic after commit:
5ba2f0a15564 ("mm: introduce deferred freeing for kernel page tables")
so choose this as the Fixes target.
[ dhansen: rephrase in imperative mood ] |
| A flaw was found in the interactive shell of the xmllint command-line tool, used for parsing XML files. When a user inputs an overly long command, the program does not check the input size properly, which can cause it to crash. This issue might allow attackers to run harmful code in rare configurations without modern protections. |
| A flaw was found in xdgmime. A heap-based buffer overflow can be triggered in _xdg_mime_magic_parse_magic_line() in the xdgmimemagic.c file on little-endian systems when an attacker-controlled MIME magic file in a user-writable XDG data location (e.g., in the $XDG_DATA_HOME/mime/magic path) is parsed by an application performing MIME type detection (e.g., via g_content_type_guess()). When performing byte-swap, incorrect pointer arithmetic on the write side causes an out-of-bounds write of 2 bytes, resulting in an application crash or memory corruption. |
| In the Linux kernel, the following vulnerability has been resolved:
pinctrl: mediatek: paris: bypass pinctrl GPIO layer in set GPIO direction
pinctrl_gpio_direction_input() / pinctrl_gpio_direction_output() take
the pinctrl mutex. This causes a gpiochip operations to need to sleep.
Worse yet, the .can_sleep field in the gpiochip is not set. This causes
the shared GPIO proxy to trip over, as it uses gpiod_cansleep() to check
whether it can use a spinlock or needs a mutex. In this case, it ends
up taking a spinlock, then calls pinctrl_gpio_direction_output(), which
takes a mutex. This causes a huge warning.
While this class of Mediatek hardware does not have separate clear/set
registers, the pinctrl context has a spinlock that is taken whenever
a register read-modify-write is done. Also, once the GPIO function is
selected / muxed in, further GPIO operations do not involve pinctrl
operations or state. The GPIO direction and level values do not require
toggling the pinmux or any other pin config options.
Switch to directly calling mtk_pinmux_gpio_set_direction() in the GPIO
set direction callbacks to avoid taking the pinctrl mutex. Drop the
.gpio_set_direction field in mtk_pmxops to signal we are no longer using
the pinctrl GPIO layer for setting the direction. |
| In the Linux kernel, the following vulnerability has been resolved:
genirq/proc: Size interrupt directory names for 10-digit interrupt numbers
/proc/irq/<n>/ directory names are built in `char name[10]` buffers
with `sprintf(name, "%u", irq)`.
Ten-digit IRQ numbers already need 11 bytes including the trailing NUL, and
current sparse-IRQ configurations allow interrupt numbers in that range.
Size the temporary name buffer for the current decimal form and switch
to bounded formatting when creating or removing the proc entry. |
| In the Linux kernel, the following vulnerability has been resolved:
watchdog: lenovo_se10_wdt: Fix use-after-free and resource leak risk
Review by sashiko.dev highlighted potential use after free and resource
leak instances.
Set se10_pdev to null to prevent use after free
Remove DMI call back and instead directly call
se10_create_platform_device. Handle error cases appropriately |
| In the Linux kernel, the following vulnerability has been resolved:
PCI/sysfs: Add CAP_SYS_ADMIN check to __resource_resize_store()
Currently, the __resource_resize_store() allows writing to the
resourceN_resize sysfs attribute to change a BAR's size without checking
for capabilities, currently relying only on the file access check.
Resizing a BAR modifies PCI device configuration and can disrupt active
drivers. After the upcoming conversion to static attributes, it will also
trigger resource file updates via sysfs_update_groups().
Add a CAP_SYS_ADMIN check to prevent unprivileged users from performing BAR
resize operations. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix soft lockup polling continuation IOCB signature
qla27xx_copy_multiple_pkt() and qla27xx_copy_fpin_pkt() poll
rsp_q->ring_ptr->signature for RESPONSE_PROCESSED (0xDEADDEAD) to decide
whether the next continuation IOCB has arrived, spinning on cpu_relax()
without advancing the ring or decrementing the entry count while it has
not. response_t::signature lives at byte offset 60, but a continuation
IOCB (sts_cont_entry_t / struct sts_cont_entry_ext) carries raw FC frame
payload at that offset (data[56..59]). A received frame whose payload
bytes happen to equal 0xDEADDEAD is therefore misread as "not yet
arrived", and the loop spins forever in interrupt/DPC context, causing a
CPU soft lockup.
The poll is also unnecessary: callers of qla27xx_copy_multiple_pkt()
(PT_LS4_UNSOL and the NVMe purls path) already gate on
qla_chk_cont_iocb_avail(), which guarantees all entry_count IOCBs are
present before copying begins. The sibling helper
__qla_copy_purex_to_buffer() already drops the signature poll and relies
on the entry_type == STATUS_CONT_TYPE guard instead.
Remove the signature busy-wait from both helpers, keeping the entry_type
guard, and gate the FPIN path with qla_chk_cont_iocb_avail() so it defers
and re-processes on the next interrupt once all continuation IOCBs have
arrived, mirroring the ELS_AUTH_ELS and PT_LS4_UNSOL arms. With this the
signature field is never read on a continuation IOCB, eliminating the
payload-aliasing lockup. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix use-after-free of qpair work on queue teardown
The response queue MSI-X handler qla2xxx_msix_rsp_q() schedules
qla_do_work() via queue_work(ha->wq, &qpair->q_work). qla_do_work()
dereferences the qpair (vha, rsp) and takes qpair->qp_lock.
During teardown, qla2xxx_delete_qpair() deletes the response queue, which
calls free_irq() in qla25xx_free_rsp_que(), and then frees the queue and
the qpair. free_irq() waits for running hardirq handlers but does not
cancel work already placed on ha->wq. A still-pending q_work then runs
qla_do_work() against the freed qpair and response queue, causing a
use-after-free. This is especially likely during full adapter teardown,
where destroy_workqueue(ha->wq) forces pending work to run after the queue
pairs have been freed.
Flush the work item with cancel_work_sync() in qla25xx_free_rsp_que()
after free_irq() has released the interrupt (so no new work can be
queued) and before the response queue and qpair memory are freed (so the
flushed handler still sees valid memory). Guard on rsp->qpair and ha->wq
to match the INIT_WORK() condition and avoid operating on an
uninitialized work_struct. |
| NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer where permissions on read-only memory might not be preserved. A successful exploit of this vulnerability might lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering. |
| NVIDIA GPU Display Driver for Windows and Linux contains a vulnerability in the kernel mode layer, where a user could cause an incorrect conversion between numeric types. A successful exploit of this vulnerability might lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering. |
| NVIDIA GPU Display Driver for Windows and Linux contains a vulnerability in the open-source kernel module DMA-BUF import path where an unprivileged local user could cause improper preservation of memory access permissions when importing a read-only buffer from another device's DMA-BUF exporter. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, denial of service, information disclosure, and data tampering. |
| A flaw was found in tnef. A heap-based buffer overflow can occur in the find_free_number() function when generating numbered backup suffixes for duplicate filenames. When numbered backups are enabled and file overwriting is disabled, an attacker can supply a specially crafted Transport Neutral Encapsulation Format (TNEF) file with an excessive number of colliding attachment filenames, causing the numeric counter to write past the allocated memory buffer. This issue may result in an application crash, leading to a Denial of Service (DoS), or potentially arbitrary code execution. |
| A flaw was found in tnef. A remote attacker could exploit this vulnerability by providing a specially crafted Transport Neutral Encapsulation Format (TNEF) file containing multiple message bodies. During extraction, improper memory management triggers a use-after-free and double-free condition, causing the application to crash and resulting in a Denial of Service (DoS). |
| A flaw was found in tnef. An attacker can exploit this vulnerability by providing a specially crafted file containing uncompressed Rich Text Format (RTF) data. Because the application fails to properly validate input buffer boundaries before copying data in get_rtf_data_from_buf(), reading beyond the allocated memory occurs. This flaw can cause the application to crash, leading to a Denial of Service (DoS), or leak sensitive memory contents into extracted output files. |
| MISP contains an incomplete authorization check in the discussion posting functionality. When a user submits a post to a thread or replies to an existing post, the application only verified whether the target thread was restricted to a single organization (org-only distribution). It did not enforce the full thread access control list, including sharing-group membership and event-level visibility.
As a result, an authenticated user who is outside the relevant sharing group or who does not have visibility on the associated event could:
- Read the thread title and the content of the quoted post
- Submit a new post into the discussion thread
This constitutes both an information disclosure (reading restricted thread and post content) and an integrity issue (injecting content into a thread the user is not authorized to participate in).
Affected: <2.5.48 |
| In the Linux kernel, the following vulnerability has been resolved:
media: chips-media: wave5: Release m2m_ctx after Instance Removed from List
Possible use after free if IRQ thread manages to obtain spinlock between
m2m_ctx release and wave5_release function removing stream instance from
list of active instances. The IRQ thread looks for the m2m_ctx which is
freed so null pointer dereference occurs. |
| In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix bad accounting in __mptcp_subflow_push_pending()
If __subflow_push_pending() errors out we should avoid updating the
copied byte counters, to avoid mismatch push call later on. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Unlink NVMe unsol ctx before freeing on LS reject error
qla_nvme_xmt_ls_rsp() obtains uctx, which was linked into
fcport->unsol_ctx_head by qla2xxx_process_purls_iocb() and is still linked
when the NVMe transport calls back to transmit the LS response. On the
error (out:) path the function frees uctx with kfree() but never removes
it from the list. This leaves a freed node in fcport->unsol_ctx_head: the
next list_add_tail() for that fcport writes through the freed node, and a
subsequent list_del() can corrupt the list or panic.
Unlink uctx with list_del() before kfree() on the error path, matching the
other free sites in qla_nvme_release_lsrsp_cmd_kref() and
qla2xxx_process_purls_pkt(). qla2x00_rel_sp() in the failure path only
returns the SRB to its pool and does not invoke sp->put_fn, so the out:
path is the sole free and uctx is always still linked there. |
| Soft Machine is a Virtual Machine–based agentic development environment / Cloud OS. In versions 0.2.247 and prior, two authentication helpers in /app/server.js — verifyContainerAuth() and authenticateWorkspaceHttp() — accept the global CONTAINER_SHARED_SECRET as a bearer token without verifying which workspace the caller belongs to. Because that secret is set identically on every container in the Fly app and is reachable from the user-facing process environment inside each workspace, any tenant can use it to authenticate to any other tenant's workspace API. The result is cross-workspace read, write, and destructive-restore primitives reachable from any paying customer's shell. The existing per-workspace token check (workspaceTokenMatches) protects the user-facing per-workspace token path, but the shared-secret bearer path bypasses it entirely. At time of publication, there are no publicly known patches. |
