Out-of-bounds Write Affecting gfs2-kmp-default package, versions <5.14.21-150400.24.225.2


Severity

Recommended
0.0
high
0
10

Based on SUSE Linux Enterprise Server security rating.

Threat Intelligence

EPSS
0.14% (4th 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-SLES154-GFS2KMPDEFAULT-17615344
  • published27 Jun 2026
  • disclosed26 Jun 2026

Introduced: 26 Jun 2026

NewCVE-2026-46123  (opens in a new tab)
CWE-787  (opens in a new tab)

How to fix?

Upgrade SLES:15.4 gfs2-kmp-default to version 5.14.21-150400.24.225.2 or higher.

NVD Description

Note: Versions mentioned in the description apply only to the upstream gfs2-kmp-default package and not the gfs2-kmp-default package as distributed by SLES. See How to fix? for SLES:15.4 relevant fixed versions and status.

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

Bluetooth: virtio_bt: clamp rx length before skb_put

virtbt_rx_work() calls skb_put(skb, len) where len comes directly from virtqueue_get_buf() with no validation against the buffer we posted to the device. The RX skb is allocated in virtbt_add_inbuf() and exposed to virtio as exactly 1000 bytes via sg_init_one().

Checking len against skb_tailroom(skb) is not sufficient because alloc_skb() can leave more tailroom than the 1000 bytes actually handed to the device. A malicious or buggy backend can therefore report used.len between 1001 and skb_tailroom(skb), causing skb_put() to include uninitialized kernel heap bytes that were never written by the device.

The same path also accepts len == 0, in which case skb_put(skb, 0) leaves the skb empty but virtbt_rx_handle() still reads the pkt_type byte from skb->data, consuming uninitialized memory.

Define VIRTBT_RX_BUF_SIZE once and reuse it in alloc_skb() and sg_init_one(), and gate virtbt_rx_work() on that same constant so the bound checked matches the buffer actually exposed to the device. Reject used.len == 0 in the same gate so an empty completion can no longer reach virtbt_rx_handle().

Use bt_dev_err_ratelimited() because the length value comes from an untrusted backend that can otherwise flood the kernel log.

Same class of bug as commit c04db81cd028 ("net/9p: Fix buffer overflow in USB transport layer"), which hardened the USB 9p transport against unchecked device-reported length.

CVSS Base Scores

version 3.1