CVE-2024-42315
In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential deadlock on __exfat_get_dentry_set When accessing a file with more entries than ES_MAX_ENTRY_NUM, the bh-array is allocated in __exfat_get_entry_set.
Does this matter?
Lower severity and a low EPSS score (0.17%). Track it; it rarely justifies an emergency change on its own.
Description
In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential deadlock on __exfat_get_dentry_set When accessing a file with more entries than ES_MAX_ENTRY_NUM, the bh-array is allocated in __exfat_get_entry_set. The problem is that the bh-array is allocated with GFP_KERNEL. It does not make sense. In the following cases, a deadlock for sbi->s_lock between the two processes may occur. CPU0 CPU1 ---- ---- kswapd balance_pgdat lock(fs_reclaim) exfat_iterate lock(&sbi->s_lock) exfat_readdir exfat_get_uniname_from_ext_entry exfat_get_dentry_set __exfat_get_dentry_set kmalloc_array ... lock(fs_reclaim) ... evict exfat_evict_inode lock(&sbi->s_lock) To fix this, let's allocate bh-array with GFP_NOFS.
- CVSS 3.1
- 5.5 MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
- EPSS
- 0.17% probability · 6th percentile
- CISA KEV
- Not listed
- Weakness
- CWE-667
- Affected
- linux/linux kernel
- Source
- 416baaa9-dc9f-4396-8d5f-8c081fb06d67
References
- https://git.kernel.org/stable/c/1d1970493c289e3f44b9ec847ed26a5dbdf56a62Patch
- https://git.kernel.org/stable/c/632fb232b6bbf8277edcbe9ecd4b4d98ecb122eb
- https://git.kernel.org/stable/c/89fc548767a2155231128cb98726d6d2ea1256c9Patch
- https://git.kernel.org/stable/c/a7ac198f8dba791e3144c4da48a5a9b95773ee4bPatch
- https://git.kernel.org/stable/c/c052f775ee6ccacd3c97e4cf41a2a657e63d4259
- https://git.kernel.org/stable/c/cd1c7858641384191ff7033fb1fc65dfcd559c6f
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Source: NVD record, EPSS from FIRST.org, KEV from CISA. Refreshed daily.