IBM QRadar 7.5.0 through 7.5.0 Update Pack 16 Interim Fix 02, and 7.6.0.0 through 7.6.0.5 is vulnerable to Open Redirect. A victim must open a specifically crafted URL while authenticated to QRadar to trigger this.

IBM QRadar 7.5.0 through 7.5.0 Update Pack 16 Interim Fix 02, and 7.6.0.0 through 7.6.0.5 is vulnerable to Reflected XSS. A victim must open a specifically crafted URL while authenticated to QRadar to trigger this.

Global Buffer Overflow in GNU gzip

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

wifi: ath9k: hifusb: don't dereference hifdev after re-arming firmware request

ath9khifrequestfirmware() re-arms an asynchronous firmware load via requestfirmwarenowait(), passing hifdev as the completion context, and then still dereferences hifdev:

devinfo(&hifdev->udev->dev, "ath9khtc: Firmware %s requested\n", hifdev->fwname);

The re-armed callback ath9khifusbfirmwarecb() runs on the "events" workqueue and, when the firmware is missing, walks the retry chain into ath9khifusbfirmwarefail() -> completeall(&hifdev->fwdone). That releases the waitforcompletion(&hifdev->fwdone) in a concurrent ath9khifusbdisconnect(), which then kfree()s hifdev. The trailing devinfo() in the frame that re-armed the request can therefore read freed memory (hifdev->udev, the first field of struct hifdeviceusb):

BUG: KASAN: slab-use-after-free in ath9khifrequestfirmware Read of size 8 ... by task kworker/... ath9khifrequestfirmware ath9khifusbfirmwarecb drivers/net/wireless/ath/ath9k/hifusb.c:1247 requestfirmwareworkfunc Allocated by ...: ath9khifusbprobe drivers/net/wireless/ath/ath9k/hifusb.c Freed by ...: ath9khifusbdisconnect -> kfree drivers/net/wireless/ath/ath9k/hifusb.c

The fwdone barrier only makes disconnect wait for the firmware chain to terminate; it does not protect the outer ath9khifrequestfirmware() frame that re-armed the request and keeps touching hifdev afterwards.

Drop the post-request devinfo(): it is the only use of hifdev after the async request is armed, and it is purely informational (the deverr() on the failure path runs only when requestfirmwarenowait() did not arm a callback, so hifdev is still alive there).

This was first reported by syzbot as a single, non-reproduced crash that was later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer, which produced a C reproducer (USB-gadget connect/disconnect of an ath9khtc device whose firmware download fails). The vulnerable code is unchanged and still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN once the (sub-microsecond) race window is widened.

Last updated 21 September 2026

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

xfrm: fix stale skb->prev after async crypto steals a GSO segment

skbgsosegment() leaves the segment list head with ->prev pointing at the last segment, an invariant validatexmitskblist() relies on when it sets its tail pointer (tail = skb->prev).

When validatexmitxfrm() walks a GSO list and some segments are stolen by async crypto (->xmit() returns -EINPROGRESS), those segments are unlinked from the list but the head ->prev is never updated. If the last segment is the one stolen, the returned head still has ->prev pointing at it, even though it is now owned by the crypto engine and may be freed. validatexmitskblist() later does tail->next = skb, writing through that stale pointer -- a use-after-free.

Repoint skb->prev at the last retained segment before returning.

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.

dm-verity: fix buffer overflow in FEC calculation

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

scsi: qla2xxx: Clear cmds after chip reset

Commit aefed3e5548f ("scsi: qla2xxx: target: Fix offline port handling and host reset handling") caused two problems:

1. Commands sent to FW, after chip reset got stuck and never freed as FW is not going to respond to them anymore.

2. BUGON(cmd->sgmapped) in qltfreecmd(). Commit 26f9ce53817a ("scsi: qla2xxx: Fix missed DMA unmap for aborted commands") attempted to fix this, but introduced another bug under different circumstances when two different CPUs were racing to call qltunmapsg() at the same time: BUGON(!validdmadirection(dir)) in dmaunmapsgattrs().

So revert "scsi: qla2xxx: Fix missed DMA unmap for aborted commands" and partially revert "scsi: qla2xxx: target: Fix offline port handling and host reset handling" at qla2x00abortallcmds.

A flaw was found in xdgmime, affecting all versions. A heap-based buffer overflow can occur in xdgmimemagicparsemagicline() 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 $XDGDATAHOME/mime/magic path) is parsed by an application performing MIME type detection (e.g., via gcontenttypeguess()). 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. To exploit this flaw, an attacker must trick a user into installing a malicious MIME magic file.

A JNDI Injection vulnerability has been discovered in Apache CXF's JCA integration module, which can allow for code execution, if an attacker is able to manipulate the JCA deployment descriptor (ra.xml) or runtime activation parameters. Users are recommended to upgrade to versions 4.2.2 or 4.1.7 or 3.6.12, which fixes this issue.

An authentication bypass vulnerability exists in the OAuth2 TokenIntrospectionService in Apache CXF. Due to a missing 'throw' keyword in the security context check, the introspection endpoint (/services/oauth2/introspect) can be accessed by any unauthenticated network attacker. However note that this is a safeguard only in the case that someone forgot to enable authentication on the service. Users are recommended to upgrade to version 4.2.2 or 4.1.7 or 3.6.12, which fixes this issue.

A vulnerability in Apache CXF's JwsJsonContainerRequestFilter can be exploited to cause CXF to process metadata that was not authenticated by the accepted signature. This can bypass the application's assumption

that accepted Content-Type or protected HTTP-header metadata came from a verified signature entry, and may steer downstream JAX-RS entity parsing or signed-header consistency checks. Users are recommended to upgrade to versions 4.2.2 or 4.1.7 or 3.6.12, which fix this issue.

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

KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE

When installing an emulated MMIO SPTE, do so after dropping/zapping the existing SPTE (if it's shadow-present). While commit a54aa15c6bda3 was right about it being impossible to convert a shadow-present SPTE to an MMIO SPTE due to a guest write, it failed to account for writes to guest memory that are outside the scope of KVM.

E.g. if host userspace modifies a shadowed gPTE to switch from a memslot to emulted MMIO and then the guest hits a relevant page fault, KVM will install the MMIO SPTE without first zapping the shadow-present SPTE.

------------[ cut here ]------------ isshadowpresentpte(sptep) WARNING: arch/x86/kvm/mmu/mmu.c:484 at markmmiospte+0xb2/0xc0 [kvm], CPU#0: vmxeptstaler/4292 Modules linked in: kvmintel kvm irqbypass CPU: 0 UID: 1000 PID: 4292 Comm: vmxeptstaler Not tainted 7.0.0-rc2-eafebd2d2ab0-sink-vm #319 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:markmmiospte+0xb2/0xc0 [kvm] Call Trace: <TASK> mmusetspte+0x237/0x440 [kvm] eptpagefault+0x535/0x7f0 [kvm] kvmmmudopagefault+0xee/0x1f0 [kvm] kvmmmupagefault+0x8d/0x620 [kvm] vmxhandleexit+0x18c/0x5a0 [kvmintel] kvmarchvcpuioctlrun+0xc55/0x1c20 [kvm] kvmvcpuioctl+0x2d5/0x980 [kvm] x64sysioctl+0x8a/0xd0 dosyscall64+0xb5/0x730 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x47fa3f </TASK> ---[ end trace 0000000000000000 ]---

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

rhashtable: clear stale iter->p on table restart

rhashtablewalkstartcheck() has two restart paths when resuming a walk. When iter->walker.tbl is valid, it re-validates iter->p against the table and sets iter->p = NULL if the object is gone. When iter->walker.tbl is NULL (table was freed during resize), it resets slot and skip but forgets to clear iter->p.

rhashtablewalknext() then dereferences the stale iter->p, reading freed memory. This is a use-after-free.

Any caller that does multi-fragment rhashtable walks across walkstop/walkstart boundaries is affected. Concrete cases include netlinkdiag (netlinkdiagdump in net/netlink/diag.c) and TIPC (tipcnlskwalk in net/tipc/socket.c).

Crash stack (netlinkdiag): BUG: KASAN: slab-use-after-free in rhashtablewalknext+0x365/0x3c0 Read of size 8 at addr ffff88801a9d2438 (freed kmalloc-2k, offset 1080) Call Trace: rhashtablewalknext+0x365/0x3c0 (lib/rhashtable.c:1016) netlinkdiagdump+0x160/0x760 (net/netlink/diag.c:122) netlinkdiagdump+0xc2/0x240 netlinkdump+0x5bc/0x1270 netlinkrecvmsg+0x7a3/0x980 sockrecvmsg+0x1bc/0x200 sysrecvfrom+0x1d4/0x2c0

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

smb: client: validate DFS referral PathConsumed

parsedfsreferrals() validates that the response contains the fixed referral entry array and, on for-next, the per-referral string offsets. However, the response also contains a PathConsumed value that is later used for DFS path parsing.

If a malformed response provides a PathConsumed value larger than the search name, later DFS parsing can advance beyond the end of the path.

Validate PathConsumed against the search name length before storing it in the parsed referral.

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

sctp: fix authhmacs array size in struct sctpcookie

The authhmacs array in struct sctpcookie is supposed to store a complete SCTPAUTHHMACALGO parameter, which consists of a struct sctpparamhdr followed by N HMAC identifiers.

However, the array size was calculated using an extra 2 bytes instead of sizeof(struct sctpparamhdr), which is 4 bytes. When four HMAC identifiers are configured, the HMAC-ALGO parameter stored in the endpoint is larger than the authhmacs buffer in the cookie.

As a result, sctpassociationinit() copies beyond the end of authhmacs when initializing the association, corrupting the adjacent authchunks field. This can lead to an invalid HMAC identifier being accepted and later cause an out-of-bounds read in sctpauthgethmac().

Fix the array size calculation by including the full SCTP parameter header size.

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

nvmet-rdma: handle inline data with a nonzero offset

nvmetrdmauseinlinesg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inlinedatasize, but the mapping still assumes the data begins in the first inline page:

sg->offset = off; sg->length = mint(int, len, PAGESIZE - off);

When a port is configured with inlinedatasize > PAGESIZE (settable up to max(SZ16K, PAGESIZE)), an offset in (PAGESIZE, inlinedatasize] makes "PAGESIZE - off" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. numpages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist.

Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from pageoff + len. Because the request scatterlist may now start at inlinesg[pageidx] rather than inlinesg[0], generalize the inline-SGL identity test in nvmetrdmareleasersp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmetreqfreesgls() frees an inline page (and warns in freelargekmalloc()).

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

tipc: clear sock->sk on the failed-insert path in tipcskcreate()

When tipcskcreate() fails to insert the new socket (tipcskinsert() returns non-zero), its error path frees the sk with skfree() but leaves sock->sk pointing at the freed object:

if (tipcskinsert(tsk)) { skfree(sk); prwarn("Socket create failed; port number exhausted\n"); return -EINVAL; }

This is harmless for plain socket(): the syscall layer clears sock->ops before releasing, so tipcrelease() is never called. It is not harmless on the accept() path. tipcaccept() creates the pre-allocated child socket with tipcskcreate(net, newsock, 0, kern); on failure it leaves newsock->sk dangling and newsock->ops non-NULL, and doaccept() then fput()s the new file, so sockrelease() -> tipcrelease() runs locksock(newsock->sk) on the freed sk -- a use-after-free write of the sklock spinlock.

tipcrelease() already guards this exact "failed accept() releases a pre-allocated child" case with "if (sk == NULL) return 0;", but the guard is bypassed because tipcskcreate() left sock->sk non-NULL (dangling) rather than NULL.

Clear sock->sk on the failed-insert path so the existing tipcrelease() NULL check fires and the use-after-free is avoided.

The tipcskinsert() failure is reached when the per-netns socket rhashtable hits its maxsize (tskrhtparams.maxsize = 1048576, ~2M elements) -- i.e. once a netns holds ~2M TIPC sockets every insert returns -E2BIG.

BUG: KASAN: slab-use-after-free in locksocknested (net/core/sock.c:3839) Write of size 8 at addr ffff8880047cdc38 by task init/1 locksocknested (net/core/sock.c:3839) tipcrelease (net/tipc/socket.c:638) sockrelease (net/socket.c:710) sockclose (net/socket.c:1501) fput (fs/filetable.c:512) Allocated by task 1: skalloc (net/core/sock.c:2308) tipcskcreate (net/tipc/socket.c:487) tipcaccept (net/tipc/socket.c:2744) doaccept (net/socket.c:2034) Freed by task 1: skdestruct (net/core/sock.c:2391) tipcskcreate (net/tipc/socket.c:504) tipcaccept (net/tipc/socket.c:2744) doaccept (net/socket.c:2034)

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

sctp: validate stream count in sctpprocessstrresetinreq()

When processing a RESETINREQUEST from a peer, sctpprocessstrresetinreq() derives the stream count from the parameter length but does not check whether the resulting RESETOUTREQUEST would exceed SCTPMAXCHUNKLEN.

The OUT request header (sctpstrresetoutreq, 16 bytes) is 8 bytes larger than the IN request header (sctpstrresetinreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a u16 overflow in sctpmakestrresetreq() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG:

net/core/skbuff.c:207 skbpanic net/core/skbuff.c:2625 skbput net/sctp/smmakechunk.c:1535 sctpaddtochunk net/sctp/smmakechunk.c:3695 sctpmakestrresetreq net/sctp/stream.c:655 sctpprocessstrresetinreq

The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer.

Reject peer IN requests whose corresponding OUT request would exceed SCTPMAXCHUNKLEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer.

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

net: slip: serialize receive against buffer reallocation

slreallocbufs() replaces rbuff and updates buffsize while holding sl->lock. slipreceivebuf() reads those fields and writes through rbuff without holding the lock.

An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed.

Serialize receive processing with slreallocbufs() by holding sl->lock while consuming each receive batch.

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

sctp: auth: verify auth requirement when authchunk is NULL

sctpauthchunkverify() returns true unconditionally when chunk->authchunk is NULL, silently skipping authentication. This is incorrect when:

1. skbclone() failed in the BH receive path, leaving authchunk NULL. In sctpendpointbhrcv() asoc is NULL for new connections, so the early sctpauthrecvcid() check cannot catch this.

2. No AUTH chunk precedes COOKIE-ECHO, so skbclone() is never called and authchunk remains NULL.

Fix by checking sctpauthrecvcid() when authchunk is NULL: if authentication is required, return false to drop the chunk; otherwise continue normally.

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

ALSA: timer: Fix UAF at sndtimeruserparams()

At releasing a timer object, e.g. when a userspace timer (CONFIGSNDUTIMER) gets closed and sndtimerfree() is called, it tries to detach the timer instances and release the resources. However, it's still possible that other in-flight tasks are holding the timer instance where the to-be-deleted timer object is associated, and this may lead to racy accesses.

Fortunately, most of ioctls dealing with the timer instance list already have the protection with registermutex, and this also avoids such races. But, SNDRVTIMERIOCTLPARAMS isn't protected, hence the concurrent ioctl may lead to use-after-free.

This patch just adds the guard with registermutex to protect sndtimeruserparams() for covering the code path as a quick workaround. It's no hot-path but rather a rarely issued ioctl, so the performance penalty doesn't matter.

Improper handling of overlap between protected memory ranges for some Intel(R) Xeon(R) 6 processors when using Intel(R) TDX within SMM may allow an escalation of privilege. SMM adversary with a privileged user combined with a high complexity attack may enable escalation of privilege. This result may potentially occur via local access when attack requirements are present with special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (high), integrity (high) and availability (none) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts.

Improper handling of values for some Intel(R) Processors within Ring 0: Kernel, Hypervisor and Bare Metal OS may allow an escalation of privilege. Authorized adversary with a privileged user combined with a high complexity attack may enable escalation of privilege. This result may potentially occur via local access when attack requirements are present with special internal knowledge and require no user interaction. The potential vulnerability may impact the confidentiality (low), integrity (low) and availability (none) of the vulnerable system, resulting in subsequent system confidentiality (high), integrity (high) and availability (none) impacts.

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

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

scsi: libiscsitcp: Bound SCSI Response data segment to the connection buffer

iscsitcphdrdissect() receives the data segment of several PDU types into the fixed-size conn->data buffer, which is allocated for ISCSIDEFMAXRECVSEGLEN (8192) bytes. For the LOGINRSP, TEXTRSP, REJECT and ASYNCEVENT opcodes the dissect path already rejects a PDU whose DataSegmentLength exceeds that buffer.

The SCSI Command Response (ISCSIOPSCSICMDRSP) path also copies its data segment (sense/response data) into conn->data via iscsitcpdatarecvprep(), but it does so without the same check. The only upstream bound on in.datalen is conn->maxrecvdlength, the initiator's advertised MaxRecvDataSegmentLength, which is commonly negotiated well above 8192 (open-iscsi defaults to 262144). A target that returns a SCSI Response with a DataSegmentLength between 8193 and maxrecvdlength therefore overflows the 8192-byte conn->data buffer.

Once the same bound applies, ISCSIOPSCSICMDRSP is handled exactly like those responses: bound the data segment, receive it into conn->data when present, and otherwise complete the PDU with no data. Fold the opcode into that case group rather than duplicating the check.

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

net: bridge: stop fast-leave after deleting a port group

brmulticastleavegroup() iterates mp->ports with pp = &p->next in its fast-leave path. After brmulticastdelpg() removes p, continuing the loop advances pp through the deleted entry.

If multicast-to-unicast was enabled, the bridge can hold multiple port groups for the same port and group with different source MAC addresses. Once multicast-to-unicast is disabled, brportgroupequal() matches those entries by port only. A fast leave can then delete one entry and continue from its stale next pointer, leaving mp->ports pointing at a deleted port group.

Fast leave only needs to remove one matching port group. Break after brmulticastdelpg() so the loop stops before dereferencing the removed entry.

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

security/keys: fix missed RCU read section on lookup

Nicholas Carlini reports that the keyring code calls assocarrayfind() in findkeytoupdate() without holding the RCU read lock, while the assocarraygc() code really is designed around removing the node from the tree and then freeing it after an RCU grace-period.

The regular key handling doesn't see this because holding the keyring semaphore hides any lifetime issues, but the persistent key handling uses a different model.

Instead of extending the keyring locking, just do the simple RCU locking that the assocarray was designed for.

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

sctp: diag: reject stale associations in dumpone path

The SCTP exact sockdiag lookup can hold a transport reference, block on locksock(sk), and then resume after sctpassociationfree() has marked the association dead and freed its bind address list.

When that happens, inetassocattrsize() and inetdiagmsgsctpasocfill() can still dereference association state that is no longer valid for reporting. In particular, inetdiagmsgsctpasocfill() may read an empty bind-address list as a real sctpsockaddrentry and trigger an out-of-bounds read from unrelated association memory.

Reject the association after taking the socket lock if it has been reaped or detached from the endpoint, and report the lookup as stale. This keeps the exact dump-one path from formatting torn association state.