Use of Uninitialized Resource Affecting kernel-preempt package, versions <5.3.18-150300.59.167.1


Severity

Recommended
0.0
medium
0
10

Based on SUSE Linux Enterprise Server security rating.

Threat Intelligence

EPSS
0.04% (6th 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-SLES153-KERNELPREEMPT-7436116
  • published10 Jul 2024
  • disclosed9 Jul 2024

Introduced: 9 Jul 2024

CVE-2021-47583  (opens in a new tab)
CWE-908  (opens in a new tab)

How to fix?

Upgrade SLES:15.3 kernel-preempt to version 5.3.18-150300.59.167.1 or higher.

NVD Description

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

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

media: mxl111sf: change mutex_init() location

Syzbot reported, that mxl111sf_ctrl_msg() uses uninitialized mutex. The problem was in wrong mutex_init() location.

Previous mutex_init(&state->msg_lock) call was in ->init() function, but dvb_usbv2_init() has this order of calls:

dvb_usbv2_init()
  dvb_usbv2_adapter_init()
    dvb_usbv2_adapter_frontend_init()
      props-&gt;frontend_attach()

props-&gt;init()

Since mxl111sf_* devices call mxl111sf_ctrl_msg() in ->frontend_attach() internally we need to initialize state->msg_lock before frontend_attach(). To achieve it, ->probe() call added to all mxl111sf_* devices, which will simply initiaize mutex.

CVSS Scores

version 3.1