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

net/rose: fix NULL pointer dereference in rose_transmit_link on reconnect

syzkaller reported a bug [1], and the reproducer is available at [2].

ROSE sockets use four sk->sk_state values: TCP_CLOSE, TCP_LISTEN,
TCP_SYN_SENT, and TCP_ESTABLISHED. rose_connect() already rejects
calls for TCP_ESTABLISHED (-EISCONN) and TCP_CLOSE with SS_CONNECTING
(-ECONNREFUSED), but lacks a check for TCP_SYN_SENT.

When rose_connect() is called a second time while the first connection
attempt is still in progress (TCP_SYN_SENT), it overwrites
rose->neighbour via rose_get_neigh(). If that returns NULL, the socket
is left with rose->state == ROSE_STATE_1 but rose->neighbour == NULL.
When the socket is subsequently closed, rose_release() sees
ROSE_STATE_1 and calls rose_write_internal() ->
rose_transmit_link(skb, NULL), causing a NULL pointer dereference.

Per connect(2), a second connect() while a connection is already in
progress should return -EALREADY. Add this missing check for
TCP_SYN_SENT to complete the state validation in rose_connect().

[1] https://syzkaller.appspot.com/bug?extid=d00f90e0af54102fb271
[2] https://gist.github.com/mrpre/9e6779e0d13e2c66779b1653fef80516
Published: 2026-04-03
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: Denial of Service via Null Pointer Dereference
Action: Immediate Patch
AI Analysis

Impact

When a ROSE socket attempts to connect twice before the first attempt completes, the kernel overwrites the socket’s neighbour pointer with NULL. Closing the socket thereafter triggers a function that dereferences this NULL pointer, causing a kernel panic. The crash results in a denial of service; there is no evidence that an attacker can gain code execution or elevated privileges.

Affected Systems

All Linux kernel versions that include the legacy ROSE networking module are affected. The vendor list indicates the Linux kernel itself, and no specific version range is provided, so any kernel still using the old rose_connect and rose_transmit_link logic is vulnerable.

Risk and Exploitability

The EPSS score is below 1 % and the vulnerability is not listed in the CISA KEV catalog, suggesting a low probability of widespread exploitation. An attacker would need local or sufficient privileged access to create a ROSE socket and trigger the double‑connect condition. The impact is a local denial of service; the element does not allow remote code execution or privilege escalation.

Generated by OpenCVE AI on April 7, 2026 at 10:09 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply the latest Linux kernel update that includes the CVE‑2026‑23460 fix, available in the kernel commit c2ab74c12932e52cfa1e7e4582d42b0c8bec96c7.
  • If an immediate kernel upgrade is not feasible, obtain the patch from the referenced commit and rebuild the kernel after applying it.
  • Verify the kernel’s ROSE module is disabled or prevented from loading in environments where it is unnecessary to reduce attack surface.

Generated by OpenCVE AI on April 7, 2026 at 10:09 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 18 Apr 2026 09:15:00 +0000


Tue, 07 Apr 2026 08:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-476

Sat, 04 Apr 2026 01:15:00 +0000


Fri, 03 Apr 2026 21:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-476

Fri, 03 Apr 2026 16:30:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: net/rose: fix NULL pointer dereference in rose_transmit_link on reconnect syzkaller reported a bug [1], and the reproducer is available at [2]. ROSE sockets use four sk->sk_state values: TCP_CLOSE, TCP_LISTEN, TCP_SYN_SENT, and TCP_ESTABLISHED. rose_connect() already rejects calls for TCP_ESTABLISHED (-EISCONN) and TCP_CLOSE with SS_CONNECTING (-ECONNREFUSED), but lacks a check for TCP_SYN_SENT. When rose_connect() is called a second time while the first connection attempt is still in progress (TCP_SYN_SENT), it overwrites rose->neighbour via rose_get_neigh(). If that returns NULL, the socket is left with rose->state == ROSE_STATE_1 but rose->neighbour == NULL. When the socket is subsequently closed, rose_release() sees ROSE_STATE_1 and calls rose_write_internal() -> rose_transmit_link(skb, NULL), causing a NULL pointer dereference. Per connect(2), a second connect() while a connection is already in progress should return -EALREADY. Add this missing check for TCP_SYN_SENT to complete the state validation in rose_connect(). [1] https://syzkaller.appspot.com/bug?extid=d00f90e0af54102fb271 [2] https://gist.github.com/mrpre/9e6779e0d13e2c66779b1653fef80516
Title net/rose: fix NULL pointer dereference in rose_transmit_link on reconnect
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-04-18T08:59:09.559Z

Reserved: 2026-01-13T15:37:46.021Z

Link: CVE-2026-23460

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-04-03T16:16:32.963

Modified: 2026-04-18T09:16:28.687

Link: CVE-2026-23460

cve-icon Redhat

Severity :

Publid Date: 2026-04-03T00:00:00Z

Links: CVE-2026-23460 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-04-08T19:53:46Z

Weaknesses