CVE-2022-50304: mtd: core: fix possible resource leak in init_mtd()
In the Linux kernel, the following vulnerability has been resolved:
mtd: core: fix possible resource leak in init_mtd()
I got the error report while inject fault in init_mtd():
sysfs: cannot create duplicate filename '/devices/virtual/bdi/mtd-0'
Call Trace:
<TASK>
dump_stack_lvl+0x67/0x83
sysfs_warn_dup+0x60/0x70
sysfs_create_dir_ns+0x109/0x120
kobject_add_internal+0xce/0x2f0
kobject_add+0x98/0x110
device_add+0x179/0xc00
device_create_groups_vargs+0xf4/0x100
device_create+0x7b/0xb0
bdi_register_va.part.13+0x58/0x2d0
bdi_register+0x9b/0xb0
init_mtd+0x62/0x171 [mtd]
do_one_initcall+0x6c/0x3c0
do_init_module+0x58/0x222
load_module+0x268e/0x27d0
__do_sys_finit_module+0xd5/0x140
do_syscall_64+0x37/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
</TASK>
kobject_add_internal failed for mtd-0 with -EEXIST, don't try to register
things with the same name in the same directory.
Error registering mtd class or bdi: -17
If init_mtdchar() fails in init_mtd(), mtd_bdi will not be unregistered,
as a result, we can't load the mtd module again, to fix this by calling
bdi_unregister(mtd_bdi) after out_procfs label.
Security readout for executives and security teams
Plain-English summary
This Linux kernel issue is a cleanup bug in the MTD subsystem. If module initialization fails at a specific point, a backing-device object can be left registered, preventing the MTD module from loading again. The sources do not show data theft, privilege escalation, remote attack, or active exploitation.
Executive priority
Treat this as a low-priority availability cleanup issue unless MTD reliability is business-critical. Patch through normal kernel maintenance, with higher attention for embedded fleets where module reload failures could affect service recovery.
Technical view
In init_mtd(), failure in init_mtdchar() can leave mtd_bdi registered. A later load can fail with duplicate sysfs name /devices/virtual/bdi/mtd-0. The referenced stable commits address the error path by unregistering mtd_bdi after the out_procfs cleanup path.
Likely exposure
Exposure is most relevant to Linux systems that use the MTD subsystem, commonly embedded or flash-storage platforms. The CVE bundle lists Linux kernel affected entries including 4.10, 6.0.16, 6.1.2, and 6.2. Distribution-specific exposure depends on vendor backports.
Exploitation context
No KEV listing is provided, and the source bundle does not cite active exploitation. The described condition came from fault injection during init_mtd(), not a documented public attack path. Practical impact appears availability-oriented: failed reload of the MTD module after an initialization failure.
Researcher notes
The evidence supports a resource leak in an initialization error path. No CVSS, CWE, exploitability details, or vendor-specific package fixes are included. Avoid overstating impact beyond MTD module reload failure unless additional vendor analysis confirms broader consequences.
Mitigation direction
Move to a Linux kernel containing the referenced stable fixes.
Check distribution or device-vendor advisories for backported kernel fixes.
Prioritize embedded or flash-storage systems that load MTD as a module.
Avoid unnecessary MTD module reloads on affected systems until patched.
Validation and detection
Inventory systems using Linux kernels and the MTD subsystem.
Map running kernel builds to vendor advisories or stable commit backports.
Review logs for duplicate sysfs mtd-0 registration errors.
Confirm patched builds include the referenced stable commits or equivalent backport.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2022-50304 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
4Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Sep 15, 2025, 14:45 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.