{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2023-53222",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2023-53222"
  ],
  "published": "2025-09-15T14:26:11Z",
  "summary": "jfs: jfs_dmap: Validate db_l2nbperpage while mounting",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\njfs: jfs_dmap: Validate db_l2nbperpage while mounting\n\nIn jfs_dmap.c at line 381, BLKTODMAP is used to get a logical block\nnumber inside dbFree(). db_l2nbperpage, which is the log2 number of\nblocks per page, is passed as an argument to BLKTODMAP which uses it\nfor shifting.\n\nSyzbot reported a shift out-of-bounds crash because db_l2nbperpage is\ntoo big. This happens because the large value is set without any\nvalidation in dbMount() at line 181.\n\nThus, make sure that db_l2nbperpage is correct while mounting.\n\nMax number of blocks per page = Page size / Min block size\n=> log2(Max num_block per page) = log2(Page size / Min block size)\n\t\t\t\t= log2(Page size) - log2(Min block size)\n\n=> Max db_l2nbperpage = L2PSIZE - L2MINBLOCKSIZE",
  "severity": [
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
    }
  ],
  "affected": [
    {
      "package": {
        "ecosystem": "Raspberry Pi OS:12",
        "name": "linux"
      },
      "versions": [
        "1:6.1.21-1+rpt1"
      ],
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "linux-image-6.1.0-rpi1-rpi-v6",
            "binary_version": "1:6.1.21-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi1-rpi-v7",
            "binary_version": "1:6.1.21-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi1-rpi-v7l",
            "binary_version": "1:6.1.21-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi1-rpi-v8",
            "binary_version": "1:6.1.21-1+rpt1"
          }
        ]
      },
      "database_specific": {
        "per_version": {
          "1:6.1.21-1+rpt1": {
            "linux_commit": "0afb5e98488aed7017b9bf321b575d0177feb7ed",
            "upstream_version": "6.1.21",
            "assessment": "commit ancestry (strak rule)",
            "upstream_fixed": "6.1.40"
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2023-53222"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/8c1efe3f74a7864461b0dff281c5562154b4aa8e"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/ef5c205b6e6f8d1f18ef0b4a9832b1b5fa85f7f2"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/a4855aeb13e4ad1f23e16753b68212e180f7d848"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/47b7eaae08e8b2f25bdf37bc14d21be090bcb20f"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/de984faecddb900fa850af4df574a25b32bb93f5"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/c7feb54b113802d2aba98708769d3c33fb017254"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/2a03c4e683d33d17b667418eb717b13dda1fac6b"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/11509910c599cbd04585ec35a6d5e1a0053d84c1"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-08-05T11:24:39Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 7.8,
      "cvss_v3_severity": "High",
      "scenario": "AV:L - The bug is reached only after a local mount of an attacker-crafted JFS image on a block/loop device (mount \u2192 jfs_fill_super \u2192 jfs_mount \u2192 dbMount, then later dbFree); there is no network or adjacent-protocol path into fs/jfs.\nAC:L - dn_l2nbperpage is taken verbatim from the on-disk bmap descriptor, so the attacker sets the out-of-range shift amount deterministically; any subsequent free/truncate/umount path that calls BLKTODMAP/dbFree hits the bug with no race or uncontrollable state.\nPR:L - As with sibling JFS crafted-image CVEs, an unprivileged local session user can get the malicious image attached via udisks2/polkit/automount on desktops, kiosks, and shared workstations, then trigger dbFree with ordinary file operations or unmount on that volume.\nUI:N - The attacker supplies the image, causes it to be mounted (including via automount/udisks on their own session), and drives the free/umount path themselves; no separate victim action is required at exploitation time.\nS:U - Wrong metapage selection and allocator/metadata corruption stay inside the kernel\u2019s own memory and security authority; no VM, IOMMU, or sandbox boundary is crossed.\nC:H - An oversized db_l2nbperpage makes BLKTODMAP compute attacker-influenced logical block numbers so dbFree reads the wrong (still attacker-controlled) dmap metapage and walks its summary tree/bitmaps, yielding out-of-bounds reads of adjacent kernel/metapage memory that can be leveraged for disclosure, consistent with other JFS dmap shift-OOB scores.\nI:H - dbFreeDmap/dbFreeBits then write wmap/tree/nfree and in-memory db_agfree[] based on that wrong page and undefined shift results, corrupting heap-backed metapage and bmap state into a write primitive suitable for control-flow hijacking under the higher-severity rule for memory corruption.\nA:H - Syzbot reproduced this as UBSAN shift-out-of-bounds in dbFree (panic under UBSAN_TRAP/panic_on_warn), and the corrupted metapage/allocator paths also produce oopses and jfs_error filesystem shutdown."
    }
  }
}