Invoking failure to reject ASCII-only Punycode-encoded labels in golang.org/x/net/idna

GitLab Community Edition and Enterprise Edition contain a integer overflow or wraparound vulnerability that could allow an unauthenticated user to execute arbitrary code on the GitLab server via a specially crafted regular expression in a CI/CD configuration, due to insufficient regular expression validation.

An issue has been discovered in GitLab CE/EE affecting all versions from 7.0 before 18.11.13, 19.0 before 19.0.10, 19.1 before 19.1.9, 19.2 before 19.2.9, 19.3 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that, under certain conditions, could have allowed an unauthenticated user to execute arbitrary code on the GitLab server due to integer overflow when compiling a specially crafted regular expression.

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

smb: client: fix UAF in decryption with multichannel

After commit f7025d861694 ("smb: client: allocate crypto only for primary server") and commit b0abcd65ec54 ("smb: client: fix UAF in async decryption"), the channels started reusing AEAD TFM from primary channel to perform synchronous decryption, but that can't done as there could be multiple cifsd threads (one per channel) simultaneously accessing it to perform decryption.

This fixes the following KASAN splat when running fstest generic/249 with 'vers=3.1.1,multichannel,maxchannels=4,seal' against Windows Server 2022:

BUG: KASAN: slab-use-after-free in gf128mul4klle+0xba/0x110 Read of size 8 at addr ffff8881046c18a0 by task cifsd/986 CPU: 3 UID: 0 PID: 986 Comm: cifsd Not tainted 6.15.0-rc1 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x5d/0x80 printreport+0x156/0x528 ? gf128mul4klle+0xba/0x110 ? virtaddrvalid+0x145/0x300 ? physaddr+0x46/0x90 ? gf128mul4klle+0xba/0x110 kasanreport+0xdf/0x1a0 ? gf128mul4klle+0xba/0x110 gf128mul4klle+0xba/0x110 ghashupdate+0x189/0x210 shashahashupdate+0x295/0x370 ? pfxshashahashupdate+0x10/0x10 ? pfxshashahashupdate+0x10/0x10 ? pfxextractitertosg+0x10/0x10 ? kmalloclargenode+0x10e/0x180 ? asanmemset+0x23/0x50 cryptoahashupdate+0x3c/0xc0 gcmhashassocremaincontinue+0x93/0xc0 cryptmessage+0xe09/0xec0 [cifs] ? pfxcryptmessage+0x10/0x10 [cifs] ? rawspinunlock+0x23/0x40 ? pfxcifsreadvfromsocket+0x10/0x10 [cifs] decryptrawdata+0x229/0x380 [cifs] ? pfxdecryptrawdata+0x10/0x10 [cifs] ? pfxcifsreaditerfromsocket+0x10/0x10 [cifs] smb3receivetransform+0x837/0xc80 [cifs] ? pfxsmb3receivetransform+0x10/0x10 [cifs] ? pfxmightresched+0x10/0x10 ? pfxsmb3istransformhdr+0x10/0x10 [cifs] cifsdemultiplexthread+0x692/0x1570 [cifs] ? pfxcifsdemultiplexthread+0x10/0x10 [cifs] ? rcuiswatching+0x20/0x50 ? rculockdepcurrentcpuonline+0x62/0xb0 ? findheldlock+0x32/0x90 ? kvmschedclockread+0x11/0x20 ? localclocknoinstr+0xd/0xd0 ? traceirqenable.constprop.0+0xa8/0xe0 ? pfxcifsdemultiplexthread+0x10/0x10 [cifs] kthread+0x1fe/0x380 ? kthread+0x10f/0x380 ? pfxkthread+0x10/0x10 ? localclocknoinstr+0xd/0xd0 ? retfromfork+0x1b/0x60 ? localclock+0x15/0x30 ? lockrelease+0x29b/0x390 ? rcuiswatching+0x20/0x50 ? pfxkthread+0x10/0x10 retfromfork+0x31/0x60 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>

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

smb: client: let smbddestroy() call disableworksync(&info->postsendcreditswork)

In smbddestroy() we may destroy the memory so we better wait until postsendcreditswork is no longer pending and will never be started again.

I actually just hit the case using rxe:

WARNING: CPU: 0 PID: 138 at drivers/infiniband/sw/rxe/rxeverbs.c:1032 rxepostrecv+0x1ee/0x480 [rdmarxe] ... [ 5305.686979] [ T138] smbdpostrecv+0x445/0xc10 [cifs] [ 5305.687135] [ T138] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 5305.687149] [ T138] ? kasancheckwrite+0x14/0x30 [ 5305.687185] [ T138] ? pfxsmbdpostrecv+0x10/0x10 [cifs] [ 5305.687329] [ T138] ? pfxrawspinlockirqsave+0x10/0x10 [ 5305.687356] [ T138] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 5305.687368] [ T138] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 5305.687378] [ T138] ? rawspinunlockirqrestore+0x11/0x60 [ 5305.687389] [ T138] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 5305.687399] [ T138] ? getreceivebuffer+0x168/0x210 [cifs] [ 5305.687555] [ T138] smbdpostsendcredits+0x382/0x4b0 [cifs] [ 5305.687701] [ T138] ? pfxsmbdpostsendcredits+0x10/0x10 [cifs] [ 5305.687855] [ T138] ? pfxschedule+0x10/0x10 [ 5305.687865] [ T138] ? pfxrawspinlockirq+0x10/0x10 [ 5305.687875] [ T138] ? queuedelayedworkon+0x8e/0xa0 [ 5305.687889] [ T138] processonework+0x629/0xf80 [ 5305.687908] [ T138] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 5305.687917] [ T138] ? kasancheckwrite+0x14/0x30 [ 5305.687933] [ T138] workerthread+0x87f/0x1570 ...

It means rxepostrecv was called after rdmadestroyqp(). This happened because putreceivebuffer() was triggered by ibdrainqp() and called: queuework(info->workqueue, &info->postsendcreditswork);

devlink: rate: Unset parent pointer in devlratenodesdestroy

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

net/handshake: Drain pending requests at net namespace exit

The arguments to listspliceinit() in handshakenetexit() are reversed. The call moves the local empty "requests" list onto hn->hnrequests, leaving the local list empty, so the subsequent drain loop runs zero iterations. Pending handshake requests that had not yet been accepted are not torn down when the net namespace is destroyed; each one keeps a reference on a socket file and on the handshakereq allocation.

Pass the source and destination in the documented order (listspliceinit(list, head) moves list onto head) so the pending list is transferred to the local scratch list and drained through handshakecomplete().

Fixing the splice direction exposes a list-corruption race. After the splice each req->hrlist still has non-empty link pointers, threading the stack-local scratch list rather than hnrequests. A concurrent handshakereqcancel() -- for example, from sunrpc's TLS timeout on a kernel socket whose netns reference was not taken -- finds the request through the rhashtable, calls removepending(), and sees !listempty(&req->hrlist). removependinglocked() then listdelinit()s an entry off the scratch list while the drain iterates, corrupting it. The same call arriving after the drain loop has run listdel() on an entry hits LISTPOISON instead.

Have removepending() check HANDSHAKEFNETDRAINING under hnlock and report not-found when drain is in progress. The drain has already taken ownership; handshakecomplete()'s existing testandset on HANDSHAKEFREQCOMPLETED still arbitrates between drain and cancel for who calls the consumer's hpdone. Use listdelinit() rather than listdel() in the drain so req->hrlist does not carry LISTPOISON after drain releases the entry.

The DRAINING guard in removepending() makes cancel return false, but cancel still falls through to testandsetbit on HANDSHAKEFREQCOMPLETED and drops the request's hrfile reference. Without another pin, if that is the last reference, skdestruct frees the request while it is still linked on the drain loop's local list. Pin each request's hrfile under hnlock before releasing the list, and drop that drain pin after the loop finishes with the request.

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

LoongArch: Move jumplabelinit() before parseearlyparam()

When enabling both CONFIGMEMALLOCPROFILING=y and CONFIGMEMALLOCPROFILINGENABLEDBYDEFAULT=y, then diabling memory profiling by adding the boot parameter 'sysctl.vm.memprofiling=0' will cause the kernel failed to boot.

After analysis, this is because jumplabelinit() must be called before parseearlyparam(), the early param handlers may modify static keys by staticbranchenable/disable().

Fix this by moving jumplabelinit() to before parseearlyparam(). The solution is similar to other architectures.

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

tracing/probes: Remove WARNONONCE from parsebtfarg

Sashiko found that user can cause this WARNONONCE() easily with adding a kprobe event based on a raw address with BTF parameter.

Since this is not an unexpected condition, remove the WARNONONCE().

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

soc: xilinx: Shutdown and free rx mailbox channel

A mbox rx channel is requested using mboxrequestchannelbyname() in probe. In remove callback, the rx mailbox channel is cleaned up when the rxchan is NULL due to incorrect condition check. The mailbox channel is not shutdown and it can receive messages even after the device removal. This leads to use after free. Also the channel resources are not freed. Fix this by checking the rxchan correctly.

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

media: atomisp: gc2235: fix UAF and memory leak

gc2235probe() handles its error paths incorrectly.

If mediaentitypadsinit() fails, gc2235remove() is called, which tears down the subdev and frees dev, but then still falls through to atomispregisteri2cmodule(). This results in use-after-free.

If atomispregisteri2cmodule() fails, the media entity and control handler are left initialized and dev is leaked.

gc2235remove() unconditionally calls mediaentitycleanup() and v4l2ctrlhandlerfree(), but these are not initialized at every error path in gc2235probe().

Replace gc2235remove() calls in the probe error paths with explicit unwind labels that free only the resources initialized at each point of failure, in reverse order of initialization.

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

scsi: hisisas: Add slavedestroy interface for v3 hw

WARNING is triggered when executing link reset of remote PHY and rmmod SAS driver simultaneously. Following is the WARNING log:

WARNING: CPU: 61 PID: 21818 at drivers/base/core.c:1347 devicelinksnodriver+0xb4/0xc0 Call trace: devicelinksnodriver+0xb4/0xc0 devicelinksdrivercleanup+0xb0/0xfc devicereleasedriver+0x198/0x23c devicereleasedriver+0x38/0x50 busremovedevice+0x130/0x140 devicedel+0x184/0x434 scsiremovedevice+0x118/0x150 scsiremovetarget+0x1bc/0x240 sasrphyremove+0x90/0x94 sasrphydelete+0x24/0x3c sasdestructdevices+0x64/0xa0 [libsas] sasrevalidatedomain+0xe4/0x150 [libsas] processonework+0x1e0/0x46c workerthread+0x15c/0x464 kthread+0x160/0x170 retfromfork+0x10/0x20 ---[ end trace 71e059eb58f85d4a ]---

During SAS phy up, link->status is set to DLSTATEAVAILABLE in devicelinksdriverbound, then this setting influences devicelinksnodriver() before driver rmmod and caused WARNING.

Add the slavedestroy interface to make sure link is removed after flush workque.

dmaengine: idxd: fix double free of wq, engine, and group structs

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

nvme: add missing SRCU grace period in error path

nvmeallocns() error path at outunlinkns removes ns from the namespace head siblings list with listdelrcu(&ns->siblings) but does not wait for SRCU readers before freeing the namespace struct. Multipath code iterates the head->list under srcureadlock() in nvmefindpath() and nvmempathrevalidatepaths(), so a concurrent reader can still hold a reference to ns when kfree(ns) runs.

The normal removal path in nvmensremove() correctly calls synchronizesrcu(&ns->head->srcu) after listdelrcu() to wait for in-progress readers. Add the same grace period in the error path.

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

NFSD: Prevent client use-after-free during blocked-lock reaping

A bare lock owner -- its only remaining reference a blocked lock on nn->blockedlockslru -- holds a raw pointer to its nfs4client but no reference keeping the client alive. When the per-net laundromat reaps such a lock, freeing the nbl drops the owner reference held through flcowner, and the final nfs4putstateowner() takes the client's cllock. Because the laundromat detaches the nbl first, destroyclient() no longer finds it, so a concurrent forceexpireclient() can free the client before nfs4putstateowner() runs, dereferencing cllock in freed memory.

Pin the client with clrpcusers before dropping nn->blockedlockslock, and skip clients already expiring, whose blocked locks destroyclient() frees while holding an owner reference. Take nn->clientlock outside nn->blockedlockslock. Every other site holds nn->blockedlockslock as a leaf, acquiring no further lock, so placing nn->clientlock outside it cannot form a lock-order cycle.

ceph: properly decrypt filenames in vmalloc() buffers

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

smb: client: fix rlist race and missing initialization

TCPServerInfo.rlist is allocated via kzalloc which zeros both ->next and ->prev to NULL instead of pointing to itself, making listempty() always return false and listadd() dereference a NULL ->prev pointer.

Also, cifssignalcifsdforreconnect() can be called concurrently from multiple cifsd threads, allowing the same server's rlist node to be added twice into the local list, corrupting it.

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

wifi: wcn36xx: Fix potential use-after-free in TX ack timer teardown

wcn36xxdxedeinit() tears down the TX ack timer with timerdelete(), which only dequeues the timer and does not wait for a callback that is already executing; the preceding freeirq() calls synchronize the interrupt handlers only. The callback, wcn36xxdxetxtimer(), can therefore be running past the teardown and use the wcn freed along with the ieee80211hw in wcn36xxremove(): it takes wcn->dxelock, reads wcn->txackskb and passes wcn->hw to ieee80211txstatusirqsafe().

Fix this by using timershutdownsync(), which waits for a running callback and also prevents the timer from being rearmed again. The timer is set up again by wcn36xxdxeinit() on the next start, so the start/stop cycle is unaffected.

This issue was found by an in-house static analysis tool.

From: xylove21 To: security@vitess.io Subject: [Security Report] Vitess vttablet /twopcz reflected XSS Date: Tue, 24 Jun 2026 14:30:00 +0800

Summary

The twopczHandler in go/vt/vttablet/tabletserver/twopcz.go (line 185) reflects the Action and dtid form values directly into the HTML response body via fmt.Fprintln(w, msg) — without HTML escaping. The response is served as text/html; charset=utf-8, and Vitess's default acl policy is allow-all, so the endpoint is reachable by anyone who can hit the vttablet's HTTP port (default 15999, multiplexed with gRPC and MySQL wire-protocol ports).

A crafted Action or dtid value yields a reflected XSS that executes in the operator's browser with same-origin access to the vttablet's debug endpoints. This includes /queryz (live query plans), /querylogz (recent queries with bound values), /txlogz (transactions), /debug/env (environment variables — may include MySQL/topology credentials), /debug/vars (expvar stats), and /debug/pprof/ if enabled.

The bug was introduced before v20.0.0 (long-standing) and was silently fixed in commit 3140c1846c (merged 2026-06-09, PR #20255, "tabletserver: escape reflected form values in twopcz handler"). The fix replaces fmt.Fprintln(w, msg) with fmt.Fprintln(w, html.EscapeString(msg)). No released version of Vitess contains the fix — the fix lives only on main (current tip 33a3c0fafe69, 2026-06-23). There is no CVE, GHSA, or OSV entry for this specific bug (verified 2026-06-24 against GitHub Advisory Database, OSV.dev, and NVD).

Impact

| Field | Value | |-------|-------| | Type | Reflected Cross-Site Scripting (XSS) | | CVSS 3.1 | AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N = 7.7 HIGH | | Attack Vector | Network (vttablet HTTP port 15999, multiplexed with gRPC/MySQL) | | Attack Complexity | Low (craft URL, send to operator) | | Privileges Required | None (default acl policy is allow-all) | | User Interaction | Required (operator must visit crafted URL) | | Scope | Changed (XSS chain reaction to other vttablet debug endpoints) | | Confidentiality | High (query text, env vars, expvar stats) | | Integrity | None (XSS itself doesn't change state) | | Availability | None (XSS itself doesn't disrupt service) |

Affected versions (verified)

All released versions are vulnerable. The fix lives only on main:

| Tag | Released | twopcz.go line 185 | Status | |---|---|---|---| | v20.0.0 | 2024-06-27 | fmt.Fprintln(w, msg) | BUGGY | | v20.0.1 - v20.0.6 | 2024 | fmt.Fprintln(w, msg) | BUGGY | | v22.0.4 | 2026-02-27 | fmt.Fprintln(w, msg) | BUGGY | | v23.0.3, v23.0.4 | 2026-02 / 2026-05 | fmt.Fprintln(w, msg) | BUGGY | | v24.0.0, v24.0.1 | 2026-04 / 2026-05 | fmt.Fprintln(w, msg) | BUGGY | | main (33a3c0fafe69) | 2026-06-23 | fmt.Fprintln(w, html.EscapeString(msg)) | FIXED |

Sensitive data exposed via the same-origin XSS chain

A successful XSS lands in the vttablet's origin. From there, the attacker can fetch (via fetch() from injected JavaScript) the following same-origin endpoints, all of which are unauthenticated by default:

- /twopcz — in-flight 2PC transactions (query text, parameters, dtid) - /queryz — live query plans - /querylogz — recent queries with bound values - /txlogz — transactions - /debug/env — environment variables (may include MySQL creds, topology credentials, encryption keys) - /debug/vars — expvar stats - /debug/pprof/ — CPU/memory profiles (if enabled)

Reproduction (independent, runnable PoC)

The PoC is a self-contained Go HTTP server that replicates the buggy twopczHandler from Vitess v20.0.0 verbatim (using the same line-185 code). It runs on 127.0.0.1:15080 and returns the same response shape as the real Vitess endpoint.

bash 1) Build the PoC (Go 1.23+) cd /path/to/finding/CVE-pending-twopcz-xss go build -o /tmp/vitess-twopcz-poc ./poc.go

2) Start the buggy server ADDR=127.0.0.1:15080 /tmp/vitess-twopcz-poc &

3) Reproduce — Test 1: bare GET (no params) curl -sS -i "http://127.0.0.1:15080/twopcz" → Content-Type: text/html; charset=utf-8, status 200

4) Test 2: XSS via Action param (URL-encode the script tag) curl -sS -i "http://127.0.0.1:15080/twopcz?Action=%3Cscript%3Ealert(1)%3C%2Fscript%3E&dtid=zz" → Response body contains literal "<script>alert(1)</script>(zz): completed." → Browser executes the script as same-origin code

5) Test 3: XSS via dtid param (attribute-context payload) curl -sS -i "http://127.0.0.1:15080/twopcz?Action=Demo&dtid=%3Cimg%20src%3Dx%20onerror%3Dalert(1)%3E" → Response body contains literal "<img src=x onerror=alert(1)>" → Browser fires the onerror handler as same-origin code

6) Run the 3x automated runner (writes evidence/run-{1,2,3}.log) bash ./poc/run.sh

PoC result excerpt (from evidence/run-1.log):

--- Test 2: XSS via Action=<script>alert(1)</script> --- HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 ... <h2>WARNING: Actions on this page can jeopardize data integrity.</h2> <script>alert(1)</script>(zz): completed.

PASS: payload reflected UNESCAPED (XSS exploitable in browser)

The PoC was run 3 times on the buggy server (all 3/3 PASS) and the same code is byte-identical to the v20.0.0 commit 8aeb274f6c8e line 185.

Root cause (technical detail)

go/vt/vttablet/tabletserver/twopcz.go (v20.0.0 through v24.0.1):

go // Line 185 fmt.Fprintln(w, msg)

msg is constructed earlier in the handler as:

go msg := fmt.Sprintf("%s(%s): completed.", action, dtid)

with action and dtid coming from the form values r.FormValue("Action") and r.FormValue("dtid"). The form values are URL-decoded (so a + becomes a space, %3C becomes <) but never HTML-escaped. The handler explicitly sets Content-Type: text/html; charset=utf-8 (via the <!DOCTYPE html> it writes first), so the browser executes any injected <script> or attribute-context payload.

The fix in main (fmt.Fprintln(w, html.EscapeString(msg))) closes the hole by HTML-escaping both action and dtid before reflection.

Suggested fix (already in main)

go // Recommended minimal patch (already in main, needs backport to all release branches): import "html"

func twopczHandler(w http.ResponseWriter, r http.Request) { // ... existing logic ... msg := fmt.Sprintf("%s(%s): completed.", action, dtid) fmt.Fprintln(w, html.EscapeString(msg)) // ← was: fmt.Fprintln(w, msg) }

Backport the fix to v20.0.x, v22.0.x, v23.0.x, and v24.0.x as patch releases. The fix is one line and a one-line import "html" addition, so the backport risk is minimal.

Workaround / mitigation (no patch available)

If you cannot upgrade to a fixed release immediately:

1. Restrict the vttablet HTTP port (default 15999) to localhost only. vttablet can run with --tablet-allow-stats=false and --tablet-grpc-port configured separately from the HTTP port, or you can firewall the HTTP port at the network layer. The debug endpoints are not needed by production traffic.

2. Set a non-default ACL policy. Vitess supports an acl policy that defaults to allow-all. Setting it to a JSON file that denies unauthenticated access to debug endpoints (see go/acl/acl.go::savePolicy) would block the XSS, but the default policy is currently "" (allow-all) and many users don't override it.

3. Use a reverse proxy (nginx, envoy) in front of the vttablet HTTP port with a strict allowlist of clients.

Cross-references

- The bug is not related to: - CVE-2024-53257 (/debug/querylogz HTML injection, fixed in v20.0.4 — different endpoint) - CVE-2026-27969 (backup MANIFEST path traversal) - CVE-2026-27965 / GHSA-8g8j-r87h-p36x (backup external decompressor RCE) - PR #20255 is the fix commit; PR #19486 (defense-in-depth) is a separate hardening change

Contact

- GitHub: @xylove21

btrfs: fix xattr replace when multiple xattrs are packed in the same item

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

net/mlx5e: Prevent stale XSK buffer release on refill retry

When an XDP redirect to an AFXDP socket fails because its RX ring is full, the XSK core frees the buffer. During the subsequent batched refill of a legacy cyclic RQ, mlx5e also releases the WQE's XSK buffer before allocating a replacement. If that refill succeeds only partially, a WQE left without a replacement retains its old buffer pointer.

The buffer can meanwhile be allocated to another WQE. A later refill retry can then free the live buffer through the stale pointer and publish the same UMEM frame twice.

Mark the WQE as released immediately after the driver-side free. The flag is already cleared when a replacement buffer is assigned, so refill retries no longer release stale pointers.

The failure is silent and produces no kernel warning or splat. A standalone legacy cyclic-RQ zero-copy libxsk reproducer, using 64-byte UDP traffic offered at 12 Mpps, detected it: stock stopped after 2,854,914 packets in 4.094 seconds, with 4,542 xdprxringfull events and 64 ownership/double-publication errors. With this change it processed 356,904,225 packets in 30 seconds despite 571,405 xdprxringfull events, with no ownership or data errors.

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

net/mlx5e: Prevent stale XSK buffer release on MPWQE refill retry

With AFXDP on a striding RQ, mlx5e defers releasing XSK buffers until an MPWQE is refilled. If XSK allocation then returns -ENOMEM, actualwqhead is not advanced and a later NAPI poll retries the same WQE.

mlx5efreerxmpwqe() leaves each released slot marked as releasable. On retry it can therefore call xskbufffree() again through stale pointers after the frames have returned to the XSK pool and been reallocated.

Set all skipreleasebitmap bits in the common error path of mlx5exskallocrxmpwqe(). This matches mlx5eallocrxmpwqe(). A successful allocation already clears the bitmap after replacing every buffer, so retries become idempotent without changing the success path.

Fault injection forced three consecutive failures for one selected MPWQE. Both an early allocation failure and a partial 8-of-16-buffer unwind released the original 16 XSK buffers only once. Each error left a full bitmap, the following NAPI retry skipped the release, and a later successful allocation cleared it. A 20-second AFXDP zero-copy pressure run exercised 1,575,262 buffer allocation failures without invalid descriptors, WQE errors, or kernel warnings.

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

wifi: p54: validate firmware record lengths

The p54 firmware parser accesses component ID and component version records without checking that their lengths cover the fields being read. A malformed record can therefore make the parser read past the record.

Validate the component ID and component version record lengths before accessing their data. The descriptor record is also checked against the shortest descriptor length found in the supported firmware images.

Reject descriptor values that underflow the RX offset or produce an empty RX range before updating the driver state.

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

scsi: libiscsi: Validate the ITT reflected in a Reject PDU

A Reject PDU carries a copy of the header it rejects, and iscsihandlereject() takes the ITT out of that copy to find the task to clean up:

memcpy(&rejectedpdu, data, sizeof(struct iscsihdr)); ... task = iscsiitttotask(conn, rejectedpdu.itt);

That value is whatever the target put there. iscsiitttotask() bounds the index against cmdsmax and checks nothing else, so any task in the pool can be named, and iscsinopoutrsp() then completes it.

An index that has never been used gives a NULL task->conn: the pool is zeroed at session setup and conn is assigned only when a task is allocated. If the task was used and returned, iscsicompletetask() hits its WARNONONCE(task->state == ISCSITASKFREE) and the refcount underflows. An in-flight SCSI command is completed as successful - a 1 MiB read returned 1048576 with none of its buffer written and no warning.

Validate the reflected ITT the way iscsiitttoctask() validates a command ITT, and require the task to be in flight and not a SCSI command.

[ 6.248477] Oops: general protection fault, probably for non-canonical address 0xdffffc000000000c: 0000 [#1] SMP KASAN NOPTI [ 6.249357] KASAN: null-ptr-deref in range [0x0000000000000060-0x0000000000000067] [ 6.249951] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 7.2.0-rc5-ISCSI1-gf5098b6bae76 #1 PREEMPT(lazy) [ 6.250718] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, archcaps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 6.251616] RIP: 0010:iscsinopoutrsp.constprop.0+0x46/0x160 [ 6.252043] Code: c1 ea 03 48 83 ec 08 80 3c 02 00 0f 85 f5 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 6b 58 48 8d 7d 60 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 c0 00 00 00 48 8b 45 60 48 39 c3 74 50 48 b8 00 [ 6.252813] RSP: 0018:ffff88806c907b80 EFLAGS: 00010206 [ 6.253042] RAX: dffffc0000000000 RBX: ffff88800607e000 RCX: ffffffff8d571a25 [ 6.253345] RDX: 000000000000000c RSI: ffff88806c907c38 RDI: 0000000000000060 [ 6.253642] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff235a504 [ 6.253947] R10: 0000000000000003 R11: 7463656e6e6f6320 R12: 0000000000000000 [ 6.254251] R13: 0000000000000000 R14: ffff88806c907c38 R15: 0000000000000000 [ 6.254549] FS: 0000000000000000(0000) GS:ffff8880d95bc000(0000) knlGS:0000000000000000 [ 6.254887] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6.255140] CR2: 00007fc393e8ffc0 CR3: 0000000005252006 CR4: 0000000000770ef0 [ 6.255439] PKRU: 55555554 [ 6.255564] Call Trace: [ 6.255674] <IRQ> [ 6.255768] iscsicompletepdu+0x18bf/0x22a0 [ 6.256733] iscsicompletepdu+0x54/0xa0 [ 6.256905] iscsitcpdatarecvdone+0xf4/0x250 [ 6.257103] iscsitcprecvskb+0x31e/0xec0 [ 6.257680] iscsiswtcprecv+0x12f/0x390 [ 6.258061] tcpreadsock+0x1ab/0x810 [ 6.258853] iscsiswtcpdataready+0x18b/0x510 [ 6.259808] tcpdataqueue+0x1f13/0x4cd0 [ 6.260567] tcprcvestablished+0x8a5/0x3a00 [ 6.261931] tcpv4dorcv+0x449/0x960 [ 6.262269] tcpv4rcv+0x2245/0x3bc0

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

scsi: libiscsi: Reject a negative task index from parsepduitt

A transport that implements parsepduitt hands libiscsi an index taken from the PDU, and both lookups bound it from above only:

if (i >= session->cmdsmax)

i and cmdsmax are both int, so a negative index passes and session->cmds[i] is read from before the array.

be2iscsi produces one. beiscsiparsepdu() assigns the raw tag,

index = (int)itt;

and beiscsicompletepdu() forwards an unsolicited NOP-In from the hardware async ring without replacing its ITT, so the value is the target's. It also reports the session's own age rather than the one in the tag, which leaves the age comparison in iscsiverifyitt() with nothing to reject.

Bound the index from below in both lookups.

Gnome Pango 1.42 and later is affected by: Buffer Overflow. The impact is: The heap based buffer overflow can be used to get code execution. The component is: function name: pangolog2visgetembeddinglevels, assignment of nchars and the loop condition. The attack vector is: Bug can be used when application pass invalid utf-8 strings to functions like pangoitemize.

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

PCI: dwc: ep: Prevent changing BAR size/flags in pciepcsetbar()

In commit 4284c88fff0e ("PCI: designware-ep: Allow pciepcsetbar() update inbound map address") setbar() was modified to support dynamically changing the backing physical address of a BAR that was already configured.

This means that setbar() can be called twice, without ever calling clearbar() (as calling clearbar() would clear the BAR's PCI address assigned by the host).

This can only be done if the new BAR size/flags does not differ from the existing BAR configuration. Add these missing checks.

If we allow setbar() to set e.g. a new BAR size that differs from the existing BAR size, the new address translation range will be smaller than the BAR size already determined by the host, which would mean that a read past the new BAR size would pass the iATU untranslated, which could allow the host to read memory not belonging to the new struct pciepfbar.

While at it, add comments which clarifies the support for dynamically changing the physical address of a BAR. (Which was also missing.)

EDK2 contains a vulnerability in BIOS where a user may cause “Out-of-bounds Write”, Classic Buffer Overflow, and “Incorrect Calculation of Buffer Size” by remote access. Successful exploitation of this vulnerability can lead to arbitrary code execution. It could also impact Confidentiality, Integrity, and Availability.

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

KVM: SEV: Ignore Port I/O requests of length '0'

Explicitly ignore Port I/O requests of length '0' (or count '0'), so that setting up the software scratch area (and other code) doesn't have to worry about underflowing the length, and to allow for WARNing on trying to configure the scratch area with len==0.

Distrust compromised intermediate certificates in ssl module