{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2023-54134 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2023-54134 is a memory corruption vulnerability in Linux, published on 24 Dec 2025. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2023-54134 and fix it if it is affected.\n\nWhat it is: CVE-2023-54134 is a memory corruption vulnerability in Linux, published on 24 Dec 2025. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2023-54134 in the wild and no public exploit code.\n\nAffected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2023-54134/ (Markdown: https://insights.sbomify.com/CVE-2023-54134/index.md)","id":"CVE-2023-54134","markdown":"https://insights.sbomify.com/CVE-2023-54134/index.md","name":"CVE-2023-54134","record":{"aliases":["BELL-CVE-2023-54134","DEBIAN-CVE-2023-54134","GHSA-8c3j-jg6j-52j2","UBUNTU-CVE-2023-54134"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel","requires_auth":"low_privilege","summary":"A local attacker can trigger a memory leak in the Linux kernel autofs module via ioctl, leading to resource exhaustion and denial of service.","user_interaction":"not_required","vuln_class":"memory_corruption"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"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  ..........'.....\n    08 9e 27 0b 81 88 ff ff 00 00 00 00 00 00 00 00  ..'.............\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 'wq-\u003ename.name == NULL' 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's not the\nautofs mount itself. They happen independently, usually after everything\nmounted within the autofs file system has been expired away. If everything\nhasn't 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't 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't 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","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"autofs: fix memory leak of waitqueues in autofs_catatonic_mode","id":"CVE-2023-54134","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"memory_corruption","year":"2023"},"n_packages":0,"n_references":8,"next":{"headline":"maple_tree: fix potential out-of-bounds access in mas_wr_end_piv()","id":"CVE-2023-54135"},"packages":[],"prev":{"headline":"nfp: clean mc addresses in application firmware when closing port","id":"CVE-2023-54133"},"products":["Linux"],"published":"2025-12-24","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-05-11","vendors":["Linux"]},"summary":"A local attacker can trigger a memory leak in the Linux kernel autofs module via ioctl, leading to resource exhaustion and denial of service.","url":"https://insights.sbomify.com/CVE-2023-54134/"}