1913 lines
87 KiB
XML
1913 lines
87 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
|
|
<DocumentTitle xml:lang="en">An update for kernel is now available for openEuler-20.03-LTS-SP1</DocumentTitle>
|
|
<DocumentType>Security Advisory</DocumentType>
|
|
<DocumentPublisher Type="Vendor">
|
|
<ContactDetails>openeuler-security@openeuler.org</ContactDetails>
|
|
<IssuingAuthority>openEuler security committee</IssuingAuthority>
|
|
</DocumentPublisher>
|
|
<DocumentTracking>
|
|
<Identification>
|
|
<ID>openEuler-SA-2024-1567</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-SP1.</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:
|
|
|
|
sctp: use call_rcu to free endpoint
|
|
|
|
This patch is to delay the endpoint free by calling call_rcu() to fix
|
|
another use-after-free issue in sctp_sock_dump():
|
|
|
|
BUG: KASAN: use-after-free in __lock_acquire+0x36d9/0x4c20
|
|
Call Trace:
|
|
__lock_acquire+0x36d9/0x4c20 kernel/locking/lockdep.c:3218
|
|
lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844
|
|
__raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline]
|
|
_raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168
|
|
spin_lock_bh include/linux/spinlock.h:334 [inline]
|
|
__lock_sock+0x203/0x350 net/core/sock.c:2253
|
|
lock_sock_nested+0xfe/0x120 net/core/sock.c:2774
|
|
lock_sock include/net/sock.h:1492 [inline]
|
|
sctp_sock_dump+0x122/0xb20 net/sctp/diag.c:324
|
|
sctp_for_each_transport+0x2b5/0x370 net/sctp/socket.c:5091
|
|
sctp_diag_dump+0x3ac/0x660 net/sctp/diag.c:527
|
|
__inet_diag_dump+0xa8/0x140 net/ipv4/inet_diag.c:1049
|
|
inet_diag_dump+0x9b/0x110 net/ipv4/inet_diag.c:1065
|
|
netlink_dump+0x606/0x1080 net/netlink/af_netlink.c:2244
|
|
__netlink_dump_start+0x59a/0x7c0 net/netlink/af_netlink.c:2352
|
|
netlink_dump_start include/linux/netlink.h:216 [inline]
|
|
inet_diag_handler_cmd+0x2ce/0x3f0 net/ipv4/inet_diag.c:1170
|
|
__sock_diag_cmd net/core/sock_diag.c:232 [inline]
|
|
sock_diag_rcv_msg+0x31d/0x410 net/core/sock_diag.c:263
|
|
netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2477
|
|
sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:274
|
|
|
|
This issue occurs when asoc is peeled off and the old sk is freed after
|
|
getting it by asoc->base.sk and before calling lock_sock(sk).
|
|
|
|
To prevent the sk free, as a holder of the sk, ep should be alive when
|
|
calling lock_sock(). This patch uses call_rcu() and moves sock_put and
|
|
ep free into sctp_endpoint_destroy_rcu(), so that it's safe to try to
|
|
hold the ep under rcu_read_lock in sctp_transport_traverse_process().
|
|
|
|
If sctp_endpoint_hold() returns true, it means this ep is still alive
|
|
and we have held it and can continue to dump it; If it returns false,
|
|
it means this ep is dead and can be freed after rcu_read_unlock, and
|
|
we should skip it.
|
|
|
|
In sctp_sock_dump(), after locking the sk, if this ep is different from
|
|
tsp->asoc->ep, it means during this dumping, this asoc was peeled off
|
|
before calling lock_sock(), and the sk should be skipped; If this ep is
|
|
the same with tsp->asoc->ep, it means no peeloff happens on this asoc,
|
|
and due to lock_sock, no peeloff will happen either until release_sock.
|
|
|
|
Note that delaying endpoint free won't delay the port release, as the
|
|
port release happens in sctp_endpoint_destroy() before calling call_rcu().
|
|
Also, freeing endpoint by call_rcu() makes it safe to access the sk by
|
|
asoc->base.sk in sctp_assocs_seq_show() and sctp_rcv().
|
|
|
|
Thanks Jones to bring this issue up.
|
|
|
|
v1->v2:
|
|
- improve the changelog.
|
|
- add kfree(ep) into sctp_endpoint_destroy_rcu(), as Jakub noticed.(CVE-2021-46929)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: fix use-after-free in tw_timer_handler
|
|
|
|
A real world panic issue was found as follow in Linux 5.4.
|
|
|
|
BUG: unable to handle page fault for address: ffffde49a863de28
|
|
PGD 7e6fe62067 P4D 7e6fe62067 PUD 7e6fe63067 PMD f51e064067 PTE 0
|
|
RIP: 0010:tw_timer_handler+0x20/0x40
|
|
Call Trace:
|
|
<IRQ>
|
|
call_timer_fn+0x2b/0x120
|
|
run_timer_softirq+0x1ef/0x450
|
|
__do_softirq+0x10d/0x2b8
|
|
irq_exit+0xc7/0xd0
|
|
smp_apic_timer_interrupt+0x68/0x120
|
|
apic_timer_interrupt+0xf/0x20
|
|
|
|
This issue was also reported since 2017 in the thread [1],
|
|
unfortunately, the issue was still can be reproduced after fixing
|
|
DCCP.
|
|
|
|
The ipv4_mib_exit_net is called before tcp_sk_exit_batch when a net
|
|
namespace is destroyed since tcp_sk_ops is registered befrore
|
|
ipv4_mib_ops, which means tcp_sk_ops is in the front of ipv4_mib_ops
|
|
in the list of pernet_list. There will be a use-after-free on
|
|
net->mib.net_statistics in tw_timer_handler after ipv4_mib_exit_net
|
|
if there are some inflight time-wait timers.
|
|
|
|
This bug is not introduced by commit f2bf415cfed7 ("mib: add net to
|
|
NET_ADD_STATS_BH") since the net_statistics is a global variable
|
|
instead of dynamic allocation and freeing. Actually, commit
|
|
61a7e26028b9 ("mib: put net statistics on struct net") introduces
|
|
the bug since it put net statistics on struct net and free it when
|
|
net namespace is destroyed.
|
|
|
|
Moving init_ipv4_mibs() to the front of tcp_init() to fix this bug
|
|
and replace pr_crit() with panic() since continuing is meaningless
|
|
when init_ipv4_mibs() fails.
|
|
|
|
[1] https://groups.google.com/g/syzkaller/c/p1tn-_Kc6l4/m/smuL_FMAAgAJ?pli=1(CVE-2021-46936)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ACPI: custom_method: fix potential use-after-free issue
|
|
|
|
In cm_write(), buf is always freed when reaching the end of the
|
|
function. If the requested count is less than table.length, the
|
|
allocated buffer will be freed but subsequent calls to cm_write() will
|
|
still try to access it.
|
|
|
|
Remove the unconditional kfree(buf) at the end of the function and
|
|
set the buf to NULL in the -EINVAL error path to match the rest of
|
|
function.(CVE-2021-46966)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tun: avoid double free in tun_free_netdev
|
|
|
|
Avoid double free in tun_free_netdev() by moving the
|
|
dev->tstats and tun->security allocs to a new ndo_init routine
|
|
(tun_net_init()) that will be called by register_netdevice().
|
|
ndo_init is paired with the desctructor (tun_free_netdev()),
|
|
so if there's an error in register_netdevice() the destructor
|
|
will handle the frees.
|
|
|
|
BUG: KASAN: double-free or invalid-free in selinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605
|
|
|
|
CPU: 0 PID: 25750 Comm: syz-executor416 Not tainted 5.16.0-rc2-syzk #1
|
|
Hardware name: Red Hat KVM, BIOS
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106
|
|
print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:247
|
|
kasan_report_invalid_free+0x55/0x80 mm/kasan/report.c:372
|
|
____kasan_slab_free mm/kasan/common.c:346 [inline]
|
|
__kasan_slab_free+0x107/0x120 mm/kasan/common.c:374
|
|
kasan_slab_free include/linux/kasan.h:235 [inline]
|
|
slab_free_hook mm/slub.c:1723 [inline]
|
|
slab_free_freelist_hook mm/slub.c:1749 [inline]
|
|
slab_free mm/slub.c:3513 [inline]
|
|
kfree+0xac/0x2d0 mm/slub.c:4561
|
|
selinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605
|
|
security_tun_dev_free_security+0x4f/0x90 security/security.c:2342
|
|
tun_free_netdev+0xe6/0x150 drivers/net/tun.c:2215
|
|
netdev_run_todo+0x4df/0x840 net/core/dev.c:10627
|
|
rtnl_unlock+0x13/0x20 net/core/rtnetlink.c:112
|
|
__tun_chr_ioctl+0x80c/0x2870 drivers/net/tun.c:3302
|
|
tun_chr_ioctl+0x2f/0x40 drivers/net/tun.c:3311
|
|
vfs_ioctl fs/ioctl.c:51 [inline]
|
|
__do_sys_ioctl fs/ioctl.c:874 [inline]
|
|
__se_sys_ioctl fs/ioctl.c:860 [inline]
|
|
__x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860
|
|
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
|
|
do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80
|
|
entry_SYSCALL_64_after_hwframe+0x44/0xae(CVE-2021-47082)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
io_uring: fix ltout double free on completion race
|
|
|
|
Always remove linked timeout on io_link_timeout_fn() from the master
|
|
request link list, otherwise we may get use-after-free when first
|
|
io_link_timeout_fn() puts linked timeout in the fail path, and then
|
|
will be found and put on master's free.(CVE-2021-47123)
|
|
|
|
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:
|
|
|
|
tty: tty_buffer: Fix the softlockup issue in flush_to_ldisc
|
|
|
|
When running ltp testcase(ltp/testcases/kernel/pty/pty04.c) with arm64, there is a soft lockup,
|
|
which look like this one:
|
|
|
|
Workqueue: events_unbound flush_to_ldisc
|
|
Call trace:
|
|
dump_backtrace+0x0/0x1ec
|
|
show_stack+0x24/0x30
|
|
dump_stack+0xd0/0x128
|
|
panic+0x15c/0x374
|
|
watchdog_timer_fn+0x2b8/0x304
|
|
__run_hrtimer+0x88/0x2c0
|
|
__hrtimer_run_queues+0xa4/0x120
|
|
hrtimer_interrupt+0xfc/0x270
|
|
arch_timer_handler_phys+0x40/0x50
|
|
handle_percpu_devid_irq+0x94/0x220
|
|
__handle_domain_irq+0x88/0xf0
|
|
gic_handle_irq+0x84/0xfc
|
|
el1_irq+0xc8/0x180
|
|
slip_unesc+0x80/0x214 [slip]
|
|
tty_ldisc_receive_buf+0x64/0x80
|
|
tty_port_default_receive_buf+0x50/0x90
|
|
flush_to_ldisc+0xbc/0x110
|
|
process_one_work+0x1d4/0x4b0
|
|
worker_thread+0x180/0x430
|
|
kthread+0x11c/0x120
|
|
|
|
In the testcase pty04, The first process call the write syscall to send
|
|
data to the pty master. At the same time, the workqueue will do the
|
|
flush_to_ldisc to pop data in a loop until there is no more data left.
|
|
When the sender and workqueue running in different core, the sender sends
|
|
data fastly in full time which will result in workqueue doing work in loop
|
|
for a long time and occuring softlockup in flush_to_ldisc with kernel
|
|
configured without preempt. So I add need_resched check and cond_resched
|
|
in the flush_to_ldisc loop to avoid it.(CVE-2021-47185)
|
|
|
|
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:
|
|
|
|
crypto: scomp - fix req->dst buffer overflow
|
|
|
|
The req->dst buffer size should be checked before copying from the
|
|
scomp_scratch->dst to avoid req->dst buffer overflow problem.(CVE-2023-52612)
|
|
|
|
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)</Note>
|
|
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-20.03-LTS-SP1.
|
|
|
|
openEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.</Note>
|
|
<Note Title="Severity" Type="General" Ordinal="5" xml:lang="en">High</Note>
|
|
<Note Title="Affected Component" Type="General" Ordinal="6" xml:lang="en">kernel</Note>
|
|
</DocumentNotes>
|
|
<DocumentReferences>
|
|
<Reference Type="Self">
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1567</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-46929</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-46936</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-46966</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47082</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47123</URL>
|
|
<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-47185</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-2023-52612</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>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-46929</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-46936</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-46966</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47082</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47123</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47182</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47185</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-2023-52612</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>
|
|
</Reference>
|
|
</DocumentReferences>
|
|
<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
|
|
<Branch Type="Product Name" Name="openEuler">
|
|
<FullProductName ProductID="openEuler-20.03-LTS-SP1" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">openEuler-20.03-LTS-SP1</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">python2-perf-debuginfo-4.19.90-2405.1.0.0248.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-debugsource-4.19.90-2405.1.0.0248.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">python3-perf-4.19.90-2405.1.0.0248.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-source-4.19.90-2405.1.0.0248.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-tools-debuginfo-4.19.90-2405.1.0.0248.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">bpftool-debuginfo-4.19.90-2405.1.0.0248.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">python2-perf-4.19.90-2405.1.0.0248.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-debuginfo-4.19.90-2405.1.0.0248.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-tools-devel-4.19.90-2405.1.0.0248.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-tools-4.19.90-2405.1.0.0248.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">perf-debuginfo-4.19.90-2405.1.0.0248.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">python3-perf-debuginfo-4.19.90-2405.1.0.0248.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-devel-4.19.90-2405.1.0.0248.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">bpftool-4.19.90-2405.1.0.0248.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">perf-4.19.90-2405.1.0.0248.oe1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-4.19.90-2405.1.0.0248.oe1.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-4.19.90-2405.1.0.0248.oe1.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="kernel-debuginfo-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-debuginfo-4.19.90-2405.1.0.0248.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-tools-debuginfo-4.19.90-2405.1.0.0248.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">python2-perf-4.19.90-2405.1.0.0248.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-tools-4.19.90-2405.1.0.0248.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">python3-perf-debuginfo-4.19.90-2405.1.0.0248.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">python3-perf-4.19.90-2405.1.0.0248.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-source-4.19.90-2405.1.0.0248.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">perf-debuginfo-4.19.90-2405.1.0.0248.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-4.19.90-2405.1.0.0248.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">python2-perf-debuginfo-4.19.90-2405.1.0.0248.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-debugsource-4.19.90-2405.1.0.0248.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-devel-4.19.90-2405.1.0.0248.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">kernel-tools-devel-4.19.90-2405.1.0.0248.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">bpftool-debuginfo-4.19.90-2405.1.0.0248.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">perf-4.19.90-2405.1.0.0248.oe1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-4.19.90-2405.1.0.0248" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">bpftool-4.19.90-2405.1.0.0248.oe1.x86_64.rpm</FullProductName>
|
|
</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:sctp: use call_rcu to free endpointThis patch is to delay the endpoint free by calling call_rcu() to fixanother use-after-free issue in sctp_sock_dump(): BUG: KASAN: use-after-free in __lock_acquire+0x36d9/0x4c20 Call Trace: __lock_acquire+0x36d9/0x4c20 kernel/locking/lockdep.c:3218 lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline] _raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168 spin_lock_bh include/linux/spinlock.h:334 [inline] __lock_sock+0x203/0x350 net/core/sock.c:2253 lock_sock_nested+0xfe/0x120 net/core/sock.c:2774 lock_sock include/net/sock.h:1492 [inline] sctp_sock_dump+0x122/0xb20 net/sctp/diag.c:324 sctp_for_each_transport+0x2b5/0x370 net/sctp/socket.c:5091 sctp_diag_dump+0x3ac/0x660 net/sctp/diag.c:527 __inet_diag_dump+0xa8/0x140 net/ipv4/inet_diag.c:1049 inet_diag_dump+0x9b/0x110 net/ipv4/inet_diag.c:1065 netlink_dump+0x606/0x1080 net/netlink/af_netlink.c:2244 __netlink_dump_start+0x59a/0x7c0 net/netlink/af_netlink.c:2352 netlink_dump_start include/linux/netlink.h:216 [inline] inet_diag_handler_cmd+0x2ce/0x3f0 net/ipv4/inet_diag.c:1170 __sock_diag_cmd net/core/sock_diag.c:232 [inline] sock_diag_rcv_msg+0x31d/0x410 net/core/sock_diag.c:263 netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2477 sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:274This issue occurs when asoc is peeled off and the old sk is freed aftergetting it by asoc->base.sk and before calling lock_sock(sk).To prevent the sk free, as a holder of the sk, ep should be alive whencalling lock_sock(). This patch uses call_rcu() and moves sock_put andep free into sctp_endpoint_destroy_rcu(), so that it s safe to try tohold the ep under rcu_read_lock in sctp_transport_traverse_process().If sctp_endpoint_hold() returns true, it means this ep is still aliveand we have held it and can continue to dump it; If it returns false,it means this ep is dead and can be freed after rcu_read_unlock, andwe should skip it.In sctp_sock_dump(), after locking the sk, if this ep is different fromtsp->asoc->ep, it means during this dumping, this asoc was peeled offbefore calling lock_sock(), and the sk should be skipped; If this ep isthe same with tsp->asoc->ep, it means no peeloff happens on this asoc,and due to lock_sock, no peeloff will happen either until release_sock.Note that delaying endpoint free won t delay the port release, as theport release happens in sctp_endpoint_destroy() before calling call_rcu().Also, freeing endpoint by call_rcu() makes it safe to access the sk byasoc->base.sk in sctp_assocs_seq_show() and sctp_rcv().Thanks Jones to bring this issue up.v1->v2: - improve the changelog. - add kfree(ep) into sctp_endpoint_destroy_rcu(), as Jakub noticed.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-11</ReleaseDate>
|
|
<CVE>CVE-2021-46929</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.3</BaseScore>
|
|
<Vector>AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L</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-1567</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: fix use-after-free in tw_timer_handlerA real world panic issue was found as follow in Linux 5.4. BUG: unable to handle page fault for address: ffffde49a863de28 PGD 7e6fe62067 P4D 7e6fe62067 PUD 7e6fe63067 PMD f51e064067 PTE 0 RIP: 0010:tw_timer_handler+0x20/0x40 Call Trace: <IRQ> call_timer_fn+0x2b/0x120 run_timer_softirq+0x1ef/0x450 __do_softirq+0x10d/0x2b8 irq_exit+0xc7/0xd0 smp_apic_timer_interrupt+0x68/0x120 apic_timer_interrupt+0xf/0x20This issue was also reported since 2017 in the thread [1],unfortunately, the issue was still can be reproduced after fixingDCCP.The ipv4_mib_exit_net is called before tcp_sk_exit_batch when a netnamespace is destroyed since tcp_sk_ops is registered befroreipv4_mib_ops, which means tcp_sk_ops is in the front of ipv4_mib_opsin the list of pernet_list. There will be a use-after-free onnet->mib.net_statistics in tw_timer_handler after ipv4_mib_exit_netif there are some inflight time-wait timers.This bug is not introduced by commit f2bf415cfed7 ( mib: add net toNET_ADD_STATS_BH ) since the net_statistics is a global variableinstead of dynamic allocation and freeing. Actually, commit61a7e26028b9 ( mib: put net statistics on struct net ) introducesthe bug since it put net statistics on struct net and free it whennet namespace is destroyed.Moving init_ipv4_mibs() to the front of tcp_init() to fix this bugand replace pr_crit() with panic() since continuing is meaninglesswhen init_ipv4_mibs() fails.[1] https://groups.google.com/g/syzkaller/c/p1tn-_Kc6l4/m/smuL_FMAAgAJ?pli=1</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-11</ReleaseDate>
|
|
<CVE>CVE-2021-46936</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.3</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/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-1567</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:
|
|
|
|
ACPI: custom_method: fix potential use-after-free issue
|
|
|
|
In cm_write(), buf is always freed when reaching the end of the
|
|
function. If the requested count is less than table.length, the
|
|
allocated buffer will be freed but subsequent calls to cm_write() will
|
|
still try to access it.
|
|
|
|
Remove the unconditional kfree(buf) at the end of the function and
|
|
set the buf to NULL in the -EINVAL error path to match the rest of
|
|
function.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-11</ReleaseDate>
|
|
<CVE>CVE-2021-46966</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>8.0</BaseScore>
|
|
<Vector>AV:A/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-1567</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:
|
|
|
|
tun: avoid double free in tun_free_netdev
|
|
|
|
Avoid double free in tun_free_netdev() by moving the
|
|
dev->tstats and tun->security allocs to a new ndo_init routine
|
|
(tun_net_init()) that will be called by register_netdevice().
|
|
ndo_init is paired with the desctructor (tun_free_netdev()),
|
|
so if there's an error in register_netdevice() the destructor
|
|
will handle the frees.
|
|
|
|
BUG: KASAN: double-free or invalid-free in selinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605
|
|
|
|
CPU: 0 PID: 25750 Comm: syz-executor416 Not tainted 5.16.0-rc2-syzk #1
|
|
Hardware name: Red Hat KVM, BIOS
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106
|
|
print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:247
|
|
kasan_report_invalid_free+0x55/0x80 mm/kasan/report.c:372
|
|
____kasan_slab_free mm/kasan/common.c:346 [inline]
|
|
__kasan_slab_free+0x107/0x120 mm/kasan/common.c:374
|
|
kasan_slab_free include/linux/kasan.h:235 [inline]
|
|
slab_free_hook mm/slub.c:1723 [inline]
|
|
slab_free_freelist_hook mm/slub.c:1749 [inline]
|
|
slab_free mm/slub.c:3513 [inline]
|
|
kfree+0xac/0x2d0 mm/slub.c:4561
|
|
selinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605
|
|
security_tun_dev_free_security+0x4f/0x90 security/security.c:2342
|
|
tun_free_netdev+0xe6/0x150 drivers/net/tun.c:2215
|
|
netdev_run_todo+0x4df/0x840 net/core/dev.c:10627
|
|
rtnl_unlock+0x13/0x20 net/core/rtnetlink.c:112
|
|
__tun_chr_ioctl+0x80c/0x2870 drivers/net/tun.c:3302
|
|
tun_chr_ioctl+0x2f/0x40 drivers/net/tun.c:3311
|
|
vfs_ioctl fs/ioctl.c:51 [inline]
|
|
__do_sys_ioctl fs/ioctl.c:874 [inline]
|
|
__se_sys_ioctl fs/ioctl.c:860 [inline]
|
|
__x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860
|
|
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
|
|
do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80
|
|
entry_SYSCALL_64_after_hwframe+0x44/0xae</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-11</ReleaseDate>
|
|
<CVE>CVE-2021-47082</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-11</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1567</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:
|
|
|
|
io_uring: fix ltout double free on completion race
|
|
|
|
Always remove linked timeout on io_link_timeout_fn() from the master
|
|
request link list, otherwise we may get use-after-free when first
|
|
io_link_timeout_fn() puts linked timeout in the fail path, and then
|
|
will be found and put on master's free.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-11</ReleaseDate>
|
|
<CVE>CVE-2021-47123</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-11</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1567</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-11</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1567</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:
|
|
|
|
tty: tty_buffer: Fix the softlockup issue in flush_to_ldisc
|
|
|
|
When running ltp testcase(ltp/testcases/kernel/pty/pty04.c) with arm64, there is a soft lockup,
|
|
which look like this one:
|
|
|
|
Workqueue: events_unbound flush_to_ldisc
|
|
Call trace:
|
|
dump_backtrace+0x0/0x1ec
|
|
show_stack+0x24/0x30
|
|
dump_stack+0xd0/0x128
|
|
panic+0x15c/0x374
|
|
watchdog_timer_fn+0x2b8/0x304
|
|
__run_hrtimer+0x88/0x2c0
|
|
__hrtimer_run_queues+0xa4/0x120
|
|
hrtimer_interrupt+0xfc/0x270
|
|
arch_timer_handler_phys+0x40/0x50
|
|
handle_percpu_devid_irq+0x94/0x220
|
|
__handle_domain_irq+0x88/0xf0
|
|
gic_handle_irq+0x84/0xfc
|
|
el1_irq+0xc8/0x180
|
|
slip_unesc+0x80/0x214 [slip]
|
|
tty_ldisc_receive_buf+0x64/0x80
|
|
tty_port_default_receive_buf+0x50/0x90
|
|
flush_to_ldisc+0xbc/0x110
|
|
process_one_work+0x1d4/0x4b0
|
|
worker_thread+0x180/0x430
|
|
kthread+0x11c/0x120
|
|
|
|
In the testcase pty04, The first process call the write syscall to send
|
|
data to the pty master. At the same time, the workqueue will do the
|
|
flush_to_ldisc to pop data in a loop until there is no more data left.
|
|
When the sender and workqueue running in different core, the sender sends
|
|
data fastly in full time which will result in workqueue doing work in loop
|
|
for a long time and occuring softlockup in flush_to_ldisc with kernel
|
|
configured without preempt. So I add need_resched check and cond_resched
|
|
in the flush_to_ldisc loop to avoid it.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-11</ReleaseDate>
|
|
<CVE>CVE-2021-47185</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-11</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1567</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-11</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1567</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-11</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1567</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-11</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1567</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-11</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1567</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-11</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1567</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:
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-11</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1567</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="14" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="14" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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-SP1</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-1567</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="15" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="15" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
crypto: scomp - fix req->dst buffer overflow
|
|
|
|
The req->dst buffer size should be checked before copying from the
|
|
scomp_scratch->dst to avoid req->dst buffer overflow problem.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-11</ReleaseDate>
|
|
<CVE>CVE-2023-52612</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.0</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:H/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-1567</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="16" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="16" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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-SP1</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-1567</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="17" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="17" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-11</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1567</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="18" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="18" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-11</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1567</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="19" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="19" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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-SP1</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-1567</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="20" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="20" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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-20.03-LTS-SP1</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-1567</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |