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.
In the Linux kernel, the following vulnerability has been resolved:
ALSA: aloop: Fix racy access at PCM trigger
The PCM trigger callback of aloop driver tries to check the PCM state and stop the stream of the tied substream in the corresponding cable. Since both check and stop operations are performed outside the cable lock, this may result in UAF when a program attempts to trigger frequently while opening/closing the tied stream, as spotted by fuzzers.
For addressing the UAF, this patch changes two things: - It covers the most of code in loopbackcheckformat() with cable->lock spinlock, and add the proper NULL checks. This avoids already some racy accesses. - In addition, now we try to check the state of the capture PCM stream that may be stopped in this function, which was the major pain point leading to UAF.
In the Linux kernel, the following vulnerability has been resolved:
bonding: fix use-after-free due to enslave fail after slave array update
Fix a use-after-free which happens due to enslave failure after the new slave has been added to the array. Since the new slave can be used for Tx immediately, we can use it after it has been freed by the enslave error cleanup path which frees the allocated slave memory. Slave update array is supposed to be called last when further enslave failures are not expected. Move it after xdp setup to avoid any problems.
It is very easy to reproduce the problem with a simple xdppass prog: ip l add bond1 type bond mode balance-xor ip l set bond1 up ip l set dev bond1 xdp object xdppass.o sec xdppass ip l add dumdum type dummy
Then run in parallel: while :; do ip l set dumdum master bond1 1/dev/null 2&1; done; mausezahn bond1 -a own -b rand -A rand -B 1.1.1.1 -c 0 -t tcp "dp=1-1023, flags=syn"
The crash happens almost immediately: [ 605.602850] Oops: general protection fault, probably for non-canonical address 0xe0e6fc2460000137: 0000 [#1] SMP KASAN NOPTI [ 605.602916] KASAN: maybe wild-memory-access in range [0x07380123000009b8-0x07380123000009bf] [ 605.602946] CPU: 0 UID: 0 PID: 2445 Comm: mausezahn Kdump: loaded Tainted: G B 6.19.0-rc6+ #21 PREEMPT(voluntary) [ 605.602979] Tainted: [B]=BADPAGE [ 605.602998] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 605.603032] RIP: 0010:netdevcorepicktx+0xcd/0x210 [ 605.603063] Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 3e 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 6b 08 49 8d 7d 30 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 25 01 00 00 49 8b 45 30 4c 89 e2 48 89 ee 48 89 [ 605.603111] RSP: 0018:ffff88817b9af348 EFLAGS: 00010213 [ 605.603145] RAX: dffffc0000000000 RBX: ffff88817d28b420 RCX: 0000000000000000 [ 605.603172] RDX: 00e7002460000137 RSI: 0000000000000008 RDI: 07380123000009be [ 605.603199] RBP: ffff88817b541a00 R08: 0000000000000001 R09: fffffbfff3ed8c0c [ 605.603226] R10: ffffffff9f6c6067 R11: 0000000000000001 R12: 0000000000000000 [ 605.603253] R13: 073801230000098e R14: ffff88817d28b448 R15: ffff88817b541a84 [ 605.603286] FS: 00007f6570ef67c0(0000) GS:ffff888221dfa000(0000) knlGS:0000000000000000 [ 605.603319] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 605.603343] CR2: 00007f65712fae40 CR3: 000000011371b000 CR4: 0000000000350ef0 [ 605.603373] Call Trace: [ 605.603392] TASK [ 605.603410] devqueuexmit+0x448/0x32a0 [ 605.603434] ? pfxvprintkemit+0x10/0x10 [ 605.603461] ? pfxvprintkemit+0x10/0x10 [ 605.603484] ? pfxdevqueuexmit+0x10/0x10 [ 605.603507] ? bondstartxmit+0xbfb/0xc20 [bonding] [ 605.603546] ? printk+0xcb/0x100 [ 605.603566] ? pfxprintk+0x10/0x10 [ 605.603589] ? bondstartxmit+0xbfb/0xc20 [bonding] [ 605.603627] ? addtaint+0x5e/0x70 [ 605.603648] ? addtaint+0x2a/0x70 [ 605.603670] ? endreport.cold+0x51/0x75 [ 605.603693] ? bondstartxmit+0xbfb/0xc20 [bonding] [ 605.603731] bondstartxmit+0x623/0xc20 [bonding]
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.
LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. Prior to 1.6.55, an out-of-bounds read vulnerability exists in the pngsetquantize() API function. When the function is called with no histogram and the number of colors in the palette is more than twice the maximum supported by the user's display, certain palettes will cause the function to enter into an infinite loop that reads past the end of an internal heap-allocated buffer. The images that trigger this vulnerability are valid per the PNG specification. This vulnerability is fixed in 1.6.55.
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