2440 lines
107 KiB
XML
2440 lines
107 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-SP2</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-1621</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-SP2.</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:
|
|
|
|
usb: hub: Guard against accesses to uninitialized BOS descriptors
|
|
|
|
Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h
|
|
access fields inside udev->bos without checking if it was allocated and
|
|
initialized. If usb_get_bos_descriptor() fails for whatever
|
|
reason, udev->bos will be NULL and those accesses will result in a
|
|
crash:
|
|
|
|
BUG: kernel NULL pointer dereference, address: 0000000000000018
|
|
PGD 0 P4D 0
|
|
Oops: 0000 [#1] PREEMPT SMP NOPTI
|
|
CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1>
|
|
Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021
|
|
Workqueue: usb_hub_wq hub_event
|
|
RIP: 0010:hub_port_reset+0x193/0x788
|
|
Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9
|
|
RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246
|
|
RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310
|
|
RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840
|
|
RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060
|
|
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
|
|
R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000
|
|
FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0
|
|
Call Trace:
|
|
hub_event+0x73f/0x156e
|
|
? hub_activate+0x5b7/0x68f
|
|
process_one_work+0x1a2/0x487
|
|
worker_thread+0x11a/0x288
|
|
kthread+0x13a/0x152
|
|
? process_one_work+0x487/0x487
|
|
? kthread_associate_blkcg+0x70/0x70
|
|
ret_from_fork+0x1f/0x30
|
|
|
|
Fall back to a default behavior if the BOS descriptor isn't accessible
|
|
and skip all the functionalities that depend on it: LPM support checks,
|
|
Super Speed capabilitiy checks, U1/U2 states setup.(CVE-2023-52477)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
block/rnbd-srv: Check for unlikely string overflow
|
|
|
|
Since "dev_search_path" can technically be as large as PATH_MAX,
|
|
there was a risk of truncation when copying it and a second string
|
|
into "full_path" since it was also PATH_MAX sized. The W=1 builds were
|
|
reporting this warning:
|
|
|
|
drivers/block/rnbd/rnbd-srv.c: In function 'process_msg_open.isra':
|
|
drivers/block/rnbd/rnbd-srv.c:616:51: warning: '%s' directive output may be truncated writing up to 254 bytes into a region of size between 0 and 4095 [-Wformat-truncation=]
|
|
616 | snprintf(full_path, PATH_MAX, "%s/%s",
|
|
| ^~
|
|
In function 'rnbd_srv_get_full_path',
|
|
inlined from 'process_msg_open.isra' at drivers/block/rnbd/rnbd-srv.c:721:14: drivers/block/rnbd/rnbd-srv.c:616:17: note: 'snprintf' output between 2 and 4351 bytes into a destination of size 4096
|
|
616 | snprintf(full_path, PATH_MAX, "%s/%s",
|
|
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
617 | dev_search_path, dev_name);
|
|
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
To fix this, unconditionally check for truncation (as was already done
|
|
for the case where "%SESSNAME%" was present).(CVE-2023-52618)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nf_tables: disallow timeout for anonymous sets
|
|
|
|
Never used from userspace, disallow these parameters.(CVE-2023-52620)
|
|
|
|
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:
|
|
|
|
netfilter: nft_limit: reject configurations that cause integer overflow
|
|
|
|
Reject bogus configs where internal token counter wraps around.
|
|
This only occurs with very very large requests, such as 17gbyte/s.
|
|
|
|
Its better to reject this rather than having incorrect ratelimit.(CVE-2024-26668)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/sched: flower: Fix chain template offload
|
|
|
|
When a qdisc is deleted from a net device the stack instructs the
|
|
underlying driver to remove its flow offload callback from the
|
|
associated filter block using the 'FLOW_BLOCK_UNBIND' command. The stack
|
|
then continues to replay the removal of the filters in the block for
|
|
this driver by iterating over the chains in the block and invoking the
|
|
'reoffload' operation of the classifier being used. In turn, the
|
|
classifier in its 'reoffload' operation prepares and emits a
|
|
'FLOW_CLS_DESTROY' command for each filter.
|
|
|
|
However, the stack does not do the same for chain templates and the
|
|
underlying driver never receives a 'FLOW_CLS_TMPLT_DESTROY' command when
|
|
a qdisc is deleted. This results in a memory leak [1] which can be
|
|
reproduced using [2].
|
|
|
|
Fix by introducing a 'tmplt_reoffload' operation and have the stack
|
|
invoke it with the appropriate arguments as part of the replay.
|
|
Implement the operation in the sole classifier that supports chain
|
|
templates (flower) by emitting the 'FLOW_CLS_TMPLT_{CREATE,DESTROY}'
|
|
command based on whether a flow offload callback is being bound to a
|
|
filter block or being unbound from one.
|
|
|
|
As far as I can tell, the issue happens since cited commit which
|
|
reordered tcf_block_offload_unbind() before tcf_block_flush_all_chains()
|
|
in __tcf_block_put(). The order cannot be reversed as the filter block
|
|
is expected to be freed after flushing all the chains.
|
|
|
|
[1]
|
|
unreferenced object 0xffff888107e28800 (size 2048):
|
|
comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s)
|
|
hex dump (first 32 bytes):
|
|
b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff ff ..|......[......
|
|
01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff ................
|
|
backtrace:
|
|
[<ffffffff81c06a68>] __kmem_cache_alloc_node+0x1e8/0x320
|
|
[<ffffffff81ab374e>] __kmalloc+0x4e/0x90
|
|
[<ffffffff832aec6d>] mlxsw_sp_acl_ruleset_get+0x34d/0x7a0
|
|
[<ffffffff832bc195>] mlxsw_sp_flower_tmplt_create+0x145/0x180
|
|
[<ffffffff832b2e1a>] mlxsw_sp_flow_block_cb+0x1ea/0x280
|
|
[<ffffffff83a10613>] tc_setup_cb_call+0x183/0x340
|
|
[<ffffffff83a9f85a>] fl_tmplt_create+0x3da/0x4c0
|
|
[<ffffffff83a22435>] tc_ctl_chain+0xa15/0x1170
|
|
[<ffffffff838a863c>] rtnetlink_rcv_msg+0x3cc/0xed0
|
|
[<ffffffff83ac87f0>] netlink_rcv_skb+0x170/0x440
|
|
[<ffffffff83ac6270>] netlink_unicast+0x540/0x820
|
|
[<ffffffff83ac6e28>] netlink_sendmsg+0x8d8/0xda0
|
|
[<ffffffff83793def>] ____sys_sendmsg+0x30f/0xa80
|
|
[<ffffffff8379d29a>] ___sys_sendmsg+0x13a/0x1e0
|
|
[<ffffffff8379d50c>] __sys_sendmsg+0x11c/0x1f0
|
|
[<ffffffff843b9ce0>] do_syscall_64+0x40/0xe0
|
|
unreferenced object 0xffff88816d2c0400 (size 1024):
|
|
comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s)
|
|
hex dump (first 32 bytes):
|
|
40 00 00 00 00 00 00 00 57 f6 38 be 00 00 00 00 @.......W.8.....
|
|
10 04 2c 6d 81 88 ff ff 10 04 2c 6d 81 88 ff ff ..,m......,m....
|
|
backtrace:
|
|
[<ffffffff81c06a68>] __kmem_cache_alloc_node+0x1e8/0x320
|
|
[<ffffffff81ab36c1>] __kmalloc_node+0x51/0x90
|
|
[<ffffffff81a8ed96>] kvmalloc_node+0xa6/0x1f0
|
|
[<ffffffff82827d03>] bucket_table_alloc.isra.0+0x83/0x460
|
|
[<ffffffff82828d2b>] rhashtable_init+0x43b/0x7c0
|
|
[<ffffffff832aed48>] mlxsw_sp_acl_ruleset_get+0x428/0x7a0
|
|
[<ffffffff832bc195>] mlxsw_sp_flower_tmplt_create+0x145/0x180
|
|
[<ffffffff832b2e1a>] mlxsw_sp_flow_block_cb+0x1ea/0x280
|
|
[<ffffffff83a10613>] tc_setup_cb_call+0x183/0x340
|
|
[<ffffffff83a9f85a>] fl_tmplt_create+0x3da/0x4c0
|
|
[<ffffffff83a22435>] tc_ctl_chain+0xa15/0x1170
|
|
[<ffffffff838a863c>] rtnetlink_rcv_msg+0x3cc/0xed0
|
|
[<ffffffff83ac87f0>] netlink_rcv_skb+0x170/0x440
|
|
[<ffffffff83ac6270>] netlink_unicast+0x540/0x820
|
|
[<ffffffff83ac6e28>] netlink_sendmsg+0x8d8/0xda0
|
|
[<ffffffff83793def>] ____sys_sendmsg+0x30f/0xa80
|
|
|
|
[2]
|
|
# tc qdisc add dev swp1 clsact
|
|
# tc chain add dev swp1 ingress proto ip chain 1 flower dst_ip 0.0.0.0/32
|
|
# tc qdisc del dev
|
|
---truncated---(CVE-2024-26669)
|
|
|
|
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:
|
|
|
|
net: atlantic: Fix DMA mapping for PTP hwts ring
|
|
|
|
Function aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes
|
|
for PTP HWTS ring but then generic aq_ring_free() does not take this
|
|
into account.
|
|
Create and use a specific function to free HWTS ring to fix this
|
|
issue.
|
|
|
|
Trace:
|
|
[ 215.351607] ------------[ cut here ]------------
|
|
[ 215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes]
|
|
[ 215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360
|
|
...
|
|
[ 215.581176] Call Trace:
|
|
[ 215.583632] <TASK>
|
|
[ 215.585745] ? show_trace_log_lvl+0x1c4/0x2df
|
|
[ 215.590114] ? show_trace_log_lvl+0x1c4/0x2df
|
|
[ 215.594497] ? debug_dma_free_coherent+0x196/0x210
|
|
[ 215.599305] ? check_unmap+0xa6f/0x2360
|
|
[ 215.603147] ? __warn+0xca/0x1d0
|
|
[ 215.606391] ? check_unmap+0xa6f/0x2360
|
|
[ 215.610237] ? report_bug+0x1ef/0x370
|
|
[ 215.613921] ? handle_bug+0x3c/0x70
|
|
[ 215.617423] ? exc_invalid_op+0x14/0x50
|
|
[ 215.621269] ? asm_exc_invalid_op+0x16/0x20
|
|
[ 215.625480] ? check_unmap+0xa6f/0x2360
|
|
[ 215.629331] ? mark_lock.part.0+0xca/0xa40
|
|
[ 215.633445] debug_dma_free_coherent+0x196/0x210
|
|
[ 215.638079] ? __pfx_debug_dma_free_coherent+0x10/0x10
|
|
[ 215.643242] ? slab_free_freelist_hook+0x11d/0x1d0
|
|
[ 215.648060] dma_free_attrs+0x6d/0x130
|
|
[ 215.651834] aq_ring_free+0x193/0x290 [atlantic]
|
|
[ 215.656487] aq_ptp_ring_free+0x67/0x110 [atlantic]
|
|
...
|
|
[ 216.127540] ---[ end trace 6467e5964dd2640b ]---
|
|
[ 216.132160] DMA-API: Mapped at:
|
|
[ 216.132162] debug_dma_alloc_coherent+0x66/0x2f0
|
|
[ 216.132165] dma_alloc_attrs+0xf5/0x1b0
|
|
[ 216.132168] aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic]
|
|
[ 216.132193] aq_ptp_ring_alloc+0x1bb/0x540 [atlantic]
|
|
[ 216.132213] aq_nic_init+0x4a1/0x760 [atlantic](CVE-2024-26680)
|
|
|
|
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:
|
|
|
|
ceph: prevent use-after-free in encode_cap_msg()
|
|
|
|
In fs/ceph/caps.c, in encode_cap_msg(), "use after free" error was
|
|
caught by KASAN at this line - 'ceph_buffer_get(arg->xattr_buf);'. This
|
|
implies before the refcount could be increment here, it was freed.
|
|
|
|
In same file, in "handle_cap_grant()" refcount is decremented by this
|
|
line - 'ceph_buffer_put(ci->i_xattrs.blob);'. It appears that a race
|
|
occurred and resource was freed by the latter line before the former
|
|
line could increment it.
|
|
|
|
encode_cap_msg() is called by __send_cap() and __send_cap() is called by
|
|
ceph_check_caps() after calling __prep_cap(). __prep_cap() is where
|
|
arg->xattr_buf is assigned to ci->i_xattrs.blob. This is the spot where
|
|
the refcount must be increased to prevent "use after free" error.(CVE-2024-26689)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
btrfs: dev-replace: properly validate device names
|
|
|
|
There's a syzbot report that device name buffers passed to device
|
|
replace are not properly checked for string termination which could lead
|
|
to a read out of bounds in getname_kernel().
|
|
|
|
Add a helper that validates both source and target device name buffers.
|
|
For devid as the source initialize the buffer to empty string in case
|
|
something tries to read it later.
|
|
|
|
This was originally analyzed and fixed in a different way by Edward Adam
|
|
Davis (see links).(CVE-2024-26791)
|
|
|
|
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:
|
|
|
|
ksmbd: validate payload size in ipc response
|
|
|
|
If installing malicious ksmbd-tools, ksmbd.mountd can return invalid ipc
|
|
response to ksmbd kernel server. ksmbd should validate payload size of
|
|
ipc response from ksmbd.mountd to avoid memory overrun or
|
|
slab-out-of-bounds. This patch validate 3 ipc response that has payload.(CVE-2024-26811)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
vfio/pci: Create persistent INTx handler
|
|
|
|
A vulnerability exists where the eventfd for INTx signaling can be
|
|
deconfigured, which unregisters the IRQ handler but still allows
|
|
eventfds to be signaled with a NULL context through the SET_IRQS ioctl
|
|
or through unmask irqfd if the device interrupt is pending.
|
|
|
|
Ideally this could be solved with some additional locking; the igate
|
|
mutex serializes the ioctl and config space accesses, and the interrupt
|
|
handler is unregistered relative to the trigger, but the irqfd path
|
|
runs asynchronous to those. The igate mutex cannot be acquired from the
|
|
atomic context of the eventfd wake function. Disabling the irqfd
|
|
relative to the eventfd registration is potentially incompatible with
|
|
existing userspace.
|
|
|
|
As a result, the solution implemented here moves configuration of the
|
|
INTx interrupt handler to track the lifetime of the INTx context object
|
|
and irq_type configuration, rather than registration of a particular
|
|
trigger eventfd. Synchronization is added between the ioctl path and
|
|
eventfd_signal() wrapper such that the eventfd trigger can be
|
|
dynamically updated relative to in-flight interrupts or irqfd callbacks.(CVE-2024-26812)
|
|
|
|
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:
|
|
|
|
cifs: fix underflow in parse_server_interfaces()
|
|
|
|
In this loop, we step through the buffer and after each item we check
|
|
if the size_left is greater than the minimum size we need. However,
|
|
the problem is that "bytes_left" is type ssize_t while sizeof() is type
|
|
size_t. That means that because of type promotion, the comparison is
|
|
done as an unsigned and if we have negative bytes left the loop
|
|
continues instead of ending.(CVE-2024-26828)
|
|
|
|
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:
|
|
|
|
NFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102
|
|
|
|
A call to listxattr() with a buffer size = 0 returns the actual
|
|
size of the buffer needed for a subsequent call. When size > 0,
|
|
nfs4_listxattr() does not return an error because either
|
|
generic_listxattr() or nfs4_listxattr_nfs4_label() consumes
|
|
exactly all the bytes then size is 0 when calling
|
|
nfs4_listxattr_nfs4_user() which then triggers the following
|
|
kernel BUG:
|
|
|
|
[ 99.403778] kernel BUG at mm/usercopy.c:102!
|
|
[ 99.404063] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
|
|
[ 99.408463] CPU: 0 PID: 3310 Comm: python3 Not tainted 6.6.0-61.fc40.aarch64 #1
|
|
[ 99.415827] Call trace:
|
|
[ 99.415985] usercopy_abort+0x70/0xa0
|
|
[ 99.416227] __check_heap_object+0x134/0x158
|
|
[ 99.416505] check_heap_object+0x150/0x188
|
|
[ 99.416696] __check_object_size.part.0+0x78/0x168
|
|
[ 99.416886] __check_object_size+0x28/0x40
|
|
[ 99.417078] listxattr+0x8c/0x120
|
|
[ 99.417252] path_listxattr+0x78/0xe0
|
|
[ 99.417476] __arm64_sys_listxattr+0x28/0x40
|
|
[ 99.417723] invoke_syscall+0x78/0x100
|
|
[ 99.417929] el0_svc_common.constprop.0+0x48/0xf0
|
|
[ 99.418186] do_el0_svc+0x24/0x38
|
|
[ 99.418376] el0_svc+0x3c/0x110
|
|
[ 99.418554] el0t_64_sync_handler+0x120/0x130
|
|
[ 99.418788] el0t_64_sync+0x194/0x198
|
|
[ 99.418994] Code: aa0003e3 d000a3e0 91310000 97f49bdb (d4210000)
|
|
|
|
Issue is reproduced when generic_listxattr() returns 'system.nfs4_acl',
|
|
thus calling lisxattr() with size = 16 will trigger the bug.
|
|
|
|
Add check on nfs4_listxattr() to return ERANGE error when it is
|
|
called with size > 0 and the return value is greater than size.(CVE-2024-26870)
|
|
|
|
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-SP2.
|
|
|
|
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-1621</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-52477</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52618</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52620</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-26668</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26669</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-26680</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-26689</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26791</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-26811</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26812</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-26828</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-26870</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-52477</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52618</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52620</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-26668</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26669</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26671</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26680</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26688</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26689</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26791</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26792</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26811</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26812</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26817</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26828</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-26870</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-SP2" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">openEuler-22.03-LTS-SP2</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="kernel-5.10.0-153.54.0.132" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-5.10.0-153.54.0.132.oe2203sp2.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-153.54.0.132" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-headers-5.10.0-153.54.0.132.oe2203sp2.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-153.54.0.132" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-debuginfo-5.10.0-153.54.0.132.oe2203sp2.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-153.54.0.132" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-tools-debuginfo-5.10.0-153.54.0.132.oe2203sp2.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-153.54.0.132" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-tools-devel-5.10.0-153.54.0.132.oe2203sp2.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-153.54.0.132" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-tools-5.10.0-153.54.0.132.oe2203sp2.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-153.54.0.132" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">python3-perf-5.10.0-153.54.0.132.oe2203sp2.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-153.54.0.132" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-source-5.10.0-153.54.0.132.oe2203sp2.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-153.54.0.132" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">perf-5.10.0-153.54.0.132.oe2203sp2.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-153.54.0.132" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">python3-perf-debuginfo-5.10.0-153.54.0.132.oe2203sp2.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-153.54.0.132" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">perf-debuginfo-5.10.0-153.54.0.132.oe2203sp2.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-153.54.0.132" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-devel-5.10.0-153.54.0.132.oe2203sp2.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-153.54.0.132" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-debugsource-5.10.0-153.54.0.132.oe2203sp2.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-5.10.0-153.54.0.132" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-5.10.0-153.54.0.132.oe2203sp2.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="kernel-source-5.10.0-153.54.0.132" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-source-5.10.0-153.54.0.132.oe2203sp2.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-153.54.0.132" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-headers-5.10.0-153.54.0.132.oe2203sp2.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-153.54.0.132" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">python3-perf-debuginfo-5.10.0-153.54.0.132.oe2203sp2.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-153.54.0.132" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">python3-perf-5.10.0-153.54.0.132.oe2203sp2.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-153.54.0.132" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-devel-5.10.0-153.54.0.132.oe2203sp2.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-153.54.0.132" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-tools-debuginfo-5.10.0-153.54.0.132.oe2203sp2.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-153.54.0.132" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-tools-5.10.0-153.54.0.132.oe2203sp2.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-153.54.0.132" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-debugsource-5.10.0-153.54.0.132.oe2203sp2.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-5.10.0-153.54.0.132" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-5.10.0-153.54.0.132.oe2203sp2.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-153.54.0.132" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-debuginfo-5.10.0-153.54.0.132.oe2203sp2.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-153.54.0.132" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-tools-devel-5.10.0-153.54.0.132.oe2203sp2.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-153.54.0.132" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">perf-5.10.0-153.54.0.132.oe2203sp2.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-153.54.0.132" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">perf-debuginfo-5.10.0-153.54.0.132.oe2203sp2.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-SP2</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-1621</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:
|
|
|
|
usb: hub: Guard against accesses to uninitialized BOS descriptors
|
|
|
|
Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h
|
|
access fields inside udev->bos without checking if it was allocated and
|
|
initialized. If usb_get_bos_descriptor() fails for whatever
|
|
reason, udev->bos will be NULL and those accesses will result in a
|
|
crash:
|
|
|
|
BUG: kernel NULL pointer dereference, address: 0000000000000018
|
|
PGD 0 P4D 0
|
|
Oops: 0000 [#1] PREEMPT SMP NOPTI
|
|
CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1>
|
|
Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021
|
|
Workqueue: usb_hub_wq hub_event
|
|
RIP: 0010:hub_port_reset+0x193/0x788
|
|
Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9
|
|
RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246
|
|
RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310
|
|
RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840
|
|
RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060
|
|
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
|
|
R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000
|
|
FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0
|
|
Call Trace:
|
|
hub_event+0x73f/0x156e
|
|
? hub_activate+0x5b7/0x68f
|
|
process_one_work+0x1a2/0x487
|
|
worker_thread+0x11a/0x288
|
|
kthread+0x13a/0x152
|
|
? process_one_work+0x487/0x487
|
|
? kthread_associate_blkcg+0x70/0x70
|
|
ret_from_fork+0x1f/0x30
|
|
|
|
Fall back to a default behavior if the BOS descriptor isn't accessible
|
|
and skip all the functionalities that depend on it: LPM support checks,
|
|
Super Speed capabilitiy checks, U1/U2 states setup.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2023-52477</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP2</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-1621</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:
|
|
|
|
block/rnbd-srv: Check for unlikely string overflow
|
|
|
|
Since "dev_search_path" can technically be as large as PATH_MAX,
|
|
there was a risk of truncation when copying it and a second string
|
|
into "full_path" since it was also PATH_MAX sized. The W=1 builds were
|
|
reporting this warning:
|
|
|
|
drivers/block/rnbd/rnbd-srv.c: In function 'process_msg_open.isra':
|
|
drivers/block/rnbd/rnbd-srv.c:616:51: warning: '%s' directive output may be truncated writing up to 254 bytes into a region of size between 0 and 4095 [-Wformat-truncation=]
|
|
616 | snprintf(full_path, PATH_MAX, "%s/%s",
|
|
| ^~
|
|
In function 'rnbd_srv_get_full_path',
|
|
inlined from 'process_msg_open.isra' at drivers/block/rnbd/rnbd-srv.c:721:14: drivers/block/rnbd/rnbd-srv.c:616:17: note: 'snprintf' output between 2 and 4351 bytes into a destination of size 4096
|
|
616 | snprintf(full_path, PATH_MAX, "%s/%s",
|
|
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
617 | dev_search_path, dev_name);
|
|
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
To fix this, unconditionally check for truncation (as was already done
|
|
for the case where "%SESSNAME%" was present).</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2023-52618</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP2</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:H/A:N</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-1621</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:
|
|
|
|
netfilter: nf_tables: disallow timeout for anonymous sets
|
|
|
|
Never used from userspace, disallow these parameters.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2023-52620</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP2</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1621</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:
|
|
|
|
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-SP2</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-1621</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:
|
|
|
|
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-SP2</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-1621</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">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-SP2</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-1621</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:
|
|
|
|
netfilter: nft_limit: reject configurations that cause integer overflow
|
|
|
|
Reject bogus configs where internal token counter wraps around.
|
|
This only occurs with very very large requests, such as 17gbyte/s.
|
|
|
|
Its better to reject this rather than having incorrect ratelimit.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26668</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP2</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-1621</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:
|
|
|
|
net/sched: flower: Fix chain template offload
|
|
|
|
When a qdisc is deleted from a net device the stack instructs the
|
|
underlying driver to remove its flow offload callback from the
|
|
associated filter block using the 'FLOW_BLOCK_UNBIND' command. The stack
|
|
then continues to replay the removal of the filters in the block for
|
|
this driver by iterating over the chains in the block and invoking the
|
|
'reoffload' operation of the classifier being used. In turn, the
|
|
classifier in its 'reoffload' operation prepares and emits a
|
|
'FLOW_CLS_DESTROY' command for each filter.
|
|
|
|
However, the stack does not do the same for chain templates and the
|
|
underlying driver never receives a 'FLOW_CLS_TMPLT_DESTROY' command when
|
|
a qdisc is deleted. This results in a memory leak [1] which can be
|
|
reproduced using [2].
|
|
|
|
Fix by introducing a 'tmplt_reoffload' operation and have the stack
|
|
invoke it with the appropriate arguments as part of the replay.
|
|
Implement the operation in the sole classifier that supports chain
|
|
templates (flower) by emitting the 'FLOW_CLS_TMPLT_{CREATE,DESTROY}'
|
|
command based on whether a flow offload callback is being bound to a
|
|
filter block or being unbound from one.
|
|
|
|
As far as I can tell, the issue happens since cited commit which
|
|
reordered tcf_block_offload_unbind() before tcf_block_flush_all_chains()
|
|
in __tcf_block_put(). The order cannot be reversed as the filter block
|
|
is expected to be freed after flushing all the chains.
|
|
|
|
[1]
|
|
unreferenced object 0xffff888107e28800 (size 2048):
|
|
comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s)
|
|
hex dump (first 32 bytes):
|
|
b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff ff ..|......[......
|
|
01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff ................
|
|
backtrace:
|
|
[<ffffffff81c06a68>] __kmem_cache_alloc_node+0x1e8/0x320
|
|
[<ffffffff81ab374e>] __kmalloc+0x4e/0x90
|
|
[<ffffffff832aec6d>] mlxsw_sp_acl_ruleset_get+0x34d/0x7a0
|
|
[<ffffffff832bc195>] mlxsw_sp_flower_tmplt_create+0x145/0x180
|
|
[<ffffffff832b2e1a>] mlxsw_sp_flow_block_cb+0x1ea/0x280
|
|
[<ffffffff83a10613>] tc_setup_cb_call+0x183/0x340
|
|
[<ffffffff83a9f85a>] fl_tmplt_create+0x3da/0x4c0
|
|
[<ffffffff83a22435>] tc_ctl_chain+0xa15/0x1170
|
|
[<ffffffff838a863c>] rtnetlink_rcv_msg+0x3cc/0xed0
|
|
[<ffffffff83ac87f0>] netlink_rcv_skb+0x170/0x440
|
|
[<ffffffff83ac6270>] netlink_unicast+0x540/0x820
|
|
[<ffffffff83ac6e28>] netlink_sendmsg+0x8d8/0xda0
|
|
[<ffffffff83793def>] ____sys_sendmsg+0x30f/0xa80
|
|
[<ffffffff8379d29a>] ___sys_sendmsg+0x13a/0x1e0
|
|
[<ffffffff8379d50c>] __sys_sendmsg+0x11c/0x1f0
|
|
[<ffffffff843b9ce0>] do_syscall_64+0x40/0xe0
|
|
unreferenced object 0xffff88816d2c0400 (size 1024):
|
|
comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s)
|
|
hex dump (first 32 bytes):
|
|
40 00 00 00 00 00 00 00 57 f6 38 be 00 00 00 00 @.......W.8.....
|
|
10 04 2c 6d 81 88 ff ff 10 04 2c 6d 81 88 ff ff ..,m......,m....
|
|
backtrace:
|
|
[<ffffffff81c06a68>] __kmem_cache_alloc_node+0x1e8/0x320
|
|
[<ffffffff81ab36c1>] __kmalloc_node+0x51/0x90
|
|
[<ffffffff81a8ed96>] kvmalloc_node+0xa6/0x1f0
|
|
[<ffffffff82827d03>] bucket_table_alloc.isra.0+0x83/0x460
|
|
[<ffffffff82828d2b>] rhashtable_init+0x43b/0x7c0
|
|
[<ffffffff832aed48>] mlxsw_sp_acl_ruleset_get+0x428/0x7a0
|
|
[<ffffffff832bc195>] mlxsw_sp_flower_tmplt_create+0x145/0x180
|
|
[<ffffffff832b2e1a>] mlxsw_sp_flow_block_cb+0x1ea/0x280
|
|
[<ffffffff83a10613>] tc_setup_cb_call+0x183/0x340
|
|
[<ffffffff83a9f85a>] fl_tmplt_create+0x3da/0x4c0
|
|
[<ffffffff83a22435>] tc_ctl_chain+0xa15/0x1170
|
|
[<ffffffff838a863c>] rtnetlink_rcv_msg+0x3cc/0xed0
|
|
[<ffffffff83ac87f0>] netlink_rcv_skb+0x170/0x440
|
|
[<ffffffff83ac6270>] netlink_unicast+0x540/0x820
|
|
[<ffffffff83ac6e28>] netlink_sendmsg+0x8d8/0xda0
|
|
[<ffffffff83793def>] ____sys_sendmsg+0x30f/0xa80
|
|
|
|
[2]
|
|
# tc qdisc add dev swp1 clsact
|
|
# tc chain add dev swp1 ingress proto ip chain 1 flower dst_ip 0.0.0.0/32
|
|
# tc qdisc del dev
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26669</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP2</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-1621</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:
|
|
|
|
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-SP2</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-1621</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:
|
|
|
|
net: atlantic: Fix DMA mapping for PTP hwts ring
|
|
|
|
Function aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes
|
|
for PTP HWTS ring but then generic aq_ring_free() does not take this
|
|
into account.
|
|
Create and use a specific function to free HWTS ring to fix this
|
|
issue.
|
|
|
|
Trace:
|
|
[ 215.351607] ------------[ cut here ]------------
|
|
[ 215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes]
|
|
[ 215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360
|
|
...
|
|
[ 215.581176] Call Trace:
|
|
[ 215.583632] <TASK>
|
|
[ 215.585745] ? show_trace_log_lvl+0x1c4/0x2df
|
|
[ 215.590114] ? show_trace_log_lvl+0x1c4/0x2df
|
|
[ 215.594497] ? debug_dma_free_coherent+0x196/0x210
|
|
[ 215.599305] ? check_unmap+0xa6f/0x2360
|
|
[ 215.603147] ? __warn+0xca/0x1d0
|
|
[ 215.606391] ? check_unmap+0xa6f/0x2360
|
|
[ 215.610237] ? report_bug+0x1ef/0x370
|
|
[ 215.613921] ? handle_bug+0x3c/0x70
|
|
[ 215.617423] ? exc_invalid_op+0x14/0x50
|
|
[ 215.621269] ? asm_exc_invalid_op+0x16/0x20
|
|
[ 215.625480] ? check_unmap+0xa6f/0x2360
|
|
[ 215.629331] ? mark_lock.part.0+0xca/0xa40
|
|
[ 215.633445] debug_dma_free_coherent+0x196/0x210
|
|
[ 215.638079] ? __pfx_debug_dma_free_coherent+0x10/0x10
|
|
[ 215.643242] ? slab_free_freelist_hook+0x11d/0x1d0
|
|
[ 215.648060] dma_free_attrs+0x6d/0x130
|
|
[ 215.651834] aq_ring_free+0x193/0x290 [atlantic]
|
|
[ 215.656487] aq_ptp_ring_free+0x67/0x110 [atlantic]
|
|
...
|
|
[ 216.127540] ---[ end trace 6467e5964dd2640b ]---
|
|
[ 216.132160] DMA-API: Mapped at:
|
|
[ 216.132162] debug_dma_alloc_coherent+0x66/0x2f0
|
|
[ 216.132165] dma_alloc_attrs+0xf5/0x1b0
|
|
[ 216.132168] aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic]
|
|
[ 216.132193] aq_ptp_ring_alloc+0x1bb/0x540 [atlantic]
|
|
[ 216.132213] aq_nic_init+0x4a1/0x760 [atlantic]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26680</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP2</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-1621</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:
|
|
|
|
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-SP2</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-1621</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:
|
|
|
|
ceph: prevent use-after-free in encode_cap_msg()
|
|
|
|
In fs/ceph/caps.c, in encode_cap_msg(), "use after free" error was
|
|
caught by KASAN at this line - 'ceph_buffer_get(arg->xattr_buf);'. This
|
|
implies before the refcount could be increment here, it was freed.
|
|
|
|
In same file, in "handle_cap_grant()" refcount is decremented by this
|
|
line - 'ceph_buffer_put(ci->i_xattrs.blob);'. It appears that a race
|
|
occurred and resource was freed by the latter line before the former
|
|
line could increment it.
|
|
|
|
encode_cap_msg() is called by __send_cap() and __send_cap() is called by
|
|
ceph_check_caps() after calling __prep_cap(). __prep_cap() is where
|
|
arg->xattr_buf is assigned to ci->i_xattrs.blob. This is the spot where
|
|
the refcount must be increased to prevent "use after free" error.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26689</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP2</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-1621</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:
|
|
|
|
btrfs: dev-replace: properly validate device names
|
|
|
|
There's a syzbot report that device name buffers passed to device
|
|
replace are not properly checked for string termination which could lead
|
|
to a read out of bounds in getname_kernel().
|
|
|
|
Add a helper that validates both source and target device name buffers.
|
|
For devid as the source initialize the buffer to empty string in case
|
|
something tries to read it later.
|
|
|
|
This was originally analyzed and fixed in a different way by Edward Adam
|
|
Davis (see links).</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26791</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP2</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-1621</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:
|
|
|
|
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-SP2</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-1621</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:
|
|
|
|
ksmbd: validate payload size in ipc response
|
|
|
|
If installing malicious ksmbd-tools, ksmbd.mountd can return invalid ipc
|
|
response to ksmbd kernel server. ksmbd should validate payload size of
|
|
ipc response from ksmbd.mountd to avoid memory overrun or
|
|
slab-out-of-bounds. This patch validate 3 ipc response that has payload.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26811</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP2</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector></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-1621</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:
|
|
|
|
vfio/pci: Create persistent INTx handler
|
|
|
|
A vulnerability exists where the eventfd for INTx signaling can be
|
|
deconfigured, which unregisters the IRQ handler but still allows
|
|
eventfds to be signaled with a NULL context through the SET_IRQS ioctl
|
|
or through unmask irqfd if the device interrupt is pending.
|
|
|
|
Ideally this could be solved with some additional locking; the igate
|
|
mutex serializes the ioctl and config space accesses, and the interrupt
|
|
handler is unregistered relative to the trigger, but the irqfd path
|
|
runs asynchronous to those. The igate mutex cannot be acquired from the
|
|
atomic context of the eventfd wake function. Disabling the irqfd
|
|
relative to the eventfd registration is potentially incompatible with
|
|
existing userspace.
|
|
|
|
As a result, the solution implemented here moves configuration of the
|
|
INTx interrupt handler to track the lifetime of the INTx context object
|
|
and irq_type configuration, rather than registration of a particular
|
|
trigger eventfd. Synchronization is added between the ioctl path and
|
|
eventfd_signal() wrapper such that the eventfd trigger can be
|
|
dynamically updated relative to in-flight interrupts or irqfd callbacks.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26812</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP2</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-17</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1621</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:
|
|
|
|
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-SP2</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-1621</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:
|
|
|
|
cifs: fix underflow in parse_server_interfaces()
|
|
|
|
In this loop, we step through the buffer and after each item we check
|
|
if the size_left is greater than the minimum size we need. However,
|
|
the problem is that "bytes_left" is type ssize_t while sizeof() is type
|
|
size_t. That means that because of type promotion, the comparison is
|
|
done as an unsigned and if we have negative bytes left the loop
|
|
continues instead of ending.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26828</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP2</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.3</BaseScore>
|
|
<Vector>AV:N/AC:L/PR:L/UI:R/S:U/C:N/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-1621</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:
|
|
|
|
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-SP2</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-1621</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:
|
|
|
|
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-SP2</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-1621</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:
|
|
|
|
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-SP2</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-1621</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:
|
|
|
|
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-SP2</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-1621</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="24" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="24" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
NFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102
|
|
|
|
A call to listxattr() with a buffer size = 0 returns the actual
|
|
size of the buffer needed for a subsequent call. When size > 0,
|
|
nfs4_listxattr() does not return an error because either
|
|
generic_listxattr() or nfs4_listxattr_nfs4_label() consumes
|
|
exactly all the bytes then size is 0 when calling
|
|
nfs4_listxattr_nfs4_user() which then triggers the following
|
|
kernel BUG:
|
|
|
|
[ 99.403778] kernel BUG at mm/usercopy.c:102!
|
|
[ 99.404063] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
|
|
[ 99.408463] CPU: 0 PID: 3310 Comm: python3 Not tainted 6.6.0-61.fc40.aarch64 #1
|
|
[ 99.415827] Call trace:
|
|
[ 99.415985] usercopy_abort+0x70/0xa0
|
|
[ 99.416227] __check_heap_object+0x134/0x158
|
|
[ 99.416505] check_heap_object+0x150/0x188
|
|
[ 99.416696] __check_object_size.part.0+0x78/0x168
|
|
[ 99.416886] __check_object_size+0x28/0x40
|
|
[ 99.417078] listxattr+0x8c/0x120
|
|
[ 99.417252] path_listxattr+0x78/0xe0
|
|
[ 99.417476] __arm64_sys_listxattr+0x28/0x40
|
|
[ 99.417723] invoke_syscall+0x78/0x100
|
|
[ 99.417929] el0_svc_common.constprop.0+0x48/0xf0
|
|
[ 99.418186] do_el0_svc+0x24/0x38
|
|
[ 99.418376] el0_svc+0x3c/0x110
|
|
[ 99.418554] el0t_64_sync_handler+0x120/0x130
|
|
[ 99.418788] el0t_64_sync+0x194/0x198
|
|
[ 99.418994] Code: aa0003e3 d000a3e0 91310000 97f49bdb (d4210000)
|
|
|
|
Issue is reproduced when generic_listxattr() returns 'system.nfs4_acl',
|
|
thus calling lisxattr() with size = 16 will trigger the bug.
|
|
|
|
Add check on nfs4_listxattr() to return ERANGE error when it is
|
|
called with size > 0 and the return value is greater than size.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-17</ReleaseDate>
|
|
<CVE>CVE-2024-26870</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP2</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-1621</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="25" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="25" 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-SP2</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-1621</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="26" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="26" 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-SP2</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-1621</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="27" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="27" 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-SP2</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-1621</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="28" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="28" 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-SP2</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-1621</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |