1794 lines
78 KiB
XML
1794 lines
78 KiB
XML
<?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-20.03-LTS-SP1</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-1535</ID>
|
|
</Identification>
|
|
<Status>Final</Status>
|
|
<Version>1.0</Version>
|
|
<RevisionHistory>
|
|
<Revision>
|
|
<Number>1.0</Number>
|
|
<Date>2024-05-10</Date>
|
|
<Description>Initial</Description>
|
|
</Revision>
|
|
</RevisionHistory>
|
|
<InitialReleaseDate>2024-05-10</InitialReleaseDate>
|
|
<CurrentReleaseDate>2024-05-10</CurrentReleaseDate>
|
|
<Generator>
|
|
<Engine>openEuler SA Tool V1.0</Engine>
|
|
<Date>2024-05-10</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-20.03-LTS-SP1.</Note>
|
|
<Note Title="Description" Type="General" Ordinal="3" xml:lang="en">The Linux Kernel, the operating system core itself.
|
|
|
|
Security Fix(es):
|
|
|
|
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2021-47084)
|
|
|
|
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2021-47085)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mm/hwpoison: clear MF_COUNT_INCREASED before retrying get_any_page()
|
|
|
|
Hulk Robot reported a panic in put_page_testzero() when testing
|
|
madvise() with MADV_SOFT_OFFLINE. The BUG() is triggered when retrying
|
|
get_any_page(). This is because we keep MF_COUNT_INCREASED flag in
|
|
second try but the refcnt is not increased.
|
|
|
|
page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0)
|
|
------------[ cut here ]------------
|
|
kernel BUG at include/linux/mm.h:737!
|
|
invalid opcode: 0000 [#1] PREEMPT SMP
|
|
CPU: 5 PID: 2135 Comm: sshd Tainted: G B 5.16.0-rc6-dirty #373
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
|
|
RIP: release_pages+0x53f/0x840
|
|
Call Trace:
|
|
free_pages_and_swap_cache+0x64/0x80
|
|
tlb_flush_mmu+0x6f/0x220
|
|
unmap_page_range+0xe6c/0x12c0
|
|
unmap_single_vma+0x90/0x170
|
|
unmap_vmas+0xc4/0x180
|
|
exit_mmap+0xde/0x3a0
|
|
mmput+0xa3/0x250
|
|
do_exit+0x564/0x1470
|
|
do_group_exit+0x3b/0x100
|
|
__do_sys_exit_group+0x13/0x20
|
|
__x64_sys_exit_group+0x16/0x20
|
|
do_syscall_64+0x34/0x80
|
|
entry_SYSCALL_64_after_hwframe+0x44/0xae
|
|
Modules linked in:
|
|
---[ end trace e99579b570fe0649 ]---
|
|
RIP: 0010:release_pages+0x53f/0x840(CVE-2021-47090)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ipmi: Fix UAF when uninstall ipmi_si and ipmi_msghandler module
|
|
|
|
Hi,
|
|
|
|
When testing install and uninstall of ipmi_si.ko and ipmi_msghandler.ko,
|
|
the system crashed.
|
|
|
|
The log as follows:
|
|
[ 141.087026] BUG: unable to handle kernel paging request at ffffffffc09b3a5a
|
|
[ 141.087241] PGD 8fe4c0d067 P4D 8fe4c0d067 PUD 8fe4c0f067 PMD 103ad89067 PTE 0
|
|
[ 141.087464] Oops: 0010 [#1] SMP NOPTI
|
|
[ 141.087580] CPU: 67 PID: 668 Comm: kworker/67:1 Kdump: loaded Not tainted 4.18.0.x86_64 #47
|
|
[ 141.088009] Workqueue: events 0xffffffffc09b3a40
|
|
[ 141.088009] RIP: 0010:0xffffffffc09b3a5a
|
|
[ 141.088009] Code: Bad RIP value.
|
|
[ 141.088009] RSP: 0018:ffffb9094e2c3e88 EFLAGS: 00010246
|
|
[ 141.088009] RAX: 0000000000000000 RBX: ffff9abfdb1f04a0 RCX: 0000000000000000
|
|
[ 141.088009] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246
|
|
[ 141.088009] RBP: 0000000000000000 R08: ffff9abfffee3cb8 R09: 00000000000002e1
|
|
[ 141.088009] R10: ffffb9094cb73d90 R11: 00000000000f4240 R12: ffff9abfffee8700
|
|
[ 141.088009] R13: 0000000000000000 R14: ffff9abfdb1f04a0 R15: ffff9abfdb1f04a8
|
|
[ 141.088009] FS: 0000000000000000(0000) GS:ffff9abfffec0000(0000) knlGS:0000000000000000
|
|
[ 141.088009] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 141.088009] CR2: ffffffffc09b3a30 CR3: 0000008fe4c0a001 CR4: 00000000007606e0
|
|
[ 141.088009] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
[ 141.088009] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
[ 141.088009] PKRU: 55555554
|
|
[ 141.088009] Call Trace:
|
|
[ 141.088009] ? process_one_work+0x195/0x390
|
|
[ 141.088009] ? worker_thread+0x30/0x390
|
|
[ 141.088009] ? process_one_work+0x390/0x390
|
|
[ 141.088009] ? kthread+0x10d/0x130
|
|
[ 141.088009] ? kthread_flush_work_fn+0x10/0x10
|
|
[ 141.088009] ? ret_from_fork+0x35/0x40] BUG: unable to handle kernel paging request at ffffffffc0b28a5a
|
|
[ 200.223240] PGD 97fe00d067 P4D 97fe00d067 PUD 97fe00f067 PMD a580cbf067 PTE 0
|
|
[ 200.223464] Oops: 0010 [#1] SMP NOPTI
|
|
[ 200.223579] CPU: 63 PID: 664 Comm: kworker/63:1 Kdump: loaded Not tainted 4.18.0.x86_64 #46
|
|
[ 200.224008] Workqueue: events 0xffffffffc0b28a40
|
|
[ 200.224008] RIP: 0010:0xffffffffc0b28a5a
|
|
[ 200.224008] Code: Bad RIP value.
|
|
[ 200.224008] RSP: 0018:ffffbf3c8e2a3e88 EFLAGS: 00010246
|
|
[ 200.224008] RAX: 0000000000000000 RBX: ffffa0799ad6bca0 RCX: 0000000000000000
|
|
[ 200.224008] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246
|
|
[ 200.224008] RBP: 0000000000000000 R08: ffff9fe43fde3cb8 R09: 00000000000000d5
|
|
[ 200.224008] R10: ffffbf3c8cb53d90 R11: 00000000000f4240 R12: ffff9fe43fde8700
|
|
[ 200.224008] R13: 0000000000000000 R14: ffffa0799ad6bca0 R15: ffffa0799ad6bca8
|
|
[ 200.224008] FS: 0000000000000000(0000) GS:ffff9fe43fdc0000(0000) knlGS:0000000000000000
|
|
[ 200.224008] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 200.224008] CR2: ffffffffc0b28a30 CR3: 00000097fe00a002 CR4: 00000000007606e0
|
|
[ 200.224008] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
[ 200.224008] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
[ 200.224008] PKRU: 55555554
|
|
[ 200.224008] Call Trace:
|
|
[ 200.224008] ? process_one_work+0x195/0x390
|
|
[ 200.224008] ? worker_thread+0x30/0x390
|
|
[ 200.224008] ? process_one_work+0x390/0x390
|
|
[ 200.224008] ? kthread+0x10d/0x130
|
|
[ 200.224008] ? kthread_flush_work_fn+0x10/0x10
|
|
[ 200.224008] ? ret_from_fork+0x35/0x40
|
|
[ 200.224008] kernel fault(0x1) notification starting on CPU 63
|
|
[ 200.224008] kernel fault(0x1) notification finished on CPU 63
|
|
[ 200.224008] CR2: ffffffffc0b28a5a
|
|
[ 200.224008] ---[ end trace c82a412d93f57412 ]---
|
|
|
|
The reason is as follows:
|
|
T1: rmmod ipmi_si.
|
|
->ipmi_unregister_smi()
|
|
-> ipmi_bmc_unregister()
|
|
-> __ipmi_bmc_unregister()
|
|
-> kref_put(&bmc->usecount, cleanup_bmc_device);
|
|
-> schedule_work(&bmc->remove_work);
|
|
|
|
T2: rmmod ipmi_msghandl
|
|
---truncated---(CVE-2021-47100)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: caif: fix memory leak in cfusbl_device_notify
|
|
|
|
In case of caif_enroll_dev() fail, allocated
|
|
link_support won't be assigned to the corresponding
|
|
structure. So simply free allocated pointer in case
|
|
of error.(CVE-2021-47121)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: fujitsu: fix potential null-ptr-deref
|
|
|
|
In fmvj18x_get_hwinfo(), if ioremap fails there will be NULL pointer
|
|
deref. To fix this, check the return value of ioremap and return -1
|
|
to the caller in case of failure.(CVE-2021-47149)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: lpfc: Fix link down processing to address NULL pointer dereference
|
|
|
|
If an FC link down transition while PLOGIs are outstanding to fabric well
|
|
known addresses, outstanding ABTS requests may result in a NULL pointer
|
|
dereference. Driver unload requests may hang with repeated "2878" log
|
|
messages.
|
|
|
|
The Link down processing results in ABTS requests for outstanding ELS
|
|
requests. The Abort WQEs are sent for the ELSs before the driver had set
|
|
the link state to down. Thus the driver is sending the Abort with the
|
|
expectation that an ABTS will be sent on the wire. The Abort request is
|
|
stalled waiting for the link to come up. In some conditions the driver may
|
|
auto-complete the ELSs thus if the link does come up, the Abort completions
|
|
may reference an invalid structure.
|
|
|
|
Fix by ensuring that Abort set the flag to avoid link traffic if issued due
|
|
to conditions where the link failed.(CVE-2021-47183)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
cfg80211: call cfg80211_stop_ap when switch from P2P_GO type
|
|
|
|
If the userspace tools switch from NL80211_IFTYPE_P2P_GO to
|
|
NL80211_IFTYPE_ADHOC via send_msg(NL80211_CMD_SET_INTERFACE), it
|
|
does not call the cleanup cfg80211_stop_ap(), this leads to the
|
|
initialization of in-use data. For example, this path re-init the
|
|
sdata->assigned_chanctx_list while it is still an element of
|
|
assigned_vifs list, and makes that linked list corrupt.(CVE-2021-47194)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
usb: typec: tipd: Remove WARN_ON in tps6598x_block_read
|
|
|
|
Calling tps6598x_block_read with a higher than allowed len can be
|
|
handled by just returning an error. There's no need to crash systems
|
|
with panic-on-warn enabled.(CVE-2021-47210)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
pstore/ram: Fix crash when setting number of cpus to an odd number
|
|
|
|
When the number of cpu cores is adjusted to 7 or other odd numbers,
|
|
the zone size will become an odd number.
|
|
The address of the zone will become:
|
|
addr of zone0 = BASE
|
|
addr of zone1 = BASE + zone_size
|
|
addr of zone2 = BASE + zone_size*2
|
|
...
|
|
The address of zone1/3/5/7 will be mapped to non-alignment va.
|
|
Eventually crashes will occur when accessing these va.
|
|
|
|
So, use ALIGN_DOWN() to make sure the zone size is even
|
|
to avoid this bug.(CVE-2023-52619)
|
|
|
|
A race condition was found in the Linux kernel's bluetooth device driver in {min,max}_key_size_set() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.
|
|
|
|
|
|
|
|
|
|
(CVE-2024-24860)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ip6_tunnel: fix NEXTHDR_FRAGMENT handling in ip6_tnl_parse_tlv_enc_lim()
|
|
|
|
syzbot pointed out [1] that NEXTHDR_FRAGMENT handling is broken.
|
|
|
|
Reading frag_off can only be done if we pulled enough bytes
|
|
to skb->head. Currently we might access garbage.
|
|
|
|
[1]
|
|
BUG: KMSAN: uninit-value in ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0
|
|
ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0
|
|
ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]
|
|
ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432
|
|
__netdev_start_xmit include/linux/netdevice.h:4940 [inline]
|
|
netdev_start_xmit include/linux/netdevice.h:4954 [inline]
|
|
xmit_one net/core/dev.c:3548 [inline]
|
|
dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564
|
|
__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349
|
|
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
|
|
neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592
|
|
neigh_output include/net/neighbour.h:542 [inline]
|
|
ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137
|
|
ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222
|
|
NF_HOOK_COND include/linux/netfilter.h:303 [inline]
|
|
ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243
|
|
dst_output include/net/dst.h:451 [inline]
|
|
ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155
|
|
ip6_send_skb net/ipv6/ip6_output.c:1952 [inline]
|
|
ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972
|
|
rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582
|
|
rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920
|
|
inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg net/socket.c:745 [inline]
|
|
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584
|
|
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
|
|
__sys_sendmsg net/socket.c:2667 [inline]
|
|
__do_sys_sendmsg net/socket.c:2676 [inline]
|
|
__se_sys_sendmsg net/socket.c:2674 [inline]
|
|
__x64_sys_sendmsg+0x307/0x490 net/socket.c:2674
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b
|
|
|
|
Uninit was created at:
|
|
slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
|
|
slab_alloc_node mm/slub.c:3478 [inline]
|
|
__kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517
|
|
__do_kmalloc_node mm/slab_common.c:1006 [inline]
|
|
__kmalloc_node_track_caller+0x118/0x3c0 mm/slab_common.c:1027
|
|
kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582
|
|
pskb_expand_head+0x226/0x1a00 net/core/skbuff.c:2098
|
|
__pskb_pull_tail+0x13b/0x2310 net/core/skbuff.c:2655
|
|
pskb_may_pull_reason include/linux/skbuff.h:2673 [inline]
|
|
pskb_may_pull include/linux/skbuff.h:2681 [inline]
|
|
ip6_tnl_parse_tlv_enc_lim+0x901/0xbb0 net/ipv6/ip6_tunnel.c:408
|
|
ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]
|
|
ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432
|
|
__netdev_start_xmit include/linux/netdevice.h:4940 [inline]
|
|
netdev_start_xmit include/linux/netdevice.h:4954 [inline]
|
|
xmit_one net/core/dev.c:3548 [inline]
|
|
dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564
|
|
__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349
|
|
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
|
|
neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592
|
|
neigh_output include/net/neighbour.h:542 [inline]
|
|
ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137
|
|
ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222
|
|
NF_HOOK_COND include/linux/netfilter.h:303 [inline]
|
|
ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243
|
|
dst_output include/net/dst.h:451 [inline]
|
|
ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155
|
|
ip6_send_skb net/ipv6/ip6_output.c:1952 [inline]
|
|
ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972
|
|
rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582
|
|
rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920
|
|
inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg net/socket.c:745 [inline]
|
|
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584
|
|
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
|
|
__sys_sendmsg net/socket.c:2667 [inline]
|
|
__do_sys_sendms
|
|
---truncated---(CVE-2024-26633)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
btrfs: don't abort filesystem when attempting to snapshot deleted subvolume
|
|
|
|
If the source file descriptor to the snapshot ioctl refers to a deleted
|
|
subvolume, we get the following abort:
|
|
|
|
BTRFS: Transaction aborted (error -2)
|
|
WARNING: CPU: 0 PID: 833 at fs/btrfs/transaction.c:1875 create_pending_snapshot+0x1040/0x1190 [btrfs]
|
|
Modules linked in: pata_acpi btrfs ata_piix libata scsi_mod virtio_net blake2b_generic xor net_failover virtio_rng failover scsi_common rng_core raid6_pq libcrc32c
|
|
CPU: 0 PID: 833 Comm: t_snapshot_dele Not tainted 6.7.0-rc6 #2
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014
|
|
RIP: 0010:create_pending_snapshot+0x1040/0x1190 [btrfs]
|
|
RSP: 0018:ffffa09c01337af8 EFLAGS: 00010282
|
|
RAX: 0000000000000000 RBX: ffff9982053e7c78 RCX: 0000000000000027
|
|
RDX: ffff99827dc20848 RSI: 0000000000000001 RDI: ffff99827dc20840
|
|
RBP: ffffa09c01337c00 R08: 0000000000000000 R09: ffffa09c01337998
|
|
R10: 0000000000000003 R11: ffffffffb96da248 R12: fffffffffffffffe
|
|
R13: ffff99820535bb28 R14: ffff99820b7bd000 R15: ffff99820381ea80
|
|
FS: 00007fe20aadabc0(0000) GS:ffff99827dc00000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000559a120b502f CR3: 00000000055b6000 CR4: 00000000000006f0
|
|
Call Trace:
|
|
<TASK>
|
|
? create_pending_snapshot+0x1040/0x1190 [btrfs]
|
|
? __warn+0x81/0x130
|
|
? create_pending_snapshot+0x1040/0x1190 [btrfs]
|
|
? report_bug+0x171/0x1a0
|
|
? handle_bug+0x3a/0x70
|
|
? exc_invalid_op+0x17/0x70
|
|
? asm_exc_invalid_op+0x1a/0x20
|
|
? create_pending_snapshot+0x1040/0x1190 [btrfs]
|
|
? create_pending_snapshot+0x1040/0x1190 [btrfs]
|
|
create_pending_snapshots+0x92/0xc0 [btrfs]
|
|
btrfs_commit_transaction+0x66b/0xf40 [btrfs]
|
|
btrfs_mksubvol+0x301/0x4d0 [btrfs]
|
|
btrfs_mksnapshot+0x80/0xb0 [btrfs]
|
|
__btrfs_ioctl_snap_create+0x1c2/0x1d0 [btrfs]
|
|
btrfs_ioctl_snap_create_v2+0xc4/0x150 [btrfs]
|
|
btrfs_ioctl+0x8a6/0x2650 [btrfs]
|
|
? kmem_cache_free+0x22/0x340
|
|
? do_sys_openat2+0x97/0xe0
|
|
__x64_sys_ioctl+0x97/0xd0
|
|
do_syscall_64+0x46/0xf0
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
RIP: 0033:0x7fe20abe83af
|
|
RSP: 002b:00007ffe6eff1360 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
|
|
RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fe20abe83af
|
|
RDX: 00007ffe6eff23c0 RSI: 0000000050009417 RDI: 0000000000000003
|
|
RBP: 0000000000000003 R08: 0000000000000000 R09: 00007fe20ad16cd0
|
|
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
|
|
R13: 00007ffe6eff13c0 R14: 00007fe20ad45000 R15: 0000559a120b6d58
|
|
</TASK>
|
|
---[ end trace 0000000000000000 ]---
|
|
BTRFS: error (device vdc: state A) in create_pending_snapshot:1875: errno=-2 No such entry
|
|
BTRFS info (device vdc: state EA): forced readonly
|
|
BTRFS warning (device vdc: state EA): Skipping commit of aborted transaction.
|
|
BTRFS: error (device vdc: state EA) in cleanup_transaction:2055: errno=-2 No such entry
|
|
|
|
This happens because create_pending_snapshot() initializes the new root
|
|
item as a copy of the source root item. This includes the refs field,
|
|
which is 0 for a deleted subvolume. The call to btrfs_insert_root()
|
|
therefore inserts a root with refs == 0. btrfs_get_new_fs_root() then
|
|
finds the root and returns -ENOENT if refs == 0, which causes
|
|
create_pending_snapshot() to abort.
|
|
|
|
Fix it by checking the source root's refs before attempting the
|
|
snapshot, but after locking subvol_sem to avoid racing with deletion.(CVE-2024-26644)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ARM: ep93xx: Add terminator to gpiod_lookup_table
|
|
|
|
Without the terminator, if a con_id is passed to gpio_find() that
|
|
does not exist in the lookup table the function will not stop looping
|
|
correctly, and eventually cause an oops.(CVE-2024-26751)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaio
|
|
|
|
If kiocb_set_cancel_fn() is called for I/O submitted via io_uring, the
|
|
following kernel warning appears:
|
|
|
|
WARNING: CPU: 3 PID: 368 at fs/aio.c:598 kiocb_set_cancel_fn+0x9c/0xa8
|
|
Call trace:
|
|
kiocb_set_cancel_fn+0x9c/0xa8
|
|
ffs_epfile_read_iter+0x144/0x1d0
|
|
io_read+0x19c/0x498
|
|
io_issue_sqe+0x118/0x27c
|
|
io_submit_sqes+0x25c/0x5fc
|
|
__arm64_sys_io_uring_enter+0x104/0xab0
|
|
invoke_syscall+0x58/0x11c
|
|
el0_svc_common+0xb4/0xf4
|
|
do_el0_svc+0x2c/0xb0
|
|
el0_svc+0x2c/0xa4
|
|
el0t_64_sync_handler+0x68/0xb4
|
|
el0t_64_sync+0x1a4/0x1a8
|
|
|
|
Fix this by setting the IOCB_AIO_RW flag for read and write I/O that is
|
|
submitted by libaio.(CVE-2024-26764)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ext4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal()
|
|
|
|
Places the logic for checking if the group's block bitmap is corrupt under
|
|
the protection of the group lock to avoid allocating blocks from the group
|
|
with a corrupted block bitmap.(CVE-2024-26772)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ext4: avoid allocating blocks from corrupted group in ext4_mb_try_best_found()
|
|
|
|
Determine if the group block bitmap is corrupted before using ac_b_ex in
|
|
ext4_mb_try_best_found() to avoid allocating blocks from a group with a
|
|
corrupted block bitmap in the following concurrency and making the
|
|
situation worse.
|
|
|
|
ext4_mb_regular_allocator
|
|
ext4_lock_group(sb, group)
|
|
ext4_mb_good_group
|
|
// check if the group bbitmap is corrupted
|
|
ext4_mb_complex_scan_group
|
|
// Scan group gets ac_b_ex but doesn't use it
|
|
ext4_unlock_group(sb, group)
|
|
ext4_mark_group_bitmap_corrupted(group)
|
|
// The block bitmap was corrupted during
|
|
// the group unlock gap.
|
|
ext4_mb_try_best_found
|
|
ext4_lock_group(ac->ac_sb, group)
|
|
ext4_mb_use_best_found
|
|
mb_mark_used
|
|
// Allocating blocks in block bitmap corrupted group(CVE-2024-26773)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fbdev: sis: Error out if pixclock equals zero
|
|
|
|
The userspace program could pass any values to the driver through
|
|
ioctl() interface. If the driver doesn't check the value of pixclock,
|
|
it may cause divide-by-zero error.
|
|
|
|
In sisfb_check_var(), var->pixclock is used as a divisor to caculate
|
|
drate before it is checked against zero. Fix this by checking it
|
|
at the beginning.
|
|
|
|
This is similar to CVE-2022-3061 in i740fb which was fixed by
|
|
commit 15cf0b8.(CVE-2024-26777)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fbdev: savage: Error out if pixclock equals zero
|
|
|
|
The userspace program could pass any values to the driver through
|
|
ioctl() interface. If the driver doesn't check the value of pixclock,
|
|
it may cause divide-by-zero error.
|
|
|
|
Although pixclock is checked in savagefb_decode_var(), but it is not
|
|
checked properly in savagefb_probe(). Fix this by checking whether
|
|
pixclock is zero in the function savagefb_check_var() before
|
|
info->var.pixclock is used as the divisor.
|
|
|
|
This is similar to CVE-2022-3061 in i740fb which was fixed by
|
|
commit 15cf0b8.(CVE-2024-26778)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
vfio/pci: Lock external INTx masking ops
|
|
|
|
Mask operations through config space changes to DisINTx may race INTx
|
|
configuration changes via ioctl. Create wrappers that add locking for
|
|
paths outside of the core interrupt code.
|
|
|
|
In particular, irq_type is updated holding igate, therefore testing
|
|
is_intx() requires holding igate. For example clearing DisINTx from
|
|
config space can otherwise race changes of the interrupt configuration.
|
|
|
|
This aligns interfaces which may trigger the INTx eventfd into two
|
|
camps, one side serialized by igate and the other only enabled while
|
|
INTx is configured. A subsequent patch introduces synchronization for
|
|
the latter flows.(CVE-2024-26810)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
bpf: Fix hashtab overflow check on 32-bit arches
|
|
|
|
The hashtab code relies on roundup_pow_of_two() to compute the number of
|
|
hash buckets, and contains an overflow check by checking if the
|
|
resulting value is 0. However, on 32-bit arches, the roundup code itself
|
|
can overflow by doing a 32-bit left-shift of an unsigned long value,
|
|
which is undefined behaviour, so it is not guaranteed to truncate
|
|
neatly. This was triggered by syzbot on the DEVMAP_HASH type, which
|
|
contains the same check, copied from the hashtab code. So apply the same
|
|
fix to hashtab, by moving the overflow check to before the roundup.(CVE-2024-26884)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts
|
|
|
|
This patch is against CVE-2023-6270. The description of cve is:
|
|
|
|
A flaw was found in the ATA over Ethernet (AoE) driver in the Linux
|
|
kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on
|
|
`struct net_device`, and a use-after-free can be triggered by racing
|
|
between the free on the struct and the access through the `skbtxq`
|
|
global queue. This could lead to a denial of service condition or
|
|
potential code execution.
|
|
|
|
In aoecmd_cfg_pkts(), it always calls dev_put(ifp) when skb initial
|
|
code is finished. But the net_device ifp will still be used in
|
|
later tx()->dev_queue_xmit() in kthread. Which means that the
|
|
dev_put(ifp) should NOT be called in the success path of skb
|
|
initial code in aoecmd_cfg_pkts(). Otherwise tx() may run into
|
|
use-after-free because the net_device is freed.
|
|
|
|
This patch removed the dev_put(ifp) in the success path in
|
|
aoecmd_cfg_pkts(), and added dev_put() after skb xmit in tx().(CVE-2024-26898)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
vfio/pci: Disable auto-enable of exclusive INTx IRQ
|
|
|
|
Currently for devices requiring masking at the irqchip for INTx, ie.
|
|
devices without DisINTx support, the IRQ is enabled in request_irq()
|
|
and subsequently disabled as necessary to align with the masked status
|
|
flag. This presents a window where the interrupt could fire between
|
|
these events, resulting in the IRQ incrementing the disable depth twice.
|
|
This would be unrecoverable for a user since the masked flag prevents
|
|
nested enables through vfio.
|
|
|
|
Instead, invert the logic using IRQF_NO_AUTOEN such that exclusive INTx
|
|
is never auto-enabled, then unmask as required.(CVE-2024-27437)</Note>
|
|
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-20.03-LTS-SP1.
|
|
|
|
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-1535</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47084</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47085</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47090</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47100</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47121</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47149</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47183</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47194</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47210</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52619</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-24860</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26633</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26644</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26751</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26764</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26772</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26773</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26777</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26778</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26810</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26884</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26898</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27437</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47084</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47085</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47090</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47100</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47121</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47149</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47183</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47194</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47210</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52619</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-24860</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26633</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26644</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26751</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26764</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26772</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26773</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26777</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26778</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26810</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26884</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26898</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27437</URL>
|
|
</Reference>
|
|
</DocumentReferences>
|
|
<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
|
|
<Branch Type="Product Name" Name="openEuler">
|
|
<FullProductName ProductID="openEuler-20.03-LTS-SP1" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">openEuler-20.03-LTS-SP1</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">python3-perf-debuginfo-4.19.90-2405.1.0.0248.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-devel-4.19.90-2405.1.0.0248.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">bpftool-4.19.90-2405.1.0.0248.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">perf-4.19.90-2405.1.0.0248.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-4.19.90-2405.1.0.0248.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">python2-perf-debuginfo-4.19.90-2405.1.0.0248.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-debugsource-4.19.90-2405.1.0.0248.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">python3-perf-4.19.90-2405.1.0.0248.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-source-4.19.90-2405.1.0.0248.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-tools-debuginfo-4.19.90-2405.1.0.0248.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">bpftool-debuginfo-4.19.90-2405.1.0.0248.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">python2-perf-4.19.90-2405.1.0.0248.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-debuginfo-4.19.90-2405.1.0.0248.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-tools-devel-4.19.90-2405.1.0.0248.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-tools-4.19.90-2405.1.0.0248.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">perf-debuginfo-4.19.90-2405.1.0.0248.oe1.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-4.19.90-2405.1.0.0248.oe1.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="kernel-devel-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-devel-4.19.90-2405.1.0.0248.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-tools-devel-4.19.90-2405.1.0.0248.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">bpftool-debuginfo-4.19.90-2405.1.0.0248.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">perf-4.19.90-2405.1.0.0248.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">bpftool-4.19.90-2405.1.0.0248.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-debuginfo-4.19.90-2405.1.0.0248.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-tools-debuginfo-4.19.90-2405.1.0.0248.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">python2-perf-4.19.90-2405.1.0.0248.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-tools-4.19.90-2405.1.0.0248.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">python3-perf-debuginfo-4.19.90-2405.1.0.0248.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">python3-perf-4.19.90-2405.1.0.0248.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-source-4.19.90-2405.1.0.0248.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">perf-debuginfo-4.19.90-2405.1.0.0248.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-4.19.90-2405.1.0.0248.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">python2-perf-debuginfo-4.19.90-2405.1.0.0248.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-debugsource-4.19.90-2405.1.0.0248.oe1.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">Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2021-47084</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.7</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/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-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1535</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">Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2021-47085</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.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-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1535</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:
|
|
|
|
mm/hwpoison: clear MF_COUNT_INCREASED before retrying get_any_page()
|
|
|
|
Hulk Robot reported a panic in put_page_testzero() when testing
|
|
madvise() with MADV_SOFT_OFFLINE. The BUG() is triggered when retrying
|
|
get_any_page(). This is because we keep MF_COUNT_INCREASED flag in
|
|
second try but the refcnt is not increased.
|
|
|
|
page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0)
|
|
------------[ cut here ]------------
|
|
kernel BUG at include/linux/mm.h:737!
|
|
invalid opcode: 0000 [#1] PREEMPT SMP
|
|
CPU: 5 PID: 2135 Comm: sshd Tainted: G B 5.16.0-rc6-dirty #373
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
|
|
RIP: release_pages+0x53f/0x840
|
|
Call Trace:
|
|
free_pages_and_swap_cache+0x64/0x80
|
|
tlb_flush_mmu+0x6f/0x220
|
|
unmap_page_range+0xe6c/0x12c0
|
|
unmap_single_vma+0x90/0x170
|
|
unmap_vmas+0xc4/0x180
|
|
exit_mmap+0xde/0x3a0
|
|
mmput+0xa3/0x250
|
|
do_exit+0x564/0x1470
|
|
do_group_exit+0x3b/0x100
|
|
__do_sys_exit_group+0x13/0x20
|
|
__x64_sys_exit_group+0x16/0x20
|
|
do_syscall_64+0x34/0x80
|
|
entry_SYSCALL_64_after_hwframe+0x44/0xae
|
|
Modules linked in:
|
|
---[ end trace e99579b570fe0649 ]---
|
|
RIP: 0010:release_pages+0x53f/0x840</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2021-47090</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</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-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1535</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:
|
|
|
|
ipmi: Fix UAF when uninstall ipmi_si and ipmi_msghandler module
|
|
|
|
Hi,
|
|
|
|
When testing install and uninstall of ipmi_si.ko and ipmi_msghandler.ko,
|
|
the system crashed.
|
|
|
|
The log as follows:
|
|
[ 141.087026] BUG: unable to handle kernel paging request at ffffffffc09b3a5a
|
|
[ 141.087241] PGD 8fe4c0d067 P4D 8fe4c0d067 PUD 8fe4c0f067 PMD 103ad89067 PTE 0
|
|
[ 141.087464] Oops: 0010 [#1] SMP NOPTI
|
|
[ 141.087580] CPU: 67 PID: 668 Comm: kworker/67:1 Kdump: loaded Not tainted 4.18.0.x86_64 #47
|
|
[ 141.088009] Workqueue: events 0xffffffffc09b3a40
|
|
[ 141.088009] RIP: 0010:0xffffffffc09b3a5a
|
|
[ 141.088009] Code: Bad RIP value.
|
|
[ 141.088009] RSP: 0018:ffffb9094e2c3e88 EFLAGS: 00010246
|
|
[ 141.088009] RAX: 0000000000000000 RBX: ffff9abfdb1f04a0 RCX: 0000000000000000
|
|
[ 141.088009] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246
|
|
[ 141.088009] RBP: 0000000000000000 R08: ffff9abfffee3cb8 R09: 00000000000002e1
|
|
[ 141.088009] R10: ffffb9094cb73d90 R11: 00000000000f4240 R12: ffff9abfffee8700
|
|
[ 141.088009] R13: 0000000000000000 R14: ffff9abfdb1f04a0 R15: ffff9abfdb1f04a8
|
|
[ 141.088009] FS: 0000000000000000(0000) GS:ffff9abfffec0000(0000) knlGS:0000000000000000
|
|
[ 141.088009] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 141.088009] CR2: ffffffffc09b3a30 CR3: 0000008fe4c0a001 CR4: 00000000007606e0
|
|
[ 141.088009] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
[ 141.088009] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
[ 141.088009] PKRU: 55555554
|
|
[ 141.088009] Call Trace:
|
|
[ 141.088009] ? process_one_work+0x195/0x390
|
|
[ 141.088009] ? worker_thread+0x30/0x390
|
|
[ 141.088009] ? process_one_work+0x390/0x390
|
|
[ 141.088009] ? kthread+0x10d/0x130
|
|
[ 141.088009] ? kthread_flush_work_fn+0x10/0x10
|
|
[ 141.088009] ? ret_from_fork+0x35/0x40] BUG: unable to handle kernel paging request at ffffffffc0b28a5a
|
|
[ 200.223240] PGD 97fe00d067 P4D 97fe00d067 PUD 97fe00f067 PMD a580cbf067 PTE 0
|
|
[ 200.223464] Oops: 0010 [#1] SMP NOPTI
|
|
[ 200.223579] CPU: 63 PID: 664 Comm: kworker/63:1 Kdump: loaded Not tainted 4.18.0.x86_64 #46
|
|
[ 200.224008] Workqueue: events 0xffffffffc0b28a40
|
|
[ 200.224008] RIP: 0010:0xffffffffc0b28a5a
|
|
[ 200.224008] Code: Bad RIP value.
|
|
[ 200.224008] RSP: 0018:ffffbf3c8e2a3e88 EFLAGS: 00010246
|
|
[ 200.224008] RAX: 0000000000000000 RBX: ffffa0799ad6bca0 RCX: 0000000000000000
|
|
[ 200.224008] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246
|
|
[ 200.224008] RBP: 0000000000000000 R08: ffff9fe43fde3cb8 R09: 00000000000000d5
|
|
[ 200.224008] R10: ffffbf3c8cb53d90 R11: 00000000000f4240 R12: ffff9fe43fde8700
|
|
[ 200.224008] R13: 0000000000000000 R14: ffffa0799ad6bca0 R15: ffffa0799ad6bca8
|
|
[ 200.224008] FS: 0000000000000000(0000) GS:ffff9fe43fdc0000(0000) knlGS:0000000000000000
|
|
[ 200.224008] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 200.224008] CR2: ffffffffc0b28a30 CR3: 00000097fe00a002 CR4: 00000000007606e0
|
|
[ 200.224008] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
[ 200.224008] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
[ 200.224008] PKRU: 55555554
|
|
[ 200.224008] Call Trace:
|
|
[ 200.224008] ? process_one_work+0x195/0x390
|
|
[ 200.224008] ? worker_thread+0x30/0x390
|
|
[ 200.224008] ? process_one_work+0x390/0x390
|
|
[ 200.224008] ? kthread+0x10d/0x130
|
|
[ 200.224008] ? kthread_flush_work_fn+0x10/0x10
|
|
[ 200.224008] ? ret_from_fork+0x35/0x40
|
|
[ 200.224008] kernel fault(0x1) notification starting on CPU 63
|
|
[ 200.224008] kernel fault(0x1) notification finished on CPU 63
|
|
[ 200.224008] CR2: ffffffffc0b28a5a
|
|
[ 200.224008] ---[ end trace c82a412d93f57412 ]---
|
|
|
|
The reason is as follows:
|
|
T1: rmmod ipmi_si.
|
|
->ipmi_unregister_smi()
|
|
-> ipmi_bmc_unregister()
|
|
-> __ipmi_bmc_unregister()
|
|
-> kref_put(&bmc->usecount, cleanup_bmc_device);
|
|
-> schedule_work(&bmc->remove_work);
|
|
|
|
T2: rmmod ipmi_msghandl
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2021-47100</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</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-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1535</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: caif: fix memory leak in cfusbl_device_notify
|
|
|
|
In case of caif_enroll_dev() fail, allocated
|
|
link_support won't be assigned to the corresponding
|
|
structure. So simply free allocated pointer in case
|
|
of error.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2021-47121</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.7</BaseScore>
|
|
<Vector>AV:L/AC:H/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-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1535</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:
|
|
|
|
net: fujitsu: fix potential null-ptr-deref
|
|
|
|
In fmvj18x_get_hwinfo(), if ioremap fails there will be NULL pointer
|
|
deref. To fix this, check the return value of ioremap and return -1
|
|
to the caller in case of failure.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2021-47149</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</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-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1535</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:
|
|
|
|
scsi: lpfc: Fix link down processing to address NULL pointer dereference
|
|
|
|
If an FC link down transition while PLOGIs are outstanding to fabric well
|
|
known addresses, outstanding ABTS requests may result in a NULL pointer
|
|
dereference. Driver unload requests may hang with repeated "2878" log
|
|
messages.
|
|
|
|
The Link down processing results in ABTS requests for outstanding ELS
|
|
requests. The Abort WQEs are sent for the ELSs before the driver had set
|
|
the link state to down. Thus the driver is sending the Abort with the
|
|
expectation that an ABTS will be sent on the wire. The Abort request is
|
|
stalled waiting for the link to come up. In some conditions the driver may
|
|
auto-complete the ELSs thus if the link does come up, the Abort completions
|
|
may reference an invalid structure.
|
|
|
|
Fix by ensuring that Abort set the flag to avoid link traffic if issued due
|
|
to conditions where the link failed.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2021-47183</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</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-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1535</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:cfg80211: call cfg80211_stop_ap when switch from P2P_GO typeIf the userspace tools switch from NL80211_IFTYPE_P2P_GO toNL80211_IFTYPE_ADHOC via send_msg(NL80211_CMD_SET_INTERFACE), itdoes not call the cleanup cfg80211_stop_ap(), this leads to theinitialization of in-use data. For example, this path re-init thesdata->assigned_chanctx_list while it is still an element ofassigned_vifs list, and makes that linked list corrupt.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2021-47194</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</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-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1535</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:
|
|
|
|
usb: typec: tipd: Remove WARN_ON in tps6598x_block_read
|
|
|
|
Calling tps6598x_block_read with a higher than allowed len can be
|
|
handled by just returning an error. There's no need to crash systems
|
|
with panic-on-warn enabled.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2021-47210</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector></Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1535</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="10" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="10" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
pstore/ram: Fix crash when setting number of cpus to an odd number
|
|
|
|
When the number of cpu cores is adjusted to 7 or other odd numbers,
|
|
the zone size will become an odd number.
|
|
The address of the zone will become:
|
|
addr of zone0 = BASE
|
|
addr of zone1 = BASE + zone_size
|
|
addr of zone2 = BASE + zone_size*2
|
|
...
|
|
The address of zone1/3/5/7 will be mapped to non-alignment va.
|
|
Eventually crashes will occur when accessing these va.
|
|
|
|
So, use ALIGN_DOWN() to make sure the zone size is even
|
|
to avoid this bug.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2023-52619</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</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-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1535</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="11" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="11" xml:lang="en">A race condition was found in the Linux kernel's bluetooth device driver in {min,max}_key_size_set() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.
|
|
|
|
|
|
|
|
|
|
</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-24860</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.3</BaseScore>
|
|
<Vector>AV:A/AC:H/PR:N/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-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1535</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="12" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="12" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ip6_tunnel: fix NEXTHDR_FRAGMENT handling in ip6_tnl_parse_tlv_enc_lim()
|
|
|
|
syzbot pointed out [1] that NEXTHDR_FRAGMENT handling is broken.
|
|
|
|
Reading frag_off can only be done if we pulled enough bytes
|
|
to skb->head. Currently we might access garbage.
|
|
|
|
[1]
|
|
BUG: KMSAN: uninit-value in ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0
|
|
ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0
|
|
ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]
|
|
ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432
|
|
__netdev_start_xmit include/linux/netdevice.h:4940 [inline]
|
|
netdev_start_xmit include/linux/netdevice.h:4954 [inline]
|
|
xmit_one net/core/dev.c:3548 [inline]
|
|
dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564
|
|
__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349
|
|
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
|
|
neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592
|
|
neigh_output include/net/neighbour.h:542 [inline]
|
|
ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137
|
|
ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222
|
|
NF_HOOK_COND include/linux/netfilter.h:303 [inline]
|
|
ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243
|
|
dst_output include/net/dst.h:451 [inline]
|
|
ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155
|
|
ip6_send_skb net/ipv6/ip6_output.c:1952 [inline]
|
|
ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972
|
|
rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582
|
|
rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920
|
|
inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg net/socket.c:745 [inline]
|
|
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584
|
|
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
|
|
__sys_sendmsg net/socket.c:2667 [inline]
|
|
__do_sys_sendmsg net/socket.c:2676 [inline]
|
|
__se_sys_sendmsg net/socket.c:2674 [inline]
|
|
__x64_sys_sendmsg+0x307/0x490 net/socket.c:2674
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b
|
|
|
|
Uninit was created at:
|
|
slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
|
|
slab_alloc_node mm/slub.c:3478 [inline]
|
|
__kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517
|
|
__do_kmalloc_node mm/slab_common.c:1006 [inline]
|
|
__kmalloc_node_track_caller+0x118/0x3c0 mm/slab_common.c:1027
|
|
kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582
|
|
pskb_expand_head+0x226/0x1a00 net/core/skbuff.c:2098
|
|
__pskb_pull_tail+0x13b/0x2310 net/core/skbuff.c:2655
|
|
pskb_may_pull_reason include/linux/skbuff.h:2673 [inline]
|
|
pskb_may_pull include/linux/skbuff.h:2681 [inline]
|
|
ip6_tnl_parse_tlv_enc_lim+0x901/0xbb0 net/ipv6/ip6_tunnel.c:408
|
|
ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]
|
|
ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432
|
|
__netdev_start_xmit include/linux/netdevice.h:4940 [inline]
|
|
netdev_start_xmit include/linux/netdevice.h:4954 [inline]
|
|
xmit_one net/core/dev.c:3548 [inline]
|
|
dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564
|
|
__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349
|
|
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
|
|
neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592
|
|
neigh_output include/net/neighbour.h:542 [inline]
|
|
ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137
|
|
ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222
|
|
NF_HOOK_COND include/linux/netfilter.h:303 [inline]
|
|
ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243
|
|
dst_output include/net/dst.h:451 [inline]
|
|
ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155
|
|
ip6_send_skb net/ipv6/ip6_output.c:1952 [inline]
|
|
ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972
|
|
rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582
|
|
rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920
|
|
inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg net/socket.c:745 [inline]
|
|
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584
|
|
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
|
|
__sys_sendmsg net/socket.c:2667 [inline]
|
|
__do_sys_sendms
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-26633</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</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-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1535</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="13" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="13" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
btrfs: don't abort filesystem when attempting to snapshot deleted subvolume
|
|
|
|
If the source file descriptor to the snapshot ioctl refers to a deleted
|
|
subvolume, we get the following abort:
|
|
|
|
BTRFS: Transaction aborted (error -2)
|
|
WARNING: CPU: 0 PID: 833 at fs/btrfs/transaction.c:1875 create_pending_snapshot+0x1040/0x1190 [btrfs]
|
|
Modules linked in: pata_acpi btrfs ata_piix libata scsi_mod virtio_net blake2b_generic xor net_failover virtio_rng failover scsi_common rng_core raid6_pq libcrc32c
|
|
CPU: 0 PID: 833 Comm: t_snapshot_dele Not tainted 6.7.0-rc6 #2
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014
|
|
RIP: 0010:create_pending_snapshot+0x1040/0x1190 [btrfs]
|
|
RSP: 0018:ffffa09c01337af8 EFLAGS: 00010282
|
|
RAX: 0000000000000000 RBX: ffff9982053e7c78 RCX: 0000000000000027
|
|
RDX: ffff99827dc20848 RSI: 0000000000000001 RDI: ffff99827dc20840
|
|
RBP: ffffa09c01337c00 R08: 0000000000000000 R09: ffffa09c01337998
|
|
R10: 0000000000000003 R11: ffffffffb96da248 R12: fffffffffffffffe
|
|
R13: ffff99820535bb28 R14: ffff99820b7bd000 R15: ffff99820381ea80
|
|
FS: 00007fe20aadabc0(0000) GS:ffff99827dc00000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000559a120b502f CR3: 00000000055b6000 CR4: 00000000000006f0
|
|
Call Trace:
|
|
<TASK>
|
|
? create_pending_snapshot+0x1040/0x1190 [btrfs]
|
|
? __warn+0x81/0x130
|
|
? create_pending_snapshot+0x1040/0x1190 [btrfs]
|
|
? report_bug+0x171/0x1a0
|
|
? handle_bug+0x3a/0x70
|
|
? exc_invalid_op+0x17/0x70
|
|
? asm_exc_invalid_op+0x1a/0x20
|
|
? create_pending_snapshot+0x1040/0x1190 [btrfs]
|
|
? create_pending_snapshot+0x1040/0x1190 [btrfs]
|
|
create_pending_snapshots+0x92/0xc0 [btrfs]
|
|
btrfs_commit_transaction+0x66b/0xf40 [btrfs]
|
|
btrfs_mksubvol+0x301/0x4d0 [btrfs]
|
|
btrfs_mksnapshot+0x80/0xb0 [btrfs]
|
|
__btrfs_ioctl_snap_create+0x1c2/0x1d0 [btrfs]
|
|
btrfs_ioctl_snap_create_v2+0xc4/0x150 [btrfs]
|
|
btrfs_ioctl+0x8a6/0x2650 [btrfs]
|
|
? kmem_cache_free+0x22/0x340
|
|
? do_sys_openat2+0x97/0xe0
|
|
__x64_sys_ioctl+0x97/0xd0
|
|
do_syscall_64+0x46/0xf0
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
RIP: 0033:0x7fe20abe83af
|
|
RSP: 002b:00007ffe6eff1360 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
|
|
RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fe20abe83af
|
|
RDX: 00007ffe6eff23c0 RSI: 0000000050009417 RDI: 0000000000000003
|
|
RBP: 0000000000000003 R08: 0000000000000000 R09: 00007fe20ad16cd0
|
|
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
|
|
R13: 00007ffe6eff13c0 R14: 00007fe20ad45000 R15: 0000559a120b6d58
|
|
</TASK>
|
|
---[ end trace 0000000000000000 ]---
|
|
BTRFS: error (device vdc: state A) in create_pending_snapshot:1875: errno=-2 No such entry
|
|
BTRFS info (device vdc: state EA): forced readonly
|
|
BTRFS warning (device vdc: state EA): Skipping commit of aborted transaction.
|
|
BTRFS: error (device vdc: state EA) in cleanup_transaction:2055: errno=-2 No such entry
|
|
|
|
This happens because create_pending_snapshot() initializes the new root
|
|
item as a copy of the source root item. This includes the refs field,
|
|
which is 0 for a deleted subvolume. The call to btrfs_insert_root()
|
|
therefore inserts a root with refs == 0. btrfs_get_new_fs_root() then
|
|
finds the root and returns -ENOENT if refs == 0, which causes
|
|
create_pending_snapshot() to abort.
|
|
|
|
Fix it by checking the source root's refs before attempting the
|
|
snapshot, but after locking subvol_sem to avoid racing with deletion.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-26644</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</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-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1535</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="14" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="14" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ARM: ep93xx: Add terminator to gpiod_lookup_table
|
|
|
|
Without the terminator, if a con_id is passed to gpio_find() that
|
|
does not exist in the lookup table the function will not stop looping
|
|
correctly, and eventually cause an oops.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-26751</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.3</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1535</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="15" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="15" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaio
|
|
|
|
If kiocb_set_cancel_fn() is called for I/O submitted via io_uring, the
|
|
following kernel warning appears:
|
|
|
|
WARNING: CPU: 3 PID: 368 at fs/aio.c:598 kiocb_set_cancel_fn+0x9c/0xa8
|
|
Call trace:
|
|
kiocb_set_cancel_fn+0x9c/0xa8
|
|
ffs_epfile_read_iter+0x144/0x1d0
|
|
io_read+0x19c/0x498
|
|
io_issue_sqe+0x118/0x27c
|
|
io_submit_sqes+0x25c/0x5fc
|
|
__arm64_sys_io_uring_enter+0x104/0xab0
|
|
invoke_syscall+0x58/0x11c
|
|
el0_svc_common+0xb4/0xf4
|
|
do_el0_svc+0x2c/0xb0
|
|
el0_svc+0x2c/0xa4
|
|
el0t_64_sync_handler+0x68/0xb4
|
|
el0t_64_sync+0x1a4/0x1a8
|
|
|
|
Fix this by setting the IOCB_AIO_RW flag for read and write I/O that is
|
|
submitted by libaio.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-26764</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.3</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1535</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="16" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="16" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ext4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal()
|
|
|
|
Places the logic for checking if the group's block bitmap is corrupt under
|
|
the protection of the group lock to avoid allocating blocks from the group
|
|
with a corrupted block bitmap.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-26772</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</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-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1535</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="17" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="17" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ext4: avoid allocating blocks from corrupted group in ext4_mb_try_best_found()
|
|
|
|
Determine if the group block bitmap is corrupted before using ac_b_ex in
|
|
ext4_mb_try_best_found() to avoid allocating blocks from a group with a
|
|
corrupted block bitmap in the following concurrency and making the
|
|
situation worse.
|
|
|
|
ext4_mb_regular_allocator
|
|
ext4_lock_group(sb, group)
|
|
ext4_mb_good_group
|
|
// check if the group bbitmap is corrupted
|
|
ext4_mb_complex_scan_group
|
|
// Scan group gets ac_b_ex but doesn't use it
|
|
ext4_unlock_group(sb, group)
|
|
ext4_mark_group_bitmap_corrupted(group)
|
|
// The block bitmap was corrupted during
|
|
// the group unlock gap.
|
|
ext4_mb_try_best_found
|
|
ext4_lock_group(ac->ac_sb, group)
|
|
ext4_mb_use_best_found
|
|
mb_mark_used
|
|
// Allocating blocks in block bitmap corrupted group</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-26773</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</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-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1535</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="18" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="18" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fbdev: sis: Error out if pixclock equals zero
|
|
|
|
The userspace program could pass any values to the driver through
|
|
ioctl() interface. If the driver doesn't check the value of pixclock,
|
|
it may cause divide-by-zero error.
|
|
|
|
In sisfb_check_var(), var->pixclock is used as a divisor to caculate
|
|
drate before it is checked against zero. Fix this by checking it
|
|
at the beginning.
|
|
|
|
This is similar to CVE-2022-3061 in i740fb which was fixed by
|
|
commit 15cf0b8.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-26777</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</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-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1535</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="19" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="19" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fbdev: savage: Error out if pixclock equals zero
|
|
|
|
The userspace program could pass any values to the driver through
|
|
ioctl() interface. If the driver doesn't check the value of pixclock,
|
|
it may cause divide-by-zero error.
|
|
|
|
Although pixclock is checked in savagefb_decode_var(), but it is not
|
|
checked properly in savagefb_probe(). Fix this by checking whether
|
|
pixclock is zero in the function savagefb_check_var() before
|
|
info->var.pixclock is used as the divisor.
|
|
|
|
This is similar to CVE-2022-3061 in i740fb which was fixed by
|
|
commit 15cf0b8.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-26778</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</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-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1535</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="20" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="20" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
vfio/pci: Lock external INTx masking ops
|
|
|
|
Mask operations through config space changes to DisINTx may race INTx
|
|
configuration changes via ioctl. Create wrappers that add locking for
|
|
paths outside of the core interrupt code.
|
|
|
|
In particular, irq_type is updated holding igate, therefore testing
|
|
is_intx() requires holding igate. For example clearing DisINTx from
|
|
config space can otherwise race changes of the interrupt configuration.
|
|
|
|
This aligns interfaces which may trigger the INTx eventfd into two
|
|
camps, one side serialized by igate and the other only enabled while
|
|
INTx is configured. A subsequent patch introduces synchronization for
|
|
the latter flows.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-26810</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</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-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1535</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="21" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="21" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:bpf: Fix hashtab overflow check on 32-bit archesThe hashtab code relies on roundup_pow_of_two() to compute the number ofhash buckets, and contains an overflow check by checking if theresulting value is 0. However, on 32-bit arches, the roundup code itselfcan overflow by doing a 32-bit left-shift of an unsigned long value,which is undefined behaviour, so it is not guaranteed to truncateneatly. This was triggered by syzbot on the DEVMAP_HASH type, whichcontains the same check, copied from the hashtab code. So apply the samefix to hashtab, by moving the overflow check to before the roundup.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-26884</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</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-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1535</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="22" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="22" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts
|
|
|
|
This patch is against CVE-2023-6270. The description of cve is:
|
|
|
|
A flaw was found in the ATA over Ethernet (AoE) driver in the Linux
|
|
kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on
|
|
`struct net_device`, and a use-after-free can be triggered by racing
|
|
between the free on the struct and the access through the `skbtxq`
|
|
global queue. This could lead to a denial of service condition or
|
|
potential code execution.
|
|
|
|
In aoecmd_cfg_pkts(), it always calls dev_put(ifp) when skb initial
|
|
code is finished. But the net_device ifp will still be used in
|
|
later tx()->dev_queue_xmit() in kthread. Which means that the
|
|
dev_put(ifp) should NOT be called in the success path of skb
|
|
initial code in aoecmd_cfg_pkts(). Otherwise tx() may run into
|
|
use-after-free because the net_device is freed.
|
|
|
|
This patch removed the dev_put(ifp) in the success path in
|
|
aoecmd_cfg_pkts(), and added dev_put() after skb xmit in tx().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-26898</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</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-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1535</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="23" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="23" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
vfio/pci: Disable auto-enable of exclusive INTx IRQ
|
|
|
|
Currently for devices requiring masking at the irqchip for INTx, ie.
|
|
devices without DisINTx support, the IRQ is enabled in request_irq()
|
|
and subsequently disabled as necessary to align with the masked status
|
|
flag. This presents a window where the interrupt could fire between
|
|
these events, resulting in the IRQ incrementing the disable depth twice.
|
|
This would be unrecoverable for a user since the masked flag prevents
|
|
nested enables through vfio.
|
|
|
|
Instead, invert the logic using IRQF_NO_AUTOEN such that exclusive INTx
|
|
is never auto-enabled, then unmask as required.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-10</ReleaseDate>
|
|
<CVE>CVE-2024-27437</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</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-05-10</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1535</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |