LiveActive security incident?Get immediate response
CVE Record

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.

UnknownCVSS not scoredNot KEV-listedUpdated
Glexia's TakeAutomated analysislow

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.
Prepared
Confidence
medium
Sources
5

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.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

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.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinux445caaa20c4d6da74f426464f90513b81157ad77, 445caaa20c4d6da74f426464f90513b81157ad77, 445caaa20c4d6da74f426464f90513b81157ad77unaffected
LinuxLinux4.10, 0, 6.0.16, 6.1.2, 6.2affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.