CVE-2023-53222: jfs: jfs_dmap: Validate db_l2nbperpage while mounting
In the Linux kernel, the following vulnerability has been resolved:
jfs: jfs_dmap: Validate db_l2nbperpage while mounting
In jfs_dmap.c at line 381, BLKTODMAP is used to get a logical block
number inside dbFree(). db_l2nbperpage, which is the log2 number of
blocks per page, is passed as an argument to BLKTODMAP which uses it
for shifting.
Syzbot reported a shift out-of-bounds crash because db_l2nbperpage is
too big. This happens because the large value is set without any
validation in dbMount() at line 181.
Thus, make sure that db_l2nbperpage is correct while mounting.
Max number of blocks per page = Page size / Min block size
=> log2(Max num_block per page) = log2(Page size / Min block size)
= log2(Page size) - log2(Min block size)
=> Max db_l2nbperpage = L2PSIZE - L2MINBLOCKSIZE
Security readout for executives and security teams
Plain-English summary
This Linux kernel flaw affects JFS filesystem mounting. A malformed or unexpected JFS metadata value can trigger an invalid shift and crash the kernel. Business impact is mainly system instability and possible confidentiality exposure on systems where local users or services can mount or process JFS filesystems.
Executive priority
Prioritize patching internet-adjacent, multi-user, container-hosting, forensic, storage, and image-processing systems first. This is not evidenced as remotely exploitable, but kernel crashes on shared infrastructure can create meaningful outage risk.
Technical view
The bug is in jfs_dmap.c: db_l2nbperpage was accepted during dbMount() without validation and later used by BLKTODMAP in dbFree(). Syzbot reported a shift out-of-bounds crash. The fix validates db_l2nbperpage against the maximum derived from page size and minimum block size.
Likely exposure
Exposure is most likely on Linux systems with JFS support enabled and workflows that mount JFS filesystems. The CVSS vector is local, low complexity, low privilege, and no user interaction, so shared systems and environments handling user-supplied disk images deserve attention.
Exploitation context
The source bundle does not show CISA KEV listing or active exploitation. Evidence supports a local mount-time kernel crash condition found by Syzbot, not confirmed in-the-wild exploitation. Treat exploitability as local and dependent on access to mount or influence a JFS filesystem.
Researcher notes
The affected data path is JFS mount initialization feeding db_l2nbperpage into later block-to-dmap shift logic. The source bundle lists CWE-125 and CVSS confidentiality plus availability impact, but does not provide proof-of-concept details or exploitation evidence.
Mitigation direction
Apply vendor kernel updates containing the referenced stable fixes.
Check distribution advisories for CVE-2023-53222 package status.
Avoid mounting untrusted JFS filesystems until patched.
Restrict local privileges that allow filesystem mounting.
Disable unused JFS support where operationally safe.
Validation and detection
Inventory Linux kernels and compare against vendor fixed packages.
Check whether JFS support is enabled or loaded.
Identify hosts that mount JFS filesystems or disk images.
Review kernel logs for JFS mount crashes or Oops events.
Confirm updated kernels include the db_l2nbperpage validation fix.
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.
cwe · low confidence lookup
CWE-125: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
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.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.