1300 lines
59 KiB
XML
1300 lines
59 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
|
|
<DocumentTitle xml:lang="en">An update for kernel is now available for openEuler-20.03-LTS-SP4</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-1568</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-20.03-LTS-SP4.</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:
|
|
|
|
iavf: free q_vectors before queues in iavf_disable_vf
|
|
|
|
iavf_free_queues() clears adapter->num_active_queues, which
|
|
iavf_free_q_vectors() relies on, so swap the order of these two function
|
|
calls in iavf_disable_vf(). This resolves a panic encountered when the
|
|
interface is disabled and then later brought up again after PF
|
|
communication is restored.(CVE-2021-47201)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: lpfc: Fix list_add() corruption in lpfc_drain_txq()
|
|
|
|
When parsing the txq list in lpfc_drain_txq(), the driver attempts to pass
|
|
the requests to the adapter. If such an attempt fails, a local "fail_msg"
|
|
string is set and a log message output. The job is then added to a
|
|
completions list for cancellation.
|
|
|
|
Processing of any further jobs from the txq list continues, but since
|
|
"fail_msg" remains set, jobs are added to the completions list regardless
|
|
of whether a wqe was passed to the adapter. If successfully added to
|
|
txcmplq, jobs are added to both lists resulting in list corruption.
|
|
|
|
Fix by clearing the fail_msg string after adding a job to the completions
|
|
list. This stops the subsequent jobs from being added to the completions
|
|
list unless they had an appropriate failure.(CVE-2021-47203)
|
|
|
|
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:
|
|
|
|
scsi: advansys: Fix kernel pointer leak
|
|
|
|
Pointers should be printed with %p or %px rather than cast to 'unsigned
|
|
long' and printed with %lx.
|
|
|
|
Change %lx to %p to print the hashed pointer.(CVE-2021-47216)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
x86/hyperv: Fix NULL deref in set_hv_tscchange_cb() if Hyper-V setup fails
|
|
|
|
Check for a valid hv_vp_index array prior to derefencing hv_vp_index when
|
|
setting Hyper-V's TSC change callback. If Hyper-V setup failed in
|
|
hyperv_init(), the kernel will still report that it's running under
|
|
Hyper-V, but will have silently disabled nearly all functionality.
|
|
|
|
BUG: kernel NULL pointer dereference, address: 0000000000000010
|
|
#PF: supervisor read access in kernel mode
|
|
#PF: error_code(0x0000) - not-present page
|
|
PGD 0 P4D 0
|
|
Oops: 0000 [#1] SMP
|
|
CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.15.0-rc2+ #75
|
|
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
|
|
RIP: 0010:set_hv_tscchange_cb+0x15/0xa0
|
|
Code: <8b> 04 82 8b 15 12 17 85 01 48 c1 e0 20 48 0d ee 00 01 00 f6 c6 08
|
|
...
|
|
Call Trace:
|
|
kvm_arch_init+0x17c/0x280
|
|
kvm_init+0x31/0x330
|
|
vmx_init+0xba/0x13a
|
|
do_one_initcall+0x41/0x1c0
|
|
kernel_init_freeable+0x1f2/0x23b
|
|
kernel_init+0x16/0x120
|
|
ret_from_fork+0x22/0x30(CVE-2021-47217)
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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)</Note>
|
|
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-20.03-LTS-SP4.
|
|
|
|
openEuler Security has rated this update as having a security impact of medium. 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">Medium</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-1568</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-47201</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47203</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-2021-47216</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47217</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-52609</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>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47182</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47201</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47203</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47211</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47216</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47217</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52477</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52609</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>
|
|
</Reference>
|
|
</DocumentReferences>
|
|
<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
|
|
<Branch Type="Product Name" Name="openEuler">
|
|
<FullProductName ProductID="openEuler-20.03-LTS-SP4" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">openEuler-20.03-LTS-SP4</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-source-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-devel-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-devel-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debugsource-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-4.19.90-2405.1.0.0275.oe2003sp4.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2405.1.0.0275.oe2003sp4.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-devel-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-devel-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-debuginfo-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debugsource-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-source-4.19.90-2405.1.0.0275.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-4.19.90-2405.1.0.0275" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2405.1.0.0275.oe2003sp4.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-20.03-LTS-SP4</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-1568</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:
|
|
|
|
iavf: free q_vectors before queues in iavf_disable_vf
|
|
|
|
iavf_free_queues() clears adapter->num_active_queues, which
|
|
iavf_free_q_vectors() relies on, so swap the order of these two function
|
|
calls in iavf_disable_vf(). This resolves a panic encountered when the
|
|
interface is disabled and then later brought up again after PF
|
|
communication is restored.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-11</ReleaseDate>
|
|
<CVE>CVE-2021-47201</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</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-1568</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:
|
|
|
|
scsi: lpfc: Fix list_add() corruption in lpfc_drain_txq()
|
|
|
|
When parsing the txq list in lpfc_drain_txq(), the driver attempts to pass
|
|
the requests to the adapter. If such an attempt fails, a local "fail_msg"
|
|
string is set and a log message output. The job is then added to a
|
|
completions list for cancellation.
|
|
|
|
Processing of any further jobs from the txq list continues, but since
|
|
"fail_msg" remains set, jobs are added to the completions list regardless
|
|
of whether a wqe was passed to the adapter. If successfully added to
|
|
txcmplq, jobs are added to both lists resulting in list corruption.
|
|
|
|
Fix by clearing the fail_msg string after adding a job to the completions
|
|
list. This stops the subsequent jobs from being added to the completions
|
|
list unless they had an appropriate failure.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-11</ReleaseDate>
|
|
<CVE>CVE-2021-47203</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</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-1568</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:
|
|
|
|
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-20.03-LTS-SP4</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-1568</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:
|
|
|
|
scsi: advansys: Fix kernel pointer leak
|
|
|
|
Pointers should be printed with %p or %px rather than cast to 'unsigned
|
|
long' and printed with %lx.
|
|
|
|
Change %lx to %p to print the hashed pointer.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-11</ReleaseDate>
|
|
<CVE>CVE-2021-47216</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</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-1568</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:
|
|
|
|
x86/hyperv: Fix NULL deref in set_hv_tscchange_cb() if Hyper-V setup fails
|
|
|
|
Check for a valid hv_vp_index array prior to derefencing hv_vp_index when
|
|
setting Hyper-V's TSC change callback. If Hyper-V setup failed in
|
|
hyperv_init(), the kernel will still report that it's running under
|
|
Hyper-V, but will have silently disabled nearly all functionality.
|
|
|
|
BUG: kernel NULL pointer dereference, address: 0000000000000010
|
|
#PF: supervisor read access in kernel mode
|
|
#PF: error_code(0x0000) - not-present page
|
|
PGD 0 P4D 0
|
|
Oops: 0000 [#1] SMP
|
|
CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.15.0-rc2+ #75
|
|
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
|
|
RIP: 0010:set_hv_tscchange_cb+0x15/0xa0
|
|
Code: <8b> 04 82 8b 15 12 17 85 01 48 c1 e0 20 48 0d ee 00 01 00 f6 c6 08
|
|
...
|
|
Call Trace:
|
|
kvm_arch_init+0x17c/0x280
|
|
kvm_init+0x31/0x330
|
|
vmx_init+0xba/0x13a
|
|
do_one_initcall+0x41/0x1c0
|
|
kernel_init_freeable+0x1f2/0x23b
|
|
kernel_init+0x16/0x120
|
|
ret_from_fork+0x22/0x30</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-11</ReleaseDate>
|
|
<CVE>CVE-2021-47217</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</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-1568</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:
|
|
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-11</ReleaseDate>
|
|
<CVE>CVE-2023-52477</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</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-1568</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:
|
|
|
|
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-20.03-LTS-SP4</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-1568</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: 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-20.03-LTS-SP4</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-1568</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:
|
|
|
|
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-20.03-LTS-SP4</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-1568</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:
|
|
|
|
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-20.03-LTS-SP4</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-1568</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="12" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="12" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ip6_tunnel: 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-20.03-LTS-SP4</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-1568</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |