Where
AND
-Infinity
0
Severity
4.8
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L

In the Linux kernel, the following vulnerability has been resolved:

sctp: reject stale cookies with mismatched verification tags

sctpunpackcookie() skips cookie expiration checks whenever an association already exists. This is broader than the exception in RFC 9260 Section 5.2.4.

For an existing association, Section 5.2.4 permits an expired State Cookie only when both Verification Tags in the cookie match the current association. Otherwise, the packet SHOULD be discarded and a Stale Cookie ERROR MUST be sent.

The broad check lets an expired Action A restart cookie reach sctpsfdodupcooka(). In a runtime test with the default 60 second cookie lifetime, replaying such a cookie after 65 seconds returned a COOKIE-ACK and restarted the association.

Check cookie expiration unless both Verification Tags match. This preserves the Action D exception for a lost COOKIE ACK while rejecting expired cookies in all other cases.

1 / 2
Source: MITRE
First published (updated )
Severity
5.5
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

drm/vmwgfx: drop dmabuf reference on foreign-fd prime import

1 / 2
Source: Microsoft
First published (updated )
Severity
5.5
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H/E:U

In the Linux kernel, the following vulnerability has been resolved:

net: remove WARNONONCE() from skmcloop()

skmcloop() can be called for sockets that are neither AFINET nor AFINET6 (e.g. AFPACKET sockets when sending packets via raw/packet socket over virtual devices such as VRF or ipvlan).

In such cases, skfamily is not AFINET/AFINET6 and skmcloop() falls through the switch statement and triggers WARNONONCE(1).

Non-INET sockets do not support IPMULTICASTLOOP or IPV6MULTICASTLOOP options, so loopback should default to true without generating a warning.

1 / 2
Source: MITRE
First published (updated )
Severity
6.5
Path Traversal
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

IBM Langflow OSS 1.0.0 through 1.10.2 could allow a remote authenticated attacker to obtain sensitive information due to improper limitation of a pathname to a restricted directory.

1 / 2
Source: MITRE
First published (updated )
Severity
5.4
Path Traversal
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N

IBM Langflow OSS 1.0.0 through 1.10.2 could allow a remote attacker to traverse directories on the system. An attacker could send a specially crafted URL request containing "dot dot " sequences ( /.. /) to view arbitrary files on the system.

First published (updated )
Severity
6.5
Path Traversal
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

IBM Langflow OSS 1.0.0 through 1.10.2 could allow an authenticated attacker to traverse directories on the system. An attacker could send a specially crafted URL request containing "dot dot" sequences (/../) to view arbitrary files on the system.

1 / 2
Source: MITRE
First published (updated )
Severity
4.4
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L

drm/amdkfd: Fix missing authorization check in KFDIOCDBGTRAPDISABLE

1 / 2
Source: Microsoft
First published (updated )
Severity
5.5
Null Pointer Dereference
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H/E:U

In the Linux kernel, the following vulnerability has been resolved:

s390/dasd: Fix potential NULL pointer dereference

dasdreleasespace() checks the implementation of the isese() discipline function before calling it to determine if a given device is an ESE DASD.

The current usage of the logical AND operator will lead to a NULL pointer dereference as the function is called even if the function pointer is NULL.

Fix this by using the logical OR operator.

1 / 2
Source: MITRE
First published (updated )
Severity
6.1
XSS
AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

IBM Langflow OSS 1.0.0 through 1.11.2 suffer from a stored cross-site scripting vulnerability in the Playground chat interface.

1 / 2
Source: MITRE
First published (updated )
Severity
6.5
EPSS
0.30%
Input Validation, Path Traversal
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N

IBM Langflow OSS 1.0.0 through 1.11.2 Langflow could allow an authenticated attacker to write arbitrary files to the server due to improper input validation in the SaveToFileComponent. The application constructs local file paths using attacker‑controlled input without sufficient sanitization when handling requests to the /api/v1/run/{flowid} endpoint. An attacker with low‑privileged authenticated access (such as a valid API key or user session) can supply crafted path values, including absolute paths or path traversal sequences, allowing arbitrary file writes to locations writable by the Langflow process. Successful exploitation may lead to unauthorized file creation or modification, potentially resulting in further compromise depending on the deployment environment.

1 / 2
Source: MITRE
First published (updated )
Severity
6.5
EPSS
0.27%
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N

IBM Langflow OSS 1.0.0 through 1.11.2 allows remote authenticated attackers to bypass localhost-only MCP configuration installation by spoofing X-Forwarded-For: 127.0.0.1 header, enabling arbitrary writes to IDE config files (~/.cursor/mcp.json, etc.).

1 / 2
Source: MITRE
First published (updated )
Severity
6.5
Path Traversal
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

IBM Langflow OSS 1.0.0 through 1.11.2 could allow a remote authenticated attacker to obtain sensitive information due to path traversal.

1 / 2
Source: MITRE
First published (updated )
Severity
6.5
Path Traversal
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

IBM Langflow OSS 1.0.0 through 1.11.2 could allow a remote authenticated attacker to obtain sensitive information due to improper validation of symbolic links.

1 / 2
Source: MITRE
First published (updated )
Severity
6.5
SSRF
AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N

IBM Langflow OSS 1.0.0 through 1.11.2 could allow a remote authenticated attacker to obtain sensitive information due to server-side request forgery.

1 / 2
Source: MITRE
First published (updated )
Severity
6.5
SSRF
AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N

IBM Langflow OSS 1.0.0 through 1.10.2 could allow a remote authenticated attacker to obtain sensitive information due to a server-side request forgery (SSRF) vulnerability.

1 / 2
Source: MITRE
First published (updated )
Severity
5.9
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N

IBM Concert 1.0.0 through 2.3.1 could allow a remote attacker to perform unauthorized actions using man in the middle techniques due to improper certificate validation.

1 / 2
Source: MITRE

Remedy

IBM strongly recommends addressing the vulnerability now by upgrading to IBM Concert Software 3.0.0 Download IBM Concert Software 3.0.0 from Container software library section of IBM Entitled Registry ( ICR https://myibm.ibm.com/products-services/containerlibrary ) and follow  installation instructions https://www.ibm.com/docs/en/concert  depending on the type of deployment.
First published (updated )
Severity
5.5
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

NVIDIA NemoClaw contains a vulnerability where an attacker could cause invocation of process using visible sensitive information. A successful exploit of this vulnerability might lead to information disclosure.

First published (updated )
Severity
6.1
AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:L/A:N

NVIDIA NemoClaw contains a vulnerability where an attacker could cause insufficiently protected credentials . A successful exploit of this vulnerability might lead to information disclosure and data tampering.

First published (updated )
Severity
6.8
OS Command Injection, Command Injection
AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N

NVIDIA OpenShell for Linux contains a vulnerability in its sandbox exec handler, where an attacker could cause an OS command injection. A successful exploit of this vulnerability might lead to code execution, information disclosure, and data tampering.

First published (updated )
Severity
5.2
AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N

NVIDIA OpenShell for Linux contains a vulnerability in its inference proxy, where an attacker could cause an improper encoding or escaping of output. A successful exploit of this vulnerability might lead to information disclosure and data tampering.

First published (updated )
Severity
6.4
EPSS
0.08%
AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:L

The userspace syscall verifier zvrfymboxsend() in drivers/mbox/mboxhandlers.c validated the nested msg->data/msg->size fields by reading them directly out of live userspace memory, and then forwarded the original, still-mutable userspace struct mboxmsg pointer to zimplmboxsend() and the underlying driver. Between the access check and the driver's use of msg->data, the validated pointer could be replaced, leaving a time-of-check/time-of-use window.

On a system built with CONFIGUSERSPACE, any unprivileged userspace thread may invoke the mboxsend() system call. A second thread sharing the caller's address space can race to overwrite msg->data with a supervisor (kernel) address after the verifier's bounds check has passed but before the driver dereferences it. The driver then reads from the attacker-chosen address in supervisor context (for example memcpy(&data32, msg->data, msg->size) in the NXP mailbox driver, whose bytes are subsequently emitted to the peer mailbox endpoint).

The impact is a userspace-to-supervisor access-control bypass: disclosure of kernel memory contents (high confidentiality impact), or, for an invalid/unmapped target address, a faulting kernel read causing denial of service. The fix snapshots the entire struct mboxmsg into a kernel-stack copy with kusermodefromcopy() and validates and forwards that immutable copy, closing the race.

First published (updated )
Severity
5.5
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

btrfs: fix memory leak in btrfsdoencodedwrite()

1 / 2
Source: Microsoft
First published (updated )
Severity
4.7
AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N

In the Linux kernel, the following vulnerability has been resolved:

Input: evdev - sanitize event type index when fetching event masks

The user-supplied event type index passed to EVIOCGMASK / EVIOCSMASK ioctls is used to index the static counts array in evdevgetmaskcnt() and client evmasks array in evdevgetmask().

While the event type is architecturally bounded by EVCNT, speculative execution may mispredict bounds checks and perform out-of-bounds loads.

Sanitize the event type index in evdevgetmaskcnt() branchlessly using arrayindexmasknospec(). This clamps the index to 0 for safe array access and forces the returned count to 0 speculatively when the index is out of bounds.

We do not need additional arrayindexnospec() calls in evdevgetmask() because evdevgetmaskcnt() speculatively forces the count (and resulting xfersize) to 0 for out-of-bounds types, preventing any speculative memory access to client evmasks array.

1 / 2
Source: MITRE
First published (updated )
Severity
5.9
AV:P/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H

ALSA: usb-audio: fix OOB write on Type II inbound URBs

1 / 2
Source: Microsoft
First published (updated )
Severity
4.4
AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H

In the Linux kernel, the following vulnerability has been resolved:

ipv4: Fix fibnlmsgsize() for RTAVIA nexthops

fibnlmsgsize() still estimates nexthop space as if every gateway is encoded as an IPv4 RTAGATEWAY attribute. IPv4 routes can also carry an IPv6 gateway, which fibnexthopinfo() dumps as RTAVIA.

As a result, route notifications can allocate an skb that is too small. fibdumpinfo() then fails with -EMSGSIZE and rtmsgfib() hits the WARNON() that marks such failures as a fibnlmsgsize() bug. With paniconwarn set, this becomes a kernel panic.

Mirror the actual nexthop dump layout in fibnlmsgsize(): account for IPv6 nexthop gateways dumped as RTAVIA, for the no-header rtnexthop layout used inside RTAMULTIPATH, and for RTAFLOW only when it is actually present.

1 / 2
Source: MITRE
First published (updated )
Severity
5.5
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

In the Linux kernel, the following vulnerability has been resolved:

serial: 8250dma: Clear stale RX state on shutdown

serial8250releasedma() terminates RX DMA and releases the channel, but leaves rxrunning set. If the port is closed while an RX transfer is active, the stale state remains while rxchan is NULL until the channel is requested again on the next open.

The DesignWare BUSY workaround added by commit a7b9ce39fbe4 ("serial: 8250dw: Ensure BUSY is deasserted") calls serial8250rxdmaflush() from the LCR write path during startup. This happens before serial8250requestdma() obtains a new RX channel. On reopen, the stale rxrunning state therefore makes the flush path pass a NULL channel to dmaenginepause(), causing a kernel Oops.

Clear rxrunning after terminating RX DMA, matching the TX cleanup. Also make the flush helper return if the DMA object or RX channel is not available so startup and teardown paths cannot pass a NULL channel to the DMAengine API.

1 / 2
Source: MITRE
First published (updated )
Severity
4.1
AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H

In the Linux kernel, the following vulnerability has been resolved:

tracing: Fix race between updateeventfields and, eventdefinefields

The following sequence may leads race between eventdefinefields() and updateeventfields():

CPU0 (loads module A) CPU1 (loads module B) =============================== =============================== loadmodule(A) loadmodule(B) notifiercallchain notifiercallchain tracemodulenotify tracemodulenotify mutexlock(&eventmutex) traceeventupdateall() tracemoduleaddevents(A) downwrite(&traceeventsem) registerevent(callA) addeventtotracers(callA) eventdefinefields(callA) for each f: listforeachentry(field, listadd(&f->link, &class->fields, link) &class->fields) field = class->fields->next;

Where access to the class->fields is not protected by the eventmutex in traceeventupdateall().

This produces the following panic: Unable to handle kernel access ... at virtual address 0000000000000018 pc : updateeventfields+0xf8/0x368 Call trace: updateeventfields+0xf8/0x368 traceeventupdateall+0x7c/0x2b4 tracemodulenotify+0x4c/0x1dc notifiercallchain+0x84/0x168 blockingnotifiercallchainrobust+0x64/0xd4 loadmodule+0x10c8/0x123c arm64sysfinitmodule+0x230/0x31c

Fix by taking eventmutex in traceeventupdateall() before traceeventsem.

1 / 2
Source: MITRE
First published (updated )
Severity
4.4
AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H

In the Linux kernel, the following vulnerability has been resolved:

net: atlantic: free stranded TX buffers on ring deinit

aqvecdeinit() drains the TX rings with a single aqringtxclean() call, which frees at most AQCFGTXCLEANBUDGET (256) descriptors and stops at hwhead, which no longer moves once aqvecstop() has stopped the hardware and NAPI. Completed descriptors beyond the budget and everything still posted in [hwhead, swtail) keep their skb or xdpframe when the interface goes down: aqvecringfree() then frees the buffer ring and the references are lost for good.

Today this is a silent memory leak on every interface down under TX/XDPTX load. With the conversion of the RX path to pagepool posted for net-next it becomes much more visible: XDPTX frames carry fragment references on the RX ring's pagepool, so a single stranded frame keeps the pool's inflight count above zero forever. pagepooldestroy() then never completes, the pool is leaked together with its pages, and "pagepoolreleaseretry() stalled pool shutdown" is warned every 60 seconds from that point on, on every ifdown, XDP detach or ring resize under XDPTX load.

Bring back aqringtxdeinit() as it was before the removal and use it for teardown again, with one extension: TX rings can hold xdpframes nowadays, so release those too. They are returned with xdpreturnframe() since this runs in process context.

1 / 2
Source: NVD
First published (updated )
Severity
4.4
AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H

In the Linux kernel, the following vulnerability has been resolved:

net: atlantic: free RX pages of consumed but not refilled buffers

aqringrxdeinit() only walks [swhead, swtail), the region posted to hardware. Since the page reuse strategy was added, a cleaned RX buffer keeps its page (and its DMA mapping) in the ring for reuse, and refill is batched: aqringrxfill() returns early until AQCFGRXREFILLTHRES slots are free. Slots that were consumed but not yet reposted therefore sit in the complementary [swtail, swhead) gap with a live page, and the deinit walk never visits them: up to a refill batch worth of pages and DMA mappings leak on every interface down.

Walk the whole ring instead and release whatever is still there. Also bail out if the buffer ring is already gone: a partial aqptpringalloc() failure frees the ring but leaves aqnic set, so aqptpringdeinit() still gets here on the unwind path.

1 / 2
Source: MITRE
First published (updated )
Severity
4.4
AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H

In the Linux kernel, the following vulnerability has been resolved:

net/sched: actgact, actpolice: range check the fallback control action

tcfactioncheckctrlact() range checks the primary control action:

if (!opcode) ret = action > TCACTVALUEMAX ? -EINVAL : 0;

TCACTVALUEMAX is TCACTTRAP, so kernel-internal verdicts above it cannot be set that way. But actgact and actpolice each carry a second, independent control action supplied by user space that never reaches that helper - TCAGACTPROB.paction and TCAPOLICERESULT. Both only reject TCACTGOTOCHAIN, so any other value is stored verbatim and returned verbatim from the action.

In particular user space can store TCACTCONSUMED, which is TCACTVALUEMAX + 1 and is deliberately not part of the UAPI value range. That verdict tells every caller the action took ownership of the skb, so nobody frees it: schhandleingress(), schhandleegress() and tcfqeventhandle() all deliberately skip the free for it. The result is one leaked skbuff plus its data buffer per packet traversing the filter, unbounded, for all traffic on the chain including kernel-generated packets.

Both are trivially deterministic. actgact clamps tcfgpval to >= 1, so with pval = 1 gactdeterm() returns the fallback for every packet. actpolice has no mandatory rate, so rate = 0 leaves tcfpmtu = ~0 and tcfpolicemtucheck() always passes.

TCACTCONSUMED was added by commit 720f22fed81b ("net: sched: refactor reinsert action"), after both goto-chain guards were written: commit 9469f375ab09 ("net/sched: actgact: disallow 'goto chain' on fallback control action") and commit c08f5ed5d625 ("net/sched: actpolice: disallow 'goto chain' on fallback control action"). Neither guard was widened when the new verdict appeared.

Factor the existing range test out of tcfactioncheckctrlact() as tcfactionvalid() and apply it to both fallbacks. The helper cannot call tcfactioncheckctrlact() directly because that also allocates a gotochain, which is exactly what these two sites must not do.

Reproduced on v7.2-rc6: kmemleak reports one leaked 232-byte skbuffheadcache object plus its 704-byte data buffer per packet. With this patch both configurations are rejected with -EINVAL and kmemleak reports none.

1 / 2
Source: NVD
First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203