CVE-2025-68339 Affecting kernel-source package, versions <6.12.0-160000.9.1


Severity

Recommended
0.0
medium
0
10

Based on SUSE Linux Enterprise Server security rating.

Threat Intelligence

EPSS
0.04% (11th 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-SLES1600-KERNELSOURCE-15243647
  • published6 Feb 2026
  • disclosed2 Feb 2026

Introduced: 2 Feb 2026

CVE-2025-68339  (opens in a new tab)

How to fix?

Upgrade SLES:16.0.0 kernel-source to version 6.12.0-160000.9.1 or higher.

NVD Description

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

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

atm/fore200e: Fix possible data race in fore200e_open()

Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race.

The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos().

In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock.

This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs.

Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.

CVSS Base Scores

version 3.1