jiachao2130/cvrf2cusa
1
0
Fork 1
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
0b34274085
cvrf2cusa/cvrf/2024/cvrf-openEuler-SA-2024-1837.xml
Jia Chao 0b34274085 git mv 
Signed-off-by: Jia Chao <jiac13@chinaunicom.cn>
2024-07-25 09:57:37 +08:00

574 lines
26 KiB
XML
Raw Blame History

<?xml version="1.0" encoding="UTF-8"?>
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
<DocumentTitle xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP4</DocumentTitle>
<DocumentType>Security Advisory</DocumentType>
<DocumentPublisher Type="Vendor">
<ContactDetails>openeuler-security@openeuler.org</ContactDetails>
<IssuingAuthority>openEuler security committee</IssuingAuthority>
</DocumentPublisher>
<DocumentTracking>
<Identification>
<ID>openEuler-SA-2024-1837</ID>
</Identification>
<Status>Final</Status>
<Version>1.0</Version>
<RevisionHistory>
<Revision>
<Number>1.0</Number>
<Date>2024-07-12</Date>
<Description>Initial</Description>
</Revision>
</RevisionHistory>
<InitialReleaseDate>2024-07-12</InitialReleaseDate>
<CurrentReleaseDate>2024-07-12</CurrentReleaseDate>
<Generator>
<Engine>openEuler SA Tool V1.0</Engine>
<Date>2024-07-12</Date>
</Generator>
</DocumentTracking>
<DocumentNotes>
<Note Title="Synopsis" Type="General" Ordinal="1" xml:lang="en">kernel security update</Note>
<Note Title="Summary" Type="General" Ordinal="2" xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP4</Note>
<Note Title="Description" Type="General" Ordinal="3" xml:lang="en">The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
ARM: 9170/1: fix panic when kasan and kprobe are enabled
arm32 uses software to simulate the instruction replaced
by kprobe. some instructions may be simulated by constructing
assembly functions. therefore, before executing instruction
simulation, it is necessary to construct assembly function
execution environment in C language through binding registers.
after kasan is enabled, the register binding relationship will
be destroyed, resulting in instruction simulation errors and
causing kernel panic.
the kprobe emulate instruction function is distributed in three
files: actions-common.c actions-arm.c actions-thumb.c, so disable
KASAN when compiling these files.
for example, use kprobe insert on cap_capable+20 after kasan
enabled, the cap_capable assembly code is as follows:
&lt;cap_capable&gt;:
e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr}
e1a05000 mov r5, r0
e280006c add r0, r0, #108 ; 0x6c
e1a04001 mov r4, r1
e1a06002 mov r6, r2
e59fa090 ldr sl, [pc, #144] ;
ebfc7bf8 bl c03aa4b4 &lt;__asan_load4&gt;
e595706c ldr r7, [r5, #108] ; 0x6c
e2859014 add r9, r5, #20
......
The emulate_ldr assembly code after enabling kasan is as follows:
c06f1384 &lt;emulate_ldr&gt;:
e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr}
e282803c add r8, r2, #60 ; 0x3c
e1a05000 mov r5, r0
e7e37855 ubfx r7, r5, #16, #4
e1a00008 mov r0, r8
e1a09001 mov r9, r1
e1a04002 mov r4, r2
ebf35462 bl c03c6530 &lt;__asan_load4&gt;
e357000f cmp r7, #15
e7e36655 ubfx r6, r5, #12, #4
e205a00f and sl, r5, #15
0a000001 beq c06f13bc &lt;emulate_ldr+0x38&gt;
e0840107 add r0, r4, r7, lsl #2
ebf3545c bl c03c6530 &lt;__asan_load4&gt;
e084010a add r0, r4, sl, lsl #2
ebf3545a bl c03c6530 &lt;__asan_load4&gt;
e2890010 add r0, r9, #16
ebf35458 bl c03c6530 &lt;__asan_load4&gt;
e5990010 ldr r0, [r9, #16]
e12fff30 blx r0
e356000f cm r6, #15
1a000014 bne c06f1430 &lt;emulate_ldr+0xac&gt;
e1a06000 mov r6, r0
e2840040 add r0, r4, #64 ; 0x40
......
when running in emulate_ldr to simulate the ldr instruction, panic
occurred, and the log is as follows:
Unable to handle kernel NULL pointer dereference at virtual address
00000090
pgd = ecb46400
[00000090] *pgd=2e0fa003, *pmd=00000000
Internal error: Oops: 206 [#1] SMP ARM
PC is at cap_capable+0x14/0xb0
LR is at emulate_ldr+0x50/0xc0
psr: 600d0293 sp : ecd63af8 ip : 00000004 fp : c0a7c30c
r10: 00000000 r9 : c30897f4 r8 : ecd63cd4
r7 : 0000000f r6 : 0000000a r5 : e59fa090 r4 : ecd63c98
r3 : c06ae294 r2 : 00000000 r1 : b7611300 r0 : bf4ec008
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
Control: 32c5387d Table: 2d546400 DAC: 55555555
Process bash (pid: 1643, stack limit = 0xecd60190)
(cap_capable) from (kprobe_handler+0x218/0x340)
(kprobe_handler) from (kprobe_trap_handler+0x24/0x48)
(kprobe_trap_handler) from (do_undefinstr+0x13c/0x364)
(do_undefinstr) from (__und_svc_finish+0x0/0x30)
(__und_svc_finish) from (cap_capable+0x18/0xb0)
(cap_capable) from (cap_vm_enough_memory+0x38/0x48)
(cap_vm_enough_memory) from
(security_vm_enough_memory_mm+0x48/0x6c)
(security_vm_enough_memory_mm) from
(copy_process.constprop.5+0x16b4/0x25c8)
(copy_process.constprop.5) from (_do_fork+0xe8/0x55c)
(_do_fork) from (SyS_clone+0x1c/0x24)
(SyS_clone) from (__sys_trace_return+0x0/0x10)
Code: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7)(CVE-2021-47618)
In the Linux kernel, the following vulnerability has been resolved:
ax25: Fix reference count leak issue of net_device
There is a reference count leak issue of the object &quot;net_device&quot; in
ax25_dev_device_down(). When the ax25 device is shutting down, the
ax25_dev_device_down() drops the reference count of net_device one
or zero times depending on if we goto unlock_put or not, which will
cause memory leak.
In order to solve the above issue, decrease the reference count of
net_device after dev-&gt;ax25_ptr is set to null.(CVE-2024-38554)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix potential hang in nilfs_detach_log_writer()
Syzbot has reported a potential hang in nilfs_detach_log_writer() called
during nilfs2 unmount.
Analysis revealed that this is because nilfs_segctor_sync(), which
synchronizes with the log writer thread, can be called after
nilfs_segctor_destroy() terminates that thread, as shown in the call trace
below:
nilfs_detach_log_writer
nilfs_segctor_destroy
nilfs_segctor_kill_thread --&gt; Shut down log writer thread
flush_work
nilfs_iput_work_func
nilfs_dispose_list
iput
nilfs_evict_inode
nilfs_transaction_commit
nilfs_construct_segment (if inode needs sync)
nilfs_segctor_sync --&gt; Attempt to synchronize with
log writer thread
*** DEADLOCK ***
Fix this issue by changing nilfs_segctor_sync() so that the log writer
thread returns normally without synchronizing after it terminates, and by
forcing tasks that are already waiting to complete once after the thread
terminates.
The skipped inode metadata flushout will then be processed together in the
subsequent cleanup work in nilfs_segctor_destroy().(CVE-2024-38582)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix use-after-free of timer for log writer thread
Patch series &quot;nilfs2: fix log writer related issues&quot;.
This bug fix series covers three nilfs2 log writer-related issues,
including a timer use-after-free issue and potential deadlock issue on
unmount, and a potential freeze issue in event synchronization found
during their analysis. Details are described in each commit log.
This patch (of 3):
A use-after-free issue has been reported regarding the timer sc_timer on
the nilfs_sc_info structure.
The problem is that even though it is used to wake up a sleeping log
writer thread, sc_timer is not shut down until the nilfs_sc_info structure
is about to be freed, and is used regardless of the thread&apos;s lifetime.
Fix this issue by limiting the use of sc_timer only while the log writer
thread is alive.(CVE-2024-38583)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Check &apos;folio&apos; pointer for NULL
It can be NULL if bmap is called.(CVE-2024-38625)</Note>
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP4.
openEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.</Note>
<Note Title="Severity" Type="General" Ordinal="5" xml:lang="en">High</Note>
<Note Title="Affected Component" Type="General" Ordinal="6" xml:lang="en">kernel</Note>
</DocumentNotes>
<DocumentReferences>
<Reference Type="Self">
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1837</URL>
</Reference>
<Reference Type="openEuler CVE">
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2021-47618</URL>
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38554</URL>
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38582</URL>
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38583</URL>
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38625</URL>
</Reference>
<Reference Type="Other">
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47618</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38554</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38582</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38583</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38625</URL>
</Reference>
</DocumentReferences>
<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
<Branch Type="Product Name" Name="openEuler">
<FullProductName ProductID="openEuler-22.03-LTS-SP4" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">openEuler-22.03-LTS-SP4</FullProductName>
</Branch>
<Branch Type="Package Arch" Name="x86_64">
<FullProductName ProductID="bpftool-5.10.0-218.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">bpftool-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm</FullProductName>
<FullProductName ProductID="bpftool-debuginfo-5.10.0-218.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">bpftool-debuginfo-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-5.10.0-218.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-debuginfo-5.10.0-218.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-debuginfo-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-debugsource-5.10.0-218.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-debugsource-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-devel-5.10.0-218.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-devel-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-headers-5.10.0-218.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-headers-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-source-5.10.0-218.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-source-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-5.10.0-218.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-tools-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-218.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-tools-debuginfo-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-devel-5.10.0-218.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-tools-devel-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm</FullProductName>
<FullProductName ProductID="perf-5.10.0-218.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">perf-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm</FullProductName>
<FullProductName ProductID="perf-debuginfo-5.10.0-218.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">perf-debuginfo-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm</FullProductName>
<FullProductName ProductID="python3-perf-5.10.0-218.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">python3-perf-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm</FullProductName>
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-218.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">python3-perf-debuginfo-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm</FullProductName>
</Branch>
<Branch Type="Package Arch" Name="src">
<FullProductName ProductID="kernel-5.10.0-218.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-5.10.0-218.0.0.117.oe2203sp4.src.rpm</FullProductName>
</Branch>
<Branch Type="Package Arch" Name="aarch64">
<FullProductName ProductID="bpftool-5.10.0-218.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">bpftool-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm</FullProductName>
<FullProductName ProductID="bpftool-debuginfo-5.10.0-218.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">bpftool-debuginfo-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-5.10.0-218.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-debuginfo-5.10.0-218.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-debuginfo-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-debugsource-5.10.0-218.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-debugsource-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-devel-5.10.0-218.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-devel-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-headers-5.10.0-218.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-headers-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-source-5.10.0-218.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-source-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-5.10.0-218.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-tools-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-218.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-tools-debuginfo-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-devel-5.10.0-218.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-tools-devel-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm</FullProductName>
<FullProductName ProductID="perf-5.10.0-218.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">perf-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm</FullProductName>
<FullProductName ProductID="perf-debuginfo-5.10.0-218.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">perf-debuginfo-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm</FullProductName>
<FullProductName ProductID="python3-perf-5.10.0-218.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">python3-perf-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm</FullProductName>
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-218.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">python3-perf-debuginfo-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm</FullProductName>
</Branch>
</ProductTree>
<Vulnerability Ordinal="1" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
<Notes>
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
ARM: 9170/1: fix panic when kasan and kprobe are enabled
arm32 uses software to simulate the instruction replaced
by kprobe. some instructions may be simulated by constructing
assembly functions. therefore, before executing instruction
simulation, it is necessary to construct assembly function
execution environment in C language through binding registers.
after kasan is enabled, the register binding relationship will
be destroyed, resulting in instruction simulation errors and
causing kernel panic.
the kprobe emulate instruction function is distributed in three
files: actions-common.c actions-arm.c actions-thumb.c, so disable
KASAN when compiling these files.
for example, use kprobe insert on cap_capable+20 after kasan
enabled, the cap_capable assembly code is as follows:
&lt;cap_capable&gt;:
e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr}
e1a05000 mov r5, r0
e280006c add r0, r0, #108 ; 0x6c
e1a04001 mov r4, r1
e1a06002 mov r6, r2
e59fa090 ldr sl, [pc, #144] ;
ebfc7bf8 bl c03aa4b4 &lt;__asan_load4&gt;
e595706c ldr r7, [r5, #108] ; 0x6c
e2859014 add r9, r5, #20
......
The emulate_ldr assembly code after enabling kasan is as follows:
c06f1384 &lt;emulate_ldr&gt;:
e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr}
e282803c add r8, r2, #60 ; 0x3c
e1a05000 mov r5, r0
e7e37855 ubfx r7, r5, #16, #4
e1a00008 mov r0, r8
e1a09001 mov r9, r1
e1a04002 mov r4, r2
ebf35462 bl c03c6530 &lt;__asan_load4&gt;
e357000f cmp r7, #15
e7e36655 ubfx r6, r5, #12, #4
e205a00f and sl, r5, #15
0a000001 beq c06f13bc &lt;emulate_ldr+0x38&gt;
e0840107 add r0, r4, r7, lsl #2
ebf3545c bl c03c6530 &lt;__asan_load4&gt;
e084010a add r0, r4, sl, lsl #2
ebf3545a bl c03c6530 &lt;__asan_load4&gt;
e2890010 add r0, r9, #16
ebf35458 bl c03c6530 &lt;__asan_load4&gt;
e5990010 ldr r0, [r9, #16]
e12fff30 blx r0
e356000f cm r6, #15
1a000014 bne c06f1430 &lt;emulate_ldr+0xac&gt;
e1a06000 mov r6, r0
e2840040 add r0, r4, #64 ; 0x40
......
when running in emulate_ldr to simulate the ldr instruction, panic
occurred, and the log is as follows:
Unable to handle kernel NULL pointer dereference at virtual address
00000090
pgd = ecb46400
[00000090] *pgd=2e0fa003, *pmd=00000000
Internal error: Oops: 206 [#1] SMP ARM
PC is at cap_capable+0x14/0xb0
LR is at emulate_ldr+0x50/0xc0
psr: 600d0293 sp : ecd63af8 ip : 00000004 fp : c0a7c30c
r10: 00000000 r9 : c30897f4 r8 : ecd63cd4
r7 : 0000000f r6 : 0000000a r5 : e59fa090 r4 : ecd63c98
r3 : c06ae294 r2 : 00000000 r1 : b7611300 r0 : bf4ec008
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
Control: 32c5387d Table: 2d546400 DAC: 55555555
Process bash (pid: 1643, stack limit = 0xecd60190)
(cap_capable) from (kprobe_handler+0x218/0x340)
(kprobe_handler) from (kprobe_trap_handler+0x24/0x48)
(kprobe_trap_handler) from (do_undefinstr+0x13c/0x364)
(do_undefinstr) from (__und_svc_finish+0x0/0x30)
(__und_svc_finish) from (cap_capable+0x18/0xb0)
(cap_capable) from (cap_vm_enough_memory+0x38/0x48)
(cap_vm_enough_memory) from
(security_vm_enough_memory_mm+0x48/0x6c)
(security_vm_enough_memory_mm) from
(copy_process.constprop.5+0x16b4/0x25c8)
(copy_process.constprop.5) from (_do_fork+0xe8/0x55c)
(_do_fork) from (SyS_clone+0x1c/0x24)
(SyS_clone) from (__sys_trace_return+0x0/0x10)
Code: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7)</Note>
</Notes>
<ReleaseDate>2024-07-12</ReleaseDate>
<CVE>CVE-2021-47618</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS-SP4</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>5.5</BaseScore>
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-07-12</DATE>
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1837</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="2" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
<Notes>
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
ax25: Fix reference count leak issue of net_device
There is a reference count leak issue of the object &quot;net_device&quot; in
ax25_dev_device_down(). When the ax25 device is shutting down, the
ax25_dev_device_down() drops the reference count of net_device one
or zero times depending on if we goto unlock_put or not, which will
cause memory leak.
In order to solve the above issue, decrease the reference count of
net_device after dev-&gt;ax25_ptr is set to null.</Note>
</Notes>
<ReleaseDate>2024-07-12</ReleaseDate>
<CVE>CVE-2024-38554</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS-SP4</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>4.1</BaseScore>
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-07-12</DATE>
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1837</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="3" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
<Notes>
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix potential hang in nilfs_detach_log_writer()
Syzbot has reported a potential hang in nilfs_detach_log_writer() called
during nilfs2 unmount.
Analysis revealed that this is because nilfs_segctor_sync(), which
synchronizes with the log writer thread, can be called after
nilfs_segctor_destroy() terminates that thread, as shown in the call trace
below:
nilfs_detach_log_writer
nilfs_segctor_destroy
nilfs_segctor_kill_thread --&gt; Shut down log writer thread
flush_work
nilfs_iput_work_func
nilfs_dispose_list
iput
nilfs_evict_inode
nilfs_transaction_commit
nilfs_construct_segment (if inode needs sync)
nilfs_segctor_sync --&gt; Attempt to synchronize with
log writer thread
*** DEADLOCK ***
Fix this issue by changing nilfs_segctor_sync() so that the log writer
thread returns normally without synchronizing after it terminates, and by
forcing tasks that are already waiting to complete once after the thread
terminates.
The skipped inode metadata flushout will then be processed together in the
subsequent cleanup work in nilfs_segctor_destroy().</Note>
</Notes>
<ReleaseDate>2024-07-12</ReleaseDate>
<CVE>CVE-2024-38582</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS-SP4</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>None</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>0.0</BaseScore>
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-07-12</DATE>
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1837</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="4" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
<Notes>
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix use-after-free of timer for log writer thread
Patch series &quot;nilfs2: fix log writer related issues&quot;.
This bug fix series covers three nilfs2 log writer-related issues,
including a timer use-after-free issue and potential deadlock issue on
unmount, and a potential freeze issue in event synchronization found
during their analysis. Details are described in each commit log.
This patch (of 3):
A use-after-free issue has been reported regarding the timer sc_timer on
the nilfs_sc_info structure.
The problem is that even though it is used to wake up a sleeping log
writer thread, sc_timer is not shut down until the nilfs_sc_info structure
is about to be freed, and is used regardless of the thread&apos;s lifetime.
Fix this issue by limiting the use of sc_timer only while the log writer
thread is alive.</Note>
</Notes>
<ReleaseDate>2024-07-12</ReleaseDate>
<CVE>CVE-2024-38583</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS-SP4</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>High</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>7.0</BaseScore>
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-07-12</DATE>
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1837</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="5" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
<Notes>
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Check &apos;folio&apos; pointer for NULL
It can be NULL if bmap is called.</Note>
</Notes>
<ReleaseDate>2024-07-12</ReleaseDate>
<CVE>CVE-2024-38625</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS-SP4</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>5.5</BaseScore>
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-07-12</DATE>
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1837</URL>
</Remediation>
</Remediations>
</Vulnerability>
</cvrfdoc>
Reference in New Issue View Git Blame Copy Permalink