1444 lines
64 KiB
XML
1444 lines
64 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-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-1619</ID>
|
|
</Identification>
|
|
<Status>Final</Status>
|
|
<Version>1.0</Version>
|
|
<RevisionHistory>
|
|
<Revision>
|
|
<Number>1.0</Number>
|
|
<Date>2024-05-17</Date>
|
|
<Description>Initial</Description>
|
|
</Revision>
|
|
</RevisionHistory>
|
|
<InitialReleaseDate>2024-05-17</InitialReleaseDate>
|
|
<CurrentReleaseDate>2024-05-17</CurrentReleaseDate>
|
|
<Generator>
|
|
<Engine>openEuler SA Tool V1.0</Engine>
|
|
<Date>2024-05-17</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:
|
|
|
|
firmware: arm_scmi: Harden accesses to the reset domains
|
|
|
|
Accessing reset domains descriptors by the index upon the SCMI drivers
|
|
requests through the SCMI reset operations interface can potentially
|
|
lead to out-of-bound violations if the SCMI driver misbehave.
|
|
|
|
Add an internal consistency check before any such domains descriptors
|
|
accesses.(CVE-2022-48655)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nftables: exthdr: fix 4-byte stack OOB write
|
|
|
|
If priv->len is a multiple of 4, then dst[len / 4] can write past
|
|
the destination array which leads to stack corruption.
|
|
|
|
This construct is necessary to clean the remainder of the register
|
|
in case ->len is NOT a multiple of the register size, so make it
|
|
conditional just like nft_payload.c does.
|
|
|
|
The bug was added in 4.1 cycle and then copied/inherited when
|
|
tcp/sctp and ip option support was added.
|
|
|
|
Bug reported by Zero Day Initiative project (ZDI-CAN-21950,
|
|
ZDI-CAN-21951, ZDI-CAN-21961).(CVE-2023-52628)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: rc: bpf attach/detach requires write permission
|
|
|
|
Note that bpf attach/detach also requires CAP_NET_ADMIN.(CVE-2023-52642)
|
|
|
|
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.(CVE-2023-6270)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
blk-mq: fix IO hang from sbitmap wakeup race
|
|
|
|
In blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered
|
|
with the following blk_mq_get_driver_tag() in case of getting driver
|
|
tag failure.
|
|
|
|
Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observe
|
|
the added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime
|
|
blk_mq_mark_tag_wait() can't get driver tag successfully.
|
|
|
|
This issue can be reproduced by running the following test in loop, and
|
|
fio hang can be observed in < 30min when running it on my test VM
|
|
in laptop.
|
|
|
|
modprobe -r scsi_debug
|
|
modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4
|
|
dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename`
|
|
fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \
|
|
--runtime=100 --numjobs=40 --time_based --name=test \
|
|
--ioengine=libaio
|
|
|
|
Fix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), which
|
|
is just fine in case of running out of tag.(CVE-2024-26671)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fs,hugetlb: fix NULL pointer dereference in hugetlbs_fill_super
|
|
|
|
When configuring a hugetlb filesystem via the fsconfig() syscall, there is
|
|
a possible NULL dereference in hugetlbfs_fill_super() caused by assigning
|
|
NULL to ctx->hstate in hugetlbfs_parse_param() when the requested pagesize
|
|
is non valid.
|
|
|
|
E.g: Taking the following steps:
|
|
|
|
fd = fsopen("hugetlbfs", FSOPEN_CLOEXEC);
|
|
fsconfig(fd, FSCONFIG_SET_STRING, "pagesize", "1024", 0);
|
|
fsconfig(fd, FSCONFIG_CMD_CREATE, NULL, NULL, 0);
|
|
|
|
Given that the requested "pagesize" is invalid, ctxt->hstate will be replaced
|
|
with NULL, losing its previous value, and we will print an error:
|
|
|
|
...
|
|
...
|
|
case Opt_pagesize:
|
|
ps = memparse(param->string, &rest);
|
|
ctx->hstate = h;
|
|
if (!ctx->hstate) {
|
|
pr_err("Unsupported page size %lu MB\n", ps / SZ_1M);
|
|
return -EINVAL;
|
|
}
|
|
return 0;
|
|
...
|
|
...
|
|
|
|
This is a problem because later on, we will dereference ctxt->hstate in
|
|
hugetlbfs_fill_super()
|
|
|
|
...
|
|
...
|
|
sb->s_blocksize = huge_page_size(ctx->hstate);
|
|
...
|
|
...
|
|
|
|
Causing below Oops.
|
|
|
|
Fix this by replacing cxt->hstate value only when then pagesize is known
|
|
to be valid.
|
|
|
|
kernel: hugetlbfs: Unsupported page size 0 MB
|
|
kernel: BUG: kernel NULL pointer dereference, address: 0000000000000028
|
|
kernel: #PF: supervisor read access in kernel mode
|
|
kernel: #PF: error_code(0x0000) - not-present page
|
|
kernel: PGD 800000010f66c067 P4D 800000010f66c067 PUD 1b22f8067 PMD 0
|
|
kernel: Oops: 0000 [#1] PREEMPT SMP PTI
|
|
kernel: CPU: 4 PID: 5659 Comm: syscall Tainted: G E 6.8.0-rc2-default+ #22 5a47c3fef76212addcc6eb71344aabc35190ae8f
|
|
kernel: Hardware name: Intel Corp. GROVEPORT/GROVEPORT, BIOS GVPRCRB1.86B.0016.D04.1705030402 05/03/2017
|
|
kernel: RIP: 0010:hugetlbfs_fill_super+0xb4/0x1a0
|
|
kernel: Code: 48 8b 3b e8 3e c6 ed ff 48 85 c0 48 89 45 20 0f 84 d6 00 00 00 48 b8 ff ff ff ff ff ff ff 7f 4c 89 e7 49 89 44 24 20 48 8b 03 <8b> 48 28 b8 00 10 00 00 48 d3 e0 49 89 44 24 18 48 8b 03 8b 40 28
|
|
kernel: RSP: 0018:ffffbe9960fcbd48 EFLAGS: 00010246
|
|
kernel: RAX: 0000000000000000 RBX: ffff9af5272ae780 RCX: 0000000000372004
|
|
kernel: RDX: ffffffffffffffff RSI: ffffffffffffffff RDI: ffff9af555e9b000
|
|
kernel: RBP: ffff9af52ee66b00 R08: 0000000000000040 R09: 0000000000370004
|
|
kernel: R10: ffffbe9960fcbd48 R11: 0000000000000040 R12: ffff9af555e9b000
|
|
kernel: R13: ffffffffa66b86c0 R14: ffff9af507d2f400 R15: ffff9af507d2f400
|
|
kernel: FS: 00007ffbc0ba4740(0000) GS:ffff9b0bd7000000(0000) knlGS:0000000000000000
|
|
kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
kernel: CR2: 0000000000000028 CR3: 00000001b1ee0000 CR4: 00000000001506f0
|
|
kernel: Call Trace:
|
|
kernel: <TASK>
|
|
kernel: ? __die_body+0x1a/0x60
|
|
kernel: ? page_fault_oops+0x16f/0x4a0
|
|
kernel: ? search_bpf_extables+0x65/0x70
|
|
kernel: ? fixup_exception+0x22/0x310
|
|
kernel: ? exc_page_fault+0x69/0x150
|
|
kernel: ? asm_exc_page_fault+0x22/0x30
|
|
kernel: ? __pfx_hugetlbfs_fill_super+0x10/0x10
|
|
kernel: ? hugetlbfs_fill_super+0xb4/0x1a0
|
|
kernel: ? hugetlbfs_fill_super+0x28/0x1a0
|
|
kernel: ? __pfx_hugetlbfs_fill_super+0x10/0x10
|
|
kernel: vfs_get_super+0x40/0xa0
|
|
kernel: ? __pfx_bpf_lsm_capable+0x10/0x10
|
|
kernel: vfs_get_tree+0x25/0xd0
|
|
kernel: vfs_cmd_create+0x64/0xe0
|
|
kernel: __x64_sys_fsconfig+0x395/0x410
|
|
kernel: do_syscall_64+0x80/0x160
|
|
kernel: ? syscall_exit_to_user_mode+0x82/0x240
|
|
kernel: ? do_syscall_64+0x8d/0x160
|
|
kernel: ? syscall_exit_to_user_mode+0x82/0x240
|
|
kernel: ? do_syscall_64+0x8d/0x160
|
|
kernel: ? exc_page_fault+0x69/0x150
|
|
kernel: entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
kernel: RIP: 0033:0x7ffbc0cb87c9
|
|
kernel: Code: 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 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 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 97 96 0d 00 f7 d8 64 89 01 48
|
|
kernel: RSP: 002b:00007ffc29d2f388 EFLAGS: 00000206 ORIG_RAX: 00000000000001af
|
|
kernel: RAX: fffffffffff
|
|
---truncated---(CVE-2024-26688)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
btrfs: fix double free of anonymous device after snapshot creation failure
|
|
|
|
When creating a snapshot we may do a double free of an anonymous device
|
|
in case there's an error committing the transaction. The second free may
|
|
result in freeing an anonymous device number that was allocated by some
|
|
other subsystem in the kernel or another btrfs filesystem.
|
|
|
|
The steps that lead to this:
|
|
|
|
1) At ioctl.c:create_snapshot() we allocate an anonymous device number
|
|
and assign it to pending_snapshot->anon_dev;
|
|
|
|
2) Then we call btrfs_commit_transaction() and end up at
|
|
transaction.c:create_pending_snapshot();
|
|
|
|
3) There we call btrfs_get_new_fs_root() and pass it the anonymous device
|
|
number stored in pending_snapshot->anon_dev;
|
|
|
|
4) btrfs_get_new_fs_root() frees that anonymous device number because
|
|
btrfs_lookup_fs_root() returned a root - someone else did a lookup
|
|
of the new root already, which could some task doing backref walking;
|
|
|
|
5) After that some error happens in the transaction commit path, and at
|
|
ioctl.c:create_snapshot() we jump to the 'fail' label, and after
|
|
that we free again the same anonymous device number, which in the
|
|
meanwhile may have been reallocated somewhere else, because
|
|
pending_snapshot->anon_dev still has the same value as in step 1.
|
|
|
|
Recently syzbot ran into this and reported the following trace:
|
|
|
|
------------[ cut here ]------------
|
|
ida_free called for id=51 which is not allocated.
|
|
WARNING: CPU: 1 PID: 31038 at lib/idr.c:525 ida_free+0x370/0x420 lib/idr.c:525
|
|
Modules linked in:
|
|
CPU: 1 PID: 31038 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00410-gc02197fc9076 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
|
|
RIP: 0010:ida_free+0x370/0x420 lib/idr.c:525
|
|
Code: 10 42 80 3c 28 (...)
|
|
RSP: 0018:ffffc90015a67300 EFLAGS: 00010246
|
|
RAX: be5130472f5dd000 RBX: 0000000000000033 RCX: 0000000000040000
|
|
RDX: ffffc90009a7a000 RSI: 000000000003ffff RDI: 0000000000040000
|
|
RBP: ffffc90015a673f0 R08: ffffffff81577992 R09: 1ffff92002b4cdb4
|
|
R10: dffffc0000000000 R11: fffff52002b4cdb5 R12: 0000000000000246
|
|
R13: dffffc0000000000 R14: ffffffff8e256b80 R15: 0000000000000246
|
|
FS: 00007fca3f4b46c0(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 00007f167a17b978 CR3: 000000001ed26000 CR4: 0000000000350ef0
|
|
Call Trace:
|
|
<TASK>
|
|
btrfs_get_root_ref+0xa48/0xaf0 fs/btrfs/disk-io.c:1346
|
|
create_pending_snapshot+0xff2/0x2bc0 fs/btrfs/transaction.c:1837
|
|
create_pending_snapshots+0x195/0x1d0 fs/btrfs/transaction.c:1931
|
|
btrfs_commit_transaction+0xf1c/0x3740 fs/btrfs/transaction.c:2404
|
|
create_snapshot+0x507/0x880 fs/btrfs/ioctl.c:848
|
|
btrfs_mksubvol+0x5d0/0x750 fs/btrfs/ioctl.c:998
|
|
btrfs_mksnapshot+0xb5/0xf0 fs/btrfs/ioctl.c:1044
|
|
__btrfs_ioctl_snap_create+0x387/0x4b0 fs/btrfs/ioctl.c:1306
|
|
btrfs_ioctl_snap_create_v2+0x1ca/0x400 fs/btrfs/ioctl.c:1393
|
|
btrfs_ioctl+0xa74/0xd40
|
|
vfs_ioctl fs/ioctl.c:51 [inline]
|
|
__do_sys_ioctl fs/ioctl.c:871 [inline]
|
|
__se_sys_ioctl+0xfe/0x170 fs/ioctl.c:857
|
|
do_syscall_64+0xfb/0x240
|
|
entry_SYSCALL_64_after_hwframe+0x6f/0x77
|
|
RIP: 0033:0x7fca3e67dda9
|
|
Code: 28 00 00 00 (...)
|
|
RSP: 002b:00007fca3f4b40c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
|
|
RAX: ffffffffffffffda RBX: 00007fca3e7abf80 RCX: 00007fca3e67dda9
|
|
RDX: 00000000200005c0 RSI: 0000000050009417 RDI: 0000000000000003
|
|
RBP: 00007fca3e6ca47a R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
|
|
R13: 000000000000000b R14: 00007fca3e7abf80 R15: 00007fff6bf95658
|
|
</TASK>
|
|
|
|
Where we get an explicit message where we attempt to free an anonymous
|
|
device number that is not currently allocated. It happens in a different
|
|
code path from the example below, at btrfs_get_root_ref(), so this change
|
|
may not fix the case triggered by sy
|
|
---truncated---(CVE-2024-26792)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
amdkfd: use calloc instead of kzalloc to avoid integer overflow
|
|
|
|
This uses calloc instead of doing the multiplication which might
|
|
overflow.(CVE-2024-26817)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
IB/hfi1: Fix a memleak in init_credit_return
|
|
|
|
When dma_alloc_coherent fails to allocate dd->cr_base[i].va,
|
|
init_credit_return should deallocate dd->cr_base and
|
|
dd->cr_base[i] that allocated before. Or those resources
|
|
would be never freed and a memleak is triggered.(CVE-2024-26839)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
cachefiles: fix memory leak in cachefiles_add_cache()
|
|
|
|
The following memory leak was reported after unbinding /dev/cachefiles:
|
|
|
|
==================================================================
|
|
unreferenced object 0xffff9b674176e3c0 (size 192):
|
|
comm "cachefilesd2", pid 680, jiffies 4294881224
|
|
hex dump (first 32 bytes):
|
|
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
backtrace (crc ea38a44b):
|
|
[<ffffffff8eb8a1a5>] kmem_cache_alloc+0x2d5/0x370
|
|
[<ffffffff8e917f86>] prepare_creds+0x26/0x2e0
|
|
[<ffffffffc002eeef>] cachefiles_determine_cache_security+0x1f/0x120
|
|
[<ffffffffc00243ec>] cachefiles_add_cache+0x13c/0x3a0
|
|
[<ffffffffc0025216>] cachefiles_daemon_write+0x146/0x1c0
|
|
[<ffffffff8ebc4a3b>] vfs_write+0xcb/0x520
|
|
[<ffffffff8ebc5069>] ksys_write+0x69/0xf0
|
|
[<ffffffff8f6d4662>] do_syscall_64+0x72/0x140
|
|
[<ffffffff8f8000aa>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
==================================================================
|
|
|
|
Put the reference count of cache_cred in cachefiles_daemon_unbind() to
|
|
fix the problem. And also put cache_cred in cachefiles_add_cache() error
|
|
branch to avoid memory leaks.(CVE-2024-26840)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
efi: runtime: Fix potential overflow of soft-reserved region size
|
|
|
|
md_size will have been narrowed if we have >= 4GB worth of pages in a
|
|
soft-reserved region.(CVE-2024-26843)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: ice: Fix potential NULL pointer dereference in ice_bridge_setlink()
|
|
|
|
The function ice_bridge_setlink() may encounter a NULL pointer dereference
|
|
if nlmsg_find_attr() returns NULL and br_spec is dereferenced subsequently
|
|
in nla_for_each_nested(). To address this issue, add a check to ensure that
|
|
br_spec is not NULL before proceeding with the nested attribute iteration.(CVE-2024-26855)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: pvrusb2: fix uaf in pvr2_context_set_notify
|
|
|
|
[Syzbot reported]
|
|
BUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35
|
|
Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26
|
|
|
|
CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
|
|
Workqueue: usb_hub_wq hub_event
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106
|
|
print_address_description mm/kasan/report.c:377 [inline]
|
|
print_report+0xc4/0x620 mm/kasan/report.c:488
|
|
kasan_report+0xda/0x110 mm/kasan/report.c:601
|
|
pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35
|
|
pvr2_context_notify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline]
|
|
pvr2_context_disconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272
|
|
|
|
Freed by task 906:
|
|
kasan_save_stack+0x33/0x50 mm/kasan/common.c:47
|
|
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
|
|
kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640
|
|
poison_slab_object mm/kasan/common.c:241 [inline]
|
|
__kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257
|
|
kasan_slab_free include/linux/kasan.h:184 [inline]
|
|
slab_free_hook mm/slub.c:2121 [inline]
|
|
slab_free mm/slub.c:4299 [inline]
|
|
kfree+0x105/0x340 mm/slub.c:4409
|
|
pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline]
|
|
pvr2_context_thread_func+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158
|
|
|
|
[Analyze]
|
|
Task A set disconnect_flag = !0, which resulted in Task B's condition being met
|
|
and releasing mp, leading to this issue.
|
|
|
|
[Fix]
|
|
Place the disconnect_flag assignment operation after all code in pvr2_context_disconnect()
|
|
to avoid this issue.(CVE-2024-26875)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
quota: Fix potential NULL pointer dereference
|
|
|
|
Below race may cause NULL pointer dereference
|
|
|
|
P1 P2
|
|
dquot_free_inode quota_off
|
|
drop_dquot_ref
|
|
remove_dquot_ref
|
|
dquots = i_dquot(inode)
|
|
dquots = i_dquot(inode)
|
|
srcu_read_lock
|
|
dquots[cnt]) != NULL (1)
|
|
dquots[type] = NULL (2)
|
|
spin_lock(&dquots[cnt]->dq_dqb_lock) (3)
|
|
....
|
|
|
|
If dquot_free_inode(or other routines) checks inode's quota pointers (1)
|
|
before quota_off sets it to NULL(2) and use it (3) after that, NULL pointer
|
|
dereference will be triggered.
|
|
|
|
So let's fix it by using a temporary pointer to avoid this issue.(CVE-2024-26878)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
firmware: arm_scmi: Fix double free in SMC transport cleanup path
|
|
|
|
When the generic SCMI code tears down a channel, it calls the chan_free
|
|
callback function, defined by each transport. Since multiple protocols
|
|
might share the same transport_info member, chan_free() might want to
|
|
clean up the same member multiple times within the given SCMI transport
|
|
implementation. In this case, it is SMC transport. This will lead to a NULL
|
|
pointer dereference at the second time:
|
|
|
|
| scmi_protocol scmi_dev.1: Enabled polling mode TX channel - prot_id:16
|
|
| arm-scmi firmware:scmi: SCMI Notifications - Core Enabled.
|
|
| arm-scmi firmware:scmi: unable to communicate with SCMI
|
|
| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
|
|
| Mem abort info:
|
|
| ESR = 0x0000000096000004
|
|
| EC = 0x25: DABT (current EL), IL = 32 bits
|
|
| SET = 0, FnV = 0
|
|
| EA = 0, S1PTW = 0
|
|
| FSC = 0x04: level 0 translation fault
|
|
| Data abort info:
|
|
| ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
|
|
| CM = 0, WnR = 0, TnD = 0, TagAccess = 0
|
|
| GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
|
|
| user pgtable: 4k pages, 48-bit VAs, pgdp=0000000881ef8000
|
|
| [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
|
|
| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
|
|
| Modules linked in:
|
|
| CPU: 4 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc2-00124-g455ef3d016c9-dirty #793
|
|
| Hardware name: FVP Base RevC (DT)
|
|
| pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
|
|
| pc : smc_chan_free+0x3c/0x6c
|
|
| lr : smc_chan_free+0x3c/0x6c
|
|
| Call trace:
|
|
| smc_chan_free+0x3c/0x6c
|
|
| idr_for_each+0x68/0xf8
|
|
| scmi_cleanup_channels.isra.0+0x2c/0x58
|
|
| scmi_probe+0x434/0x734
|
|
| platform_probe+0x68/0xd8
|
|
| really_probe+0x110/0x27c
|
|
| __driver_probe_device+0x78/0x12c
|
|
| driver_probe_device+0x3c/0x118
|
|
| __driver_attach+0x74/0x128
|
|
| bus_for_each_dev+0x78/0xe0
|
|
| driver_attach+0x24/0x30
|
|
| bus_add_driver+0xe4/0x1e8
|
|
| driver_register+0x60/0x128
|
|
| __platform_driver_register+0x28/0x34
|
|
| scmi_driver_init+0x84/0xc0
|
|
| do_one_initcall+0x78/0x33c
|
|
| kernel_init_freeable+0x2b8/0x51c
|
|
| kernel_init+0x24/0x130
|
|
| ret_from_fork+0x10/0x20
|
|
| Code: f0004701 910a0021 aa1403e5 97b91c70 (b9400280)
|
|
| ---[ end trace 0000000000000000 ]---
|
|
|
|
Simply check for the struct pointer being NULL before trying to access
|
|
its members, to avoid this situation.
|
|
|
|
This was found when a transport doesn't really work (for instance no SMC
|
|
service), the probe routines then tries to clean up, and triggers a crash.(CVE-2024-26893)
|
|
|
|
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)</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-1619</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2022-48655</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52628</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52642</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-6270</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26671</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26688</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26792</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26817</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26839</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26840</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26843</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26855</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26875</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26878</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26893</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26898</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48655</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52628</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52642</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-6270</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26671</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26688</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26792</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26817</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26839</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26840</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26843</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26855</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26875</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26878</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26893</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26898</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="python3-perf-5.10.0-60.137.0.164" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">python3-perf-5.10.0-60.137.0.164.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-60.137.0.164" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">python3-perf-debuginfo-5.10.0-60.137.0.164.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-60.137.0.164" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-debuginfo-5.10.0-60.137.0.164.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-60.137.0.164" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-debugsource-5.10.0-60.137.0.164.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-60.137.0.164" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-devel-5.10.0-60.137.0.164.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-60.137.0.164" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-headers-5.10.0-60.137.0.164.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-5.10.0-60.137.0.164" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-5.10.0-60.137.0.164.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-60.137.0.164" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">perf-debuginfo-5.10.0-60.137.0.164.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-60.137.0.164" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-devel-5.10.0-60.137.0.164.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-60.137.0.164" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-source-5.10.0-60.137.0.164.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-60.137.0.164" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">perf-5.10.0-60.137.0.164.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-5.10.0-60.137.0.164" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">bpftool-5.10.0-60.137.0.164.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-60.137.0.164" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-debuginfo-5.10.0-60.137.0.164.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-60.137.0.164" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-5.10.0-60.137.0.164.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-5.10.0-60.137.0.164" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">bpftool-debuginfo-5.10.0-60.137.0.164.oe2203.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-5.10.0-60.137.0.164" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-5.10.0-60.137.0.164.oe2203.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-60.137.0.164" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">python3-perf-debuginfo-5.10.0-60.137.0.164.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-5.10.0-60.137.0.164" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">bpftool-5.10.0-60.137.0.164.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-60.137.0.164" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-devel-5.10.0-60.137.0.164.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-60.137.0.164" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">perf-5.10.0-60.137.0.164.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-60.137.0.164" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-devel-5.10.0-60.137.0.164.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-5.10.0-60.137.0.164" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-5.10.0-60.137.0.164.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-60.137.0.164" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-debuginfo-5.10.0-60.137.0.164.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-60.137.0.164" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-5.10.0-60.137.0.164.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-60.137.0.164" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">python3-perf-5.10.0-60.137.0.164.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-5.10.0-60.137.0.164" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">bpftool-debuginfo-5.10.0-60.137.0.164.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-60.137.0.164" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-headers-5.10.0-60.137.0.164.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-60.137.0.164" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-debuginfo-5.10.0-60.137.0.164.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-60.137.0.164" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">perf-debuginfo-5.10.0-60.137.0.164.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-60.137.0.164" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-debugsource-5.10.0-60.137.0.164.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-60.137.0.164" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-source-5.10.0-60.137.0.164.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:firmware: arm_scmi: Harden accesses to the reset domainsAccessing reset domains descriptors by the index upon the SCMI driversrequests through the SCMI reset operations interface can potentiallylead to out-of-bound violations if the SCMI driver misbehave.Add an internal consistency check before any such domains descriptorsaccesses.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2022-48655</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-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1619</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:
|
|
|
|
netfilter: nftables: exthdr: fix 4-byte stack OOB write
|
|
|
|
If priv->len is a multiple of 4, then dst[len / 4] can write past
|
|
the destination array which leads to stack corruption.
|
|
|
|
This construct is necessary to clean the remainder of the register
|
|
in case ->len is NOT a multiple of the register size, so make it
|
|
conditional just like nft_payload.c does.
|
|
|
|
The bug was added in 4.1 cycle and then copied/inherited when
|
|
tcp/sctp and ip option support was added.
|
|
|
|
Bug reported by Zero Day Initiative project (ZDI-CAN-21950,
|
|
ZDI-CAN-21951, ZDI-CAN-21961).</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2023-52628</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-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1619</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: rc: bpf attach/detach requires write permission
|
|
|
|
Note that bpf attach/detach also requires CAP_NET_ADMIN.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2023-52642</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.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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1619</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">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.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2023-6270</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.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1619</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:
|
|
|
|
blk-mq: fix IO hang from sbitmap wakeup race
|
|
|
|
In blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered
|
|
with the following blk_mq_get_driver_tag() in case of getting driver
|
|
tag failure.
|
|
|
|
Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observe
|
|
the added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime
|
|
blk_mq_mark_tag_wait() can't get driver tag successfully.
|
|
|
|
This issue can be reproduced by running the following test in loop, and
|
|
fio hang can be observed in < 30min when running it on my test VM
|
|
in laptop.
|
|
|
|
modprobe -r scsi_debug
|
|
modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4
|
|
dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename`
|
|
fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \
|
|
--runtime=100 --numjobs=40 --time_based --name=test \
|
|
--ioengine=libaio
|
|
|
|
Fix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), which
|
|
is just fine in case of running out of tag.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26671</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.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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1619</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:
|
|
|
|
fs,hugetlb: fix NULL pointer dereference in hugetlbs_fill_super
|
|
|
|
When configuring a hugetlb filesystem via the fsconfig() syscall, there is
|
|
a possible NULL dereference in hugetlbfs_fill_super() caused by assigning
|
|
NULL to ctx->hstate in hugetlbfs_parse_param() when the requested pagesize
|
|
is non valid.
|
|
|
|
E.g: Taking the following steps:
|
|
|
|
fd = fsopen("hugetlbfs", FSOPEN_CLOEXEC);
|
|
fsconfig(fd, FSCONFIG_SET_STRING, "pagesize", "1024", 0);
|
|
fsconfig(fd, FSCONFIG_CMD_CREATE, NULL, NULL, 0);
|
|
|
|
Given that the requested "pagesize" is invalid, ctxt->hstate will be replaced
|
|
with NULL, losing its previous value, and we will print an error:
|
|
|
|
...
|
|
...
|
|
case Opt_pagesize:
|
|
ps = memparse(param->string, &rest);
|
|
ctx->hstate = h;
|
|
if (!ctx->hstate) {
|
|
pr_err("Unsupported page size %lu MB\n", ps / SZ_1M);
|
|
return -EINVAL;
|
|
}
|
|
return 0;
|
|
...
|
|
...
|
|
|
|
This is a problem because later on, we will dereference ctxt->hstate in
|
|
hugetlbfs_fill_super()
|
|
|
|
...
|
|
...
|
|
sb->s_blocksize = huge_page_size(ctx->hstate);
|
|
...
|
|
...
|
|
|
|
Causing below Oops.
|
|
|
|
Fix this by replacing cxt->hstate value only when then pagesize is known
|
|
to be valid.
|
|
|
|
kernel: hugetlbfs: Unsupported page size 0 MB
|
|
kernel: BUG: kernel NULL pointer dereference, address: 0000000000000028
|
|
kernel: #PF: supervisor read access in kernel mode
|
|
kernel: #PF: error_code(0x0000) - not-present page
|
|
kernel: PGD 800000010f66c067 P4D 800000010f66c067 PUD 1b22f8067 PMD 0
|
|
kernel: Oops: 0000 [#1] PREEMPT SMP PTI
|
|
kernel: CPU: 4 PID: 5659 Comm: syscall Tainted: G E 6.8.0-rc2-default+ #22 5a47c3fef76212addcc6eb71344aabc35190ae8f
|
|
kernel: Hardware name: Intel Corp. GROVEPORT/GROVEPORT, BIOS GVPRCRB1.86B.0016.D04.1705030402 05/03/2017
|
|
kernel: RIP: 0010:hugetlbfs_fill_super+0xb4/0x1a0
|
|
kernel: Code: 48 8b 3b e8 3e c6 ed ff 48 85 c0 48 89 45 20 0f 84 d6 00 00 00 48 b8 ff ff ff ff ff ff ff 7f 4c 89 e7 49 89 44 24 20 48 8b 03 <8b> 48 28 b8 00 10 00 00 48 d3 e0 49 89 44 24 18 48 8b 03 8b 40 28
|
|
kernel: RSP: 0018:ffffbe9960fcbd48 EFLAGS: 00010246
|
|
kernel: RAX: 0000000000000000 RBX: ffff9af5272ae780 RCX: 0000000000372004
|
|
kernel: RDX: ffffffffffffffff RSI: ffffffffffffffff RDI: ffff9af555e9b000
|
|
kernel: RBP: ffff9af52ee66b00 R08: 0000000000000040 R09: 0000000000370004
|
|
kernel: R10: ffffbe9960fcbd48 R11: 0000000000000040 R12: ffff9af555e9b000
|
|
kernel: R13: ffffffffa66b86c0 R14: ffff9af507d2f400 R15: ffff9af507d2f400
|
|
kernel: FS: 00007ffbc0ba4740(0000) GS:ffff9b0bd7000000(0000) knlGS:0000000000000000
|
|
kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
kernel: CR2: 0000000000000028 CR3: 00000001b1ee0000 CR4: 00000000001506f0
|
|
kernel: Call Trace:
|
|
kernel: <TASK>
|
|
kernel: ? __die_body+0x1a/0x60
|
|
kernel: ? page_fault_oops+0x16f/0x4a0
|
|
kernel: ? search_bpf_extables+0x65/0x70
|
|
kernel: ? fixup_exception+0x22/0x310
|
|
kernel: ? exc_page_fault+0x69/0x150
|
|
kernel: ? asm_exc_page_fault+0x22/0x30
|
|
kernel: ? __pfx_hugetlbfs_fill_super+0x10/0x10
|
|
kernel: ? hugetlbfs_fill_super+0xb4/0x1a0
|
|
kernel: ? hugetlbfs_fill_super+0x28/0x1a0
|
|
kernel: ? __pfx_hugetlbfs_fill_super+0x10/0x10
|
|
kernel: vfs_get_super+0x40/0xa0
|
|
kernel: ? __pfx_bpf_lsm_capable+0x10/0x10
|
|
kernel: vfs_get_tree+0x25/0xd0
|
|
kernel: vfs_cmd_create+0x64/0xe0
|
|
kernel: __x64_sys_fsconfig+0x395/0x410
|
|
kernel: do_syscall_64+0x80/0x160
|
|
kernel: ? syscall_exit_to_user_mode+0x82/0x240
|
|
kernel: ? do_syscall_64+0x8d/0x160
|
|
kernel: ? syscall_exit_to_user_mode+0x82/0x240
|
|
kernel: ? do_syscall_64+0x8d/0x160
|
|
kernel: ? exc_page_fault+0x69/0x150
|
|
kernel: entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
kernel: RIP: 0033:0x7ffbc0cb87c9
|
|
kernel: Code: 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 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 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 97 96 0d 00 f7 d8 64 89 01 48
|
|
kernel: RSP: 002b:00007ffc29d2f388 EFLAGS: 00000206 ORIG_RAX: 00000000000001af
|
|
kernel: RAX: fffffffffff
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26688</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.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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1619</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:
|
|
|
|
btrfs: fix double free of anonymous device after snapshot creation failure
|
|
|
|
When creating a snapshot we may do a double free of an anonymous device
|
|
in case there's an error committing the transaction. The second free may
|
|
result in freeing an anonymous device number that was allocated by some
|
|
other subsystem in the kernel or another btrfs filesystem.
|
|
|
|
The steps that lead to this:
|
|
|
|
1) At ioctl.c:create_snapshot() we allocate an anonymous device number
|
|
and assign it to pending_snapshot->anon_dev;
|
|
|
|
2) Then we call btrfs_commit_transaction() and end up at
|
|
transaction.c:create_pending_snapshot();
|
|
|
|
3) There we call btrfs_get_new_fs_root() and pass it the anonymous device
|
|
number stored in pending_snapshot->anon_dev;
|
|
|
|
4) btrfs_get_new_fs_root() frees that anonymous device number because
|
|
btrfs_lookup_fs_root() returned a root - someone else did a lookup
|
|
of the new root already, which could some task doing backref walking;
|
|
|
|
5) After that some error happens in the transaction commit path, and at
|
|
ioctl.c:create_snapshot() we jump to the 'fail' label, and after
|
|
that we free again the same anonymous device number, which in the
|
|
meanwhile may have been reallocated somewhere else, because
|
|
pending_snapshot->anon_dev still has the same value as in step 1.
|
|
|
|
Recently syzbot ran into this and reported the following trace:
|
|
|
|
------------[ cut here ]------------
|
|
ida_free called for id=51 which is not allocated.
|
|
WARNING: CPU: 1 PID: 31038 at lib/idr.c:525 ida_free+0x370/0x420 lib/idr.c:525
|
|
Modules linked in:
|
|
CPU: 1 PID: 31038 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00410-gc02197fc9076 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
|
|
RIP: 0010:ida_free+0x370/0x420 lib/idr.c:525
|
|
Code: 10 42 80 3c 28 (...)
|
|
RSP: 0018:ffffc90015a67300 EFLAGS: 00010246
|
|
RAX: be5130472f5dd000 RBX: 0000000000000033 RCX: 0000000000040000
|
|
RDX: ffffc90009a7a000 RSI: 000000000003ffff RDI: 0000000000040000
|
|
RBP: ffffc90015a673f0 R08: ffffffff81577992 R09: 1ffff92002b4cdb4
|
|
R10: dffffc0000000000 R11: fffff52002b4cdb5 R12: 0000000000000246
|
|
R13: dffffc0000000000 R14: ffffffff8e256b80 R15: 0000000000000246
|
|
FS: 00007fca3f4b46c0(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 00007f167a17b978 CR3: 000000001ed26000 CR4: 0000000000350ef0
|
|
Call Trace:
|
|
<TASK>
|
|
btrfs_get_root_ref+0xa48/0xaf0 fs/btrfs/disk-io.c:1346
|
|
create_pending_snapshot+0xff2/0x2bc0 fs/btrfs/transaction.c:1837
|
|
create_pending_snapshots+0x195/0x1d0 fs/btrfs/transaction.c:1931
|
|
btrfs_commit_transaction+0xf1c/0x3740 fs/btrfs/transaction.c:2404
|
|
create_snapshot+0x507/0x880 fs/btrfs/ioctl.c:848
|
|
btrfs_mksubvol+0x5d0/0x750 fs/btrfs/ioctl.c:998
|
|
btrfs_mksnapshot+0xb5/0xf0 fs/btrfs/ioctl.c:1044
|
|
__btrfs_ioctl_snap_create+0x387/0x4b0 fs/btrfs/ioctl.c:1306
|
|
btrfs_ioctl_snap_create_v2+0x1ca/0x400 fs/btrfs/ioctl.c:1393
|
|
btrfs_ioctl+0xa74/0xd40
|
|
vfs_ioctl fs/ioctl.c:51 [inline]
|
|
__do_sys_ioctl fs/ioctl.c:871 [inline]
|
|
__se_sys_ioctl+0xfe/0x170 fs/ioctl.c:857
|
|
do_syscall_64+0xfb/0x240
|
|
entry_SYSCALL_64_after_hwframe+0x6f/0x77
|
|
RIP: 0033:0x7fca3e67dda9
|
|
Code: 28 00 00 00 (...)
|
|
RSP: 002b:00007fca3f4b40c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
|
|
RAX: ffffffffffffffda RBX: 00007fca3e7abf80 RCX: 00007fca3e67dda9
|
|
RDX: 00000000200005c0 RSI: 0000000050009417 RDI: 0000000000000003
|
|
RBP: 00007fca3e6ca47a R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
|
|
R13: 000000000000000b R14: 00007fca3e7abf80 R15: 00007fff6bf95658
|
|
</TASK>
|
|
|
|
Where we get an explicit message where we attempt to free an anonymous
|
|
device number that is not currently allocated. It happens in a different
|
|
code path from the example below, at btrfs_get_root_ref(), so this change
|
|
may not fix the case triggered by sy
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26792</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.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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1619</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:
|
|
|
|
amdkfd: use calloc instead of kzalloc to avoid integer overflow
|
|
|
|
This uses calloc instead of doing the multiplication which might
|
|
overflow.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26817</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.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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1619</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:
|
|
|
|
IB/hfi1: Fix a memleak in init_credit_return
|
|
|
|
When dma_alloc_coherent fails to allocate dd->cr_base[i].va,
|
|
init_credit_return should deallocate dd->cr_base and
|
|
dd->cr_base[i] that allocated before. Or those resources
|
|
would be never freed and a memleak is triggered.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26839</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1619</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:
|
|
|
|
cachefiles: fix memory leak in cachefiles_add_cache()
|
|
|
|
The following memory leak was reported after unbinding /dev/cachefiles:
|
|
|
|
==================================================================
|
|
unreferenced object 0xffff9b674176e3c0 (size 192):
|
|
comm "cachefilesd2", pid 680, jiffies 4294881224
|
|
hex dump (first 32 bytes):
|
|
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
backtrace (crc ea38a44b):
|
|
[<ffffffff8eb8a1a5>] kmem_cache_alloc+0x2d5/0x370
|
|
[<ffffffff8e917f86>] prepare_creds+0x26/0x2e0
|
|
[<ffffffffc002eeef>] cachefiles_determine_cache_security+0x1f/0x120
|
|
[<ffffffffc00243ec>] cachefiles_add_cache+0x13c/0x3a0
|
|
[<ffffffffc0025216>] cachefiles_daemon_write+0x146/0x1c0
|
|
[<ffffffff8ebc4a3b>] vfs_write+0xcb/0x520
|
|
[<ffffffff8ebc5069>] ksys_write+0x69/0xf0
|
|
[<ffffffff8f6d4662>] do_syscall_64+0x72/0x140
|
|
[<ffffffff8f8000aa>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
==================================================================
|
|
|
|
Put the reference count of cache_cred in cachefiles_daemon_unbind() to
|
|
fix the problem. And also put cache_cred in cachefiles_add_cache() error
|
|
branch to avoid memory leaks.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26840</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1619</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">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
efi: runtime: Fix potential overflow of soft-reserved region size
|
|
|
|
md_size will have been narrowed if we have >= 4GB worth of pages in a
|
|
soft-reserved region.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26843</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.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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1619</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:
|
|
|
|
net: ice: Fix potential NULL pointer dereference in ice_bridge_setlink()
|
|
|
|
The function ice_bridge_setlink() may encounter a NULL pointer dereference
|
|
if nlmsg_find_attr() returns NULL and br_spec is dereferenced subsequently
|
|
in nla_for_each_nested(). To address this issue, add a check to ensure that
|
|
br_spec is not NULL before proceeding with the nested attribute iteration.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26855</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.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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1619</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:
|
|
|
|
media: pvrusb2: fix uaf in pvr2_context_set_notify
|
|
|
|
[Syzbot reported]
|
|
BUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35
|
|
Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26
|
|
|
|
CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
|
|
Workqueue: usb_hub_wq hub_event
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106
|
|
print_address_description mm/kasan/report.c:377 [inline]
|
|
print_report+0xc4/0x620 mm/kasan/report.c:488
|
|
kasan_report+0xda/0x110 mm/kasan/report.c:601
|
|
pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35
|
|
pvr2_context_notify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline]
|
|
pvr2_context_disconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272
|
|
|
|
Freed by task 906:
|
|
kasan_save_stack+0x33/0x50 mm/kasan/common.c:47
|
|
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
|
|
kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640
|
|
poison_slab_object mm/kasan/common.c:241 [inline]
|
|
__kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257
|
|
kasan_slab_free include/linux/kasan.h:184 [inline]
|
|
slab_free_hook mm/slub.c:2121 [inline]
|
|
slab_free mm/slub.c:4299 [inline]
|
|
kfree+0x105/0x340 mm/slub.c:4409
|
|
pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline]
|
|
pvr2_context_thread_func+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158
|
|
|
|
[Analyze]
|
|
Task A set disconnect_flag = !0, which resulted in Task B's condition being met
|
|
and releasing mp, leading to this issue.
|
|
|
|
[Fix]
|
|
Place the disconnect_flag assignment operation after all code in pvr2_context_disconnect()
|
|
to avoid this issue.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26875</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>6.4</BaseScore>
|
|
<Vector>AV:L/AC:H/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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1619</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:
|
|
|
|
quota: Fix potential NULL pointer dereference
|
|
|
|
Below race may cause NULL pointer dereference
|
|
|
|
P1 P2
|
|
dquot_free_inode quota_off
|
|
drop_dquot_ref
|
|
remove_dquot_ref
|
|
dquots = i_dquot(inode)
|
|
dquots = i_dquot(inode)
|
|
srcu_read_lock
|
|
dquots[cnt]) != NULL (1)
|
|
dquots[type] = NULL (2)
|
|
spin_lock(&dquots[cnt]->dq_dqb_lock) (3)
|
|
....
|
|
|
|
If dquot_free_inode(or other routines) checks inode's quota pointers (1)
|
|
before quota_off sets it to NULL(2) and use it (3) after that, NULL pointer
|
|
dereference will be triggered.
|
|
|
|
So let's fix it by using a temporary pointer to avoid this issue.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26878</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.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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1619</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:
|
|
|
|
firmware: arm_scmi: Fix double free in SMC transport cleanup path
|
|
|
|
When the generic SCMI code tears down a channel, it calls the chan_free
|
|
callback function, defined by each transport. Since multiple protocols
|
|
might share the same transport_info member, chan_free() might want to
|
|
clean up the same member multiple times within the given SCMI transport
|
|
implementation. In this case, it is SMC transport. This will lead to a NULL
|
|
pointer dereference at the second time:
|
|
|
|
| scmi_protocol scmi_dev.1: Enabled polling mode TX channel - prot_id:16
|
|
| arm-scmi firmware:scmi: SCMI Notifications - Core Enabled.
|
|
| arm-scmi firmware:scmi: unable to communicate with SCMI
|
|
| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
|
|
| Mem abort info:
|
|
| ESR = 0x0000000096000004
|
|
| EC = 0x25: DABT (current EL), IL = 32 bits
|
|
| SET = 0, FnV = 0
|
|
| EA = 0, S1PTW = 0
|
|
| FSC = 0x04: level 0 translation fault
|
|
| Data abort info:
|
|
| ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
|
|
| CM = 0, WnR = 0, TnD = 0, TagAccess = 0
|
|
| GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
|
|
| user pgtable: 4k pages, 48-bit VAs, pgdp=0000000881ef8000
|
|
| [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
|
|
| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
|
|
| Modules linked in:
|
|
| CPU: 4 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc2-00124-g455ef3d016c9-dirty #793
|
|
| Hardware name: FVP Base RevC (DT)
|
|
| pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
|
|
| pc : smc_chan_free+0x3c/0x6c
|
|
| lr : smc_chan_free+0x3c/0x6c
|
|
| Call trace:
|
|
| smc_chan_free+0x3c/0x6c
|
|
| idr_for_each+0x68/0xf8
|
|
| scmi_cleanup_channels.isra.0+0x2c/0x58
|
|
| scmi_probe+0x434/0x734
|
|
| platform_probe+0x68/0xd8
|
|
| really_probe+0x110/0x27c
|
|
| __driver_probe_device+0x78/0x12c
|
|
| driver_probe_device+0x3c/0x118
|
|
| __driver_attach+0x74/0x128
|
|
| bus_for_each_dev+0x78/0xe0
|
|
| driver_attach+0x24/0x30
|
|
| bus_add_driver+0xe4/0x1e8
|
|
| driver_register+0x60/0x128
|
|
| __platform_driver_register+0x28/0x34
|
|
| scmi_driver_init+0x84/0xc0
|
|
| do_one_initcall+0x78/0x33c
|
|
| kernel_init_freeable+0x2b8/0x51c
|
|
| kernel_init+0x24/0x130
|
|
| ret_from_fork+0x10/0x20
|
|
| Code: f0004701 910a0021 aa1403e5 97b91c70 (b9400280)
|
|
| ---[ end trace 0000000000000000 ]---
|
|
|
|
Simply check for the struct pointer being NULL before trying to access
|
|
its members, to avoid this situation.
|
|
|
|
This was found when a transport doesn't really work (for instance no SMC
|
|
service), the probe routines then tries to clean up, and triggers a crash.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26893</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.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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1619</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:aoe: fix the potential use-after-free problem in aoecmd_cfg_pktsThis 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 initialcode is finished. But the net_device ifp will still be used inlater tx()->dev_queue_xmit() in kthread. Which means that thedev_put(ifp) should NOT be called in the success path of skbinitial code in aoecmd_cfg_pkts(). Otherwise tx() may run intouse-after-free because the net_device is freed.This patch removed the dev_put(ifp) in the success path inaoecmd_cfg_pkts(), and added dev_put() after skb xmit in tx().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26898</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-05-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1619</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |