OESA-2025-1337

Source
https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2025-1337
Import Source
https://repo.openeuler.org/security/data/osv/OESA-2025-1337.json
JSON Data
https://api.test.osv.dev/v1/vulns/OESA-2025-1337
Upstream
Published
2025-03-29T06:23:07Z
Modified
2025-08-12T05:38:05.574702Z
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:

drm/amd/display: Fix memory leak

[why] Resource release is needed on the error handling path to prevent memory leak.

[how] Fix this by adding kfree on the error handling path.(CVE-2022-49135)

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

block: fix rq-qos breakage from skipping rqqosdone_bio()

a647a524a467 ("block: don't call rqqosops->donebio if the bio isn't tracked") made bioendio() skip rqqosdonebio() if BIOTRACKED is not set. While this fixed a potential oops, it also broke blk-iocost by skipping the done_bio callback for merged bios.

Before, whether a bio goes through rqqosthrottle() or rqqosmerge(), rqqosdonebio() would be called on the bio on completion with BIOTRACKED distinguishing the former from the latter. rqqosdonebio() is not called for bios which wenth through rqqos_merge(). This royally confuses blk-iocost as the merged bios never finish and are considered perpetually in-flight.

One reliably reproducible failure mode is an intermediate cgroup geting stuck active preventing its children from being activated due to the leaf-only rule, leading to loss of control. The following is from resctl-bench protection scenario which emulates isolating a web server like workload from a memory bomb run on an iocost configuration which should yield a reasonable level of protection.

# cat /sys/block/nvme2n1/device/model Samsung SSD 970 PRO 512GB # cat /sys/fs/cgroup/io.cost.model 259:0 ctrl=user model=linear rbps=834913556 rseqiops=93622 rrandiops=102913 wbps=618985353 wseqiops=72325 wrandiops=71025 # cat /sys/fs/cgroup/io.cost.qos 259:0 enable=1 ctrl=user rpct=95.00 rlat=18776 wpct=95.00 wlat=8897 min=60.00 max=100.00 # resctl-bench -m 29.6G -r out.json run protection::scenario=mem-hog,loops=1 ... Memory Hog Summary ==================

IO Latency: R p50=242u:336u/2.5m p90=794u:1.4m/7.5m p99=2.7m:8.0m/62.5m max=8.0m:36.4m/350m W p50=221u:323u/1.5m p90=709u:1.2m/5.5m p99=1.5m:2.5m/9.5m max=6.9m:35.9m/350m

Isolation and Request Latency Impact Distributions:

            min   p01   p05   p10   p25   p50   p75   p90   p95   p99   max  mean stdev

isol% 15.90 15.90 15.90 40.05 57.24 59.07 60.01 74.63 74.63 90.35 90.35 58.12 15.82 lat-imp% 0 0 0 0 0 4.55 14.68 15.54 233.5 548.1 548.1 53.88 143.6

Result: isol=58.12:15.82% latimp=53.88%:143.6 workcsv=100.0% missing=3.96%

The isolation result of 58.12% is close to what this device would show without any IO control.

Fix it by introducing a new flag BIOQOSMERGED to mark merged bios and calling rqqosdonebio() on them too. For consistency and clarity, rename BIOTRACKED to BIOQOSTHROTTLED. The flag checks are moved into rqqosdone_bio() so that it's next to the code paths that set the flags.

With the patch applied, the above same benchmark shows:

# resctl-bench -m 29.6G -r out.json run protection::scenario=mem-hog,loops=1 ... Memory Hog Summary ==================

IO Latency: R p50=123u:84.4u/985u p90=322u:256u/2.5m p99=1.6m:1.4m/9.5m max=11.1m:36.0m/350m W p50=429u:274u/995u p90=1.7m:1.3m/4.5m p99=3.4m:2.7m/11.5m max=7.9m:5.9m/26.5m

Isolation and Request Latency Impact Distributions:

            min   p01   p05   p10   p25   p50   p75   p90   p95   p99   max  mean stdev

isol% 84.91 84.91 89.51 90.73 92.31 94.49 96.36 98.04 98.71 100.0 100.0 94.42 2.81 lat-imp% 0 0 0 0 0 2.81 5.73 11.11 13.92 17.53 22.61 4.10 4.68

Result: isol=94.42:2.81% latimp=4.10%:4.68 workcsv=58.34% missing=0%(CVE-2022-49266)

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

module: fix [eshstrndx].shsize=0 OOB access

It is trivial to craft a module to trigger OOB access in this line:

if (info->secstrings[strhdr->sh_size - 1] != '\0') {

BUG: unable to handle page fault for address: ffffc90000aa0fff PGD 100000067 P4D 100000067 PUD 100066067 PMD 10436f067 PTE 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 7 PID: 1215 Comm: insmod Not tainted 5.18.0-rc5-00007-g9bf578647087-dirty #10 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014 RIP: 0010:load_module+0x19b/0x2391

rebased patch onto modules-next

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

bus: fsl-mc-bus: fix KASAN use-after-free in fslmcbus_remove()

In fslmcbusremove(), mc->rootmcbusdev->mcio is passed to fsldestroymcio(). However, mc->rootmcbusdev is already freed in fslmcdeviceremove(). Then reference to mc->rootmcbusdev->mcio triggers KASAN use-after-free. To avoid the use-after-free, keep the reference to mc->rootmcbusdev->mcio in a local variable and pass to fsldestroymc_io().

This patch needs rework to apply to kernels older than v5.15.(CVE-2022-49711)

Database specific
{
    "severity": "High"
}
References

Affected packages

openEuler:22.03-LTS-SP3 / kernel

Package

Name
kernel
Purl
pkg:rpm/openEuler/kernel&distro=openEuler-22.03-LTS-SP3

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
5.10.0-257.0.0.159.oe2203sp3

Ecosystem specific

{
    "x86_64": [
        "kernel-5.10.0-257.0.0.159.oe2203sp3.x86_64.rpm",
        "kernel-debuginfo-5.10.0-257.0.0.159.oe2203sp3.x86_64.rpm",
        "kernel-debugsource-5.10.0-257.0.0.159.oe2203sp3.x86_64.rpm",
        "kernel-devel-5.10.0-257.0.0.159.oe2203sp3.x86_64.rpm",
        "kernel-headers-5.10.0-257.0.0.159.oe2203sp3.x86_64.rpm",
        "kernel-source-5.10.0-257.0.0.159.oe2203sp3.x86_64.rpm",
        "kernel-tools-5.10.0-257.0.0.159.oe2203sp3.x86_64.rpm",
        "kernel-tools-debuginfo-5.10.0-257.0.0.159.oe2203sp3.x86_64.rpm",
        "kernel-tools-devel-5.10.0-257.0.0.159.oe2203sp3.x86_64.rpm",
        "perf-5.10.0-257.0.0.159.oe2203sp3.x86_64.rpm",
        "perf-debuginfo-5.10.0-257.0.0.159.oe2203sp3.x86_64.rpm",
        "python3-perf-5.10.0-257.0.0.159.oe2203sp3.x86_64.rpm",
        "python3-perf-debuginfo-5.10.0-257.0.0.159.oe2203sp3.x86_64.rpm"
    ],
    "src": [
        "kernel-5.10.0-257.0.0.159.oe2203sp3.src.rpm"
    ],
    "aarch64": [
        "kernel-5.10.0-257.0.0.159.oe2203sp3.aarch64.rpm",
        "kernel-debuginfo-5.10.0-257.0.0.159.oe2203sp3.aarch64.rpm",
        "kernel-debugsource-5.10.0-257.0.0.159.oe2203sp3.aarch64.rpm",
        "kernel-devel-5.10.0-257.0.0.159.oe2203sp3.aarch64.rpm",
        "kernel-headers-5.10.0-257.0.0.159.oe2203sp3.aarch64.rpm",
        "kernel-source-5.10.0-257.0.0.159.oe2203sp3.aarch64.rpm",
        "kernel-tools-5.10.0-257.0.0.159.oe2203sp3.aarch64.rpm",
        "kernel-tools-debuginfo-5.10.0-257.0.0.159.oe2203sp3.aarch64.rpm",
        "kernel-tools-devel-5.10.0-257.0.0.159.oe2203sp3.aarch64.rpm",
        "perf-5.10.0-257.0.0.159.oe2203sp3.aarch64.rpm",
        "perf-debuginfo-5.10.0-257.0.0.159.oe2203sp3.aarch64.rpm",
        "python3-perf-5.10.0-257.0.0.159.oe2203sp3.aarch64.rpm",
        "python3-perf-debuginfo-5.10.0-257.0.0.159.oe2203sp3.aarch64.rpm"
    ]
}