CVE-2026-98600 Affecting linux-6.12 package, versions <6.12.113-1~deb12u1


Severity

Recommended
low

Based on default assessment until relevant scores are available.

Threat Intelligence

EPSS
0.18% (8th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-DEBIAN12-LINUX612-21434868
  • published23 Oct 2026
  • disclosed18 Oct 2026

Introduced: 18 Oct 2026

NewCVE-2026-98600  (opens in a new tab)

How to fix?

Upgrade Debian:12 linux-6.12 to version 6.12.113-1~deb12u1 or higher.

NVD Description

Note: Versions mentioned in the description apply only to the upstream linux-6.12 package and not the linux-6.12 package as distributed by Debian. See How to fix? for Debian:12 relevant fixed versions and status.

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

Bluetooth: RFCOMM: Reject short EA=0 frames in rfcomm_recv_frame()

While rfcomm_recv_frame() verifies that skb->len is at least sizeof(*hdr) + 1 (4 bytes: 3-byte header + 1-byte FCS), an RFCOMM frame with an extended 2-byte length field (!__test_ea(hdr->len)) has a 4-byte header plus a 1-byte FCS (5 bytes minimum, sizeof(*hdr) + 2).

When a 4-byte RFCOMM frame with EA == 0 arrives:

  1. The initial skb->len < sizeof(*hdr) + 1 check passes (4 < 4 is false).
  2. Trimming the FCS byte decrements skb->len to 3.
  3. If __check_fcs() succeeds, skb_pull(skb, 4) fails (4 > 3) and returns NULL without advancing skb->data.
  4. Because the return value of skb_pull() is ignored, the un-pulled 3-byte struct rfcomm_hdr remains at skb->data and is either queued as application payload via rfcomm_recv_data() or parsed as a multiplexer control command via rfcomm_recv_mcc() on DLCI 0.

Fix this by extending the length check in rfcomm_recv_frame() to also require skb->len >= sizeof(*hdr) + 2 when !__test_ea(hdr->len).

CVSS Base Scores

version 3.1