OESA-2026-3985

See a problem?
Please try reporting it to the source first.

Source

https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2026-3985

Import Source

https://repo.openeuler.org/security/data/osv/OESA-2026-3985.json

JSON Data

https://api.osv.dev/v1/vulns/OESA-2026-3985

Upstream

CVE (3)

Published

2026-09-20T13:23:51Z

Modified

2026-09-20T13:30:32Z

Severity

9.8 (Critical) CVSS_V3 - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H CVSS Calculator

Summary

kernel security update

Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

configfs: fix lockless traversals of ->s_children

Having the parent directory locked protects entries from removal by another thread, but it does not protect cursors from being moved around by lseek() - or freed, for that matter.(CVE-2026-74330)

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

configfs_lookup(): don't leave ->s_dentry dangling on failure

Normally ->s_dentry is cleared when dentry it's pointing to becomes negative (on eviction, realistically). However, that only happens if dentry gets to be positive in the first place; in case of inode allocation failure dentry never becomes positive, so ->d_iput() is not called at all.

We do part of what normally would've been done by configfs_d_iput() (dropping the reference to configfs_dirent) manually, but we do not clear ->s_dentry there. Sloppy as it is, it does not matter in case of configfs_create_{dir,link}() - there configfs_dirent does not survive dropping the sole reference to it.

However, for configfs_lookup() it does survive, with a dangling pointer to soon to be freed dentry sitting it its ->s_dentry.

Subsequent getdents(2) in that directory will end up dereferencing that pointer in order to pick the inode number. Use after free...

This is the minimal fix; the right approach is to set the linkage between dentry and configfs_dirent only after we know that we have an inode, but that takes more surgery and the bug had been there since 2006, so...(CVE-2026-74359)

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

NFS: Pin the 'struct nfs_server' during a FREE_STATEID call

Dan Aloni reports that he was able to hit a use-after-free bug if a FREE_STATEID operation gets delayed for whatever reason. Fix this by bumping the refcount of the 'struct nfs_server' object for the duration of the FREE_STATEID so it doesn't get cleaned up from underneath us while operations are still in flight.(CVE-2026-74730)

Database specific

{
    "severity":  "Critical"
}

References

Affected packages

openEuler:20.03-LTS-SP4 / kernel

Package

Name: kernel
Purl: pkg:rpm/openEuler/kernel&distro=openEuler-20.03-LTS-SP4

Affected ranges

Type: ECOSYSTEM
Events: Introduced

0 Unknown introduced version / All previous versions are affected

Fixed

4.19.90-2609.2.0.0390.oe2003sp4

Ecosystem specific

{
    "aarch64":  [
        "bpftool-4.19.90-2609.2.0.0390.oe2003sp4.aarch64.rpm",
        "bpftool-debuginfo-4.19.90-2609.2.0.0390.oe2003sp4.aarch64.rpm",
        "kernel-4.19.90-2609.2.0.0390.oe2003sp4.aarch64.rpm",
        "kernel-debuginfo-4.19.90-2609.2.0.0390.oe2003sp4.aarch64.rpm",
        "kernel-debugsource-4.19.90-2609.2.0.0390.oe2003sp4.aarch64.rpm",
        "kernel-devel-4.19.90-2609.2.0.0390.oe2003sp4.aarch64.rpm",
        "kernel-source-4.19.90-2609.2.0.0390.oe2003sp4.aarch64.rpm",
        "kernel-tools-4.19.90-2609.2.0.0390.oe2003sp4.aarch64.rpm",
        "kernel-tools-debuginfo-4.19.90-2609.2.0.0390.oe2003sp4.aarch64.rpm",
        "kernel-tools-devel-4.19.90-2609.2.0.0390.oe2003sp4.aarch64.rpm",
        "perf-4.19.90-2609.2.0.0390.oe2003sp4.aarch64.rpm",
        "perf-debuginfo-4.19.90-2609.2.0.0390.oe2003sp4.aarch64.rpm",
        "python2-perf-4.19.90-2609.2.0.0390.oe2003sp4.aarch64.rpm",
        "python2-perf-debuginfo-4.19.90-2609.2.0.0390.oe2003sp4.aarch64.rpm",
        "python3-perf-4.19.90-2609.2.0.0390.oe2003sp4.aarch64.rpm",
        "python3-perf-debuginfo-4.19.90-2609.2.0.0390.oe2003sp4.aarch64.rpm"
    ],
    "src":  [
        "kernel-4.19.90-2609.2.0.0390.oe2003sp4.src.rpm"
    ],
    "x86_64":  [
        "bpftool-4.19.90-2609.2.0.0390.oe2003sp4.x86_64.rpm",
        "bpftool-debuginfo-4.19.90-2609.2.0.0390.oe2003sp4.x86_64.rpm",
        "kernel-4.19.90-2609.2.0.0390.oe2003sp4.x86_64.rpm",
        "kernel-debuginfo-4.19.90-2609.2.0.0390.oe2003sp4.x86_64.rpm",
        "kernel-debugsource-4.19.90-2609.2.0.0390.oe2003sp4.x86_64.rpm",
        "kernel-devel-4.19.90-2609.2.0.0390.oe2003sp4.x86_64.rpm",
        "kernel-source-4.19.90-2609.2.0.0390.oe2003sp4.x86_64.rpm",
        "kernel-tools-4.19.90-2609.2.0.0390.oe2003sp4.x86_64.rpm",
        "kernel-tools-debuginfo-4.19.90-2609.2.0.0390.oe2003sp4.x86_64.rpm",
        "kernel-tools-devel-4.19.90-2609.2.0.0390.oe2003sp4.x86_64.rpm",
        "perf-4.19.90-2609.2.0.0390.oe2003sp4.x86_64.rpm",
        "perf-debuginfo-4.19.90-2609.2.0.0390.oe2003sp4.x86_64.rpm",
        "python2-perf-4.19.90-2609.2.0.0390.oe2003sp4.x86_64.rpm",
        "python2-perf-debuginfo-4.19.90-2609.2.0.0390.oe2003sp4.x86_64.rpm",
        "python3-perf-4.19.90-2609.2.0.0390.oe2003sp4.x86_64.rpm",
        "python3-perf-debuginfo-4.19.90-2609.2.0.0390.oe2003sp4.x86_64.rpm"
    ]
}

Database specific

source

"https://repo.openeuler.org/security/data/osv/OESA-2026-3985.json"