CVE-2024-35986 Affecting kernel-default-livepatch-devel package, versions <6.4.0-150600.23.7.3


Severity

Recommended
0.0
medium
0
10

Based on SUSE Linux Enterprise Server security rating.

Threat Intelligence

EPSS
0.05% (18th 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-SLES156-KERNELDEFAULTLIVEPATCHDEVEL-7718828
  • published20 Aug 2024
  • disclosed25 Jun 2024

Introduced: 25 Jun 2024

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

How to fix?

Upgrade SLES:15.6 kernel-default-livepatch-devel to version 6.4.0-150600.23.7.3 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.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 Scores

version 3.1