CVE-2024-42271: net/iucv: fix use after free in iucv_sock_close()
In the Linux kernel, the following vulnerability has been resolved:
net/iucv: fix use after free in iucv_sock_close()
iucv_sever_path() is called from process context and from bh context.
iucv->path is used as indicator whether somebody else is taking care of
severing the path (or it is already removed / never existed).
This needs to be done with atomic compare and swap, otherwise there is a
small window where iucv_sock_close() will try to work with a path that has
already been severed and freed by iucv_callback_connrej() called by
iucv_tasklet_fn().
Example:
[452744.123844] Call Trace:
[452744.123845] ([<0000001e87f03880>] 0x1e87f03880)
[452744.123966] [<00000000d593001e>] iucv_path_sever+0x96/0x138
[452744.124330] [<000003ff801ddbca>] iucv_sever_path+0xc2/0xd0 [af_iucv]
[452744.124336] [<000003ff801e01b6>] iucv_sock_close+0xa6/0x310 [af_iucv]
[452744.124341] [<000003ff801e08cc>] iucv_sock_release+0x3c/0xd0 [af_iucv]
[452744.124345] [<00000000d574794e>] __sock_release+0x5e/0xe8
[452744.124815] [<00000000d5747a0c>] sock_close+0x34/0x48
[452744.124820] [<00000000d5421642>] __fput+0xba/0x268
[452744.124826] [<00000000d51b382c>] task_work_run+0xbc/0xf0
[452744.124832] [<00000000d5145710>] do_notify_resume+0x88/0x90
[452744.124841] [<00000000d5978096>] system_call+0xe2/0x2c8
[452744.125319] Last Breaking-Event-Address:
[452744.125321] [<00000000d5930018>] iucv_path_sever+0x90/0x138
[452744.125324]
[452744.125325] Kernel panic - not syncing: Fatal exception in interrupt
Note that bh_lock_sock() is not serializing the tasklet context against
process context, because the check for sock_owned_by_user() and
corresponding handling is missing.
Ideas for a future clean-up patch:
A) Correct usage of bh_lock_sock() in tasklet context, as described in
Re-enqueue, if needed. This may require adding return values to the
tasklet functions and thus changes to all users of iucv.
B) Change iucv tasklet into worker and use only lock_sock() in af_iucv.
Security readout for executives and security teams
Plain-English summary
A race in the Linux kernel’s IUCV socket shutdown handling can access an already-freed path object. The supplied trace shows this causing a kernel panic. CVSS 3.1 rates potential confidentiality, integrity, and availability impacts as high, but exploitation requires local, low-privileged access and no user interaction.
Executive priority
Prioritize affected multi-user or otherwise locally accessible systems because successful triggering occurs in kernel context and may crash the host. Apply normal high-severity kernel patching urgency, accelerated for systems using IUCV. Avoid emergency internet-edge treatment unless separate evidence shows remote reachability or exploitation.
Technical view
Process-context socket closure can race with a bottom-half tasklet rejecting a connection. Both may attempt to sever the same IUCV path because path ownership was not claimed atomically. The callback can sever and free the path before iucv_sock_close() uses it, producing a use-after-free. Stable-kernel commits implement the correction.
Likely exposure
Exposure is most likely on Linux systems running an affected kernel where AF_IUCV functionality is present and reachable by a local low-privileged user. The supplied version data is not sufficiently clear to determine every fixed release reliably. This is a local-attack issue, not evidence of direct internet exposure.
Exploitation context
The supplied CVSS vector is local, low complexity, low privileges, and requires no user interaction. A kernel panic is documented. The bundle marks this CVE as absent from KEV and provides no evidence of active exploitation, public weaponization, or a demonstrated path beyond the reported use-after-free.
Researcher notes
The core defect is a race over iucv->path between process and tasklet contexts; bh_lock_sock() did not provide the expected serialization. Atomic compare-and-swap is identified as necessary. The source discusses broader locking or worker redesign only as future cleanup, not as required remediation. Exact affected-to-fixed release mapping remains unclear from the bundle.
Mitigation direction
Update to a vendor-supported kernel release containing the applicable stable fix.
Check Linux distribution advisories to map the fix to packaged kernel versions.
Restrict unnecessary local access while patching is pending.
Review whether AF_IUCV functionality is required on affected systems.
Validation and detection
Record each system’s running kernel version and distribution package revision.
Compare package revisions with vendor advisories and the referenced stable commits.
Confirm whether AF_IUCV is present or used in the deployed configuration.
After updating, verify the fixed kernel is running following reboot.
Monitor kernel logs for IUCV faults, use-after-free reports, or unexpected panics.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-42271 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.