Common Weakness Enumeration

CWE-908

Allowed

Use of Uninitialized Resource

Abstraction: Base · Status: Incomplete

The product uses or accesses a resource that has not been initialized.

899 vulnerabilities reference this CWE, most recent first.

GHSA-J86M-G62R-5G7R

Vulnerability from github – Published: 2022-05-02 03:37 – Updated: 2024-02-09 00:31
VLAI
Details

The Linux kernel 2.6.0 through 2.6.30.4, and 2.4.4 through 2.4.37.4, does not initialize all function pointers for socket operations in proto_ops structures, which allows local users to trigger a NULL pointer dereference and gain privileges by using mmap to map page zero, placing arbitrary code on this page, and then invoking an unavailable operation, as demonstrated by the sendpage operation (sock_sendpage function) on a PF_PPPOX socket.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2009-2692"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-119",
      "CWE-908"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2009-08-14T15:16:00Z",
    "severity": "HIGH"
  },
  "details": "The Linux kernel 2.6.0 through 2.6.30.4, and 2.4.4 through 2.4.37.4, does not initialize all function pointers for socket operations in proto_ops structures, which allows local users to trigger a NULL pointer dereference and gain privileges by using mmap to map page zero, placing arbitrary code on this page, and then invoking an unavailable operation, as demonstrated by the sendpage operation (sock_sendpage function) on a PF_PPPOX socket.",
  "id": "GHSA-j86m-g62r-5g7r",
  "modified": "2024-02-09T00:31:33Z",
  "published": "2022-05-02T03:37:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2009-2692"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=516949"
    },
    {
      "type": "WEB",
      "url": "https://issues.rpath.com/browse/RPL-3103"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A11526"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A11591"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A8657"
    },
    {
      "type": "WEB",
      "url": "http://archives.neohapsis.com/archives/fulldisclosure/2009-08/0174.html"
    },
    {
      "type": "WEB",
      "url": "http://blog.cr0.org/2009/08/linux-null-pointer-dereference-due-to.html"
    },
    {
      "type": "WEB",
      "url": "http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.4.37.y.git%3Ba=commit%3Bh=c18d0fe535a73b219f960d1af3d0c264555a12e3"
    },
    {
      "type": "WEB",
      "url": "http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.4.37.y.git;a=commit;h=c18d0fe535a73b219f960d1af3d0c264555a12e3"
    },
    {
      "type": "WEB",
      "url": "http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git%3Ba=commit%3Bh=e694958388c50148389b0e9b9e9e8945cf0f1b98"
    },
    {
      "type": "WEB",
      "url": "http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e694958388c50148389b0e9b9e9e8945cf0f1b98"
    },
    {
      "type": "WEB",
      "url": "http://grsecurity.net/~spender/wunderbar_emporium.tgz"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2009-09/msg00001.html"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2009-1222.html"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2009-1223.html"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/36278"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/36289"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/36327"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/36430"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/37298"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/37471"
    },
    {
      "type": "WEB",
      "url": "http://support.avaya.com/css/P8/documents/100067254"
    },
    {
      "type": "WEB",
      "url": "http://wiki.rpath.com/wiki/Advisories:rPSA-2009-0121"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2009/dsa-1865"
    },
    {
      "type": "WEB",
      "url": "http://www.exploit-db.com/exploits/19933"
    },
    {
      "type": "WEB",
      "url": "http://www.exploit-db.com/exploits/9477"
    },
    {
      "type": "WEB",
      "url": "http://www.kernel.org/pub/linux/kernel/v2.4/ChangeLog-2.4.37.5"
    },
    {
      "type": "WEB",
      "url": "http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.30.5"
    },
    {
      "type": "WEB",
      "url": "http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.31-rc6"
    },
    {
      "type": "WEB",
      "url": "http://www.mandriva.com/security/advisories?name=MDVSA-2009:233"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2009/08/14/1"
    },
    {
      "type": "WEB",
      "url": "http://www.redhat.com/support/errata/RHSA-2009-1233.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/505751/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/505912/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/507985/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/512019/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/36038"
    },
    {
      "type": "WEB",
      "url": "http://www.vmware.com/security/advisories/VMSA-2009-0016.html"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2009/2272"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2009/3316"
    },
    {
      "type": "WEB",
      "url": "http://zenthought.org/content/file/android-root-2009-08-16-source"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J8QQ-58CR-8CC7

Vulnerability from github – Published: 2021-08-25 20:52 – Updated: 2022-05-05 00:44
VLAI
Summary
Out of bounds read in bra
Details

Buffered Random Access (BRA) provides easy random memory access to a sequential source of data in Rust. This is achieved by greedily retaining all memory read from a given source. Buffered Random Access (BRA) provides easy random memory access to a sequential source of data in Rust. An issue was discovered in the bra crate before 0.1.1 for Rust. It lacks soundness because it can read uninitialized memory.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "bra"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-25905"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125",
      "CWE-908"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-08-19T18:46:05Z",
    "nvd_published_at": "2021-01-26T18:16:00Z",
    "severity": "CRITICAL"
  },
  "details": "Buffered Random Access (BRA) provides easy random memory access to a sequential source of data in Rust. This is achieved by greedily retaining all memory read from a given source. Buffered Random Access (BRA) provides easy random memory access to a sequential source of data in Rust. An issue was discovered in the bra crate before 0.1.1 for Rust. It lacks soundness because it can read uninitialized memory.",
  "id": "GHSA-j8qq-58cr-8cc7",
  "modified": "2022-05-05T00:44:22Z",
  "published": "2021-08-25T20:52:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25905"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Enet4/bra-rs/issues/1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Enet4/bra-rs/commit/aabf5562f8c6374ab30f615b28e0cff9b5c79e5f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Enet4/bra-rs"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2021-0008.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Out of bounds read in bra"
}

GHSA-J92M-G7G3-P573

Vulnerability from github – Published: 2025-08-19 18:31 – Updated: 2026-01-07 21:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

bpf, ktls: Fix data corruption when using bpf_msg_pop_data() in ktls

When sending plaintext data, we initially calculated the corresponding ciphertext length. However, if we later reduced the plaintext data length via socket policy, we failed to recalculate the ciphertext length.

This results in transmitting buffers containing uninitialized data during ciphertext transmission.

This causes uninitialized bytes to be appended after a complete "Application Data" packet, leading to errors on the receiving end when parsing TLS record.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-38608"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-908"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-19T17:15:39Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, ktls: Fix data corruption when using bpf_msg_pop_data() in ktls\n\nWhen sending plaintext data, we initially calculated the corresponding\nciphertext length. However, if we later reduced the plaintext data length\nvia socket policy, we failed to recalculate the ciphertext length.\n\nThis results in transmitting buffers containing uninitialized data during\nciphertext transmission.\n\nThis causes uninitialized bytes to be appended after a complete\n\"Application Data\" packet, leading to errors on the receiving end when\nparsing TLS record.",
  "id": "GHSA-j92m-g7g3-p573",
  "modified": "2026-01-07T21:31:39Z",
  "published": "2025-08-19T18:31:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38608"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0e853c1464bcf61207f8b5c32d2ac5ee495e859d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/16aca8bb4ad0d8a13c8b6da4007f4e52d53035bb"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/178f6a5c8cb3b6be1602de0964cd440243f493c9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1e480387d4b42776f8957fb148af9d75ce93b96d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6ba20ff3cdb96a908b9dc93cf247d0b087672e7c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/73fc5d04009d3969ff8e8574f0fd769f04124e59"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/849d24dc5aed45ebeb3490df429356739256ac40"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/90d6ef67440cec2a0aad71a0108c8f216437345c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ee03766d79de0f61ea29ffb6ab1c7b196ea1b02e"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JC9R-34FJ-74J2

Vulnerability from github – Published: 2022-05-24 19:18 – Updated: 2022-05-24 19:18
VLAI
Details

This vulnerability allows local attackers to disclose sensitive information on affected installations of Parallels Desktop 16.1.3 (49160). An attacker must first obtain the ability to execute low-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the Toolgate component. The issue results from the lack of proper initialization of memory prior to accessing it. An attacker can leverage this in conjunction with other vulnerabilities to escalate privileges and execute arbitrary code in the context of the hypervisor. Was ZDI-CAN-13592.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-34855"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-908"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-10-25T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "This vulnerability allows local attackers to disclose sensitive information on affected installations of Parallels Desktop 16.1.3 (49160). An attacker must first obtain the ability to execute low-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the Toolgate component. The issue results from the lack of proper initialization of memory prior to accessing it. An attacker can leverage this in conjunction with other vulnerabilities to escalate privileges and execute arbitrary code in the context of the hypervisor. Was ZDI-CAN-13592.",
  "id": "GHSA-jc9r-34fj-74j2",
  "modified": "2022-05-24T19:18:42Z",
  "published": "2022-05-24T19:18:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34855"
    },
    {
      "type": "WEB",
      "url": "https://kb.parallels.com/125013"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-21-939"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-JCP9-WRQQ-GG3H

Vulnerability from github – Published: 2024-09-24 00:31 – Updated: 2024-09-25 21:30
VLAI
Details

Uninitialized Use in V8 in Google Chrome prior to 123.0.6312.58 allowed a remote attacker to perform out of bounds memory access via a crafted HTML page. (Chromium security severity: Medium)

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-7022"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-457",
      "CWE-908"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-23T22:15:03Z",
    "severity": "HIGH"
  },
  "details": "Uninitialized Use in V8 in Google Chrome prior to 123.0.6312.58 allowed a remote attacker to perform out of bounds memory access via a crafted HTML page. (Chromium security severity: Medium)",
  "id": "GHSA-jcp9-wrqq-gg3h",
  "modified": "2024-09-25T21:30:34Z",
  "published": "2024-09-24T00:31:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7022"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/324690505"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JCXM-CFV5-GP8J

Vulnerability from github – Published: 2024-01-09 18:30 – Updated: 2024-01-09 18:30
VLAI
Details

Windows CoreMessaging Information Disclosure Vulnerability

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-20694"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-668",
      "CWE-908"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-09T18:15:52Z",
    "severity": "MODERATE"
  },
  "details": "Windows CoreMessaging Information Disclosure  Vulnerability",
  "id": "GHSA-jcxm-cfv5-gp8j",
  "modified": "2024-01-09T18:30:29Z",
  "published": "2024-01-09T18:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-20694"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-20694"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JJ65-JVHX-4H6P

Vulnerability from github – Published: 2024-11-26 00:33 – Updated: 2026-05-12 15:30
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

fs: Fix uninitialized value issue in from_kuid and from_kgid

ocfs2_setattr() uses attr->ia_mode, attr->ia_uid and attr->ia_gid in a trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren't set.

Initialize all fields of newattrs to avoid uninitialized variables, by checking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-53101"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-908"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-25T22:15:17Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs: Fix uninitialized value issue in from_kuid and from_kgid\n\nocfs2_setattr() uses attr-\u003eia_mode, attr-\u003eia_uid and attr-\u003eia_gid in\na trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren\u0027t set.\n\nInitialize all fields of newattrs to avoid uninitialized variables, by\nchecking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0.",
  "id": "GHSA-jj65-jvhx-4h6p",
  "modified": "2026-05-12T15:30:41Z",
  "published": "2024-11-26T00:33:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53101"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-355557.html"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/15f34347481648a567db67fb473c23befb796af5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/17ecb40c5cc7755a321fb6148cba5797431ee5b8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1c28bca1256aecece6e94b26b85cd07e08b0dc90"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1cb5bfc5bfc651982b6203c224d49b7ddacf28bc"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5a72b0d3497b818d8f000c347a7c11801eb27bfc"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9db25c2b41c34963c3ccf473b08171f87670652e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a0c77e5e3dcbffc7c6080ccc89c037f0c86496cf"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b3e612bd8f64ce62e731e95f635e06a2efe3c80c"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JJH5-MVRV-5XMG

Vulnerability from github – Published: 2026-07-19 18:31 – Updated: 2026-08-13 15:34
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

mm/page_alloc: fix initialization of tags of the huge zero folio with init_on_free

__GFP_ZEROTAGS semantics are currently a bit weird, but effectively this flag is only ever set alongside __GFP_ZERO and __GFP_SKIP_KASAN.

If we run with init_on_free, we will zero out pages during __free_pages_prepare(), to skip zeroing on the allocation path.

However, when allocating with __GFP_ZEROTAG set, post_alloc_hook() will consequently not only skip clearing page content, but also skip clearing tag memory.

Not clearing tags through __GFP_ZEROTAGS is irrelevant for most pages that will get mapped to user space through set_pte_at() later: set_pte_at() and friends will detect that the tags have not been initialized yet (PG_mte_tagged not set), and initialize them.

However, for the huge zero folio, which will be mapped through a PMD marked as special, this initialization will not be performed, ending up exposing whatever tags were still set for the pages.

The docs (Documentation/arch/arm64/memory-tagging-extension.rst) state that allocation tags are set to 0 when a page is first mapped to user space. That no longer holds with the huge zero folio when init_on_free is enabled.

Fix it by decoupling __GFP_ZEROTAGS from __GFP_ZERO, passing to tag_clear_highpages() whether we want to also clear page content.

Invert the meaning of the tag_clear_highpages() return value to have clearer semantics.

Reproduced with the huge zero folio by modifying the check_buffer_fill arm64/mte selftest to use a 2 MiB area, after making sure that pages have a non-0 tag set when freeing (note that, during boot, we will not actually initialize tags, but only set KASAN_TAG_KERNEL in the page flags).

$ ./check_buffer_fill
1..20
...
not ok 17 Check initial tags with private mapping, sync error mode and mmap memory
not ok 18 Check initial tags with private mapping, sync error mode and mmap/mprotect memory
...

This code needs more cleanups; we'll tackle that next, like decoupling __GFP_ZEROTAGS from __GFP_SKIP_KASAN.

[akpm@linux-foundation.org: s/__GPF_ZERO/__GFP_ZERO/, per David]

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-64130"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-908"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-19T16:17:54Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/page_alloc: fix initialization of tags of the huge zero folio with init_on_free\n\n__GFP_ZEROTAGS semantics are currently a bit weird, but effectively this\nflag is only ever set alongside __GFP_ZERO and __GFP_SKIP_KASAN.\n\nIf we run with init_on_free, we will zero out pages during\n__free_pages_prepare(), to skip zeroing on the allocation path.\n\nHowever, when allocating with __GFP_ZEROTAG set, post_alloc_hook() will\nconsequently not only skip clearing page content, but also skip clearing\ntag memory.\n\nNot clearing tags through __GFP_ZEROTAGS is irrelevant for most pages that\nwill get mapped to user space through set_pte_at() later: set_pte_at() and\nfriends will detect that the tags have not been initialized yet\n(PG_mte_tagged not set), and initialize them.\n\nHowever, for the huge zero folio, which will be mapped through a PMD\nmarked as special, this initialization will not be performed, ending up\nexposing whatever tags were still set for the pages.\n\nThe docs (Documentation/arch/arm64/memory-tagging-extension.rst) state\nthat allocation tags are set to 0 when a page is first mapped to user\nspace.  That no longer holds with the huge zero folio when init_on_free is\nenabled.\n\nFix it by decoupling __GFP_ZEROTAGS from __GFP_ZERO, passing to\ntag_clear_highpages() whether we want to also clear page content.\n\nInvert the meaning of the tag_clear_highpages() return value to have\nclearer semantics.\n\nReproduced with the huge zero folio by modifying the check_buffer_fill\narm64/mte selftest to use a 2 MiB area, after making sure that pages have\na non-0 tag set when freeing (note that, during boot, we will not actually\ninitialize tags, but only set KASAN_TAG_KERNEL in the page flags).\n\n\t$ ./check_buffer_fill\n\t1..20\n\t...\n\tnot ok 17 Check initial tags with private mapping, sync error mode and mmap memory\n\tnot ok 18 Check initial tags with private mapping, sync error mode and mmap/mprotect memory\n\t...\n\nThis code needs more cleanups; we\u0027ll tackle that next, like\ndecoupling __GFP_ZEROTAGS from __GFP_SKIP_KASAN.\n\n[akpm@linux-foundation.org: s/__GPF_ZERO/__GFP_ZERO/, per David]",
  "id": "GHSA-jjh5-mvrv-5xmg",
  "modified": "2026-08-13T15:34:13Z",
  "published": "2026-07-19T18:31:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64130"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2f2aec5120b93a8f8b52dc50cdc60dbb8aec72f6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6a288a4ddb4a994490505ab5f41c445f8e6b6467"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/738d18f1da3513d17b6f7bf30146cc4ac2480ffd"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JJWM-G4J5-Q96V

Vulnerability from github – Published: 2026-08-19 09:31 – Updated: 2026-08-26 18:31
VLAI
Details

The compat32 kevent() handler translates a 64-bit kevent struct into a stack- declared 32-bit struct. It did not first zero the stack struct.

An unprivileged user may observe a small amount of uninitialized kernel stack data, which may contain sensitive information.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-49425"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-908"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-19T08:17:12Z",
    "severity": "MODERATE"
  },
  "details": "The compat32 kevent() handler translates a 64-bit kevent struct into a stack- declared 32-bit struct.  It did not first zero the stack struct.\n\nAn unprivileged user may observe a small amount of uninitialized kernel stack data, which may contain sensitive information.",
  "id": "GHSA-jjwm-g4j5-q96v",
  "modified": "2026-08-26T18:31:14Z",
  "published": "2026-08-19T09:31:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49425"
    },
    {
      "type": "WEB",
      "url": "https://security.freebsd.org/advisories/FreeBSD-SA-26:48.compat32.asc"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JM7V-C85H-4VVR

Vulnerability from github – Published: 2024-05-21 18:31 – Updated: 2025-09-24 00:30
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

llc: verify mac len before reading mac header

LLC reads the mac header with eth_hdr without verifying that the skb has an Ethernet header.

Syzbot was able to enter llc_rcv on a tun device. Tun can insert packets without mac len and with user configurable skb->protocol (passing a tun_pi header when not configuring IFF_NO_PI).

BUG: KMSAN: uninit-value in llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]
BUG: KMSAN: uninit-value in llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111
llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]
llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111
llc_rcv+0xc5d/0x14a0 net/llc/llc_input.c:218
__netif_receive_skb_one_core net/core/dev.c:5523 [inline]
__netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637
netif_receive_skb_internal net/core/dev.c:5723 [inline]
netif_receive_skb+0x58/0x660 net/core/dev.c:5782
tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
tun_get_user+0x54c5/0x69c0 drivers/net/tun.c:2002

Add a mac_len test before all three eth_hdr(skb) calls under net/llc.

There are further uses in include/net/llc_pdu.h. All these are protected by a test skb->protocol == ETH_P_802_2. Which does not protect against this tun scenario.

But the mac_len test added in this patch in llc_fixup_skb will indirectly protect those too. That is called from llc_rcv before any other LLC code.

It is tempting to just add a blanket mac_len check in llc_rcv, but not sure whether that could break valid LLC paths that do not assume an Ethernet header. 802.2 LLC may be used on top of non-802.3 protocols in principle. The below referenced commit shows that used to, on top of Token Ring.

At least one of the three eth_hdr uses goes back to before the start of git history. But the one that syzbot exercises is introduced in this commit. That commit is old enough (2008), that effectively all stable kernels should receive this.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-52843"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-908"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-21T16:15:21Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nllc: verify mac len before reading mac header\n\nLLC reads the mac header with eth_hdr without verifying that the skb\nhas an Ethernet header.\n\nSyzbot was able to enter llc_rcv on a tun device. Tun can insert\npackets without mac len and with user configurable skb-\u003eprotocol\n(passing a tun_pi header when not configuring IFF_NO_PI).\n\n    BUG: KMSAN: uninit-value in llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]\n    BUG: KMSAN: uninit-value in llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111\n    llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]\n    llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111\n    llc_rcv+0xc5d/0x14a0 net/llc/llc_input.c:218\n    __netif_receive_skb_one_core net/core/dev.c:5523 [inline]\n    __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637\n    netif_receive_skb_internal net/core/dev.c:5723 [inline]\n    netif_receive_skb+0x58/0x660 net/core/dev.c:5782\n    tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555\n    tun_get_user+0x54c5/0x69c0 drivers/net/tun.c:2002\n\nAdd a mac_len test before all three eth_hdr(skb) calls under net/llc.\n\nThere are further uses in include/net/llc_pdu.h. All these are\nprotected by a test skb-\u003eprotocol == ETH_P_802_2. Which does not\nprotect against this tun scenario.\n\nBut the mac_len test added in this patch in llc_fixup_skb will\nindirectly protect those too. That is called from llc_rcv before any\nother LLC code.\n\nIt is tempting to just add a blanket mac_len check in llc_rcv, but\nnot sure whether that could break valid LLC paths that do not assume\nan Ethernet header. 802.2 LLC may be used on top of non-802.3\nprotocols in principle. The below referenced commit shows that used\nto, on top of Token Ring.\n\nAt least one of the three eth_hdr uses goes back to before the start\nof git history. But the one that syzbot exercises is introduced in\nthis commit. That commit is old enough (2008), that effectively all\nstable kernels should receive this.",
  "id": "GHSA-jm7v-c85h-4vvr",
  "modified": "2025-09-24T00:30:40Z",
  "published": "2024-05-21T18:31:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52843"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0a720d0259ad3521ec6c9e4199f9f6fc75bac77a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/352887b3edd007cf9b0abc30fe9d98622acd859b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3a2653828ffc6101aef80bf58d5b77484239f779"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7b3ba18703a63f6fd487183b9262b08e5632da1b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/900a4418e3f66a32db6baaf23f92b99c20ae6535"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9a3f9054a5227d7567cba1fb821df48ccecad10c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cbdcdf42d15dac74c7287679fb2a9d955f8feb1f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f980e9a57dfb9530f1f4ee41a2420f2a256d7b29"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ff5cb6a4f0c6d7fbdc84858323fb4b7af32cfd79"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Implementation

Explicitly initialize the resource before use. If this is performed through an API function or standard procedure, follow all required steps.

Mitigation
Implementation

Pay close attention to complex conditionals that affect initialization, since some branches might not perform the initialization.

Mitigation
Implementation

Avoid race conditions (CWE-362) during initialization routines.

Mitigation
Build and Compilation

Run or compile the product with settings that generate warnings about uninitialized variables or data.

No CAPEC attack patterns related to this CWE.