IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 and IBM Verify Identity Access Container 11.0 through 11.0.3 Reverse Proxy in certain configurations may provide weaker than expected cryptographic validation of user supplied data.
IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 and IBM Verify Identity Access Container 11.0 through 11.0.3 could allow a remote attacker to access sensitive information due to an inconsistent interpretation of an HTTP request by a reverse proxy.
IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 and IBM Verify Identity Access Container 11.0 through 11.0.3 could allow an administrator to execute additional commands they are not entitled to due to improper validation of user supplied input.
IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 and IBM Verify Identity Access Container 11.0 through 11.0.3 is vulnerable to a denial of service attack.
IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 and IBM Verify Identity Access Container 11.0 through 11.0.3 contains a input validation vulnerability in the management interface that allows already privileged attackers to execute additional operations by crafting a malicious HTTP request.
IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 and IBM Verify Identity Access Container 11.0 through 11.0.3 contains a format string injection vulnerability in the management interface that allows attackers to cause denial of service and information disclosure by crafting a malicious HTTP request.
IBM Security Verify Access 10.0 through 10.0.9.2 and IBM Verify Identity Access 11.0 through 11.0.3 and IBM Verify Identity Access Container 11.0 through 11.0.3 could allow an authenticated user to gain privileges of another user via a specially crafted request.
In Eclipse Parsson published Maven Central artifacts before version 1.1.8, the JSON parser did not enforce a default maximum on the number of characters consumed while parsing a single JSON document. Applications that parse attacker- controlled JSON can be forced to consume excessive CPU and memory by processing very large documents, including large arrays, objects, strings, numbers, whitespace, or nested structures, resulting in a denial of service. Eclipse Parsson 1.1.8 introduces a configurable maximum parsing limit with a default limit of 15 million parser-consumed characters.
There is no restriction on the amount of attachment headers that a message can contain when being deserialized by Apache CXF, which can lead to uncontrolled resource consumption or a denial of service attack. Users are recommended to upgrade to versions 4.2.2 or 4.1.7 or 3.6.12, which fix this issue by imposing a maximum default of 500 attachments per message.
crypto: algifaead - Revert to operating out-of-place
IBM Security Verify Access Container could allow an unauthenticated user to execute arbitrary commands as lower user privileges on the system due to improper validation of user supplied input.
IBM Verify Identity Access Container 11.0 through 11.0.2 and IBM Security Verify Access Container 10.0 through 10.0.9.1 and IBM Verify Identity Access 11.0 through 11.0.2 and IBM Security Verify Access 10.0 through 10.0.9.1 could allow a locally authenticated user to execute malicious scripts from outside of its control sphere.
IBM Verify Identity Access Container 11.0 through 11.0.2 and IBM Security Verify Access Container 10.0 through 10.0.9.1 and IBM Verify Identity Access 11.0 through 11.0.2 and IBM Security Verify Access 10.0 through 10.0.9.1 allows an attacker to contact internal authentication endpoints which are protected by the Reverse Proxy.
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Only allow actct to bind to clsact/ingress qdiscs and shared blocks
As Paolo said earlier [1]:
"Since the blamed commit below, classify can return TCACTCONSUMED while the current skb being held by the defragmentation engine. As reported by GangMin Kim, if such packet is that may cause a UaF when the defrag engine later on tries to tuch again such packet."
actct was never meant to be used in the egress path, however some users are attaching it to egress today [2]. Attempting to reach a middle ground, we noticed that, while most qdiscs are not handling TCACTCONSUMED, clsact/ingress qdiscs are. With that in mind, we address the issue by only allowing actct to bind to clsact/ingress qdiscs and shared blocks. That way it's still possible to attach actct to egress (albeit only with clsact).
[1]
In the Linux kernel, the following vulnerability has been resolved:
macvlan: fix error recovery in macvlancommonnewlink()
valis provided a nice repro to crash the kernel:
ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2
ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20
ping -c1 -I p1 1.2.3.4
He also gave a very detailed analysis:
<quote valis>
The issue is triggered when a new macvlan link is created with MACVLANMODESOURCE mode and MACVLANMACADDRADD (or MACVLANMACADDRSET) parameter, lower device already has a macvlan port and registernetdevice() called from macvlancommonnewlink() fails (e.g. because of the invalid link name).
In this case macvlanhashaddsource is called from macvlanchangesources() / macvlancommonnewlink():
This adds a reference to vlan to the port's vlansourcehash using macvlansourceentry.
vlan is a pointer to the priv data of the link that is being created.
When registernetdevice() fails, the error is returned from macvlannewlink() to rtnlnewlinkcreate():
if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = registernetdevice(dev); if (err < 0) { freenetdev(dev); goto out; }
and freenetdev() is called, causing a kvfree() on the struct netdevice that is still referenced in the source entry attached to the lower device's macvlan port.
Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlanforwardsource().
</quote valis>
With all that, my fix is to make sure we call macvlanflushsources() regardless of @create value whenever "goto destroymacvlanport;" path is taken.
Many thanks to valis for following up on this issue.
In the Linux kernel, the following vulnerability has been resolved:
net/sched: clsu32: use skbheaderpointercareful()
skbheaderpointer() does not fully validate negative @offset values.
Use skbheaderpointercareful() instead.
GangMin Kim provided a report and a repro fooling u32classify():
BUG: KASAN: slab-out-of-bounds in u32classify+0x1180/0x11b0 net/sched/clsu32.c:221
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: iscsi: Fix use-after-free in iscsitdecsessionusagecount()
In iscsitdecsessionusagecount(), the function calls complete() while holding the sess->sessionusagelock. Similar to the connection usage count logic, the waiter signaled by complete() (e.g., in the session release path) may wake up and free the iscsitsession structure immediately.
This creates a race condition where the current thread may attempt to execute spinunlockbh() on a session structure that has already been deallocated, resulting in a KASAN slab-use-after-free.
To resolve this, release the sessionusagelock before calling complete() to ensure all dereferences of the sess pointer are finished before the waiter is allowed to proceed with deallocation.
ALSA: aloop: Fix racy access at PCM trigger
bonding: fix use-after-free due to enslave fail after slave array update
In the Linux kernel, the following vulnerability has been resolved:
libceph: reset sparse-read state in osdfault()
When a fault occurs, the connection is abandoned, reestablished, and any pending operations are retried. The OSD client tracks the progress of a sparse-read reply using a separate state machine, largely independent of the messenger's state.
If a connection is lost mid-payload or the sparse-read state machine returns an error, the sparse-read state is not reset. The OSD client will then interpret the beginning of a new reply as the continuation of the old one. If this makes the sparse-read machinery enter a failure state, it may never recover, producing loops like:
libceph: [0] got 0 extents libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read
Therefore, reset the sparse-read state in osdfault(), ensuring retries start from a clean state.
In the Linux kernel, the following vulnerability has been resolved:
nvme-tcp: fix NULL pointer dereferences in nvmettcpbuildpduiovec
Commit efa56305908b ("nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length") added ttag bounds checking and dataoffset validation in nvmettcphandleh2cdatapdu(), but it did not validate whether the command's data structures (cmd->req.sg and cmd->iov) have been properly initialized before processing H2CDATA PDUs.
The nvmettcpbuildpduiovec() function dereferences these pointers without NULL checks. This can be triggered by sending H2CDATA PDU immediately after the ICREQ/ICRESP handshake, before sending a CONNECT command or NVMe write command.
Attack vectors that trigger NULL pointer dereferences: 1. H2CDATA PDU sent before CONNECT → both pointers NULL 2. H2CDATA PDU for READ command → cmd->req.sg allocated, cmd->iov NULL 3. H2CDATA PDU for uninitialized command slot → both pointers NULL
The fix validates both cmd->req.sg and cmd->iov before calling nvmettcpbuildpduiovec(). Both checks are required because: - Uninitialized commands: both NULL - READ commands: cmd->req.sg allocated, cmd->iov NULL - WRITE commands: both allocated
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrummr: Fix use-after-free when updating multicast route stats
Cited commit added a dedicated mutex (instead of RTNL) to protect the multicast route list, so that it will not change while the driver periodically traverses it in order to update the kernel about multicast route stats that were queried from the device.
One instance of list entry deletion (during route replace) was missed and it can result in a use-after-free [1].
Fix by acquiring the mutex before deleting the entry from the list and releasing it afterwards.
[1] BUG: KASAN: slab-use-after-free in mlxswspmrstatsupdate+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrummr.c:1006 [mlxswspectrum] Read of size 8 at addr ffff8881523c2fa8 by task kworker/2:5/22043
CPU: 2 UID: 0 PID: 22043 Comm: kworker/2:5 Not tainted 6.18.0-rc1-custom-g1a3d6d7cd014 #1 PREEMPT(full) Hardware name: Mellanox Technologies Ltd. MSN2010/SA002610, BIOS 5.6.5 08/24/2017 Workqueue: mlxswcore mlxswspmrstatsupdate [mlxswspectrum] Call Trace: <TASK> dumpstacklvl+0xba/0x110 printreport+0x174/0x4f5 kasanreport+0xdf/0x110 mlxswspmrstatsupdate+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrummr.c:1006 [mlxswspectrum] processonework+0x9cc/0x18e0 workerthread+0x5df/0xe40 kthread+0x3b8/0x730 retfromfork+0x3e9/0x560 retfromforkasm+0x1a/0x30 </TASK>
Allocated by task 29933: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 kasankmalloc+0x8f/0xa0 mlxswspmrrouteadd+0xd8/0x4770 [mlxswspectrum] mlxswsprouterfibmreventwork+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrumrouter.c:7965 [mlxswspectrum] processonework+0x9cc/0x18e0 workerthread+0x5df/0xe40 kthread+0x3b8/0x730 retfromfork+0x3e9/0x560 retfromforkasm+0x1a/0x30
Freed by task 29933: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3b/0x70 kasanslabfree+0x43/0x70 kfree+0x14e/0x700 mlxswspmrrouteadd+0x2dea/0x4770 drivers/net/ethernet/mellanox/mlxsw/spectrummr.c:444 [mlxswspectrum] mlxswsprouterfibmreventwork+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrumrouter.c:7965 [mlxswspectrum] processonework+0x9cc/0x18e0 workerthread+0x5df/0xe40 kthread+0x3b8/0x730 retfromfork+0x3e9/0x560 retfromforkasm+0x1a/0x30
LIBPNG has an integer truncation causing heap buffer over-read in pngimagewrite
LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From 1.6.51 to 1.6.53, there is a heap buffer over-read in the libpng simplified API function pngimagefinishread when processing interlaced 16-bit PNGs with 8-bit output format and non-minimal row stride. This is a regression introduced by the fix for CVE-2025-65018. This vulnerability is fixed in 1.6.54.
In GnuPG before 2.4.9, armorfilter in g10/armor.c has two increments of an index variable where one is intended, leading to an out-of-bounds write for crafted input. (For ExtendedLTS, 2.2.51 and later are fixed versions.)
In the Linux kernel, the following vulnerability has been resolved:
NFSv4/pNFS: Clear NFSINOLAYOUTCOMMIT in pnfsmarklayoutstateidinvalid
Fixes a crash when layout is null during this call stack:
writeinode - nfs4writeinode - pnfslayoutcommitinode
pnfssetlayoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFSINOLAYOUTCOMMIT otherwise we might attempt to reference a null layout.
In jose4j before 0.9.5, an attacker can cause a Denial-of-Service (DoS) condition by crafting a malicious JSON Web Encryption (JWE) token with an exceptionally high compression ratio. When this token is processed by the server, it results in significant memory allocation and processing time during decompression.
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hcisync: fix race in hcicmdsyncdequeueonce
hcicmdsyncdequeueonce() does lookup and then cancel the entry under two separate lock sections. Meanwhile, hcicmdsyncwork() can also delete the same entry, leading to double listdel() and "UAF".
Fix this by holding cmdsyncworklock across both lookup and cancel, so that the entry cannot be removed concurrently.
fbdev: Add bounds checking in bitputcs to fix vmalloc-out-of-bounds
ALSA: usb-audio: Fix potential overflow of PCM transfer buffer