jiachao2130/cvrf2cusa
1
0
Fork 1
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
fd42fc96e3
cvrf2cusa/cvrf/2024/cvrf-openEuler-SA-2024-1347.xml

944 lines
44 KiB
XML
Raw Normal View History

增加测试用的配置和目录 Signed-off-by: Jia Chao <jiac13@chinaunicom.cn>
2024-07-02 07:51:55 +00:00
<?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</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-1347</ID>
</Identification>
<Status>Final</Status>
<Version>1.0</Version>
<RevisionHistory>
<Revision>
<Number>1.0</Number>
<Date>2024-03-29</Date>
<Description>Initial</Description>
</Revision>
</RevisionHistory>
<InitialReleaseDate>2024-03-29</InitialReleaseDate>
<CurrentReleaseDate>2024-03-29</CurrentReleaseDate>
<Generator>
<Engine>openEuler SA Tool V1.0</Engine>
<Date>2024-03-29</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.</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:
net/sched: act_ct: fix wild memory access when clearing fragments
while testing re-assembly/re-fragmentation using act_ct, it&apos;s possible to
observe a crash like the following one:
KASAN: maybe wild-memory-access in range [0x0001000000000448-0x000100000000044f]
CPU: 50 PID: 0 Comm: swapper/50 Tainted: G S 5.12.0-rc7+ #424
Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017
RIP: 0010:inet_frag_rbtree_purge+0x50/0xc0
Code: 00 fc ff df 48 89 c3 31 ed 48 89 df e8 a9 7a 38 ff 4c 89 fe 48 89 df 49 89 c6 e8 5b 3a 38 ff 48 8d 7b 40 48 89 f8 48 c1 e8 03 &lt;42&gt; 80 3c 20 00 75 59 48 8d bb d0 00 00 00 4c 8b 6b 40 48 89 f8 48
RSP: 0018:ffff888c31449db8 EFLAGS: 00010203
RAX: 0000200000000089 RBX: 000100000000040e RCX: ffffffff989eb960
RDX: 0000000000000140 RSI: ffffffff97cfb977 RDI: 000100000000044e
RBP: 0000000000000900 R08: 0000000000000000 R09: ffffed1186289350
R10: 0000000000000003 R11: ffffed1186289350 R12: dffffc0000000000
R13: 000100000000040e R14: 0000000000000000 R15: ffff888155e02160
FS: 0000000000000000(0000) GS:ffff888c31440000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005600cb70a5b8 CR3: 0000000a2c014005 CR4: 00000000003706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
&lt;IRQ&gt;
inet_frag_destroy+0xa9/0x150
call_timer_fn+0x2d/0x180
run_timer_softirq+0x4fe/0xe70
__do_softirq+0x197/0x5a0
irq_exit_rcu+0x1de/0x200
sysvec_apic_timer_interrupt+0x6b/0x80
&lt;/IRQ&gt;
when act_ct temporarily stores an IP fragment, restoring the skb qdisc cb
results in putting random data in FRAG_CB(), and this causes those &quot;wild&quot;
memory accesses later, when the rbtree is purged. Never overwrite the skb
cb in case tcf_ct_handle_fragments() returns -EINPROGRESS.(CVE-2021-47014)
In the Linux kernel, the following vulnerability has been resolved:
udp: skip L4 aggregation for UDP tunnel packets
If NETIF_F_GRO_FRAGLIST or NETIF_F_GRO_UDP_FWD are enabled, and there
are UDP tunnels available in the system, udp_gro_receive() could end-up
doing L4 aggregation (either SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST) at
the outer UDP tunnel level for packets effectively carrying and UDP
tunnel header.
That could cause inner protocol corruption. If e.g. the relevant
packets carry a vxlan header, different vxlan ids will be ignored/
aggregated to the same GSO packet. Inner headers will be ignored, too,
so that e.g. TCP over vxlan push packets will be held in the GRO
engine till the next flush, etc.
Just skip the SKB_GSO_UDP_L4 and SKB_GSO_FRAGLIST code path if the
current packet could land in a UDP tunnel, and let udp_gro_receive()
do GRO via udp_sk(sk)-&gt;gro_receive.
The check implemented in this patch is broader than what is strictly
needed, as the existing UDP tunnel could be e.g. configured on top of
a different device: we could end-up skipping GRO at-all for some packets.
Anyhow, that is a very thin corner case and covering it will add quite
a bit of complexity.
v1 -&gt; v2:
- hopefully clarify the commit message(CVE-2021-47036)
In the Linux kernel, the following vulnerability has been resolved:
media: pvrusb2: fix use after free on context disconnection
Upon module load, a kthread is created targeting the
pvr2_context_thread_func function, which may call pvr2_context_destroy
and thus call kfree() on the context object. However, that might happen
before the usb hub_event handler is able to notify the driver. This
patch adds a sanity check before the invalid read reported by syzbot,
within the context disconnection call stack.(CVE-2023-52445)
In the Linux kernel, the following vulnerability has been resolved:
block: add check that partition length needs to be aligned with block size
Before calling add partition or resize partition, there is no check
on whether the length is aligned with the logical block size.
If the logical block size of the disk is larger than 512 bytes,
then the partition size maybe not the multiple of the logical block size,
and when the last sector is read, bio_truncate() will adjust the bio size,
resulting in an IO error if the size of the read command is smaller than
the logical block size.If integrity data is supported, this will also
result in a null pointer dereference when calling bio_integrity_free.(CVE-2023-52458)
In the Linux kernel, the following vulnerability has been resolved:
net: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg
syzbot reported the following uninit-value access issue:
=====================================================
BUG: KMSAN: uninit-value in smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]
BUG: KMSAN: uninit-value in smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482
CPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x21c/0x280 lib/dump_stack.c:118
kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121
__msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215
smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]
smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482
usbnet_probe+0x1152/0x3f90 drivers/net/usb/usbnet.c:1737
usb_probe_interface+0xece/0x1550 drivers/usb/core/driver.c:374
really_probe+0xf20/0x20b0 drivers/base/dd.c:529
driver_probe_device+0x293/0x390 drivers/base/dd.c:701
__device_attach_driver+0x63f/0x830 drivers/base/dd.c:807
bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431
__device_attach+0x4e2/0x7f0 drivers/base/dd.c:873
device_initial_probe+0x4a/0x60 drivers/base/dd.c:920
bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491
device_add+0x3b0e/0x40d0 drivers/base/core.c:2680
usb_set_configuration+0x380f/0x3f10 drivers/usb/core/message.c:2032
usb_generic_driver_probe+0x138/0x300 drivers/usb/core/generic.c:241
usb_probe_device+0x311/0x490 drivers/usb/core/driver.c:272
really_probe+0xf20/0x20b0 drivers/base/dd.c:529
driver_probe_device+0x293/0x390 drivers/base/dd.c:701
__device_attach_driver+0x63f/0x830 drivers/base/dd.c:807
bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431
__device_attach+0x4e2/0x7f0 drivers/base/dd.c:873
device_initial_probe+0x4a/0x60 drivers/base/dd.c:920
bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491
device_add+0x3b0e/0x40d0 drivers/base/core.c:2680
usb_new_device+0x1bd4/0x2a30 drivers/usb/core/hub.c:2554
hub_port_connect drivers/usb/core/hub.c:5208 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5348 [inline]
port_event drivers/usb/core/hub.c:5494 [inline]
hub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576
process_one_work+0x1688/0x2140 kernel/workqueue.c:2269
worker_thread+0x10bc/0x2730 kernel/workqueue.c:2415
kthread+0x551/0x590 kernel/kthread.c:292
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
Local variable ----buf.i87@smsc75xx_bind created at:
__smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]
smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]
smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482
__smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]
smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]
smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482
This issue is caused because usbnet_read_cmd() reads less bytes than requested
(zero byte in the reproducer). In this case, &apos;buf&apos; is not properly filled.
This patch fixes the issue by returning -ENODATA if usbnet_read_cmd() reads
less bytes than requested.(CVE-2023-52528)
In the Linux kernel, the following vulnerability has been resolved:
wifi: wfx: fix possible NULL pointer dereference in wfx_set_mfp_ap()
Since &apos;ieee80211_beacon_get()&apos; can return NULL, &apos;wfx_set_mfp_ap()&apos;
should check the return value before examining skb data. So convert
the latter to return an appropriate error code and propagate it to
return from &apos;wfx_start_ap()&apos; as well. Compile tested only.(CVE-2023-52593)
In the Linux kernel, the following vulnerability has been resolved:
jfs: fix slab-out-of-bounds Read in dtSearch
Currently while searching for current page in the sorted entry table
of the page there is a out of bound access. Added a bound check to fix
the error.
Dave:
Set return code to -EIO(CVE-2023-52602)
In the Linux kernel, the following vulnerability has been resolved:
UBSAN: array-index-out-of-bounds in dtSplitRoot
Syzkaller reported the following issue:
oop0: detected capacity change from 0 to 32768
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dtree.c:1971:9
index -2 is out of range for type &apos;struct dtslot [128]&apos;
CPU: 0 PID: 3613 Comm: syz-executor270 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Call Trace:
&lt;TASK&gt;
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106
ubsan_epilogue lib/ubsan.c:151 [inline]
__ubsan_handle_out_of_bounds+0xdb/0x130 lib/ubsan.c:283
dtSplitRoot+0x8d8/0x1900 fs/jfs/jfs_dtree.c:1971
dtSplitUp fs/jfs/jfs_dtree.c:985 [inline]
dtInsert+0x1189/0x6b80 fs/jfs/jfs_dtree.c:863
jfs_mkdir+0x757/0xb00 fs/jfs/namei.c:270
vfs_mkdir+0x3b3/0x590 fs/namei.c:4013
do_mkdirat+0x279/0x550 fs/namei.c:4038
__do_sys_mkdirat fs/namei.c:4053 [inline]
__se_sys_mkdirat fs/namei.c:4051 [inline]
__x64_sys_mkdirat+0x85/0x90 fs/namei.c:4051
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fcdc0113fd9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffeb8bc67d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000102
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fcdc0113fd9
RDX: 0000000000000000 RSI: 0000000020000340 RDI: 0000000000000003
RBP: 00007fcdc00d37a0 R08: 0000000000000000 R09: 00007fcdc00d37a0
R10: 00005555559a72c0 R11: 0000000000000246 R12: 00000000f8008000
R13: 0000000000000000 R14: 00083878000000f8 R15: 0000000000000000
&lt;/TASK&gt;
The issue is caused when the value of fsi becomes less than -1.
The check to break the loop when fsi value becomes -1 is present
but syzbot was able to produce value less than -1 which cause the error.
This patch simply add the change for the values less than 0.
The patch is tested via syzbot.(CVE-2023-52603)
In the Linux kernel, the following vulnerability has been resolved:
FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree
Syzkaller reported the following issue:
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:2867:6
index 196694 is out of range for type &apos;s8[1365]&apos; (aka &apos;signed char[1365]&apos;)
CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
Call Trace:
&lt;TASK&gt;
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
ubsan_epilogue lib/ubsan.c:217 [inline]
__ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348
dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867
dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834
dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331
dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline]
dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402
txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534
txUpdateMap+0x342/0x9e0
txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]
jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732
kthread+0x2d3/0x370 kernel/kthread.c:388
ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
&lt;/TASK&gt;
================================================================================
Kernel panic - not syncing: UBSAN: panic_on_warn set ...
CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
Call Trace:
&lt;TASK&gt;
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
panic+0x30f/0x770 kernel/panic.c:340
check_panic_on_warn+0x82/0xa0 kernel/panic.c:236
ubsan_epilogue lib/ubsan.c:223 [inline]
__ubsan_handle_out_of_bounds+0x13c/0x150 lib/ubsan.c:348
dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867
dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834
dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331
dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline]
dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402
txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534
txUpdateMap+0x342/0x9e0
txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]
jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732
kthread+0x2d3/0x370 kernel/kthread.c:388
ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
&lt;/TASK&gt;
Kernel Offset: disabled
Rebooting in 86400 seconds..
The issue is caused when the value of lp becomes greater than
CTLTREESIZE which is the max size of stree. Adding a simple check
solves this issue.
Dave:
As the function returns a void, good error handling
would require a more intrusive code reorganization, so I modified
Osama&apos;s patch at use WARN_ON_ONCE for lack of a cleaner option.
The patch is tested via syzbot.(CVE-2023-52604)</Note>
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS.
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/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1347</URL>
</Reference>
<Reference Type="openEuler CVE">
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47014</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47036</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52445</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52458</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52528</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52593</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52602</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52603</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52604</URL>
</Reference>
<Reference Type="Other">
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47014</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47036</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52445</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52458</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52528</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52593</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52602</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52603</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52604</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" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">openEuler-22.03-LTS</FullProductName>
</Branch>
<Branch Type="Package Arch" Name="aarch64">
<FullProductName ProductID="perf-debuginfo-5.10.0-60.131.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">perf-debuginfo-5.10.0-60.131.0.158.oe2203.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-debugsource-5.10.0-60.131.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-debugsource-5.10.0-60.131.0.158.oe2203.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-60.131.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-debuginfo-5.10.0-60.131.0.158.oe2203.aarch64.rpm</FullProductName>
<FullProductName ProductID="bpftool-5.10.0-60.131.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">bpftool-5.10.0-60.131.0.158.oe2203.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-5.10.0-60.131.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-5.10.0-60.131.0.158.oe2203.aarch64.rpm</FullProductName>
<FullProductName ProductID="bpftool-debuginfo-5.10.0-60.131.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">bpftool-debuginfo-5.10.0-60.131.0.158.oe2203.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-debuginfo-5.10.0-60.131.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-debuginfo-5.10.0-60.131.0.158.oe2203.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-5.10.0-60.131.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-5.10.0-60.131.0.158.oe2203.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-source-5.10.0-60.131.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-source-5.10.0-60.131.0.158.oe2203.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-devel-5.10.0-60.131.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-devel-5.10.0-60.131.0.158.oe2203.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-headers-5.10.0-60.131.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-headers-5.10.0-60.131.0.158.oe2203.aarch64.rpm</FullProductName>
<FullProductName ProductID="perf-5.10.0-60.131.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">perf-5.10.0-60.131.0.158.oe2203.aarch64.rpm</FullProductName>
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-60.131.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">python3-perf-debuginfo-5.10.0-60.131.0.158.oe2203.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-devel-5.10.0-60.131.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-devel-5.10.0-60.131.0.158.oe2203.aarch64.rpm</FullProductName>
<FullProductName ProductID="python3-perf-5.10.0-60.131.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">python3-perf-5.10.0-60.131.0.158.oe2203.aarch64.rpm</FullProductName>
</Branch>
<Branch Type="Package Arch" Name="src">
<FullProductName ProductID="kernel-5.10.0-60.131.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-5.10.0-60.131.0.158.oe2203.src.rpm</FullProductName>
</Branch>
<Branch Type="Package Arch" Name="x86_64">
<FullProductName ProductID="kernel-debugsource-5.10.0-60.131.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-debugsource-5.10.0-60.131.0.158.oe2203.x86_64.rpm</FullProductName>
<FullProductName ProductID="perf-debuginfo-5.10.0-60.131.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">perf-debuginfo-5.10.0-60.131.0.158.oe2203.x86_64.rpm</FullProductName>
<FullProductName ProductID="perf-5.10.0-60.131.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">perf-5.10.0-60.131.0.158.oe2203.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-5.10.0-60.131.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-5.10.0-60.131.0.158.oe2203.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-debuginfo-5.10.0-60.131.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-debuginfo-5.10.0-60.131.0.158.oe2203.x86_64.rpm</FullProductName>
<FullProductName ProductID="bpftool-debuginfo-5.10.0-60.131.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">bpftool-debuginfo-5.10.0-60.131.0.158.oe2203.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-headers-5.10.0-60.131.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-headers-5.10.0-60.131.0.158.oe2203.x86_64.rpm</FullProductName>
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-60.131.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">python3-perf-debuginfo-5.10.0-60.131.0.158.oe2203.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-devel-5.10.0-60.131.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-devel-5.10.0-60.131.0.158.oe2203.x86_64.rpm</FullProductName>
<FullProductName ProductID="python3-perf-5.10.0-60.131.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">python3-perf-5.10.0-60.131.0.158.oe2203.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-5.10.0-60.131.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-5.10.0-60.131.0.158.oe2203.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-devel-5.10.0-60.131.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-devel-5.10.0-60.131.0.158.oe2203.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-60.131.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-debuginfo-5.10.0-60.131.0.158.oe2203.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-source-5.10.0-60.131.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-source-5.10.0-60.131.0.158.oe2203.x86_64.rpm</FullProductName>
<FullProductName ProductID="bpftool-5.10.0-60.131.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">bpftool-5.10.0-60.131.0.158.oe2203.x86_64.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:
net/sched: act_ct: fix wild memory access when clearing fragments
while testing re-assembly/re-fragmentation using act_ct, it&apos;s possible to
observe a crash like the following one:
KASAN: maybe wild-memory-access in range [0x0001000000000448-0x000100000000044f]
CPU: 50 PID: 0 Comm: swapper/50 Tainted: G S 5.12.0-rc7+ #424
Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017
RIP: 0010:inet_frag_rbtree_purge+0x50/0xc0
Code: 00 fc ff df 48 89 c3 31 ed 48 89 df e8 a9 7a 38 ff 4c 89 fe 48 89 df 49 89 c6 e8 5b 3a 38 ff 48 8d 7b 40 48 89 f8 48 c1 e8 03 &lt;42&gt; 80 3c 20 00 75 59 48 8d bb d0 00 00 00 4c 8b 6b 40 48 89 f8 48
RSP: 0018:ffff888c31449db8 EFLAGS: 00010203
RAX: 0000200000000089 RBX: 000100000000040e RCX: ffffffff989eb960
RDX: 0000000000000140 RSI: ffffffff97cfb977 RDI: 000100000000044e
RBP: 0000000000000900 R08: 0000000000000000 R09: ffffed1186289350
R10: 0000000000000003 R11: ffffed1186289350 R12: dffffc0000000000
R13: 000100000000040e R14: 0000000000000000 R15: ffff888155e02160
FS: 0000000000000000(0000) GS:ffff888c31440000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005600cb70a5b8 CR3: 0000000a2c014005 CR4: 00000000003706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
&lt;IRQ&gt;
inet_frag_destroy+0xa9/0x150
call_timer_fn+0x2d/0x180
run_timer_softirq+0x4fe/0xe70
__do_softirq+0x197/0x5a0
irq_exit_rcu+0x1de/0x200
sysvec_apic_timer_interrupt+0x6b/0x80
&lt;/IRQ&gt;
when act_ct temporarily stores an IP fragment, restoring the skb qdisc cb
results in putting random data in FRAG_CB(), and this causes those &quot;wild&quot;
memory accesses later, when the rbtree is purged. Never overwrite the skb
cb in case tcf_ct_handle_fragments() returns -EINPROGRESS.</Note>
</Notes>
<ReleaseDate>2024-03-29</ReleaseDate>
<CVE>CVE-2021-47014</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>High</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>7.1</BaseScore>
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-03-29</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1347</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="2" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
udp: skip L4 aggregation for UDP tunnel packets
If NETIF_F_GRO_FRAGLIST or NETIF_F_GRO_UDP_FWD are enabled, and there
are UDP tunnels available in the system, udp_gro_receive() could end-up
doing L4 aggregation (either SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST) at
the outer UDP tunnel level for packets effectively carrying and UDP
tunnel header.
That could cause inner protocol corruption. If e.g. the relevant
packets carry a vxlan header, different vxlan ids will be ignored/
aggregated to the same GSO packet. Inner headers will be ignored, too,
so that e.g. TCP over vxlan push packets will be held in the GRO
engine till the next flush, etc.
Just skip the SKB_GSO_UDP_L4 and SKB_GSO_FRAGLIST code path if the
current packet could land in a UDP tunnel, and let udp_gro_receive()
do GRO via udp_sk(sk)-&gt;gro_receive.
The check implemented in this patch is broader than what is strictly
needed, as the existing UDP tunnel could be e.g. configured on top of
a different device: we could end-up skipping GRO at-all for some packets.
Anyhow, that is a very thin corner case and covering it will add quite
a bit of complexity.
v1 -&gt; v2:
- hopefully clarify the commit message</Note>
</Notes>
<ReleaseDate>2024-03-29</ReleaseDate>
<CVE>CVE-2021-47036</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>5.3</BaseScore>
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-03-29</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1347</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="3" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
media: pvrusb2: fix use after free on context disconnection
Upon module load, a kthread is created targeting the
pvr2_context_thread_func function, which may call pvr2_context_destroy
and thus call kfree() on the context object. However, that might happen
before the usb hub_event handler is able to notify the driver. This
patch adds a sanity check before the invalid read reported by syzbot,
within the context disconnection call stack.</Note>
</Notes>
<ReleaseDate>2024-03-29</ReleaseDate>
<CVE>CVE-2023-52445</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>High</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>7.8</BaseScore>
<Vector>AV:L/AC:L/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-03-29</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1347</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="4" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
block: add check that partition length needs to be aligned with block size
Before calling add partition or resize partition, there is no check
on whether the length is aligned with the logical block size.
If the logical block size of the disk is larger than 512 bytes,
then the partition size maybe not the multiple of the logical block size,
and when the last sector is read, bio_truncate() will adjust the bio size,
resulting in an IO error if the size of the read command is smaller than
the logical block size.If integrity data is supported, this will also
result in a null pointer dereference when calling bio_integrity_free.</Note>
</Notes>
<ReleaseDate>2024-03-29</ReleaseDate>
<CVE>CVE-2023-52458</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>4.2</BaseScore>
<Vector>AV:L/AC:L/PR:H/UI:R/S:U/C:N/I:N/A:H</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-03-29</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1347</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="5" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
net: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg
syzbot reported the following uninit-value access issue:
=====================================================
BUG: KMSAN: uninit-value in smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]
BUG: KMSAN: uninit-value in smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482
CPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x21c/0x280 lib/dump_stack.c:118
kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121
__msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215
smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]
smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482
usbnet_probe+0x1152/0x3f90 drivers/net/usb/usbnet.c:1737
usb_probe_interface+0xece/0x1550 drivers/usb/core/driver.c:374
really_probe+0xf20/0x20b0 drivers/base/dd.c:529
driver_probe_device+0x293/0x390 drivers/base/dd.c:701
__device_attach_driver+0x63f/0x830 drivers/base/dd.c:807
bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431
__device_attach+0x4e2/0x7f0 drivers/base/dd.c:873
device_initial_probe+0x4a/0x60 drivers/base/dd.c:920
bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491
device_add+0x3b0e/0x40d0 drivers/base/core.c:2680
usb_set_configuration+0x380f/0x3f10 drivers/usb/core/message.c:2032
usb_generic_driver_probe+0x138/0x300 drivers/usb/core/generic.c:241
usb_probe_device+0x311/0x490 drivers/usb/core/driver.c:272
really_probe+0xf20/0x20b0 drivers/base/dd.c:529
driver_probe_device+0x293/0x390 drivers/base/dd.c:701
__device_attach_driver+0x63f/0x830 drivers/base/dd.c:807
bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431
__device_attach+0x4e2/0x7f0 drivers/base/dd.c:873
device_initial_probe+0x4a/0x60 drivers/base/dd.c:920
bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491
device_add+0x3b0e/0x40d0 drivers/base/core.c:2680
usb_new_device+0x1bd4/0x2a30 drivers/usb/core/hub.c:2554
hub_port_connect drivers/usb/core/hub.c:5208 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5348 [inline]
port_event drivers/usb/core/hub.c:5494 [inline]
hub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576
process_one_work+0x1688/0x2140 kernel/workqueue.c:2269
worker_thread+0x10bc/0x2730 kernel/workqueue.c:2415
kthread+0x551/0x590 kernel/kthread.c:292
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
Local variable ----buf.i87@smsc75xx_bind created at:
__smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]
smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]
smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482
__smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]
smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]
smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482
This issue is caused because usbnet_read_cmd() reads less bytes than requested
(zero byte in the reproducer). In this case, &apos;buf&apos; is not properly filled.
This patch fixes the issue by returning -ENODATA if usbnet_read_cmd() reads
less bytes than requested.</Note>
</Notes>
<ReleaseDate>2024-03-29</ReleaseDate>
<CVE>CVE-2023-52528</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>4.4</BaseScore>
<Vector>AV:L/AC:L/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-03-29</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1347</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="6" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
<Notes>
<Note Title="Vulnerability Description" Type="General" Ordinal="6" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
wifi: wfx: fix possible NULL pointer dereference in wfx_set_mfp_ap()
Since &apos;ieee80211_beacon_get()&apos; can return NULL, &apos;wfx_set_mfp_ap()&apos;
should check the return value before examining skb data. So convert
the latter to return an appropriate error code and propagate it to
return from &apos;wfx_start_ap()&apos; as well. Compile tested only.</Note>
</Notes>
<ReleaseDate>2024-03-29</ReleaseDate>
<CVE>CVE-2023-52593</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Medium</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>4.4</BaseScore>
<Vector>AV:L/AC:L/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-03-29</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1347</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="7" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
<Notes>
<Note Title="Vulnerability Description" Type="General" Ordinal="7" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
jfs: fix slab-out-of-bounds Read in dtSearch
Currently while searching for current page in the sorted entry table
of the page there is a out of bound access. Added a bound check to fix
the error.
Dave:
Set return code to -EIO</Note>
</Notes>
<ReleaseDate>2024-03-29</ReleaseDate>
<CVE>CVE-2023-52602</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>High</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>7.1</BaseScore>
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-03-29</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1347</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="8" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
<Notes>
<Note Title="Vulnerability Description" Type="General" Ordinal="8" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
UBSAN: array-index-out-of-bounds in dtSplitRoot
Syzkaller reported the following issue:
oop0: detected capacity change from 0 to 32768
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dtree.c:1971:9
index -2 is out of range for type &apos;struct dtslot [128]&apos;
CPU: 0 PID: 3613 Comm: syz-executor270 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Call Trace:
&lt;TASK&gt;
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106
ubsan_epilogue lib/ubsan.c:151 [inline]
__ubsan_handle_out_of_bounds+0xdb/0x130 lib/ubsan.c:283
dtSplitRoot+0x8d8/0x1900 fs/jfs/jfs_dtree.c:1971
dtSplitUp fs/jfs/jfs_dtree.c:985 [inline]
dtInsert+0x1189/0x6b80 fs/jfs/jfs_dtree.c:863
jfs_mkdir+0x757/0xb00 fs/jfs/namei.c:270
vfs_mkdir+0x3b3/0x590 fs/namei.c:4013
do_mkdirat+0x279/0x550 fs/namei.c:4038
__do_sys_mkdirat fs/namei.c:4053 [inline]
__se_sys_mkdirat fs/namei.c:4051 [inline]
__x64_sys_mkdirat+0x85/0x90 fs/namei.c:4051
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fcdc0113fd9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffeb8bc67d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000102
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fcdc0113fd9
RDX: 0000000000000000 RSI: 0000000020000340 RDI: 0000000000000003
RBP: 00007fcdc00d37a0 R08: 0000000000000000 R09: 00007fcdc00d37a0
R10: 00005555559a72c0 R11: 0000000000000246 R12: 00000000f8008000
R13: 0000000000000000 R14: 00083878000000f8 R15: 0000000000000000
&lt;/TASK&gt;
The issue is caused when the value of fsi becomes less than -1.
The check to break the loop when fsi value becomes -1 is present
but syzbot was able to produce value less than -1 which cause the error.
This patch simply add the change for the values less than 0.
The patch is tested via syzbot.</Note>
</Notes>
<ReleaseDate>2024-03-29</ReleaseDate>
<CVE>CVE-2023-52603</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>High</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>7.1</BaseScore>
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-03-29</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1347</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="9" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
<Notes>
<Note Title="Vulnerability Description" Type="General" Ordinal="9" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree
Syzkaller reported the following issue:
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:2867:6
index 196694 is out of range for type &apos;s8[1365]&apos; (aka &apos;signed char[1365]&apos;)
CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
Call Trace:
&lt;TASK&gt;
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
ubsan_epilogue lib/ubsan.c:217 [inline]
__ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348
dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867
dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834
dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331
dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline]
dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402
txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534
txUpdateMap+0x342/0x9e0
txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]
jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732
kthread+0x2d3/0x370 kernel/kthread.c:388
ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
&lt;/TASK&gt;
================================================================================
Kernel panic - not syncing: UBSAN: panic_on_warn set ...
CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
Call Trace:
&lt;TASK&gt;
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
panic+0x30f/0x770 kernel/panic.c:340
check_panic_on_warn+0x82/0xa0 kernel/panic.c:236
ubsan_epilogue lib/ubsan.c:223 [inline]
__ubsan_handle_out_of_bounds+0x13c/0x150 lib/ubsan.c:348
dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867
dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834
dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331
dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline]
dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402
txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534
txUpdateMap+0x342/0x9e0
txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]
jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732
kthread+0x2d3/0x370 kernel/kthread.c:388
ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
&lt;/TASK&gt;
Kernel Offset: disabled
Rebooting in 86400 seconds..
The issue is caused when the value of lp becomes greater than
CTLTREESIZE which is the max size of stree. Adding a simple check
solves this issue.
Dave:
As the function returns a void, good error handling
would require a more intrusive code reorganization, so I modified
Osama&apos;s patch at use WARN_ON_ONCE for lack of a cleaner option.
The patch is tested via syzbot.</Note>
</Notes>
<ReleaseDate>2024-03-29</ReleaseDate>
<CVE>CVE-2023-52604</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>High</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>7.8</BaseScore>
<Vector>AV:L/AC:L/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-03-29</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1347</URL>
</Remediation>
</Remediations>
</Vulnerability>
</cvrfdoc>
Reference in New Issue Copy Permalink