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

can: j1939: j1939sessionnew(): fix skb reference counting

Since j1939sessionskbqueue() does an extra skbget() for each new skb, do the same for the initial one in j1939sessionnew() to avoid refcount underflow.

[mkl: clean up commit message]

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

nfsd: clear aclaccess/acldefault after releasing them

If getting acldefault fails, aclaccess and acldefault will be released simultaneously. However, aclaccess will still retain a pointer pointing to the released posixacl, which will trigger a WARNING in nfs3svcreleasegetacl like this:

------------[ cut here ]------------ refcountt: underflow; use-after-free. WARNING: CPU: 26 PID: 3199 at lib/refcount.c:28 refcountwarnsaturate+0xb5/0x170 Modules linked in: CPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted 6.12.0-rc6-00079-g04ae226af01f-dirty #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcountwarnsaturate+0xb5/0x170 Code: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75 e4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff <0f> 0b eb cd 0f b6 1d 8a3 RSP: 0018:ffffc90008637cd8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fde RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380 RBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56 R10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001 R13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0 FS: 0000000000000000(0000) GS:ffff88871ed00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? refcountwarnsaturate+0xb5/0x170 ? warn+0xa5/0x140 ? refcountwarnsaturate+0xb5/0x170 ? reportbug+0x1b1/0x1e0 ? handlebug+0x53/0xa0 ? excinvalidop+0x17/0x40 ? asmexcinvalidop+0x1a/0x20 ? ticknohztickstopped+0x1e/0x40 ? refcountwarnsaturate+0xb5/0x170 ? refcountwarnsaturate+0xb5/0x170 nfs3svcreleasegetacl+0xc9/0xe0 svcprocesscommon+0x5db/0xb60 ? pfxsvcprocesscommon+0x10/0x10 ? rcureadunlock+0x69/0xa0 ? pfxnfsddispatch+0x10/0x10 ? svcxprtreceived+0xa1/0x120 ? xdrinitdecode+0x11d/0x190 svcprocess+0x2a7/0x330 svchandlexprt+0x69d/0x940 svcrecv+0x180/0x2d0 nfsd+0x168/0x200 ? pfxnfsd+0x10/0x10 kthread+0x1a2/0x1e0 ? kthread+0xf4/0x1e0 ? pfxkthread+0x10/0x10 retfromfork+0x34/0x60 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK> Kernel panic - not syncing: kernel: paniconwarn set ...

Clear aclaccess/acldefault after posixaclrelease is called to prevent UAF from being triggered.

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

RDMA/rxe: Fix the warning "rxecleanup+0x12c/0x170 [rdmarxe]"

The Call Trace is as below: " <TASK> ? showregs.cold+0x1a/0x1f ? rxecleanup+0x12c/0x170 [rdmarxe] ? warn+0x84/0xd0 ? rxecleanup+0x12c/0x170 [rdmarxe] ? reportbug+0x105/0x180 ? handlebug+0x46/0x80 ? excinvalidop+0x19/0x70 ? asmexcinvalidop+0x1b/0x20 ? rxecleanup+0x12c/0x170 [rdmarxe] ? rxecleanup+0x124/0x170 [rdmarxe] rxedestroyqp.cold+0x24/0x29 [rdmarxe] ibdestroyqpuser+0x118/0x190 [ibcore] rdmadestroyqp.cold+0x43/0x5e [rdmacm] rtrscqqpdestroy.cold+0x1d/0x2b [rtrscore] rtrssrvclosework.cold+0x1b/0x31 [rtrsserver] processonework+0x21d/0x3f0 workerthread+0x4a/0x3c0 ? processonework+0x3f0/0x3f0 kthread+0xf0/0x120 ? kthreadcompleteandexit+0x20/0x20 retfromfork+0x22/0x30 </TASK> " When too many rdma resources are allocated, rxe needs more time to handle these rdma resources. Sometimes with the current timeout, rxe can not release the rdma resources correctly.

Compared with other rdma drivers, a bigger timeout is used.

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

net: atlantic: fix fragment overflow handling in RX path

The atlantic driver can receive packets with more than MAXSKBFRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skbaddrxfragnetmem() leading to kernel panic.

The issue occurs because the driver doesn't check the total number of fragments before calling skbaddrxfrag(). When a packet requires more than MAXSKBFRAGS fragments, the fragment index exceeds the array bounds.

Fix by assuming there will be an extra frag if buff->len > AQCFGRXHDRSIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path.

This crash occurred in production with an Aquantia AQC113 10G NIC.

Stack trace from production environment: RIP: 0010:skbaddrxfragnetmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: <IRQ> aqringrxclean+0x175/0xe60 [atlantic] ? aqringrxclean+0x14d/0xe60 [atlantic] ? aqringtxclean+0xdf/0x190 [atlantic] ? kmemcachefree+0x348/0x450 ? aqvecpoll+0x81/0x1d0 [atlantic] ? napipoll+0x28/0x1c0 ? netrxaction+0x337/0x420

Changes in v4: - Add Fixes: tag to satisfy patch validation requirements.

Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQCFGRXHDRSIZE, then all fragments are accounted for.

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

svcrdma: use rcpageoff for memcpy byte offset

svcrdmacopyinlinerange added rccurpage (page index) to the page base instead of the byte offset rcpageoff. Use rcpageoff so copies land within the current page.

Found by ZeroPath (

IBM WebSphere Application Server - Liberty 17.0.0.3 through 26.0.0.2 IBM WebSphere Application Server Liberty could provide weaker than expected security when using the Security Utility when administering security settings.

IBM Security Verify Access under certain load conditions could allow an attacker to bypass authentication mechanisms and gain unauthorized access to the application.

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

nfsd: fix heap overflow in NFSv4.0 LOCK replay cache

The NFSv4.0 replay cache uses a fixed 112-byte inline buffer (rpibuf[NFSD4REPLAYISIZE]) to store encoded operation responses. This size was calculated based on OPEN responses and does not account for LOCK denied responses, which include the conflicting lock owner as a variable-length field up to 1024 bytes (NFS4OPAQUELIMIT).

When a LOCK operation is denied due to a conflict with an existing lock that has a large owner, nfsd4encodeoperation() copies the full encoded response into the undersized replay buffer via readbytesfromxdrbuf() with no bounds check. This results in a slab-out-of-bounds write of up to 944 bytes past the end of the buffer, corrupting adjacent heap memory.

This can be triggered remotely by an unauthenticated attacker with two cooperating NFSv4.0 clients: one sets a lock with a large owner string, then the other requests a conflicting lock to provoke the denial.

We could fix this by increasing NFSD4REPLAYISIZE to allow for a full opaque, but that would increase the size of every stateowner, when most lockowners are not that large.

Instead, fix this by checking the encoded response length against NFSD4REPLAYISIZE before copying into the replay buffer. If the response is too large, set rpbuflen to 0 to skip caching the replay payload. The status is still cached, and the client already received the correct response on the original 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 Reverse Proxy in certain configurations may provide weaker than expected cryptographic validation of user supplied data.

IBM Security Verify Access and IBM Security Verify Access Docker 10.0.0.0 through 10.0.9.0 and 11.0.0.0 through 11.0.1.0 could allow a locally authenticated user to escalate their privileges to root due to execution with more privileges than required.

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 escalate their privileges to root due to execution with unnecessary privileges than required.

Impact Summary Crypto-js PBKDF2 is 1,000 times weaker than originally specified in 1993, and [at least 1,300,000 times weaker than current industry standard][OWASP PBKDF2 Cheatsheet]. This is because it both (1) defaults to [SHA1][SHA1 wiki], a cryptographic hash algorithm considered insecure [since at least 2005][Cryptanalysis of SHA-1] and (2) defaults to [one single iteration][one iteration src], a 'strength' or 'difficulty' value specified at 1,000 when specified in 1993. PBKDF2 relies on iteration count as a countermeasure to [preimage][preimage attack] and [collision][collision attack] attacks.

Potential Impact:

1. If used to protect passwords, the impact is high. 2. If used to generate signatures, the impact is high.

Probability / risk analysis / attack enumeration:

1. [For at most $45,000][SHA1 is a Shambles], an attacker, given control of only the beginning of a crypto-js PBKDF2 input, can create a value which has identical cryptographic signature to any chosen known value. 4. Due to the [length extension attack] on SHA1, we can create a value that has identical signature to any unknown value, provided it is prefixed by a known value. It does not matter if PBKDF2 applies '[salt][cryptographic salt]' or '[pepper][cryptographic pepper]' or any other secret unknown to the attacker. It will still create an identical signature.

Update: PBKDF2 requires a pseudo-random function that takes two inputs, so HMAC-SHA1 is used rather than plain SHA1. HMAC is not affected by [length extension attacks][Length Extension attack]. However, by defaulting to a single PBKDF2 iteration, the hashes do not benefit from the extra computational complexity that PBKDF2 is supposed to provide. The resulting hashes therefore have little protection against an offline brute-force attack. [cryptographic salt]: https://en.wikipedia.org/wiki/Salt(cryptography) "Salt (cryptography), Wikipedia" [cryptographic pepper]: https://en.wikipedia.org/wiki/Pepper(cryptography) "Pepper (cryptography), Wikipedia" [SHA1 wiki]: https://en.wikipedia.org/wiki/SHA-1 "SHA-1, Wikipedia" [Cryptanalysis of SHA-1]: https://www.schneier.com/blog/archives/2005/02/cryptanalysiso.html "Cryptanalysis of SHA-1" [one iteration src]: https://github.com/brix/crypto-js/blob/1da3dabf93f0a0435c47627d6f171ad25f452012/src/pbkdf2.js#L22-L26 "crypto-js/src/pbkdf2.js lines 22-26" [collision attack]: https://en.wikipedia.org/wiki/Hashcollision "Collision Attack, Wikipedia" [preimage attack]: https://en.wikipedia.org/wiki/Preimageattack "Preimage Attack, Wikipedia" [SHA1 is a Shambles]: https://eprint.iacr.org/2020/014.pdf "SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and Application to the PGP Web of Trust, Gaëtan Leurent and Thomas Peyrin" [Length Extension attack]: https://en.wikipedia.org/wiki/Lengthextensionattack "Length extension attack, Wikipedia"

crypto-js has 10,642 public users [as displayed on NPM][crypto-js, NPM], today October 11th 2023. The number of transient dependents is likely several orders of magnitude higher.

A very rough GitHub search[ shows 432 files][GitHub search: affected files] cross GitHub using PBKDF2 in crypto-js in Typescript or JavaScript, but not specifying any number of iterations.

[OWASP PBKDF2 Cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/PasswordStorageCheatSheet.html#pbkdf2 "OWASP PBKDF2 Cheatsheet" [crypto-js, NPM]: https://www.npmjs.com/package/crypto-js "crypto-js on NPM" [GitHub search: affected files]: https://github.com/search?q=%22crypto-js%22+AND+pbkdf2+AND+%28lang%3AJavaScript+OR+lang%3ATypeScript%29++NOT+%22iterations%22&type=code&p=2 "GitHub search: crypto-js AND pbkdf2 AND (lang:JavaScript OR lang:TypeScript) NOT iterations"

Affected versions All versions are impacted. This code has been the same since crypto-js was first created.

Further Cryptanalysis

The issue here is especially egregious because the length extension attack makes useless any secret that might be appended to the plaintext before calculating its signature.

Consider a scheme in which a secret is created for a user's username, and that secret is used to protect e.g. their passwords. Let's say that password is 'fake-password', and their username is 'example-username'.

To encrypt the user password via symmetric encryption we might do encrypt(plaintext: 'fake-password', encryptionkey: cryptojs.pbkdf2(value: 'example username' + saltorpepper)). By this means, we would, in theory, create an encryptionkey that can be determined from the public username, but which requires the secret saltorpepper to generate. This is a common scheme for protecting passwords, as exemplified in bcrypt & scrypt. Because the encryption key is symmetric, we can use this derived key to also decrypt the ciphertext.

Because of the length extension issue, if the attacker obtains (via attack 1), a collision with 'example username', the attacker does not need to know saltorpepper to decrypt their account data, only their public username.

Description

PBKDF2 is a key-derivation is a key-derivation function that is used for two main purposes: (1) to stretch or squash a variable length password's entropy into a fixed size for consumption by another cryptographic operation and (2) to reduce the chance of downstream operations recovering the password input (for example, for password storage).

Unlike the modern webcrypto standard, crypto-js does not throw an error when a number of iterations is not specified, and defaults to one single iteration. In the year 2000, when PBKDF2 was originally specified, the minimum number of iterations suggested was set at 1,000. Today, [OWASP recommends 1,300,000][OWASP PBKDF2 Cheatsheet]:

https://github.com/brix/crypto-js/blob/4dcaa7afd08f48cd285463b8f9499cdb242605fa/src/pbkdf2.js#L22-L26

Patches No available patch. The package is not maintained.

Workarounds Consult the [OWASP PBKDF2 Cheatsheet]. Configure to use SHA256 with at least 250,000 iterations.

Coordinated disclosure This issue was simultaneously submitted to crypto-js and crypto-es on the 23rd of October 2023.

Caveats

This issue was found in a security review that was not scoped to crypto-js. This report is not an indication that crypto-js has undergone a formal security assessment by the author.

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

can: isotp: fix potential CAN frame reception race in isotprcv()

When receiving a CAN frame the current code logic does not consider concurrently receiving processes which do not show up in real world usage.

Ziyang Xuan writes:

The following syz problem is one of the scenarios. so->rx.len is changed by isotprcvff() during isotprcvcf(), so->rx.len equals 0 before allocskb() and equals 4096 after allocskb(). That will trigger skboverpanic() in skbput().

======================================================= CPU: 1 PID: 19 Comm: ksoftirqd/1 Not tainted 5.16.0-rc8-syzkaller #0 RIP: 0010:skbpanic+0x16c/0x16e net/core/skbuff.c:113 Call Trace: <TASK> skboverpanic net/core/skbuff.c:118 [inline] skbput.cold+0x24/0x24 net/core/skbuff.c:1990 isotprcvcf net/can/isotp.c:570 [inline] isotprcv+0xa38/0x1e30 net/can/isotp.c:668 deliver net/can/afcan.c:574 [inline] canrcvfilter+0x445/0x8d0 net/can/afcan.c:635 canreceive+0x31d/0x580 net/can/afcan.c:665 canrcv+0x120/0x1c0 net/can/afcan.c:696 netifreceiveskbonecore+0x114/0x180 net/core/dev.c:5465 netifreceiveskb+0x24/0x1b0 net/core/dev.c:5579

Therefore we make sure the state changes and data structures stay consistent at CAN frame reception time by adding a spinlock in isotprcv(). This fixes the issue reported by syzkaller but does not affect real world operation.

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

KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIGBROKEN

Hide KVM's ptmode module param behind CONFIGBROKEN, i.e. disable support for virtualizing Intel PT via guest/host mode unless BROKEN=y. There are myriad bugs in the implementation, some of which are fatal to the guest, and others which put the stability and health of the host at risk.

For guest fatalities, the most glaring issue is that KVM fails to ensure tracing is disabled, and stays disabled prior to VM-Enter, which is necessary as hardware disallows loading (the guest's) RTITCTL if tracing is enabled (enforced via a VMX consistency check). Per the SDM:

If the logical processor is operating with Intel PT enabled (if IA32RTITCTL.TraceEn = 1) at the time of VM entry, the "load IA32RTITCTL" VM-entry control must be 0.

On the host side, KVM doesn't validate the guest CPUID configuration provided by userspace, and even worse, uses the guest configuration to decide what MSRs to save/load at VM-Enter and VM-Exit. E.g. configuring guest CPUID to enumerate more address ranges than are supported in hardware will result in KVM trying to passthrough, save, and load non-existent MSRs, which generates a variety of WARNs, ToPA ERRORs in the host, a potential deadlock, etc.

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

wifi: ath12k: fix read pointer after free in ath12kmacassignviftovdev()

In ath12kmacassignviftovdev(), if arvif is created on a different radio, it gets deleted from that radio through a call to ath12kmacunassignlinkvif(). This action frees the arvif pointer. Subsequently, there is a check involving arvif, which will result in a read-after-free scenario.

Fix this by moving this check after arvif is again assigned via call to ath12kmacassignlinkvif().

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPLSILICONZ-1

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

wifi: mac80211: don't flush non-uploaded STAs

If STA state is pre-moved to AUTHORIZED (such as in IBSS scenarios) and insertion fails, the station is freed. In this case, the driver never knew about the station, so trying to flush it is unexpected and may crash.

Check if the sta was uploaded to the driver before and fix this.

HID: multitouch: fix slab out-of-bounds access in mtreportfixup()

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.

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.

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.

ibmvnic: Don't reference skb after sending to VIOS

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

sctp: avoid NULL dereference when chunk data buffer is missing

chunk->skb pointer is dereferenced in the if-block where it's supposed to be NULL only.

chunk->skb can only be NULL if chunk->headskb is not. Check for fraglist instead and do it just before replacing chunk->skb. We're sure that otherwise chunk->skb is non-NULL because of outer if() condition.

IBM Security Verify Access and IBM Security Verify Access Docker 10.0.0.0 through 10.0.9.0 and 11.0.0.0 through 11.0.1.0

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 could allow a locally authenticated user to execute malicious scripts from outside of its control sphere.

Impact ### This attack is very similar in concept and application to CVE-2025-31133, except that it attacks a similar vulnerability in a different target (namely, the bind-mount of /dev/pts/$n to /dev/console as configured for all containers that allocate a console).

In runc version 1.0.0-rc3 and later, due to insufficient checks when bind-mounting /dev/pts/$n to /dev/console inside the container, an attacker can trick runc into bind-mounting paths which would normally be made read-only or be masked onto a path that the attacker can write to. This happens after pivotroot(2), so this cannot be used to write to host files directly -- however, as with CVE-2025-31133, this can load to denial of service of the host or a container breakout by providing the attacker with a writable copy of /proc/sysrq-trigger or /proc/sys/kernel/corepattern (respectively).

The reason that the attacker can gain write access to these files is because the /dev/console bind-mount happens before maskedPaths and readonlyPaths are applied.

Additional Findings #### While investigating this issue, runc discovered some other theoretical issues that may or may not be exploitable, as well as taking the opportunity to fix some fairly well-known issues related to consoles.

Issue 1: Problematic Usage of os.Create ##### Go provides an os.Create function for creating files, which older code in runc (dating back to the original libcontainer from the early 2010s) had a tendency to use fairly liberally. os.Create implies OCREAT|OTRUNC but by design it does not apply ONOFOLLOW nor OEXCL, meaning if the target is swapped with a malicious symlink runc can be tricked into truncating host files (which can lead to denial of service attacks, among other concerns).

Runc conducted an audit of all os.Create usages in runc and found some suspicious usages related to device inodes, but based on runc's testing these were not exploitable in practice. Runc now has custom code lints to block any os.Create usage in runc, and plan to do a further audit of any other plain os. operation usage throughout runc after this advisory becomes public.

CVE-2024-45310 was a similar attack but without the OTRUNC component (which resulted in a "Low" severity) -- a similar attack being exploitable would've been much more severe.

Issue 2: Malicious /dev/pts/$n Inode Attacks (TIOCGPTPEER) ##### The (very) classic API for constructing consoles involves first opening /dev/ptmx for reading and writing. This allocates a new pseudo-terminal and the returned file descriptor is the "master" end (which is used by higher-level runtimes to do I/O with the container).

Traditionally, in order to get the "slave" end, you do ioctl(ptm, TIOCGPTN) to get the pseudo-terminal number and then open the file in /dev/pts/ with the corresponding base-10 decimal number of the number returned by TIOCGPTN. The naive way of doing this is vulnerable to very basic race attacks where /dev/pts/$n is replaced with a different pseudo-terminal or other malicious file.

In order to provide a mechanism to mitigate this risk, Aleksa Sarai (@cyphar from SUSE) implemented TIOCGPTPEER back in 2017 to provide a race-free way of doing the last TIOCGPTN step by opening the peer end of the pseudo-terminal directly. However, at the time it was believed to be too impractical to implement this protection in runc due to its no-monitor-process architecture (unlike runtimes like LXC which made use of TIOCGPTPEER almost immediately). While working on this advisory, runc found a way to make TIOCGPTN usage on pre-4.13 kernels still safe against race attacks and so have implemented both TIOCGPTPEER support as well as safe TIOCGPTN support as a fallback.

Another possible target of attack would be replacing /dev/ptmx or /dev/pts/ptmx with a different inode and tricking runc into trying to operate on it. This is very similar to the core issue in CVE-2025-31133 and had a similar solution.

Runc's analysis was that while this attack appears to be potentially problematic in theory, it seems unlikely to actually be exploitable due to how consoles are treated (runc tries to do several pseudo-terminal-specific ioctls and will error out if they fail -- which happens for most other file types). In principle you could imagine a DoS attack using a disconnected NFS handle but it seems impractical to exploit. However, runc felt it prudent to include a solution (and this also provides a safe mechanism to get the source mount for the /dev/console bind-mount issue at the beginning of this advisory).

Patches ### This advisory is being published as part of a set of three advisories:

CVE-2025-31133 CVE-2025-52881 CVE-2025-52565

The patches fixing this issue have accordingly been combined into a single patchset. The following patches from that patchset resolve the issues in this advisory:

db19bbed5348 ("internal/sys: add VerifyInode helper") ff94f9991bd3 (": switch to safer securejoin.Reopen") 531ef794e4ec ("console: use TIOCGPTPEER when allocating peer PTY") 398955bccb7f ("console: add fallback for pre-TIOCGPTPEER kernels") 9be1dbf4ac67 ("console: avoid trivial symlink attacks for /dev/console") de87203e625c ("console: verify /dev/pts/ptmx before use") 01de9d65dc72 ("rootfs: avoid using os.Create for new device inodes") aee7d3fe355d ("ci: add lint to forbid the usage of os.Create")

runc 1.2.8, 1.3.3, and 1.4.0-rc.3 have been released and all contain fixes for these issues. As per runc's new release model, runc 1.1.x and earlier are no longer supported and thus have not been patched.

[CVE-2025-31133]: https://github.com/opencontainers/runc/security/advisories/GHSA-9493-h29p-rfm2 [CVE-2025-52565]: https://github.com/opencontainers/runc/security/advisories/GHSA-qw9x-cqr3-wc7r [CVE-2025-52881]: https://github.com/opencontainers/runc/security/advisories/GHSA-cgrx-mc8f-2prm [RELEASES.md]: https://github.com/opencontainers/runc/blob/v1.4.0-rc.2/RELEASES.md

Mitigations ### Use containers with user namespaces (with the host root user not mapped into the container's user namespace). This will block most of the most serious aspects of these attacks, as the procfs files used for the container breakout use Unix DAC permissions and user namespaced users will not have access to the relevant files.

An attacker would still be able to bind-mount host paths into the container but if the host uids and gids mapped into the container do not overlap with ordinary users on the host (which is the generally recommended configuration) then the attacker would likely not be able to read or write to most sensitive host files (depending on the Unix DAC permissions of the host files). Note that this is still technically more privilege than an unprivileged user on the host -- because the bind-mount is done by a privileged process, the attacker would be able to get access to directories whose parents may have denied search access (i.e., they may be able to access paths inside a chmod 700 directory that would normally block them from resolving subpaths).

Runc would also like to take this opportunity to re-iterate that runc strongly recommend all users use user namespaced containers. They have proven to be one of the best security hardening mechanisms against container breakouts, and the kernel applies additional restrictions to user namespaced containers above and beyond the user remapping functionality provided. With the advent of id-mapped mounts (Linux 5.12), there is very little reason to not use user namespaces for most applications. Note that using user namespaces to configure your container does not mean you have to enable unprivileged user namespace creation inside the container -- most container runtimes apply a seccomp-bpf profile which blocks unshare(CLONENEWUSER) inside containers regardless of whether the container itself uses user namespaces.

Rootless containers can provide even more protection if your configuration can use them -- by having runc itself be an unprivileged process, in general you would expect the impact scope of a runc bug to be less severe as it would only have the privileges afforded to the host user which spawned runc.

For non-user namespaced containers, configure all containers you spawn to not permit processes to run with root privileges. In most cases this would require configuring the container to use a non-root user and enabling noNewPrivileges to disable any setuid or set-capability binaries. (Note that this is runc's general recommendation for a secure container setup -- it is very difficult, if not impossible, to run an untrusted program with root privileges safely.) If you need to use ping in your containers, there is a net.ipv4.pinggrouprange sysctl that can be used to allow unprivileged users to ping without requiring setuid or set-capability binaries. Do not run untrusted container images from unknown or unverified sources. The default containers-selinux SELinux policy mitigates this issue, as (unlike CVE-2025-31133) the /dev/console bind-mount does not get relabeled and so the container process cannot write to the bind-mounted procfs file by default.

Please note that CVE-2025-52881 allows an attacker to bypass LSM labels, and so this mitigation is not that helpful when considered in combination with CVE-2025-52881.

The default AppArmor policy used by Docker and Podman does not mitigate this issue (as access to /dev/console) is usually permitted. Users could create a custom profile that blocks access to /dev/console, but such a profile might break regular containers.

Please note that CVE-2025-52881 allows an attacker to bypass LSM labels, and so the mitigation provided with a custom profile is not that helpful when considered in combination with CVE-2025-52881.

[CVE-2025-31133]: https://github.com/opencontainers/runc/security/advisories/GHSA-9493-h29p-rfm2 [CVE-2025-52881]: https://github.com/opencontainers/runc/security/advisories/GHSA-cgrx-mc8f-2prm

Other Runtimes ### As this vulnerability boils down to a fairly easy-to-make logic bug,runc has provided information to other OCI (crun, youki) and non-OCI (LXC) container runtimes about this vulnerability.

Based on discussions with other runtimes, it seems that crun and youki may have similar security issues and will release a co-ordinated security release along with runc. LXC appears to also be vulnerable in some aspects, but [their security stance][lxc-security] is (understandably) that non-user-namespaced containers are fundamentally insecure by design.

[lxc-security]: https://linuxcontainers.org/lxc/security/

Credits ###

Thanks to Lei Wang (@ssst0n3 from Huawei) and Li Fubang (@lifubang from acmcoder.com, CIIC) for discovering and reporting the main /dev/console bind-mount vulnerability, as well as Aleksa Sarai (@cyphar from SUSE) for discovering Issues 1 and 2 and the original research into these classes of issues several years ago.

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

ipv6: use RCU in ip6xmit()

Use RCU in ip6xmit() in order to use dstdevrcu() to prevent possible UAF.

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:

ipv6: use RCU protection in ip6defaultadvmss()

ip6defaultadvmss() needs rcu protection to make sure the net structure it reads does not disappear.

A flaw was found in the libssh library in versions less than 0.11.2. An out-of-bounds read can be triggered in the sftphandle function due to an incorrect comparison check that permits the function to access memory beyond the valid handle list and to return an invalid pointer, which is used in further processing. This vulnerability allows an authenticated remote attacker to potentially read unintended memory regions, exposing sensitive information or affect service behavior.

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

ipv6: use RCU in ip6output()

Use RCU in ip6output() in order to use dstdevrcu() to prevent possible UAF.

We can remove rcureadlock()/rcureadunlock() pairs from ip6finishoutput2().