Improper Locking Affecting dlm-kmp-default package, versions <6.4.0-150600.23.25.1
Threat Intelligence
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 ID SNYK-SLES156-DLMKMPDEFAULT-8174815
- published 10 Oct 2024
- disclosed 9 Oct 2024
Introduced: 9 Oct 2024
New CVE-2024-44951 Open this link in a new tabHow to fix?
Upgrade SLES:15.6
dlm-kmp-default
to version 6.4.0-150600.23.25.1 or higher.
NVD Description
Note: Versions mentioned in the description apply only to the upstream dlm-kmp-default
package and not the dlm-kmp-default
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:
serial: sc16is7xx: fix TX fifo corruption
Sometimes, when a packet is received on channel A at almost the same time as a packet is about to be transmitted on channel B, we observe with a logic analyzer that the received packet on channel A is transmitted on channel B. In other words, the Tx buffer data on channel B is corrupted with data from channel A.
The problem appeared since commit 4409df5866b7 ("serial: sc16is7xx: change EFR lock to operate on each channels"), which changed the EFR locking to operate on each channel instead of chip-wise.
This commit has introduced a regression, because the EFR lock is used not only to protect the EFR registers access, but also, in a very obscure and undocumented way, to protect access to the data buffer, which is shared by the Tx and Rx handlers, but also by each channel of the IC.
Fix this regression first by switching to kfifo_out_linear_ptr() in sc16is7xx_handle_tx() to eliminate the need for a shared Rx/Tx buffer.
Secondly, replace the chip-wise Rx buffer with a separate Rx buffer for each channel.