Improper Locking Affecting kernel-tools package, versions <0:4.18.0-477.74.1.el8_8
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-RHEL8-KERNELTOOLS-8084573
- published 24 Sep 2024
- disclosed 19 Jun 2024
Introduced: 19 Jun 2024
CVE-2024-38598 Open this link in a new tabHow to fix?
Upgrade RHEL:8
kernel-tools
to version 0:4.18.0-477.74.1.el8_8 or higher.
This issue was patched in RHSA-2024:6993
.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-tools
package and not the kernel-tools
package as distributed by RHEL
.
See How to fix?
for RHEL:8
relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
md: fix resync softlockup when bitmap size is less than array size
Is is reported that for dm-raid10, lvextend + lvchange --syncaction will trigger following softlockup:
kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976] CPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1 RIP: 0010:_raw_spin_unlock_irq+0x13/0x30 Call Trace: <TASK> md_bitmap_start_sync+0x6b/0xf0 raid10_sync_request+0x25c/0x1b40 [raid10] md_do_sync+0x64b/0x1020 md_thread+0xa7/0x170 kthread+0xcf/0x100 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1a/0x30
And the detailed process is as follows:
md_do_sync j = mddev->resync_min while (j < max_sectors) sectors = raid10_sync_request(mddev, j, &skipped) if (!md_bitmap_start_sync(..., &sync_blocks)) // md_bitmap_start_sync set sync_blocks to 0 return sync_blocks + sectors_skippe; // sectors = 0; j += sectors; // j never change
Root cause is that commit 301867b1c168 ("md/raid10: check slab-out-of-bounds in md_bitmap_get_counter") return early from md_bitmap_get_counter(), without setting returned blocks.
Fix this problem by always set returned blocks from md_bitmap_get_counter"(), as it used to be.
Noted that this patch just fix the softlockup problem in kernel, the case that bitmap size doesn't match array size still need to be fixed.
References
- https://access.redhat.com/security/cve/CVE-2024-38598
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
- https://git.kernel.org/stable/c/3f5b73ef8fd6268cbc968b308d8eafe56fda97f3
- https://git.kernel.org/stable/c/43771597feba89a839c5f893716df88ae5c237ce
- https://git.kernel.org/stable/c/5817f43ae1a118855676f57ef7ab50e37eac7482
- https://git.kernel.org/stable/c/69296914bfd508c85935bf5f711cad9b0fe78492
- https://git.kernel.org/stable/c/71e8e4f288e74a896b6d9cd194f3bab12bd7a10f
- https://git.kernel.org/stable/c/8bbc71315e0ae4bb7e37f8d43b915e1cb01a481b
- https://git.kernel.org/stable/c/c9566b812c8f66160466cc1e29df6d3646add0b1
- https://git.kernel.org/stable/c/d4b9c764d48fa41caa24cfb4275f3aa9fb4bd798
- https://git.kernel.org/stable/c/f0e729af2eb6bee9eb58c4df1087f14ebaefe26b