CVE-2026-68408 Affecting kernel-default-livepatch-devel package, versions <6.4.0-150700.53.81.1


Severity

Recommended
high

Based on SUSE Linux Enterprise Server security rating.

Threat Intelligence

EPSS
0.21% (10th 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-SLES157-KERNELDEFAULTLIVEPATCHDEVEL-19916784
  • published18 Sept 2026
  • disclosed17 Sept 2026

Introduced: 17 Sep 2026

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

How to fix?

Upgrade SLES:15.7 kernel-default-livepatch-devel to version 6.4.0-150700.53.81.1 or higher.

NVD Description

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

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

wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock

When a netlink socket that owns a PMSR session is closed, cfg80211_release_pmsr() clears the request's nl_portid and queues pmsr_free_wk to call cfg80211_pmsr_process_abort() asynchronously.

If the interface tears down concurrently, cfg80211_pmsr_wdev_down() is called under wiphy_lock and calls cancel_work_sync(&pmsr_free_wk) to wait for any running work. The work function acquires wiphy_lock via guard(wiphy) before calling process_abort.

This is a deadlock: wdev_down holds wiphy_lock and blocks inside cancel_work_sync(); pmsr_free_wk blocks trying to acquire that same wiphy_lock. Neither thread can proceed.

The same deadlock is reachable from cfg80211_leave_locked(), which calls cfg80211_pmsr_wdev_down() for all interface types under wiphy_lock.

Fix this by converting pmsr_free_wk from a plain work_struct to a wiphy_work. The wiphy_work dispatcher holds wiphy_lock when running work items, so the explicit guard(wiphy) in the work function is no longer needed. wiphy_work_cancel() can be called safely while holding wiphy_lock - since wiphy_lock prevents the work from running concurrently, wiphy_work_cancel() never blocks, eliminating the deadlock.

Remove the cancel_work_sync() for pmsr_free_wk from the NETDEV_GOING_DOWN handler. cfg80211_leave(), called unconditionally just before it, already cancels any pending work under wiphy_lock via wiphy_work_cancel() inside cfg80211_pmsr_wdev_down().

CVSS Base Scores

version 3.1