1600 lines
71 KiB
XML
1600 lines
71 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-SP3</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-1566</ID>
|
|
</Identification>
|
|
<Status>Final</Status>
|
|
<Version>1.0</Version>
|
|
<RevisionHistory>
|
|
<Revision>
|
|
<Number>1.0</Number>
|
|
<Date>2024-05-11</Date>
|
|
<Description>Initial</Description>
|
|
</Revision>
|
|
</RevisionHistory>
|
|
<InitialReleaseDate>2024-05-11</InitialReleaseDate>
|
|
<CurrentReleaseDate>2024-05-11</CurrentReleaseDate>
|
|
<Generator>
|
|
<Engine>openEuler SA Tool V1.0</Engine>
|
|
<Date>2024-05-11</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-SP3.</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:
|
|
|
|
scsi: core: Fix scsi_mode_sense() buffer length handling
|
|
|
|
Several problems exist with scsi_mode_sense() buffer length handling:
|
|
|
|
1) The allocation length field of the MODE SENSE(10) command is 16-bits,
|
|
occupying bytes 7 and 8 of the CDB. With this command, access to mode
|
|
pages larger than 255 bytes is thus possible. However, the CDB
|
|
allocation length field is set by assigning len to byte 8 only, thus
|
|
truncating buffer length larger than 255.
|
|
|
|
2) If scsi_mode_sense() is called with len smaller than 8 with
|
|
sdev->use_10_for_ms set, or smaller than 4 otherwise, the buffer length
|
|
is increased to 8 and 4 respectively, and the buffer is zero filled
|
|
with these increased values, thus corrupting the memory following the
|
|
buffer.
|
|
|
|
Fix these 2 problems by using put_unaligned_be16() to set the allocation
|
|
length field of MODE SENSE(10) CDB and by returning an error when len is
|
|
too small.
|
|
|
|
Furthermore, if len is larger than 255B, always try MODE SENSE(10) first,
|
|
even if the device driver did not set sdev->use_10_for_ms. In case of
|
|
invalid opcode error for MODE SENSE(10), access to mode pages larger than
|
|
255 bytes are not retried using MODE SENSE(6). To avoid buffer length
|
|
overflows for the MODE_SENSE(10) case, check that len is smaller than 65535
|
|
bytes.
|
|
|
|
While at it, also fix the folowing:
|
|
|
|
* Use get_unaligned_be16() to retrieve the mode data length and block
|
|
descriptor length fields of the mode sense reply header instead of using
|
|
an open coded calculation.
|
|
|
|
* Fix the kdoc dbd argument explanation: the DBD bit stands for Disable
|
|
Block Descriptor, which is the opposite of what the dbd argument
|
|
description was.(CVE-2021-47182)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/mlx5e: CT, Fix multiple allocations and memleak of mod acts
|
|
|
|
CT clear action offload adds additional mod hdr actions to the
|
|
flow's original mod actions in order to clear the registers which
|
|
hold ct_state.
|
|
When such flow also includes encap action, a neigh update event
|
|
can cause the driver to unoffload the flow and then reoffload it.
|
|
|
|
Each time this happens, the ct clear handling adds that same set
|
|
of mod hdr actions to reset ct_state until the max of mod hdr
|
|
actions is reached.
|
|
|
|
Also the driver never releases the allocated mod hdr actions and
|
|
causing a memleak.
|
|
|
|
Fix above two issues by moving CT clear mod acts allocation
|
|
into the parsing actions phase and only use it when offloading the rule.
|
|
The release of mod acts will be done in the normal flow_put().
|
|
|
|
backtrace:
|
|
[<000000007316e2f3>] krealloc+0x83/0xd0
|
|
[<00000000ef157de1>] mlx5e_mod_hdr_alloc+0x147/0x300 [mlx5_core]
|
|
[<00000000970ce4ae>] mlx5e_tc_match_to_reg_set_and_get_id+0xd7/0x240 [mlx5_core]
|
|
[<0000000067c5fa17>] mlx5e_tc_match_to_reg_set+0xa/0x20 [mlx5_core]
|
|
[<00000000d032eb98>] mlx5_tc_ct_entry_set_registers.isra.0+0x36/0xc0 [mlx5_core]
|
|
[<00000000fd23b869>] mlx5_tc_ct_flow_offload+0x272/0x1f10 [mlx5_core]
|
|
[<000000004fc24acc>] mlx5e_tc_offload_fdb_rules.part.0+0x150/0x620 [mlx5_core]
|
|
[<00000000dc741c17>] mlx5e_tc_encap_flows_add+0x489/0x690 [mlx5_core]
|
|
[<00000000e92e49d7>] mlx5e_rep_update_flows+0x6e4/0x9b0 [mlx5_core]
|
|
[<00000000f60f5602>] mlx5e_rep_neigh_update+0x39a/0x5d0 [mlx5_core](CVE-2021-47199)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ALSA: usb-audio: fix null pointer dereference on pointer cs_desc
|
|
|
|
The pointer cs_desc return from snd_usb_find_clock_source could
|
|
be null, so there is a potential null pointer dereference issue.
|
|
Fix this by adding a null check before dereference.(CVE-2021-47211)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
binder: fix race between mmput() and do_exit()
|
|
|
|
Task A calls binder_update_page_range() to allocate and insert pages on
|
|
a remote address space from Task B. For this, Task A pins the remote mm
|
|
via mmget_not_zero() first. This can race with Task B do_exit() and the
|
|
final mmput() refcount decrement will come from Task A.
|
|
|
|
Task A | Task B
|
|
------------------+------------------
|
|
mmget_not_zero() |
|
|
| do_exit()
|
|
| exit_mm()
|
|
| mmput()
|
|
mmput() |
|
|
exit_mmap() |
|
|
remove_vma() |
|
|
fput() |
|
|
|
|
In this case, the work of ____fput() from Task B is queued up in Task A
|
|
as TWA_RESUME. So in theory, Task A returns to userspace and the cleanup
|
|
work gets executed. However, Task A instead sleep, waiting for a reply
|
|
from Task B that never comes (it's dead).
|
|
|
|
This means the binder_deferred_release() is blocked until an unrelated
|
|
binder event forces Task A to go back to userspace. All the associated
|
|
death notifications will also be delayed until then.
|
|
|
|
In order to fix this use mmput_async() that will schedule the work in
|
|
the corresponding mm->async_put_work WQ instead of Task A.(CVE-2023-52609)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/sched: act_ct: fix skb leak and crash on ooo frags
|
|
|
|
act_ct adds skb->users before defragmentation. If frags arrive in order,
|
|
the last frag's reference is reset in:
|
|
|
|
inet_frag_reasm_prepare
|
|
skb_morph
|
|
|
|
which is not straightforward.
|
|
|
|
However when frags arrive out of order, nobody unref the last frag, and
|
|
all frags are leaked. The situation is even worse, as initiating packet
|
|
capture can lead to a crash[0] when skb has been cloned and shared at the
|
|
same time.
|
|
|
|
Fix the issue by removing skb_get() before defragmentation. act_ct
|
|
returns TC_ACT_CONSUMED when defrag failed or in progress.
|
|
|
|
[0]:
|
|
[ 843.804823] ------------[ cut here ]------------
|
|
[ 843.809659] kernel BUG at net/core/skbuff.c:2091!
|
|
[ 843.814516] invalid opcode: 0000 [#1] PREEMPT SMP
|
|
[ 843.819296] CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G S 6.7.0-rc3 #2
|
|
[ 843.824107] Hardware name: XFUSION 1288H V6/BC13MBSBD, BIOS 1.29 11/25/2022
|
|
[ 843.828953] RIP: 0010:pskb_expand_head+0x2ac/0x300
|
|
[ 843.833805] Code: 8b 70 28 48 85 f6 74 82 48 83 c6 08 bf 01 00 00 00 e8 38 bd ff ff 8b 83 c0 00 00 00 48 03 83 c8 00 00 00 e9 62 ff ff ff 0f 0b <0f> 0b e8 8d d0 ff ff e9 b3 fd ff ff 81 7c 24 14 40 01 00 00 4c 89
|
|
[ 843.843698] RSP: 0018:ffffc9000cce07c0 EFLAGS: 00010202
|
|
[ 843.848524] RAX: 0000000000000002 RBX: ffff88811a211d00 RCX: 0000000000000820
|
|
[ 843.853299] RDX: 0000000000000640 RSI: 0000000000000000 RDI: ffff88811a211d00
|
|
[ 843.857974] RBP: ffff888127d39518 R08: 00000000bee97314 R09: 0000000000000000
|
|
[ 843.862584] R10: 0000000000000000 R11: ffff8881109f0000 R12: 0000000000000880
|
|
[ 843.867147] R13: ffff888127d39580 R14: 0000000000000640 R15: ffff888170f7b900
|
|
[ 843.871680] FS: 0000000000000000(0000) GS:ffff889ffffc0000(0000) knlGS:0000000000000000
|
|
[ 843.876242] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 843.880778] CR2: 00007fa42affcfb8 CR3: 000000011433a002 CR4: 0000000000770ef0
|
|
[ 843.885336] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
[ 843.889809] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
[ 843.894229] PKRU: 55555554
|
|
[ 843.898539] Call Trace:
|
|
[ 843.902772] <IRQ>
|
|
[ 843.906922] ? __die_body+0x1e/0x60
|
|
[ 843.911032] ? die+0x3c/0x60
|
|
[ 843.915037] ? do_trap+0xe2/0x110
|
|
[ 843.918911] ? pskb_expand_head+0x2ac/0x300
|
|
[ 843.922687] ? do_error_trap+0x65/0x80
|
|
[ 843.926342] ? pskb_expand_head+0x2ac/0x300
|
|
[ 843.929905] ? exc_invalid_op+0x50/0x60
|
|
[ 843.933398] ? pskb_expand_head+0x2ac/0x300
|
|
[ 843.936835] ? asm_exc_invalid_op+0x1a/0x20
|
|
[ 843.940226] ? pskb_expand_head+0x2ac/0x300
|
|
[ 843.943580] inet_frag_reasm_prepare+0xd1/0x240
|
|
[ 843.946904] ip_defrag+0x5d4/0x870
|
|
[ 843.950132] nf_ct_handle_fragments+0xec/0x130 [nf_conntrack]
|
|
[ 843.953334] tcf_ct_act+0x252/0xd90 [act_ct]
|
|
[ 843.956473] ? tcf_mirred_act+0x516/0x5a0 [act_mirred]
|
|
[ 843.959657] tcf_action_exec+0xa1/0x160
|
|
[ 843.962823] fl_classify+0x1db/0x1f0 [cls_flower]
|
|
[ 843.966010] ? skb_clone+0x53/0xc0
|
|
[ 843.969173] tcf_classify+0x24d/0x420
|
|
[ 843.972333] tc_run+0x8f/0xf0
|
|
[ 843.975465] __netif_receive_skb_core+0x67a/0x1080
|
|
[ 843.978634] ? dev_gro_receive+0x249/0x730
|
|
[ 843.981759] __netif_receive_skb_list_core+0x12d/0x260
|
|
[ 843.984869] netif_receive_skb_list_internal+0x1cb/0x2f0
|
|
[ 843.987957] ? mlx5e_handle_rx_cqe_mpwrq_rep+0xfa/0x1a0 [mlx5_core]
|
|
[ 843.991170] napi_complete_done+0x72/0x1a0
|
|
[ 843.994305] mlx5e_napi_poll+0x28c/0x6d0 [mlx5_core]
|
|
[ 843.997501] __napi_poll+0x25/0x1b0
|
|
[ 844.000627] net_rx_action+0x256/0x330
|
|
[ 844.003705] __do_softirq+0xb3/0x29b
|
|
[ 844.006718] irq_exit_rcu+0x9e/0xc0
|
|
[ 844.009672] common_interrupt+0x86/0xa0
|
|
[ 844.012537] </IRQ>
|
|
[ 844.015285] <TASK>
|
|
[ 844.017937] asm_common_interrupt+0x26/0x40
|
|
[ 844.020591] RIP: 0010:acpi_safe_halt+0x1b/0x20
|
|
[ 844.023247] Code: ff 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 65 48 8b 04 25 00 18 03 00 48 8b 00 a8 08 75 0c 66 90 0f 00 2d 81 d0 44 00 fb
|
|
---truncated---(CVE-2023-52610)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
crypto: lib/mpi - Fix unexpected pointer access in mpi_ec_init
|
|
|
|
When the mpi_ec_ctx structure is initialized, some fields are not
|
|
cleared, causing a crash when referencing the field when the
|
|
structure was released. Initially, this issue was ignored because
|
|
memory for mpi_ec_ctx is allocated with the __GFP_ZERO flag.
|
|
For example, this error will be triggered when calculating the
|
|
Za value for SM2 separately.(CVE-2023-52616)
|
|
|
|
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:
|
|
|
|
llc: Drop support for ETH_P_TR_802_2.
|
|
|
|
syzbot reported an uninit-value bug below. [0]
|
|
|
|
llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2
|
|
(0x0011), and syzbot abused the latter to trigger the bug.
|
|
|
|
write$tun(r0, &(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', "90e5dd"}}}}, 0x16)
|
|
|
|
llc_conn_handler() initialises local variables {saddr,daddr}.mac
|
|
based on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes
|
|
them to __llc_lookup().
|
|
|
|
However, the initialisation is done only when skb->protocol is
|
|
htons(ETH_P_802_2), otherwise, __llc_lookup_established() and
|
|
__llc_lookup_listener() will read garbage.
|
|
|
|
The missing initialisation existed prior to commit 211ed865108e
|
|
("net: delete all instances of special processing for token ring").
|
|
|
|
It removed the part to kick out the token ring stuff but forgot to
|
|
close the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().
|
|
|
|
Let's remove llc_tr_packet_type and complete the deprecation.
|
|
|
|
[0]:
|
|
BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90
|
|
__llc_lookup_established+0xe9d/0xf90
|
|
__llc_lookup net/llc/llc_conn.c:611 [inline]
|
|
llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791
|
|
llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206
|
|
__netif_receive_skb_one_core net/core/dev.c:5527 [inline]
|
|
__netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641
|
|
netif_receive_skb_internal net/core/dev.c:5727 [inline]
|
|
netif_receive_skb+0x58/0x660 net/core/dev.c:5786
|
|
tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
|
|
tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002
|
|
tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
|
|
call_write_iter include/linux/fs.h:2020 [inline]
|
|
new_sync_write fs/read_write.c:491 [inline]
|
|
vfs_write+0x8ef/0x1490 fs/read_write.c:584
|
|
ksys_write+0x20f/0x4c0 fs/read_write.c:637
|
|
__do_sys_write fs/read_write.c:649 [inline]
|
|
__se_sys_write fs/read_write.c:646 [inline]
|
|
__x64_sys_write+0x93/0xd0 fs/read_write.c:646
|
|
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
|
|
do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b
|
|
|
|
Local variable daddr created at:
|
|
llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783
|
|
llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206
|
|
|
|
CPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023(CVE-2024-26635)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
llc: make llc_ui_sendmsg() more robust against bonding changes
|
|
|
|
syzbot was able to trick llc_ui_sendmsg(), allocating an skb with no
|
|
headroom, but subsequently trying to push 14 bytes of Ethernet header [1]
|
|
|
|
Like some others, llc_ui_sendmsg() releases the socket lock before
|
|
calling sock_alloc_send_skb().
|
|
Then it acquires it again, but does not redo all the sanity checks
|
|
that were performed.
|
|
|
|
This fix:
|
|
|
|
- Uses LL_RESERVED_SPACE() to reserve space.
|
|
- Check all conditions again after socket lock is held again.
|
|
- Do not account Ethernet header for mtu limitation.
|
|
|
|
[1]
|
|
|
|
skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0
|
|
|
|
kernel BUG at net/core/skbuff.c:193 !
|
|
Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
|
|
Modules linked in:
|
|
CPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
|
|
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
|
pc : skb_panic net/core/skbuff.c:189 [inline]
|
|
pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203
|
|
lr : skb_panic net/core/skbuff.c:189 [inline]
|
|
lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203
|
|
sp : ffff800096f97000
|
|
x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000
|
|
x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2
|
|
x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0
|
|
x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce
|
|
x17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001
|
|
x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000
|
|
x11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400
|
|
x8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000
|
|
x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714
|
|
x2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089
|
|
Call trace:
|
|
skb_panic net/core/skbuff.c:189 [inline]
|
|
skb_under_panic+0x13c/0x140 net/core/skbuff.c:203
|
|
skb_push+0xf0/0x108 net/core/skbuff.c:2451
|
|
eth_header+0x44/0x1f8 net/ethernet/eth.c:83
|
|
dev_hard_header include/linux/netdevice.h:3188 [inline]
|
|
llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33
|
|
llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85
|
|
llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline]
|
|
llc_sap_next_state net/llc/llc_sap.c:182 [inline]
|
|
llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209
|
|
llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270
|
|
llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg net/socket.c:745 [inline]
|
|
sock_sendmsg+0x194/0x274 net/socket.c:767
|
|
splice_to_socket+0x7cc/0xd58 fs/splice.c:881
|
|
do_splice_from fs/splice.c:933 [inline]
|
|
direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142
|
|
splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088
|
|
do_splice_direct+0x20c/0x348 fs/splice.c:1194
|
|
do_sendfile+0x4bc/0xc70 fs/read_write.c:1254
|
|
__do_sys_sendfile64 fs/read_write.c:1322 [inline]
|
|
__se_sys_sendfile64 fs/read_write.c:1308 [inline]
|
|
__arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308
|
|
__invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]
|
|
invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51
|
|
el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136
|
|
do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155
|
|
el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678
|
|
el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696
|
|
el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595
|
|
Code: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000)(CVE-2024-26636)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tcp: add sanity checks to rx zerocopy
|
|
|
|
TCP rx zerocopy intent is to map pages initially allocated
|
|
from NIC drivers, not pages owned by a fs.
|
|
|
|
This patch adds to can_map_frag() these additional checks:
|
|
|
|
- Page must not be a compound one.
|
|
- page->mapping must be NULL.
|
|
|
|
This fixes the panic reported by ZhangPeng.
|
|
|
|
syzbot was able to loopback packets built with sendfile(),
|
|
mapping pages owned by an ext4 file to TCP rx zerocopy.
|
|
|
|
r3 = socket$inet_tcp(0x2, 0x1, 0x0)
|
|
mmap(&(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0)
|
|
r4 = socket$inet_tcp(0x2, 0x1, 0x0)
|
|
bind$inet(r4, &(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10)
|
|
connect$inet(r4, &(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10)
|
|
r5 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00',
|
|
0x181e42, 0x0)
|
|
fallocate(r5, 0x0, 0x0, 0x85b8)
|
|
sendfile(r4, r5, 0x0, 0x8ba0)
|
|
getsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23,
|
|
&(0x7f00000001c0)={&(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0,
|
|
0x0, 0x0, 0x0, 0x0}, &(0x7f0000000440)=0x40)
|
|
r6 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00',
|
|
0x181e42, 0x0)(CVE-2024-26640)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()
|
|
|
|
syzbot found __ip6_tnl_rcv() could access unitiliazed data [1].
|
|
|
|
Call pskb_inet_may_pull() to fix this, and initialize ipv6h
|
|
variable after this call as it can change skb->head.
|
|
|
|
[1]
|
|
BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
|
|
BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
|
|
BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321
|
|
__INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
|
|
INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
|
|
IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321
|
|
ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727
|
|
__ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845
|
|
ip6_tnl_rcv+0xce/0x100 net/ipv6/ip6_tunnel.c:888
|
|
gre_rcv+0x143f/0x1870
|
|
ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438
|
|
ip6_input_finish net/ipv6/ip6_input.c:483 [inline]
|
|
NF_HOOK include/linux/netfilter.h:314 [inline]
|
|
ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492
|
|
ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586
|
|
dst_input include/net/dst.h:461 [inline]
|
|
ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79
|
|
NF_HOOK include/linux/netfilter.h:314 [inline]
|
|
ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310
|
|
__netif_receive_skb_one_core net/core/dev.c:5532 [inline]
|
|
__netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646
|
|
netif_receive_skb_internal net/core/dev.c:5732 [inline]
|
|
netif_receive_skb+0x58/0x660 net/core/dev.c:5791
|
|
tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
|
|
tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002
|
|
tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
|
|
call_write_iter include/linux/fs.h:2084 [inline]
|
|
new_sync_write fs/read_write.c:497 [inline]
|
|
vfs_write+0x786/0x1200 fs/read_write.c:590
|
|
ksys_write+0x20f/0x4c0 fs/read_write.c:643
|
|
__do_sys_write fs/read_write.c:655 [inline]
|
|
__se_sys_write fs/read_write.c:652 [inline]
|
|
__x64_sys_write+0x93/0xd0 fs/read_write.c:652
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b
|
|
|
|
Uninit was created at:
|
|
slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
|
|
slab_alloc_node mm/slub.c:3478 [inline]
|
|
kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523
|
|
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560
|
|
__alloc_skb+0x318/0x740 net/core/skbuff.c:651
|
|
alloc_skb include/linux/skbuff.h:1286 [inline]
|
|
alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334
|
|
sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787
|
|
tun_alloc_skb drivers/net/tun.c:1531 [inline]
|
|
tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846
|
|
tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
|
|
call_write_iter include/linux/fs.h:2084 [inline]
|
|
new_sync_write fs/read_write.c:497 [inline]
|
|
vfs_write+0x786/0x1200 fs/read_write.c:590
|
|
ksys_write+0x20f/0x4c0 fs/read_write.c:643
|
|
__do_sys_write fs/read_write.c:655 [inline]
|
|
__se_sys_write fs/read_write.c:652 [inline]
|
|
__x64_sys_write+0x93/0xd0 fs/read_write.c:652
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b
|
|
|
|
CPU: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023(CVE-2024-26641)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
l2tp: pass correct message length to ip6_append_data
|
|
|
|
l2tp_ip6_sendmsg needs to avoid accounting for the transport header
|
|
twice when splicing more data into an already partially-occupied skbuff.
|
|
|
|
To manage this, we check whether the skbuff contains data using
|
|
skb_queue_empty when deciding how much data to append using
|
|
ip6_append_data.
|
|
|
|
However, the code which performed the calculation was incorrect:
|
|
|
|
ulen = len + skb_queue_empty(&sk->sk_write_queue) ? transhdrlen : 0;
|
|
|
|
...due to C operator precedence, this ends up setting ulen to
|
|
transhdrlen for messages with a non-zero length, which results in
|
|
corrupted packets on the wire.
|
|
|
|
Add parentheses to correct the calculation in line with the original
|
|
intent.(CVE-2024-26752)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
IB/hfi1: Fix sdma.h tx->num_descs off-by-one error
|
|
|
|
Unfortunately the commit `fd8958efe877` introduced another error
|
|
causing the `descs` array to overflow. This reults in further crashes
|
|
easily reproducible by `sendmsg` system call.
|
|
|
|
[ 1080.836473] general protection fault, probably for non-canonical address 0x400300015528b00a: 0000 [#1] PREEMPT SMP PTI
|
|
[ 1080.869326] RIP: 0010:hfi1_ipoib_build_ib_tx_headers.constprop.0+0xe1/0x2b0 [hfi1]
|
|
--
|
|
[ 1080.974535] Call Trace:
|
|
[ 1080.976990] <TASK>
|
|
[ 1081.021929] hfi1_ipoib_send_dma_common+0x7a/0x2e0 [hfi1]
|
|
[ 1081.027364] hfi1_ipoib_send_dma_list+0x62/0x270 [hfi1]
|
|
[ 1081.032633] hfi1_ipoib_send+0x112/0x300 [hfi1]
|
|
[ 1081.042001] ipoib_start_xmit+0x2a9/0x2d0 [ib_ipoib]
|
|
[ 1081.046978] dev_hard_start_xmit+0xc4/0x210
|
|
--
|
|
[ 1081.148347] __sys_sendmsg+0x59/0xa0
|
|
|
|
crash> ipoib_txreq 0xffff9cfeba229f00
|
|
struct ipoib_txreq {
|
|
txreq = {
|
|
list = {
|
|
next = 0xffff9cfeba229f00,
|
|
prev = 0xffff9cfeba229f00
|
|
},
|
|
descp = 0xffff9cfeba229f40,
|
|
coalesce_buf = 0x0,
|
|
wait = 0xffff9cfea4e69a48,
|
|
complete = 0xffffffffc0fe0760 <hfi1_ipoib_sdma_complete>,
|
|
packet_len = 0x46d,
|
|
tlen = 0x0,
|
|
num_desc = 0x0,
|
|
desc_limit = 0x6,
|
|
next_descq_idx = 0x45c,
|
|
coalesce_idx = 0x0,
|
|
flags = 0x0,
|
|
descs = {{
|
|
qw = {0x8024000120dffb00, 0x4} # SDMA_DESC0_FIRST_DESC_FLAG (bit 63)
|
|
}, {
|
|
qw = { 0x3800014231b108, 0x4}
|
|
}, {
|
|
qw = { 0x310000e4ee0fcf0, 0x8}
|
|
}, {
|
|
qw = { 0x3000012e9f8000, 0x8}
|
|
}, {
|
|
qw = { 0x59000dfb9d0000, 0x8}
|
|
}, {
|
|
qw = { 0x78000e02e40000, 0x8}
|
|
}}
|
|
},
|
|
sdma_hdr = 0x400300015528b000, <<< invalid pointer in the tx request structure
|
|
sdma_status = 0x0, SDMA_DESC0_LAST_DESC_FLAG (bit 62)
|
|
complete = 0x0,
|
|
priv = 0x0,
|
|
txq = 0xffff9cfea4e69880,
|
|
skb = 0xffff9d099809f400
|
|
}
|
|
|
|
If an SDMA send consists of exactly 6 descriptors and requires dword
|
|
padding (in the 7th descriptor), the sdma_txreq descriptor array is not
|
|
properly expanded and the packet will overflow into the container
|
|
structure. This results in a panic when the send completion runs. The
|
|
exact panic varies depending on what elements of the container structure
|
|
get corrupted. The fix is to use the correct expression in
|
|
_pad_sdma_tx_descs() to test the need to expand the descriptor array.
|
|
|
|
With this patch the crashes are no longer reproducible and the machine is
|
|
stable.(CVE-2024-26766)</Note>
|
|
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP3.
|
|
|
|
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-1566</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47182</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47199</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47211</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52609</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52610</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52616</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-2024-26635</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26636</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26640</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26641</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26752</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26766</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47182</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47199</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47211</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52609</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52610</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52616</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52618</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26635</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26636</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26640</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26641</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26752</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26766</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-SP3" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">openEuler-22.03-LTS-SP3</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="kernel-source-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-source-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debugsource-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-devel-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-debuginfo-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debuginfo-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-devel-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-headers-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-debuginfo-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-debuginfo-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-5.10.0-198.0.0.111.oe2203sp3.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-198.0.0.111.oe2203sp3.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debugsource-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-devel-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-debuginfo-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-headers-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-debuginfo-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-debuginfo-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-source-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-devel-5.10.0-198.0.0.111.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-198.0.0.111" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debuginfo-5.10.0-198.0.0.111.oe2203sp3.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:
|
|
|
|
scsi: core: Fix scsi_mode_sense() buffer length handling
|
|
|
|
Several problems exist with scsi_mode_sense() buffer length handling:
|
|
|
|
1) The allocation length field of the MODE SENSE(10) command is 16-bits,
|
|
occupying bytes 7 and 8 of the CDB. With this command, access to mode
|
|
pages larger than 255 bytes is thus possible. However, the CDB
|
|
allocation length field is set by assigning len to byte 8 only, thus
|
|
truncating buffer length larger than 255.
|
|
|
|
2) If scsi_mode_sense() is called with len smaller than 8 with
|
|
sdev->use_10_for_ms set, or smaller than 4 otherwise, the buffer length
|
|
is increased to 8 and 4 respectively, and the buffer is zero filled
|
|
with these increased values, thus corrupting the memory following the
|
|
buffer.
|
|
|
|
Fix these 2 problems by using put_unaligned_be16() to set the allocation
|
|
length field of MODE SENSE(10) CDB and by returning an error when len is
|
|
too small.
|
|
|
|
Furthermore, if len is larger than 255B, always try MODE SENSE(10) first,
|
|
even if the device driver did not set sdev->use_10_for_ms. In case of
|
|
invalid opcode error for MODE SENSE(10), access to mode pages larger than
|
|
255 bytes are not retried using MODE SENSE(6). To avoid buffer length
|
|
overflows for the MODE_SENSE(10) case, check that len is smaller than 65535
|
|
bytes.
|
|
|
|
While at it, also fix the folowing:
|
|
|
|
* Use get_unaligned_be16() to retrieve the mode data length and block
|
|
descriptor length fields of the mode sense reply header instead of using
|
|
an open coded calculation.
|
|
|
|
* Fix the kdoc dbd argument explanation: the DBD bit stands for Disable
|
|
Block Descriptor, which is the opposite of what the dbd argument
|
|
description was.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-11</ReleaseDate>
|
|
<CVE>CVE-2021-47182</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-11</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1566</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:
|
|
|
|
net/mlx5e: CT, Fix multiple allocations and memleak of mod acts
|
|
|
|
CT clear action offload adds additional mod hdr actions to the
|
|
flow's original mod actions in order to clear the registers which
|
|
hold ct_state.
|
|
When such flow also includes encap action, a neigh update event
|
|
can cause the driver to unoffload the flow and then reoffload it.
|
|
|
|
Each time this happens, the ct clear handling adds that same set
|
|
of mod hdr actions to reset ct_state until the max of mod hdr
|
|
actions is reached.
|
|
|
|
Also the driver never releases the allocated mod hdr actions and
|
|
causing a memleak.
|
|
|
|
Fix above two issues by moving CT clear mod acts allocation
|
|
into the parsing actions phase and only use it when offloading the rule.
|
|
The release of mod acts will be done in the normal flow_put().
|
|
|
|
backtrace:
|
|
[<000000007316e2f3>] krealloc+0x83/0xd0
|
|
[<00000000ef157de1>] mlx5e_mod_hdr_alloc+0x147/0x300 [mlx5_core]
|
|
[<00000000970ce4ae>] mlx5e_tc_match_to_reg_set_and_get_id+0xd7/0x240 [mlx5_core]
|
|
[<0000000067c5fa17>] mlx5e_tc_match_to_reg_set+0xa/0x20 [mlx5_core]
|
|
[<00000000d032eb98>] mlx5_tc_ct_entry_set_registers.isra.0+0x36/0xc0 [mlx5_core]
|
|
[<00000000fd23b869>] mlx5_tc_ct_flow_offload+0x272/0x1f10 [mlx5_core]
|
|
[<000000004fc24acc>] mlx5e_tc_offload_fdb_rules.part.0+0x150/0x620 [mlx5_core]
|
|
[<00000000dc741c17>] mlx5e_tc_encap_flows_add+0x489/0x690 [mlx5_core]
|
|
[<00000000e92e49d7>] mlx5e_rep_update_flows+0x6e4/0x9b0 [mlx5_core]
|
|
[<00000000f60f5602>] mlx5e_rep_neigh_update+0x39a/0x5d0 [mlx5_core]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-11</ReleaseDate>
|
|
<CVE>CVE-2021-47199</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-11</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1566</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:
|
|
|
|
ALSA: usb-audio: fix null pointer dereference on pointer cs_desc
|
|
|
|
The pointer cs_desc return from snd_usb_find_clock_source could
|
|
be null, so there is a potential null pointer dereference issue.
|
|
Fix this by adding a null check before dereference.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-11</ReleaseDate>
|
|
<CVE>CVE-2021-47211</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-11</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1566</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:
|
|
|
|
binder: fix race between mmput() and do_exit()
|
|
|
|
Task A calls binder_update_page_range() to allocate and insert pages on
|
|
a remote address space from Task B. For this, Task A pins the remote mm
|
|
via mmget_not_zero() first. This can race with Task B do_exit() and the
|
|
final mmput() refcount decrement will come from Task A.
|
|
|
|
Task A | Task B
|
|
------------------+------------------
|
|
mmget_not_zero() |
|
|
| do_exit()
|
|
| exit_mm()
|
|
| mmput()
|
|
mmput() |
|
|
exit_mmap() |
|
|
remove_vma() |
|
|
fput() |
|
|
|
|
In this case, the work of ____fput() from Task B is queued up in Task A
|
|
as TWA_RESUME. So in theory, Task A returns to userspace and the cleanup
|
|
work gets executed. However, Task A instead sleep, waiting for a reply
|
|
from Task B that never comes (it's dead).
|
|
|
|
This means the binder_deferred_release() is blocked until an unrelated
|
|
binder event forces Task A to go back to userspace. All the associated
|
|
death notifications will also be delayed until then.
|
|
|
|
In order to fix this use mmput_async() that will schedule the work in
|
|
the corresponding mm->async_put_work WQ instead of Task A.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-11</ReleaseDate>
|
|
<CVE>CVE-2023-52609</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.1</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-11</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1566</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="5" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="5" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/sched: act_ct: fix skb leak and crash on ooo frags
|
|
|
|
act_ct adds skb->users before defragmentation. If frags arrive in order,
|
|
the last frag's reference is reset in:
|
|
|
|
inet_frag_reasm_prepare
|
|
skb_morph
|
|
|
|
which is not straightforward.
|
|
|
|
However when frags arrive out of order, nobody unref the last frag, and
|
|
all frags are leaked. The situation is even worse, as initiating packet
|
|
capture can lead to a crash[0] when skb has been cloned and shared at the
|
|
same time.
|
|
|
|
Fix the issue by removing skb_get() before defragmentation. act_ct
|
|
returns TC_ACT_CONSUMED when defrag failed or in progress.
|
|
|
|
[0]:
|
|
[ 843.804823] ------------[ cut here ]------------
|
|
[ 843.809659] kernel BUG at net/core/skbuff.c:2091!
|
|
[ 843.814516] invalid opcode: 0000 [#1] PREEMPT SMP
|
|
[ 843.819296] CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G S 6.7.0-rc3 #2
|
|
[ 843.824107] Hardware name: XFUSION 1288H V6/BC13MBSBD, BIOS 1.29 11/25/2022
|
|
[ 843.828953] RIP: 0010:pskb_expand_head+0x2ac/0x300
|
|
[ 843.833805] Code: 8b 70 28 48 85 f6 74 82 48 83 c6 08 bf 01 00 00 00 e8 38 bd ff ff 8b 83 c0 00 00 00 48 03 83 c8 00 00 00 e9 62 ff ff ff 0f 0b <0f> 0b e8 8d d0 ff ff e9 b3 fd ff ff 81 7c 24 14 40 01 00 00 4c 89
|
|
[ 843.843698] RSP: 0018:ffffc9000cce07c0 EFLAGS: 00010202
|
|
[ 843.848524] RAX: 0000000000000002 RBX: ffff88811a211d00 RCX: 0000000000000820
|
|
[ 843.853299] RDX: 0000000000000640 RSI: 0000000000000000 RDI: ffff88811a211d00
|
|
[ 843.857974] RBP: ffff888127d39518 R08: 00000000bee97314 R09: 0000000000000000
|
|
[ 843.862584] R10: 0000000000000000 R11: ffff8881109f0000 R12: 0000000000000880
|
|
[ 843.867147] R13: ffff888127d39580 R14: 0000000000000640 R15: ffff888170f7b900
|
|
[ 843.871680] FS: 0000000000000000(0000) GS:ffff889ffffc0000(0000) knlGS:0000000000000000
|
|
[ 843.876242] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 843.880778] CR2: 00007fa42affcfb8 CR3: 000000011433a002 CR4: 0000000000770ef0
|
|
[ 843.885336] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
[ 843.889809] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
[ 843.894229] PKRU: 55555554
|
|
[ 843.898539] Call Trace:
|
|
[ 843.902772] <IRQ>
|
|
[ 843.906922] ? __die_body+0x1e/0x60
|
|
[ 843.911032] ? die+0x3c/0x60
|
|
[ 843.915037] ? do_trap+0xe2/0x110
|
|
[ 843.918911] ? pskb_expand_head+0x2ac/0x300
|
|
[ 843.922687] ? do_error_trap+0x65/0x80
|
|
[ 843.926342] ? pskb_expand_head+0x2ac/0x300
|
|
[ 843.929905] ? exc_invalid_op+0x50/0x60
|
|
[ 843.933398] ? pskb_expand_head+0x2ac/0x300
|
|
[ 843.936835] ? asm_exc_invalid_op+0x1a/0x20
|
|
[ 843.940226] ? pskb_expand_head+0x2ac/0x300
|
|
[ 843.943580] inet_frag_reasm_prepare+0xd1/0x240
|
|
[ 843.946904] ip_defrag+0x5d4/0x870
|
|
[ 843.950132] nf_ct_handle_fragments+0xec/0x130 [nf_conntrack]
|
|
[ 843.953334] tcf_ct_act+0x252/0xd90 [act_ct]
|
|
[ 843.956473] ? tcf_mirred_act+0x516/0x5a0 [act_mirred]
|
|
[ 843.959657] tcf_action_exec+0xa1/0x160
|
|
[ 843.962823] fl_classify+0x1db/0x1f0 [cls_flower]
|
|
[ 843.966010] ? skb_clone+0x53/0xc0
|
|
[ 843.969173] tcf_classify+0x24d/0x420
|
|
[ 843.972333] tc_run+0x8f/0xf0
|
|
[ 843.975465] __netif_receive_skb_core+0x67a/0x1080
|
|
[ 843.978634] ? dev_gro_receive+0x249/0x730
|
|
[ 843.981759] __netif_receive_skb_list_core+0x12d/0x260
|
|
[ 843.984869] netif_receive_skb_list_internal+0x1cb/0x2f0
|
|
[ 843.987957] ? mlx5e_handle_rx_cqe_mpwrq_rep+0xfa/0x1a0 [mlx5_core]
|
|
[ 843.991170] napi_complete_done+0x72/0x1a0
|
|
[ 843.994305] mlx5e_napi_poll+0x28c/0x6d0 [mlx5_core]
|
|
[ 843.997501] __napi_poll+0x25/0x1b0
|
|
[ 844.000627] net_rx_action+0x256/0x330
|
|
[ 844.003705] __do_softirq+0xb3/0x29b
|
|
[ 844.006718] irq_exit_rcu+0x9e/0xc0
|
|
[ 844.009672] common_interrupt+0x86/0xa0
|
|
[ 844.012537] </IRQ>
|
|
[ 844.015285] <TASK>
|
|
[ 844.017937] asm_common_interrupt+0x26/0x40
|
|
[ 844.020591] RIP: 0010:acpi_safe_halt+0x1b/0x20
|
|
[ 844.023247] Code: ff 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 65 48 8b 04 25 00 18 03 00 48 8b 00 a8 08 75 0c 66 90 0f 00 2d 81 d0 44 00 fb
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-11</ReleaseDate>
|
|
<CVE>CVE-2023-52610</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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:H/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-11</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1566</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:
|
|
|
|
crypto: lib/mpi - Fix unexpected pointer access in mpi_ec_init
|
|
|
|
When the mpi_ec_ctx structure is initialized, some fields are not
|
|
cleared, causing a crash when referencing the field when the
|
|
structure was released. Initially, this issue was ignored because
|
|
memory for mpi_ec_ctx is allocated with the __GFP_ZERO flag.
|
|
For example, this error will be triggered when calculating the
|
|
Za value for SM2 separately.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-11</ReleaseDate>
|
|
<CVE>CVE-2023-52616</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-11</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1566</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="7" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="7" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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-11</ReleaseDate>
|
|
<CVE>CVE-2023-52618</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-11</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1566</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:
|
|
|
|
llc: Drop support for ETH_P_TR_802_2.
|
|
|
|
syzbot reported an uninit-value bug below. [0]
|
|
|
|
llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2
|
|
(0x0011), and syzbot abused the latter to trigger the bug.
|
|
|
|
write$tun(r0, &(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', "90e5dd"}}}}, 0x16)
|
|
|
|
llc_conn_handler() initialises local variables {saddr,daddr}.mac
|
|
based on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes
|
|
them to __llc_lookup().
|
|
|
|
However, the initialisation is done only when skb->protocol is
|
|
htons(ETH_P_802_2), otherwise, __llc_lookup_established() and
|
|
__llc_lookup_listener() will read garbage.
|
|
|
|
The missing initialisation existed prior to commit 211ed865108e
|
|
("net: delete all instances of special processing for token ring").
|
|
|
|
It removed the part to kick out the token ring stuff but forgot to
|
|
close the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().
|
|
|
|
Let's remove llc_tr_packet_type and complete the deprecation.
|
|
|
|
[0]:
|
|
BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90
|
|
__llc_lookup_established+0xe9d/0xf90
|
|
__llc_lookup net/llc/llc_conn.c:611 [inline]
|
|
llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791
|
|
llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206
|
|
__netif_receive_skb_one_core net/core/dev.c:5527 [inline]
|
|
__netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641
|
|
netif_receive_skb_internal net/core/dev.c:5727 [inline]
|
|
netif_receive_skb+0x58/0x660 net/core/dev.c:5786
|
|
tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
|
|
tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002
|
|
tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
|
|
call_write_iter include/linux/fs.h:2020 [inline]
|
|
new_sync_write fs/read_write.c:491 [inline]
|
|
vfs_write+0x8ef/0x1490 fs/read_write.c:584
|
|
ksys_write+0x20f/0x4c0 fs/read_write.c:637
|
|
__do_sys_write fs/read_write.c:649 [inline]
|
|
__se_sys_write fs/read_write.c:646 [inline]
|
|
__x64_sys_write+0x93/0xd0 fs/read_write.c:646
|
|
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
|
|
do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b
|
|
|
|
Local variable daddr created at:
|
|
llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783
|
|
llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206
|
|
|
|
CPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-11</ReleaseDate>
|
|
<CVE>CVE-2024-26635</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.1</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-11</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1566</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:
|
|
|
|
llc: make llc_ui_sendmsg() more robust against bonding changes
|
|
|
|
syzbot was able to trick llc_ui_sendmsg(), allocating an skb with no
|
|
headroom, but subsequently trying to push 14 bytes of Ethernet header [1]
|
|
|
|
Like some others, llc_ui_sendmsg() releases the socket lock before
|
|
calling sock_alloc_send_skb().
|
|
Then it acquires it again, but does not redo all the sanity checks
|
|
that were performed.
|
|
|
|
This fix:
|
|
|
|
- Uses LL_RESERVED_SPACE() to reserve space.
|
|
- Check all conditions again after socket lock is held again.
|
|
- Do not account Ethernet header for mtu limitation.
|
|
|
|
[1]
|
|
|
|
skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0
|
|
|
|
kernel BUG at net/core/skbuff.c:193 !
|
|
Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
|
|
Modules linked in:
|
|
CPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
|
|
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
|
pc : skb_panic net/core/skbuff.c:189 [inline]
|
|
pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203
|
|
lr : skb_panic net/core/skbuff.c:189 [inline]
|
|
lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203
|
|
sp : ffff800096f97000
|
|
x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000
|
|
x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2
|
|
x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0
|
|
x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce
|
|
x17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001
|
|
x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000
|
|
x11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400
|
|
x8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000
|
|
x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714
|
|
x2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089
|
|
Call trace:
|
|
skb_panic net/core/skbuff.c:189 [inline]
|
|
skb_under_panic+0x13c/0x140 net/core/skbuff.c:203
|
|
skb_push+0xf0/0x108 net/core/skbuff.c:2451
|
|
eth_header+0x44/0x1f8 net/ethernet/eth.c:83
|
|
dev_hard_header include/linux/netdevice.h:3188 [inline]
|
|
llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33
|
|
llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85
|
|
llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline]
|
|
llc_sap_next_state net/llc/llc_sap.c:182 [inline]
|
|
llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209
|
|
llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270
|
|
llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg net/socket.c:745 [inline]
|
|
sock_sendmsg+0x194/0x274 net/socket.c:767
|
|
splice_to_socket+0x7cc/0xd58 fs/splice.c:881
|
|
do_splice_from fs/splice.c:933 [inline]
|
|
direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142
|
|
splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088
|
|
do_splice_direct+0x20c/0x348 fs/splice.c:1194
|
|
do_sendfile+0x4bc/0xc70 fs/read_write.c:1254
|
|
__do_sys_sendfile64 fs/read_write.c:1322 [inline]
|
|
__se_sys_sendfile64 fs/read_write.c:1308 [inline]
|
|
__arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308
|
|
__invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]
|
|
invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51
|
|
el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136
|
|
do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155
|
|
el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678
|
|
el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696
|
|
el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595
|
|
Code: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000)</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-11</ReleaseDate>
|
|
<CVE>CVE-2024-26636</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-11</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1566</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:
|
|
|
|
tcp: add sanity checks to rx zerocopy
|
|
|
|
TCP rx zerocopy intent is to map pages initially allocated
|
|
from NIC drivers, not pages owned by a fs.
|
|
|
|
This patch adds to can_map_frag() these additional checks:
|
|
|
|
- Page must not be a compound one.
|
|
- page->mapping must be NULL.
|
|
|
|
This fixes the panic reported by ZhangPeng.
|
|
|
|
syzbot was able to loopback packets built with sendfile(),
|
|
mapping pages owned by an ext4 file to TCP rx zerocopy.
|
|
|
|
r3 = socket$inet_tcp(0x2, 0x1, 0x0)
|
|
mmap(&(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0)
|
|
r4 = socket$inet_tcp(0x2, 0x1, 0x0)
|
|
bind$inet(r4, &(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10)
|
|
connect$inet(r4, &(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10)
|
|
r5 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00',
|
|
0x181e42, 0x0)
|
|
fallocate(r5, 0x0, 0x0, 0x85b8)
|
|
sendfile(r4, r5, 0x0, 0x8ba0)
|
|
getsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23,
|
|
&(0x7f00000001c0)={&(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0,
|
|
0x0, 0x0, 0x0, 0x0}, &(0x7f0000000440)=0x40)
|
|
r6 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00',
|
|
0x181e42, 0x0)</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-11</ReleaseDate>
|
|
<CVE>CVE-2024-26640</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-11</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1566</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:
|
|
|
|
ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()
|
|
|
|
syzbot found __ip6_tnl_rcv() could access unitiliazed data [1].
|
|
|
|
Call pskb_inet_may_pull() to fix this, and initialize ipv6h
|
|
variable after this call as it can change skb->head.
|
|
|
|
[1]
|
|
BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
|
|
BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
|
|
BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321
|
|
__INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
|
|
INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
|
|
IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321
|
|
ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727
|
|
__ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845
|
|
ip6_tnl_rcv+0xce/0x100 net/ipv6/ip6_tunnel.c:888
|
|
gre_rcv+0x143f/0x1870
|
|
ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438
|
|
ip6_input_finish net/ipv6/ip6_input.c:483 [inline]
|
|
NF_HOOK include/linux/netfilter.h:314 [inline]
|
|
ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492
|
|
ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586
|
|
dst_input include/net/dst.h:461 [inline]
|
|
ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79
|
|
NF_HOOK include/linux/netfilter.h:314 [inline]
|
|
ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310
|
|
__netif_receive_skb_one_core net/core/dev.c:5532 [inline]
|
|
__netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646
|
|
netif_receive_skb_internal net/core/dev.c:5732 [inline]
|
|
netif_receive_skb+0x58/0x660 net/core/dev.c:5791
|
|
tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
|
|
tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002
|
|
tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
|
|
call_write_iter include/linux/fs.h:2084 [inline]
|
|
new_sync_write fs/read_write.c:497 [inline]
|
|
vfs_write+0x786/0x1200 fs/read_write.c:590
|
|
ksys_write+0x20f/0x4c0 fs/read_write.c:643
|
|
__do_sys_write fs/read_write.c:655 [inline]
|
|
__se_sys_write fs/read_write.c:652 [inline]
|
|
__x64_sys_write+0x93/0xd0 fs/read_write.c:652
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b
|
|
|
|
Uninit was created at:
|
|
slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
|
|
slab_alloc_node mm/slub.c:3478 [inline]
|
|
kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523
|
|
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560
|
|
__alloc_skb+0x318/0x740 net/core/skbuff.c:651
|
|
alloc_skb include/linux/skbuff.h:1286 [inline]
|
|
alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334
|
|
sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787
|
|
tun_alloc_skb drivers/net/tun.c:1531 [inline]
|
|
tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846
|
|
tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
|
|
call_write_iter include/linux/fs.h:2084 [inline]
|
|
new_sync_write fs/read_write.c:497 [inline]
|
|
vfs_write+0x786/0x1200 fs/read_write.c:590
|
|
ksys_write+0x20f/0x4c0 fs/read_write.c:643
|
|
__do_sys_write fs/read_write.c:655 [inline]
|
|
__se_sys_write fs/read_write.c:652 [inline]
|
|
__x64_sys_write+0x93/0xd0 fs/read_write.c:652
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b
|
|
|
|
CPU: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-11</ReleaseDate>
|
|
<CVE>CVE-2024-26641</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.1</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-11</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1566</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:
|
|
|
|
l2tp: pass correct message length to ip6_append_data
|
|
|
|
l2tp_ip6_sendmsg needs to avoid accounting for the transport header
|
|
twice when splicing more data into an already partially-occupied skbuff.
|
|
|
|
To manage this, we check whether the skbuff contains data using
|
|
skb_queue_empty when deciding how much data to append using
|
|
ip6_append_data.
|
|
|
|
However, the code which performed the calculation was incorrect:
|
|
|
|
ulen = len + skb_queue_empty(&sk->sk_write_queue) ? transhdrlen : 0;
|
|
|
|
...due to C operator precedence, this ends up setting ulen to
|
|
transhdrlen for messages with a non-zero length, which results in
|
|
corrupted packets on the wire.
|
|
|
|
Add parentheses to correct the calculation in line with the original
|
|
intent.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-11</ReleaseDate>
|
|
<CVE>CVE-2024-26752</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.5</BaseScore>
|
|
<Vector>AV:N/AC:L/PR:N/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-11</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1566</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:
|
|
|
|
IB/hfi1: Fix sdma.h tx->num_descs off-by-one error
|
|
|
|
Unfortunately the commit `fd8958efe877` introduced another error
|
|
causing the `descs` array to overflow. This reults in further crashes
|
|
easily reproducible by `sendmsg` system call.
|
|
|
|
[ 1080.836473] general protection fault, probably for non-canonical address 0x400300015528b00a: 0000 [#1] PREEMPT SMP PTI
|
|
[ 1080.869326] RIP: 0010:hfi1_ipoib_build_ib_tx_headers.constprop.0+0xe1/0x2b0 [hfi1]
|
|
--
|
|
[ 1080.974535] Call Trace:
|
|
[ 1080.976990] <TASK>
|
|
[ 1081.021929] hfi1_ipoib_send_dma_common+0x7a/0x2e0 [hfi1]
|
|
[ 1081.027364] hfi1_ipoib_send_dma_list+0x62/0x270 [hfi1]
|
|
[ 1081.032633] hfi1_ipoib_send+0x112/0x300 [hfi1]
|
|
[ 1081.042001] ipoib_start_xmit+0x2a9/0x2d0 [ib_ipoib]
|
|
[ 1081.046978] dev_hard_start_xmit+0xc4/0x210
|
|
--
|
|
[ 1081.148347] __sys_sendmsg+0x59/0xa0
|
|
|
|
crash> ipoib_txreq 0xffff9cfeba229f00
|
|
struct ipoib_txreq {
|
|
txreq = {
|
|
list = {
|
|
next = 0xffff9cfeba229f00,
|
|
prev = 0xffff9cfeba229f00
|
|
},
|
|
descp = 0xffff9cfeba229f40,
|
|
coalesce_buf = 0x0,
|
|
wait = 0xffff9cfea4e69a48,
|
|
complete = 0xffffffffc0fe0760 <hfi1_ipoib_sdma_complete>,
|
|
packet_len = 0x46d,
|
|
tlen = 0x0,
|
|
num_desc = 0x0,
|
|
desc_limit = 0x6,
|
|
next_descq_idx = 0x45c,
|
|
coalesce_idx = 0x0,
|
|
flags = 0x0,
|
|
descs = {{
|
|
qw = {0x8024000120dffb00, 0x4} # SDMA_DESC0_FIRST_DESC_FLAG (bit 63)
|
|
}, {
|
|
qw = { 0x3800014231b108, 0x4}
|
|
}, {
|
|
qw = { 0x310000e4ee0fcf0, 0x8}
|
|
}, {
|
|
qw = { 0x3000012e9f8000, 0x8}
|
|
}, {
|
|
qw = { 0x59000dfb9d0000, 0x8}
|
|
}, {
|
|
qw = { 0x78000e02e40000, 0x8}
|
|
}}
|
|
},
|
|
sdma_hdr = 0x400300015528b000, <<< invalid pointer in the tx request structure
|
|
sdma_status = 0x0, SDMA_DESC0_LAST_DESC_FLAG (bit 62)
|
|
complete = 0x0,
|
|
priv = 0x0,
|
|
txq = 0xffff9cfea4e69880,
|
|
skb = 0xffff9d099809f400
|
|
}
|
|
|
|
If an SDMA send consists of exactly 6 descriptors and requires dword
|
|
padding (in the 7th descriptor), the sdma_txreq descriptor array is not
|
|
properly expanded and the packet will overflow into the container
|
|
structure. This results in a panic when the send completion runs. The
|
|
exact panic varies depending on what elements of the container structure
|
|
get corrupted. The fix is to use the correct expression in
|
|
_pad_sdma_tx_descs() to test the need to expand the descriptor array.
|
|
|
|
With this patch the crashes are no longer reproducible and the machine is
|
|
stable.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-11</ReleaseDate>
|
|
<CVE>CVE-2024-26766</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-11</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1566</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |