Skip to content
Heist/ feed
Back to feed
Unrated

CVE-2026-89768 affecting package kernel 6.6.157.1-1

Type: advisorySources: OSV

In the Linux kernel, the following vulnerability has been resolved: fs: fix user path of nested backing files backing_file_open() derives the path to be stored in the new backing file from user_file->f_path. This is incorrect when user_file itself is a backing file, which is the case for nested stacking filesystems, e.g. overlayfs mounts where the lowerdir of one overlayfs is the merged directory of another. Since commit def3ae83da02 ("fs: store real path instead of fake path in backing file f_path") the f_path of a backing file holds the real path of the intermediate layer, not the path that the user opened. Commit 924577e4f6ca ("ovl: Fix nested backing file paths") fixed this for such configurations by passing file_user_path() from ovl_open_realfile(). However, commit 6af36aeb147a ("lsm: add backing_file LSM hooks") changed the first argument of backing_file_open() from the user path back to the user file and derived the path from user_file->f_path again, silently re-introducing the problem. As a result, files mapped through a nested overlayfs show the wrong path in /proc//maps and in perf/ftrace mmap records. For example, with two nested overlayfs mounts: mkdir -p /ovl/{lower,upper,work,merged} /ovl/nested echo hello > /ovl/lower/foo mount -t overlay overlay \ -o lowerdir=/ovl/lower,upperdir=/ovl/upper,workdir=/ovl/work \ /ovl/merged # at least two lowerdirs are needed when upperdir is nonexistent mount -t overlay overlay \ -o lowerdir=/ovl/merged:/ovl/lower /ovl/nested ma

Products
kernel
Affected versions
Not specified
Fixed versions
Not specified
CVEs
CVE-2026-89768
Confirmed fixed CVEs
Not specified
Updated in this feed
31 Oct 2026, 17:42 UTC · Revision 1

Source evidence

CVE-2026-89768 affecting package kernel 6.6.157.1-1

core-osv · Original source

Published 11 Sept 2026, 20:20 UTC

In the Linux kernel, the following vulnerability has been resolved: fs: fix user path of nested backing files backing_file_open() derives the path to be stored in the new backing file from user_file->f_path. This is incorrect when user_file itself is a backing file, which is the case for nested stacking filesystems, e.g. overlayfs mounts where the lowerdir of one overlayfs is the merged directory of another. Since commit def3ae83da02 ("fs: store real path instead of fake path in backing file f_path") the f_path of a backing file holds the real path of the intermediate layer, not the path that the user opened. Commit 924577e4f6ca ("ovl: Fix nested backing file paths") fixed this for such configurations by passing file_user_path() from ovl_open_realfile(). However, commit 6af36aeb147a ("lsm: add backing_file LSM hooks") changed the first argument of backing_file_open() from the user path back to the user file and derived the path from user_file->f_path again, silently re-introducing the problem. As a result, files mapped through a nested overlayfs show the wrong path in /proc//maps and in perf/ftrace mmap records. For example, with two nested overlayfs mounts: mkdir -p /ovl/{lower,upper,work,merged} /ovl/nested echo hello > /ovl/lower/foo mount -t overlay overlay \ -o lowerdir=/ovl/lower,upperdir=/ovl/upper,workdir=/ovl/work \ /ovl/merged # at least two lowerdirs are needed when upperdir is nonexistent mount -t overlay overlay \ -o lowerdir=/ovl/merged:/ovl/lower /ovl/nested ma

osv:AZL-100442

kernel

Fixed versions: Not specified

Complete source record
{
  "id": "18a1f79b5c52c8a34e75a1d3223d22f34740b87d21a824a1b449b86190c08e8d",
  "url": "https://osv.dev/vulnerability/AZL-100442",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "CVE-2026-89768 affecting package kernel 6.6.157.1-1",
    "summary": "In the Linux kernel, the following vulnerability has been resolved: fs: fix user path of nested backing files backing_file_open() derives the path to be stored in the new backing file from user_file->f_path. This is incorrect when user_file itself is a backing file, which is the case for nested stacking filesystems, e.g. overlayfs mounts where the lowerdir of one overlayfs is the merged directory of another. Since commit def3ae83da02 (\"fs: store real path instead of fake path in backing file f_path\") the f_path of a backing file holds the real path of the intermediate layer, not the path that the user opened. Commit 924577e4f6ca (\"ovl: Fix nested backing file paths\") fixed this for such configurations by passing file_user_path() from ovl_open_realfile(). However, commit 6af36aeb147a (\"lsm: add backing_file LSM hooks\") changed the first argument of backing_file_open() from the user path back to the user file and derived the path from user_file->f_path again, silently re-introducing the problem. As a result, files mapped through a nested overlayfs show the wrong path in /proc//maps and in perf/ftrace mmap records. For example, with two nested overlayfs mounts: mkdir -p /ovl/{lower,upper,work,merged} /ovl/nested echo hello > /ovl/lower/foo mount -t overlay overlay \\ -o lowerdir=/ovl/lower,upperdir=/ovl/upper,workdir=/ovl/work \\ /ovl/merged # at least two lowerdirs are needed when upperdir is nonexistent mount -t overlay overlay \\ -o lowerdir=/ovl/merged:/ovl/lower /ovl/nested ma",
    "evidence": "osv:AZL-100442",
    "products": [
      {
        "name": {
          "value": "kernel",
          "evidence": "/affected/0/package/name"
        },
        "prerequisites": [],
        "fixed_versions": [],
        "affected_versions": []
      }
    ],
    "severity": "unknown",
    "structured": {
      "id": "AZL-100442",
      "aliases": [
        "AZL-100442"
      ],
      "affected": [
        {
          "ranges": [
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "0"
                },
                {
                  "last_affected": "6.6.157.1-1"
                }
              ]
            }
          ],
          "package": {
            "name": "kernel",
            "purl": "pkg:rpm/azure-linux/kernel",
            "ecosystem": "Azure Linux:3"
          },
          "database_specific": {
            "source": "https://github.com/microsoft/AzureLinuxVulnerabilityData/blob/main/osv/AZL-100442.json"
          }
        }
      ],
      "modified": "2026-10-22T05:35:55Z",
      "provider": "osv",
      "upstream": [
        "CVE-2026-89768"
      ],
      "references": [
        "https://nvd.nist.gov/vuln/detail/CVE-2026-89768"
      ]
    },
    "related_cves": [
      {
        "value": "CVE-2026-89768",
        "evidence": "/upstream"
      }
    ],
    "security_relevant": true,
    "severity_evidence": null
  },
  "source_id": "core-osv",
  "document_id": 404397,
  "published_at": "2026-09-11T20:20:08+00:00"
}