Use After Free Affecting kernel-devel-azure package, versions <6.4.0-150600.8.5.4


Severity

Recommended
0.0
medium
0
10

Based on SUSE Linux Enterprise Server security rating.

Threat Intelligence

EPSS
0.05% (19th 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 Learn

Learn about Use After Free vulnerabilities in an interactive lesson.

Start learning
  • Snyk IDSNYK-SLES156-KERNELDEVELAZURE-7347577
  • published22 Jun 2024
  • disclosed21 Jun 2024

Introduced: 21 Jun 2024

CVE-2024-35986  (opens in a new tab)
CWE-416  (opens in a new tab)

How to fix?

Upgrade SLES:15.6 kernel-devel-azure to version 6.4.0-150600.8.5.4 or higher.

NVD Description

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

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

phy: ti: tusb1210: Resolve charger-det crash if charger psy is unregistered

The power_supply frame-work is not really designed for there to be long living in kernel references to power_supply devices.

Specifically unregistering a power_supply while some other code has a reference to it triggers a WARN in power_supply_unregister():

WARN_ON(atomic_dec_return(&amp;psy-&gt;use_cnt));

Folllowed by the power_supply still getting removed and the backing data freed anyway, leaving the tusb1210 charger-detect code with a dangling reference, resulting in a crash the next time tusb1210_get_online() is called.

Fix this by only holding the reference in tusb1210_get_online() freeing it at the end of the function. Note this still leaves a theoretical race window, but it avoids the issue when manually rmmod-ing the charger chip driver during development.

CVSS Base Scores

version 3.1