CVE-2023-54134 (GCVE-0-2023-54134)
Vulnerability from cvelistv5 – Published: 2025-12-24 13:06 – Updated: 2026-05-11 19:56
VLAI
EPSS
VEX
Title
autofs: fix memory leak of waitqueues in autofs_catatonic_mode
Summary
In the Linux kernel, the following vulnerability has been resolved:
autofs: fix memory leak of waitqueues in autofs_catatonic_mode
Syzkaller reports a memory leak:
BUG: memory leak
unreferenced object 0xffff88810b279e00 (size 96):
comm "syz-executor399", pid 3631, jiffies 4294964921 (age 23.870s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 08 9e 27 0b 81 88 ff ff ..........'.....
08 9e 27 0b 81 88 ff ff 00 00 00 00 00 00 00 00 ..'.............
backtrace:
[<ffffffff814cfc90>] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046
[<ffffffff81bb75ca>] kmalloc include/linux/slab.h:576 [inline]
[<ffffffff81bb75ca>] autofs_wait+0x3fa/0x9a0 fs/autofs/waitq.c:378
[<ffffffff81bb88a7>] autofs_do_expire_multi+0xa7/0x3e0 fs/autofs/expire.c:593
[<ffffffff81bb8c33>] autofs_expire_multi+0x53/0x80 fs/autofs/expire.c:619
[<ffffffff81bb6972>] autofs_root_ioctl_unlocked+0x322/0x3b0 fs/autofs/root.c:897
[<ffffffff81bb6a95>] autofs_root_ioctl+0x25/0x30 fs/autofs/root.c:910
[<ffffffff81602a9c>] vfs_ioctl fs/ioctl.c:51 [inline]
[<ffffffff81602a9c>] __do_sys_ioctl fs/ioctl.c:870 [inline]
[<ffffffff81602a9c>] __se_sys_ioctl fs/ioctl.c:856 [inline]
[<ffffffff81602a9c>] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:856
[<ffffffff84608225>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
[<ffffffff84608225>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
[<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
autofs_wait_queue structs should be freed if their wait_ctr becomes zero.
Otherwise they will be lost.
In this case an AUTOFS_IOC_EXPIRE_MULTI ioctl is done, then a new
waitqueue struct is allocated in autofs_wait(), its initial wait_ctr
equals 2. After that wait_event_killable() is interrupted (it returns
-ERESTARTSYS), so that 'wq->name.name == NULL' condition may be not
satisfied. Actually, this condition can be satisfied when
autofs_wait_release() or autofs_catatonic_mode() is called and, what is
also important, wait_ctr is decremented in those places. Upon the exit of
autofs_wait(), wait_ctr is decremented to 1. Then the unmounting process
begins: kill_sb calls autofs_catatonic_mode(), which should have freed the
waitqueues, but it only decrements its usage counter to zero which is not
a correct behaviour.
edit:imk
This description is of course not correct. The umount performed as a result
of an expire is a umount of a mount that has been automounted, it's not the
autofs mount itself. They happen independently, usually after everything
mounted within the autofs file system has been expired away. If everything
hasn't been expired away the automount daemon can still exit leaving mounts
in place. But expires done in both cases will result in a notification that
calls autofs_wait_release() with a result status. The problem case is the
summary execution of of the automount daemon. In this case any waiting
processes won't be woken up until either they are terminated or the mount
is umounted.
end edit: imk
So in catatonic mode we should free waitqueues which counter becomes zero.
edit: imk
Initially I was concerned that the calling of autofs_wait_release() and
autofs_catatonic_mode() was not mutually exclusive but that can't be the
case (obviously) because the queue entry (or entries) is removed from the
list when either of these two functions are called. Consequently the wait
entry will be freed by only one of these functions or by the woken process
in autofs_wait() depending on the order of the calls.
end edit: imk
Severity
No CVSS data available.
Assigner
References
8 references
Impacted products
2 products
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
296f7bf78bc5c7a4d772aea580ce800d14040d1a , < 1985e8eae8627f02e3364690c5fed7af1c46be55
(git)
Affected: 296f7bf78bc5c7a4d772aea580ce800d14040d1a , < 976abbdc120a97049b9133e60fa7b29627d11de4 (git) Affected: 296f7bf78bc5c7a4d772aea580ce800d14040d1a , < 6079dc77c6f32936e8a6766ee8334ae3c99f4504 (git) Affected: 296f7bf78bc5c7a4d772aea580ce800d14040d1a , < 69ddafc7a7afd8401bab53eff5af813fa0d368a2 (git) Affected: 296f7bf78bc5c7a4d772aea580ce800d14040d1a , < 71eeddcad7342292c19042c290c477697acaccab (git) Affected: 296f7bf78bc5c7a4d772aea580ce800d14040d1a , < 726deae613bc1b6096ad3b61cc1e63e33330fbc2 (git) Affected: 296f7bf78bc5c7a4d772aea580ce800d14040d1a , < 696b625f3f85d80fca48c24d2948fbc451e74366 (git) Affected: 296f7bf78bc5c7a4d772aea580ce800d14040d1a , < ccbe77f7e45dfb4420f7f531b650c00c6e9c7507 (git) |
guessed | |
| Linux | Linux |
Affected:
2.6.27
Unaffected: 0 , < 2.6.27 (semver) Unaffected: 4.14.326 , ≤ 4.14.* (semver) Unaffected: 4.19.295 , ≤ 4.19.* (semver) Unaffected: 5.4.257 , ≤ 5.4.* (semver) Unaffected: 5.10.197 , ≤ 5.10.* (semver) Unaffected: 5.15.133 , ≤ 5.15.* (semver) Unaffected: 6.1.55 , ≤ 6.1.* (semver) Unaffected: 6.5.5 , ≤ 6.5.* (semver) Unaffected: 6.6 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/autofs/waitq.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "1985e8eae8627f02e3364690c5fed7af1c46be55",
"status": "affected",
"version": "296f7bf78bc5c7a4d772aea580ce800d14040d1a",
"versionType": "git"
},
{
"lessThan": "976abbdc120a97049b9133e60fa7b29627d11de4",
"status": "affected",
"version": "296f7bf78bc5c7a4d772aea580ce800d14040d1a",
"versionType": "git"
},
{
"lessThan": "6079dc77c6f32936e8a6766ee8334ae3c99f4504",
"status": "affected",
"version": "296f7bf78bc5c7a4d772aea580ce800d14040d1a",
"versionType": "git"
},
{
"lessThan": "69ddafc7a7afd8401bab53eff5af813fa0d368a2",
"status": "affected",
"version": "296f7bf78bc5c7a4d772aea580ce800d14040d1a",
"versionType": "git"
},
{
"lessThan": "71eeddcad7342292c19042c290c477697acaccab",
"status": "affected",
"version": "296f7bf78bc5c7a4d772aea580ce800d14040d1a",
"versionType": "git"
},
{
"lessThan": "726deae613bc1b6096ad3b61cc1e63e33330fbc2",
"status": "affected",
"version": "296f7bf78bc5c7a4d772aea580ce800d14040d1a",
"versionType": "git"
},
{
"lessThan": "696b625f3f85d80fca48c24d2948fbc451e74366",
"status": "affected",
"version": "296f7bf78bc5c7a4d772aea580ce800d14040d1a",
"versionType": "git"
},
{
"lessThan": "ccbe77f7e45dfb4420f7f531b650c00c6e9c7507",
"status": "affected",
"version": "296f7bf78bc5c7a4d772aea580ce800d14040d1a",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/autofs/waitq.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.27"
},
{
"lessThan": "2.6.27",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.14.*",
"status": "unaffected",
"version": "4.14.326",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.295",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.257",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.197",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.133",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.55",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.5.*",
"status": "unaffected",
"version": "6.5.5",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.6",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.14.326",
"versionStartIncluding": "2.6.27",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.19.295",
"versionStartIncluding": "2.6.27",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.257",
"versionStartIncluding": "2.6.27",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.197",
"versionStartIncluding": "2.6.27",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.133",
"versionStartIncluding": "2.6.27",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.55",
"versionStartIncluding": "2.6.27",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.5.5",
"versionStartIncluding": "2.6.27",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6",
"versionStartIncluding": "2.6.27",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nautofs: fix memory leak of waitqueues in autofs_catatonic_mode\n\nSyzkaller reports a memory leak:\n\nBUG: memory leak\nunreferenced object 0xffff88810b279e00 (size 96):\n comm \"syz-executor399\", pid 3631, jiffies 4294964921 (age 23.870s)\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 08 9e 27 0b 81 88 ff ff ..........\u0027.....\n 08 9e 27 0b 81 88 ff ff 00 00 00 00 00 00 00 00 ..\u0027.............\n backtrace:\n [\u003cffffffff814cfc90\u003e] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046\n [\u003cffffffff81bb75ca\u003e] kmalloc include/linux/slab.h:576 [inline]\n [\u003cffffffff81bb75ca\u003e] autofs_wait+0x3fa/0x9a0 fs/autofs/waitq.c:378\n [\u003cffffffff81bb88a7\u003e] autofs_do_expire_multi+0xa7/0x3e0 fs/autofs/expire.c:593\n [\u003cffffffff81bb8c33\u003e] autofs_expire_multi+0x53/0x80 fs/autofs/expire.c:619\n [\u003cffffffff81bb6972\u003e] autofs_root_ioctl_unlocked+0x322/0x3b0 fs/autofs/root.c:897\n [\u003cffffffff81bb6a95\u003e] autofs_root_ioctl+0x25/0x30 fs/autofs/root.c:910\n [\u003cffffffff81602a9c\u003e] vfs_ioctl fs/ioctl.c:51 [inline]\n [\u003cffffffff81602a9c\u003e] __do_sys_ioctl fs/ioctl.c:870 [inline]\n [\u003cffffffff81602a9c\u003e] __se_sys_ioctl fs/ioctl.c:856 [inline]\n [\u003cffffffff81602a9c\u003e] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:856\n [\u003cffffffff84608225\u003e] do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n [\u003cffffffff84608225\u003e] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n [\u003cffffffff84800087\u003e] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nautofs_wait_queue structs should be freed if their wait_ctr becomes zero.\nOtherwise they will be lost.\n\nIn this case an AUTOFS_IOC_EXPIRE_MULTI ioctl is done, then a new\nwaitqueue struct is allocated in autofs_wait(), its initial wait_ctr\nequals 2. After that wait_event_killable() is interrupted (it returns\n-ERESTARTSYS), so that \u0027wq-\u003ename.name == NULL\u0027 condition may be not\nsatisfied. Actually, this condition can be satisfied when\nautofs_wait_release() or autofs_catatonic_mode() is called and, what is\nalso important, wait_ctr is decremented in those places. Upon the exit of\nautofs_wait(), wait_ctr is decremented to 1. Then the unmounting process\nbegins: kill_sb calls autofs_catatonic_mode(), which should have freed the\nwaitqueues, but it only decrements its usage counter to zero which is not\na correct behaviour.\n\nedit:imk\nThis description is of course not correct. The umount performed as a result\nof an expire is a umount of a mount that has been automounted, it\u0027s not the\nautofs mount itself. They happen independently, usually after everything\nmounted within the autofs file system has been expired away. If everything\nhasn\u0027t been expired away the automount daemon can still exit leaving mounts\nin place. But expires done in both cases will result in a notification that\ncalls autofs_wait_release() with a result status. The problem case is the\nsummary execution of of the automount daemon. In this case any waiting\nprocesses won\u0027t be woken up until either they are terminated or the mount\nis umounted.\nend edit: imk\n\nSo in catatonic mode we should free waitqueues which counter becomes zero.\n\nedit: imk\nInitially I was concerned that the calling of autofs_wait_release() and\nautofs_catatonic_mode() was not mutually exclusive but that can\u0027t be the\ncase (obviously) because the queue entry (or entries) is removed from the\nlist when either of these two functions are called. Consequently the wait\nentry will be freed by only one of these functions or by the woken process\nin autofs_wait() depending on the order of the calls.\nend edit: imk"
}
],
"providerMetadata": {
"dateUpdated": "2026-05-11T19:56:08.647Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/1985e8eae8627f02e3364690c5fed7af1c46be55"
},
{
"url": "https://git.kernel.org/stable/c/976abbdc120a97049b9133e60fa7b29627d11de4"
},
{
"url": "https://git.kernel.org/stable/c/6079dc77c6f32936e8a6766ee8334ae3c99f4504"
},
{
"url": "https://git.kernel.org/stable/c/69ddafc7a7afd8401bab53eff5af813fa0d368a2"
},
{
"url": "https://git.kernel.org/stable/c/71eeddcad7342292c19042c290c477697acaccab"
},
{
"url": "https://git.kernel.org/stable/c/726deae613bc1b6096ad3b61cc1e63e33330fbc2"
},
{
"url": "https://git.kernel.org/stable/c/696b625f3f85d80fca48c24d2948fbc451e74366"
},
{
"url": "https://git.kernel.org/stable/c/ccbe77f7e45dfb4420f7f531b650c00c6e9c7507"
}
],
"title": "autofs: fix memory leak of waitqueues in autofs_catatonic_mode",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2023-54134",
"datePublished": "2025-12-24T13:06:50.627Z",
"dateReserved": "2025-12-24T13:02:52.522Z",
"dateUpdated": "2026-05-11T19:56:08.647Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2023-54134",
"date": "2026-11-08",
"epss": "0.00236",
"percentile": "0.14652"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/autofs/waitq.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "1985e8eae8627f02e3364690c5fed7af1c46be55",
"status": "affected",
"version": "296f7bf78bc5c7a4d772aea580ce800d14040d1a",
"versionType": "git"
},
{
"lessThan": "976abbdc120a97049b9133e60fa7b29627d11de4",
"status": "affected",
"version": "296f7bf78bc5c7a4d772aea580ce800d14040d1a",
"versionType": "git"
},
{
"lessThan": "6079dc77c6f32936e8a6766ee8334ae3c99f4504",
"status": "affected",
"version": "296f7bf78bc5c7a4d772aea580ce800d14040d1a",
"versionType": "git"
},
{
"lessThan": "69ddafc7a7afd8401bab53eff5af813fa0d368a2",
"status": "affected",
"version": "296f7bf78bc5c7a4d772aea580ce800d14040d1a",
"versionType": "git"
},
{
"lessThan": "71eeddcad7342292c19042c290c477697acaccab",
"status": "affected",
"version": "296f7bf78bc5c7a4d772aea580ce800d14040d1a",
"versionType": "git"
},
{
"lessThan": "726deae613bc1b6096ad3b61cc1e63e33330fbc2",
"status": "affected",
"version": "296f7bf78bc5c7a4d772aea580ce800d14040d1a",
"versionType": "git"
},
{
"lessThan": "696b625f3f85d80fca48c24d2948fbc451e74366",
"status": "affected",
"version": "296f7bf78bc5c7a4d772aea580ce800d14040d1a",
"versionType": "git"
},
{
"lessThan": "ccbe77f7e45dfb4420f7f531b650c00c6e9c7507",
"status": "affected",
"version": "296f7bf78bc5c7a4d772aea580ce800d14040d1a",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/autofs/waitq.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.27"
},
{
"lessThan": "2.6.27",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.14.*",
"status": "unaffected",
"version": "4.14.326",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.295",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.257",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.197",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.133",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.55",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.5.*",
"status": "unaffected",
"version": "6.5.5",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.6",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nautofs: fix memory leak of waitqueues in autofs_catatonic_mode\n\nSyzkaller reports a memory leak:\n\nBUG: memory leak\nunreferenced object 0xffff88810b279e00 (size 96):\n comm \"syz-executor399\", pid 3631, jiffies 4294964921 (age 23.870s)\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 08 9e 27 0b 81 88 ff ff ..........\u0027.....\n 08 9e 27 0b 81 88 ff ff 00 00 00 00 00 00 00 00 ..\u0027.............\n backtrace:\n [\u003cffffffff814cfc90\u003e] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046\n [\u003cffffffff81bb75ca\u003e] kmalloc include/linux/slab.h:576 [inline]\n [\u003cffffffff81bb75ca\u003e] autofs_wait+0x3fa/0x9a0 fs/autofs/waitq.c:378\n [\u003cffffffff81bb88a7\u003e] autofs_do_expire_multi+0xa7/0x3e0 fs/autofs/expire.c:593\n [\u003cffffffff81bb8c33\u003e] autofs_expire_multi+0x53/0x80 fs/autofs/expire.c:619\n [\u003cffffffff81bb6972\u003e] autofs_root_ioctl_unlocked+0x322/0x3b0 fs/autofs/root.c:897\n [\u003cffffffff81bb6a95\u003e] autofs_root_ioctl+0x25/0x30 fs/autofs/root.c:910\n [\u003cffffffff81602a9c\u003e] vfs_ioctl fs/ioctl.c:51 [inline]\n [\u003cffffffff81602a9c\u003e] __do_sys_ioctl fs/ioctl.c:870 [inline]\n [\u003cffffffff81602a9c\u003e] __se_sys_ioctl fs/ioctl.c:856 [inline]\n [\u003cffffffff81602a9c\u003e] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:856\n [\u003cffffffff84608225\u003e] do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n [\u003cffffffff84608225\u003e] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n [\u003cffffffff84800087\u003e] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nautofs_wait_queue structs should be freed if their wait_ctr becomes zero.\nOtherwise they will be lost.\n\nIn this case an AUTOFS_IOC_EXPIRE_MULTI ioctl is done, then a new\nwaitqueue struct is allocated in autofs_wait(), its initial wait_ctr\nequals 2. After that wait_event_killable() is interrupted (it returns\n-ERESTARTSYS), so that \u0027wq-\u003ename.name == NULL\u0027 condition may be not\nsatisfied. Actually, this condition can be satisfied when\nautofs_wait_release() or autofs_catatonic_mode() is called and, what is\nalso important, wait_ctr is decremented in those places. Upon the exit of\nautofs_wait(), wait_ctr is decremented to 1. Then the unmounting process\nbegins: kill_sb calls autofs_catatonic_mode(), which should have freed the\nwaitqueues, but it only decrements its usage counter to zero which is not\na correct behaviour.\n\nedit:imk\nThis description is of course not correct. The umount performed as a result\nof an expire is a umount of a mount that has been automounted, it\u0027s not the\nautofs mount itself. They happen independently, usually after everything\nmounted within the autofs file system has been expired away. If everything\nhasn\u0027t been expired away the automount daemon can still exit leaving mounts\nin place. But expires done in both cases will result in a notification that\ncalls autofs_wait_release() with a result status. The problem case is the\nsummary execution of of the automount daemon. In this case any waiting\nprocesses won\u0027t be woken up until either they are terminated or the mount\nis umounted.\nend edit: imk\n\nSo in catatonic mode we should free waitqueues which counter becomes zero.\n\nedit: imk\nInitially I was concerned that the calling of autofs_wait_release() and\nautofs_catatonic_mode() was not mutually exclusive but that can\u0027t be the\ncase (obviously) because the queue entry (or entries) is removed from the\nlist when either of these two functions are called. Consequently the wait\nentry will be freed by only one of these functions or by the woken process\nin autofs_wait() depending on the order of the calls.\nend edit: imk"
}
],
"id": "CVE-2023-54134",
"lastModified": "2026-06-17T06:46:51.830",
"metrics": {},
"published": "2025-12-24T13:16:15.383",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/1985e8eae8627f02e3364690c5fed7af1c46be55"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/6079dc77c6f32936e8a6766ee8334ae3c99f4504"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/696b625f3f85d80fca48c24d2948fbc451e74366"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/69ddafc7a7afd8401bab53eff5af813fa0d368a2"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/71eeddcad7342292c19042c290c477697acaccab"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/726deae613bc1b6096ad3b61cc1e63e33330fbc2"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/976abbdc120a97049b9133e60fa7b29627d11de4"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/ccbe77f7e45dfb4420f7f531b650c00c6e9c7507"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Deferred"
}
},
"redhat_vex": {
"aggregate_severity": "Low",
"current_release_date": "2026-11-07T11:11:08+00:00",
"cve": "CVE-2023-54134",
"id": "CVE-2023-54134",
"initial_release_date": "2023-01-01T00:00:00+00:00",
"product_status:known_affected": "171",
"product_status:known_not_affected": "29",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: Linux kernel autofs: Denial of Service due to memory leak in autofs_catatonic_mode",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2023/cve-2023-54134.json",
"version": "3"
}
}
}
Loading…
Loading…
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.