Look up another CVE · open CVE-2026-68141 in the interactive tracker
CVE-2026-68141
net/af_iucv: fix NULL deref in afiucv_hs_callback_syn()
Published 2026-08-10 (2 months ago) by the Linux kernel CNA. Subsystem net/iucv. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-68141 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4777-1 · 2026-09-08 · text | 6.1.187-1 | Update the kernel and reboot. DLA-4777-1 shipped the fix on 2026-09-08, in 6.1.187-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.101-1 | Update the kernel and reboot. Fixed in 6.12.101-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.6-1 | Update the kernel and reboot. Fixed in 7.1.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.6-1 | Update the kernel and reboot. Fixed in 7.1.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4745-1 · 2026-08-18 · text | 6.12.101-1~deb12u1 | Update the kernel and reboot. DLA-4745-1 shipped the fix on 2026-08-18, in 6.12.101-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC. If the allocation fails, nsk is NULL. The connection-refused path is entered when the listen state check fails, the accept backlog is full, or nsk is NULL. The code unconditionally calls iucv_sock_kill(nsk) in that path. iucv_sock_kill() does not accept a NULL socket pointer and immediately dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL, calling iucv_sock_kill(nsk) results in a NULL pointer dereference. Only call iucv_sock_kill() when a child socket was successfully allocated.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
net/iucv/af_iucv.c
- What this is
- S390 IUCV NETWORK LAYERMAINTAINERS section matched on net/iucv/ · linux-s390@vger.kernel.org · Supported
- Kernel module
- af_iucv
Check it on the machine
grep -wE 'CONFIG_AFIUCV|CONFIG_IUCV' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w af_iucvPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian does not build this code in 2 releases. It does build it in 3 releases, so the answer depends on which release the machine runs.
- bookwormn
- trixieMnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64, arm64/arm64, arm64/arm64-16k, arm64/cloud-arm64, arm64/rt/arm64, armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64
- forky, sidMnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt-amd64, arm64/arm64, arm64/arm64-16k, arm64/cloud-arm64, arm64/rt-arm64, armhf/armmp, armhf/armmp-lpae, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64
- bookworm · linux-6.12n
- n
- not enabled on any flavour - this release does not build the code
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_AFIUCV, CONFIG_IUCV
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-08-10 (2 months ago)source
- CVSS
- 7.5 high
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.52%, higher than 43.1% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- net/iucv
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 3.2 | 5.10.265 | 6a1eb5b46c19 |
| 3.2 | 5.15.216 | c0b6e2ae9061 |
| 3.2 | 6.1.183 | 07e21deb3664 |
| 3.2 | 6.6.148 | 8bb111f87ded |
| 3.2 | 6.12.101 | 46453b16f38e |
| 3.2 | 6.18.42 | 33736ff5e7c9 |
| 3.2 | 7.1.6 | 0e857185591f |
| 3.2 | 7.2 | 47a5116e56a6 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4777-1 | 2026-09-08 | bookworm 6.1.187-1 | tracker |
| DLA-4745-1 | 2026-08-18 | bookworm 6.12.101-1~deb12u1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:NAttack vector, network
- The flaw is reached from afiucv_hs_rcv() via dev_add_pack() when ETH_P_AF_IUCV SYN frames arrive on a HiperSockets netdev in netif RX softirq; a remote LPAR/guest on the IBM Z HiperSockets fabric can send these connection requests without local access.
- AC:LAttack complexity, low
- An attacker can repeatedly send SYN packets to a listening AF_IUCV service to pressure GFP_ATOMIC socket allocations until iucv_sock_alloc() fails and the broken connection-refused path runs; no timing race or victim-specific state beyond routine memory pressure is required.
- PR:NPrivileges required, none
- Exploitation requires only sending unauthenticated HiperSockets SYN traffic to a bound/listening AF_IUCV socket; the handshake path has no credential checks and the af_iucv code performs no capability or permission validation before reaching afiucv_hs_callback_syn().
- UI:NUser interaction, none
- Triggering the NULL dereference needs no action from an end user beyond a service already listening on HiperSockets; the attacker can initiate SYN packets remotely without victim interaction.
- S:UScope, unchanged
- Impact is a kernel NULL pointer dereference and likely oops/panic in the victim LPAR kernel; it does not cross a VM/host, IOMMU, or sandbox boundary to compromise a different security authority.
- C:NConfidentiality impact, none
- The failure is an immediate NULL pointer dereference in sock_flag() inside iucv_sock_kill(); there is no memory corruption, out-of-bounds access, or use-after-free that could yield information disclosure.
- I:NIntegrity impact, none
- The bug does not write attacker-controlled data or corrupt kernel structures; it only dereferences a NULL socket pointer during cleanup, so no integrity impact or code-execution primitive is created.
- A:HAvailability impact, high
- A NULL dereference in afiucv_hs_callback_syn() during softirq packet processing can cause a kernel oops or panic, denying all service on the affected IBM Z LPAR until reboot.