2398 lines
102 KiB
XML
2398 lines
102 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
|
|
<DocumentTitle xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-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-1860</ID>
|
|
</Identification>
|
|
<Status>Final</Status>
|
|
<Version>1.0</Version>
|
|
<RevisionHistory>
|
|
<Revision>
|
|
<Number>1.0</Number>
|
|
<Date>2024-07-19</Date>
|
|
<Description>Initial</Description>
|
|
</Revision>
|
|
</RevisionHistory>
|
|
<InitialReleaseDate>2024-07-19</InitialReleaseDate>
|
|
<CurrentReleaseDate>2024-07-19</CurrentReleaseDate>
|
|
<Generator>
|
|
<Engine>openEuler SA Tool V1.0</Engine>
|
|
<Date>2024-07-19</Date>
|
|
</Generator>
|
|
</DocumentTracking>
|
|
<DocumentNotes>
|
|
<Note Title="Synopsis" Type="General" Ordinal="1" xml:lang="en">kernel security update</Note>
|
|
<Note Title="Summary" Type="General" Ordinal="2" xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-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:
|
|
|
|
RDMA/cma: Ensure rdma_addr_cancel() happens before issuing more requests
|
|
|
|
The FSM can run in a circle allowing rdma_resolve_ip() to be called twice
|
|
on the same id_priv. While this cannot happen without going through the
|
|
work, it violates the invariant that the same address resolution
|
|
background request cannot be active twice.
|
|
|
|
CPU 1 CPU 2
|
|
|
|
rdma_resolve_addr():
|
|
RDMA_CM_IDLE -> RDMA_CM_ADDR_QUERY
|
|
rdma_resolve_ip(addr_handler) #1
|
|
|
|
process_one_req(): for #1
|
|
addr_handler():
|
|
RDMA_CM_ADDR_QUERY -> RDMA_CM_ADDR_BOUND
|
|
mutex_unlock(&id_priv->handler_mutex);
|
|
[.. handler still running ..]
|
|
|
|
rdma_resolve_addr():
|
|
RDMA_CM_ADDR_BOUND -> RDMA_CM_ADDR_QUERY
|
|
rdma_resolve_ip(addr_handler)
|
|
!! two requests are now on the req_list
|
|
|
|
rdma_destroy_id():
|
|
destroy_id_handler_unlock():
|
|
_destroy_id():
|
|
cma_cancel_operation():
|
|
rdma_addr_cancel()
|
|
|
|
// process_one_req() self removes it
|
|
spin_lock_bh(&lock);
|
|
cancel_delayed_work(&req->work);
|
|
if (!list_empty(&req->list)) == true
|
|
|
|
! rdma_addr_cancel() returns after process_on_req #1 is done
|
|
|
|
kfree(id_priv)
|
|
|
|
process_one_req(): for #2
|
|
addr_handler():
|
|
mutex_lock(&id_priv->handler_mutex);
|
|
!! Use after free on id_priv
|
|
|
|
rdma_addr_cancel() expects there to be one req on the list and only
|
|
cancels the first one. The self-removal behavior of the work only happens
|
|
after the handler has returned. This yields a situations where the
|
|
req_list can have two reqs for the same "handle" but rdma_addr_cancel()
|
|
only cancels the first one.
|
|
|
|
The second req remains active beyond rdma_destroy_id() and will
|
|
use-after-free id_priv once it inevitably triggers.
|
|
|
|
Fix this by remembering if the id_priv has called rdma_resolve_ip() and
|
|
always cancel before calling it again. This ensures the req_list never
|
|
gets more than one item in it and doesn't cost anything in the normal flow
|
|
that never uses this strange error path.(CVE-2021-47391)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/smc: Forward wakeup to smc socket waitqueue after fallback
|
|
|
|
When we replace TCP with SMC and a fallback occurs, there may be
|
|
some socket waitqueue entries remaining in smc socket->wq, such
|
|
as eppoll_entries inserted by userspace applications.
|
|
|
|
After the fallback, data flows over TCP/IP and only clcsocket->wq
|
|
will be woken up. Applications can't be notified by the entries
|
|
which were inserted in smc socket->wq before fallback. So we need
|
|
a mechanism to wake up smc socket->wq at the same time if some
|
|
entries remaining in it.
|
|
|
|
The current workaround is to transfer the entries from smc socket->wq
|
|
to clcsock->wq during the fallback. But this may cause a crash
|
|
like this:
|
|
|
|
general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#1] PREEMPT SMP PTI
|
|
CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Tainted: G E 5.16.0+ #107
|
|
RIP: 0010:__wake_up_common+0x65/0x170
|
|
Call Trace:
|
|
<IRQ>
|
|
__wake_up_common_lock+0x7a/0xc0
|
|
sock_def_readable+0x3c/0x70
|
|
tcp_data_queue+0x4a7/0xc40
|
|
tcp_rcv_established+0x32f/0x660
|
|
? sk_filter_trim_cap+0xcb/0x2e0
|
|
tcp_v4_do_rcv+0x10b/0x260
|
|
tcp_v4_rcv+0xd2a/0xde0
|
|
ip_protocol_deliver_rcu+0x3b/0x1d0
|
|
ip_local_deliver_finish+0x54/0x60
|
|
ip_local_deliver+0x6a/0x110
|
|
? tcp_v4_early_demux+0xa2/0x140
|
|
? tcp_v4_early_demux+0x10d/0x140
|
|
ip_sublist_rcv_finish+0x49/0x60
|
|
ip_sublist_rcv+0x19d/0x230
|
|
ip_list_rcv+0x13e/0x170
|
|
__netif_receive_skb_list_core+0x1c2/0x240
|
|
netif_receive_skb_list_internal+0x1e6/0x320
|
|
napi_complete_done+0x11d/0x190
|
|
mlx5e_napi_poll+0x163/0x6b0 [mlx5_core]
|
|
__napi_poll+0x3c/0x1b0
|
|
net_rx_action+0x27c/0x300
|
|
__do_softirq+0x114/0x2d2
|
|
irq_exit_rcu+0xb4/0xe0
|
|
common_interrupt+0xba/0xe0
|
|
</IRQ>
|
|
<TASK>
|
|
|
|
The crash is caused by privately transferring waitqueue entries from
|
|
smc socket->wq to clcsock->wq. The owners of these entries, such as
|
|
epoll, have no idea that the entries have been transferred to a
|
|
different socket wait queue and still use original waitqueue spinlock
|
|
(smc socket->wq.wait.lock) to make the entries operation exclusive,
|
|
but it doesn't work. The operations to the entries, such as removing
|
|
from the waitqueue (now is clcsock->wq after fallback), may cause a
|
|
crash when clcsock waitqueue is being iterated over at the moment.
|
|
|
|
This patch tries to fix this by no longer transferring wait queue
|
|
entries privately, but introducing own implementations of clcsock's
|
|
callback functions in fallback situation. The callback functions will
|
|
forward the wakeup to smc socket->wq if clcsock->wq is actually woken
|
|
up and smc socket->wq has remaining entries.(CVE-2022-48721)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ice: Do not use WQ_MEM_RECLAIM flag for workqueue
|
|
|
|
When both ice and the irdma driver are loaded, a warning in
|
|
check_flush_dependency is being triggered. This is due to ice driver
|
|
workqueue being allocated with the WQ_MEM_RECLAIM flag and the irdma one
|
|
is not.
|
|
|
|
According to kernel documentation, this flag should be set if the
|
|
workqueue will be involved in the kernel's memory reclamation flow.
|
|
Since it is not, there is no need for the ice driver's WQ to have this
|
|
flag set so remove it.
|
|
|
|
Example trace:
|
|
|
|
[ +0.000004] workqueue: WQ_MEM_RECLAIM ice:ice_service_task [ice] is flushing !WQ_MEM_RECLAIM infiniband:0x0
|
|
[ +0.000139] WARNING: CPU: 0 PID: 728 at kernel/workqueue.c:2632 check_flush_dependency+0x178/0x1a0
|
|
[ +0.000011] Modules linked in: bonding tls xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_cha
|
|
in_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink bridge stp llc rfkill vfat fat intel_rapl_msr intel
|
|
_rapl_common isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct1
|
|
0dif_pclmul crc32_pclmul ghash_clmulni_intel rapl intel_cstate rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_
|
|
core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_cm iw_cm iTCO_wdt iTCO_vendor_support ipmi_ssif irdma mei_me ib_uverbs
|
|
ib_core intel_uncore joydev pcspkr i2c_i801 acpi_ipmi mei lpc_ich i2c_smbus intel_pch_thermal ioatdma ipmi_si acpi_power_meter
|
|
acpi_pad xfs libcrc32c sd_mod t10_pi crc64_rocksoft crc64 sg ahci ixgbe libahci ice i40e igb crc32c_intel mdio i2c_algo_bit liba
|
|
ta dca wmi dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse
|
|
[ +0.000161] [last unloaded: bonding]
|
|
[ +0.000006] CPU: 0 PID: 728 Comm: kworker/0:2 Tainted: G S 6.2.0-rc2_next-queue-13jan-00458-gc20aabd57164 #1
|
|
[ +0.000006] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0010.010620200716 01/06/2020
|
|
[ +0.000003] Workqueue: ice ice_service_task [ice]
|
|
[ +0.000127] RIP: 0010:check_flush_dependency+0x178/0x1a0
|
|
[ +0.000005] Code: 89 8e 02 01 e8 49 3d 40 00 49 8b 55 18 48 8d 8d d0 00 00 00 48 8d b3 d0 00 00 00 4d 89 e0 48 c7 c7 e0 3b 08
|
|
9f e8 bb d3 07 01 <0f> 0b e9 be fe ff ff 80 3d 24 89 8e 02 00 0f 85 6b ff ff ff e9 06
|
|
[ +0.000004] RSP: 0018:ffff88810a39f990 EFLAGS: 00010282
|
|
[ +0.000005] RAX: 0000000000000000 RBX: ffff888141bc2400 RCX: 0000000000000000
|
|
[ +0.000004] RDX: 0000000000000001 RSI: dffffc0000000000 RDI: ffffffffa1213a80
|
|
[ +0.000003] RBP: ffff888194bf3400 R08: ffffed117b306112 R09: ffffed117b306112
|
|
[ +0.000003] R10: ffff888bd983088b R11: ffffed117b306111 R12: 0000000000000000
|
|
[ +0.000003] R13: ffff888111f84d00 R14: ffff88810a3943ac R15: ffff888194bf3400
|
|
[ +0.000004] FS: 0000000000000000(0000) GS:ffff888bd9800000(0000) knlGS:0000000000000000
|
|
[ +0.000003] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ +0.000003] CR2: 000056035b208b60 CR3: 000000017795e005 CR4: 00000000007706f0
|
|
[ +0.000003] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
[ +0.000003] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
[ +0.000002] PKRU: 55555554
|
|
[ +0.000003] Call Trace:
|
|
[ +0.000002] <TASK>
|
|
[ +0.000003] __flush_workqueue+0x203/0x840
|
|
[ +0.000006] ? mutex_unlock+0x84/0xd0
|
|
[ +0.000008] ? __pfx_mutex_unlock+0x10/0x10
|
|
[ +0.000004] ? __pfx___flush_workqueue+0x10/0x10
|
|
[ +0.000006] ? mutex_lock+0xa3/0xf0
|
|
[ +0.000005] ib_cache_cleanup_one+0x39/0x190 [ib_core]
|
|
[ +0.000174] __ib_unregister_device+0x84/0xf0 [ib_core]
|
|
[ +0.000094] ib_unregister_device+0x25/0x30 [ib_core]
|
|
[ +0.000093] irdma_ib_unregister_device+0x97/0xc0 [irdma]
|
|
[ +0.000064] ? __pfx_irdma_ib_unregister_device+0x10/0x10 [irdma]
|
|
[ +0.000059] ? up_write+0x5c/0x90
|
|
[ +0.000005] irdma_remove+0x36/0x90 [irdma]
|
|
[ +0.000062] auxiliary_bus_remove+0x32/0x50
|
|
[ +0.000007] device_r
|
|
---truncated---(CVE-2023-52743)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ksmbd: fix slab out of bounds write in smb_inherit_dacl()
|
|
|
|
slab out-of-bounds write is caused by that offsets is bigger than pntsd
|
|
allocation size. This patch add the check to validate 3 offsets using
|
|
allocation size.(CVE-2023-52755)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Bluetooth: btusb: Add date->evt_skb is NULL check
|
|
|
|
fix crash because of null pointers
|
|
|
|
[ 6104.969662] BUG: kernel NULL pointer dereference, address: 00000000000000c8
|
|
[ 6104.969667] #PF: supervisor read access in kernel mode
|
|
[ 6104.969668] #PF: error_code(0x0000) - not-present page
|
|
[ 6104.969670] PGD 0 P4D 0
|
|
[ 6104.969673] Oops: 0000 [#1] SMP NOPTI
|
|
[ 6104.969684] RIP: 0010:btusb_mtk_hci_wmt_sync+0x144/0x220 [btusb]
|
|
[ 6104.969688] RSP: 0018:ffffb8d681533d48 EFLAGS: 00010246
|
|
[ 6104.969689] RAX: 0000000000000000 RBX: ffff8ad560bb2000 RCX: 0000000000000006
|
|
[ 6104.969691] RDX: 0000000000000000 RSI: ffffb8d681533d08 RDI: 0000000000000000
|
|
[ 6104.969692] RBP: ffffb8d681533d70 R08: 0000000000000001 R09: 0000000000000001
|
|
[ 6104.969694] R10: 0000000000000001 R11: 00000000fa83b2da R12: ffff8ad461d1d7c0
|
|
[ 6104.969695] R13: 0000000000000000 R14: ffff8ad459618c18 R15: ffffb8d681533d90
|
|
[ 6104.969697] FS: 00007f5a1cab9d40(0000) GS:ffff8ad578200000(0000) knlGS:00000
|
|
[ 6104.969699] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 6104.969700] CR2: 00000000000000c8 CR3: 000000018620c001 CR4: 0000000000760ef0
|
|
[ 6104.969701] PKRU: 55555554
|
|
[ 6104.969702] Call Trace:
|
|
[ 6104.969708] btusb_mtk_shutdown+0x44/0x80 [btusb]
|
|
[ 6104.969732] hci_dev_do_close+0x470/0x5c0 [bluetooth]
|
|
[ 6104.969748] hci_rfkill_set_block+0x56/0xa0 [bluetooth]
|
|
[ 6104.969753] rfkill_set_block+0x92/0x160
|
|
[ 6104.969755] rfkill_fop_write+0x136/0x1e0
|
|
[ 6104.969759] __vfs_write+0x18/0x40
|
|
[ 6104.969761] vfs_write+0xdf/0x1c0
|
|
[ 6104.969763] ksys_write+0xb1/0xe0
|
|
[ 6104.969765] __x64_sys_write+0x1a/0x20
|
|
[ 6104.969769] do_syscall_64+0x51/0x180
|
|
[ 6104.969771] entry_SYSCALL_64_after_hwframe+0x44/0xa9
|
|
[ 6104.969773] RIP: 0033:0x7f5a21f18fef
|
|
[ 6104.9] RSP: 002b:00007ffeefe39010 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
|
|
[ 6104.969780] RAX: ffffffffffffffda RBX: 000055c10a7560a0 RCX: 00007f5a21f18fef
|
|
[ 6104.969781] RDX: 0000000000000008 RSI: 00007ffeefe39060 RDI: 0000000000000012
|
|
[ 6104.969782] RBP: 00007ffeefe39060 R08: 0000000000000000 R09: 0000000000000017
|
|
[ 6104.969784] R10: 00007ffeefe38d97 R11: 0000000000000293 R12: 0000000000000002
|
|
[ 6104.969785] R13: 00007ffeefe39220 R14: 00007ffeefe391a0 R15: 000055c10a72acf0(CVE-2023-52833)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
f2fs: compress: fix to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock
|
|
|
|
It needs to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock
|
|
to avoid racing with checkpoint, otherwise, filesystem metadata including
|
|
blkaddr in dnode, inode fields and .total_valid_block_count may be
|
|
corrupted after SPO case.(CVE-2024-34027)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
null_blk: fix null-ptr-dereference while configuring 'power' and 'submit_queues'
|
|
|
|
Writing 'power' and 'submit_queues' concurrently will trigger kernel
|
|
panic:
|
|
|
|
Test script:
|
|
|
|
modprobe null_blk nr_devices=0
|
|
mkdir -p /sys/kernel/config/nullb/nullb0
|
|
while true; do echo 1 > submit_queues; echo 4 > submit_queues; done &
|
|
while true; do echo 1 > power; echo 0 > power; done
|
|
|
|
Test result:
|
|
|
|
BUG: kernel NULL pointer dereference, address: 0000000000000148
|
|
Oops: 0000 [#1] PREEMPT SMP
|
|
RIP: 0010:__lock_acquire+0x41d/0x28f0
|
|
Call Trace:
|
|
<TASK>
|
|
lock_acquire+0x121/0x450
|
|
down_write+0x5f/0x1d0
|
|
simple_recursive_removal+0x12f/0x5c0
|
|
blk_mq_debugfs_unregister_hctxs+0x7c/0x100
|
|
blk_mq_update_nr_hw_queues+0x4a3/0x720
|
|
nullb_update_nr_hw_queues+0x71/0xf0 [null_blk]
|
|
nullb_device_submit_queues_store+0x79/0xf0 [null_blk]
|
|
configfs_write_iter+0x119/0x1e0
|
|
vfs_write+0x326/0x730
|
|
ksys_write+0x74/0x150
|
|
|
|
This is because del_gendisk() can concurrent with
|
|
blk_mq_update_nr_hw_queues():
|
|
|
|
nullb_device_power_store nullb_apply_submit_queues
|
|
null_del_dev
|
|
del_gendisk
|
|
nullb_update_nr_hw_queues
|
|
if (!dev->nullb)
|
|
// still set while gendisk is deleted
|
|
return 0
|
|
blk_mq_update_nr_hw_queues
|
|
dev->nullb = NULL
|
|
|
|
Fix this problem by resuing the global mutex to protect
|
|
nullb_device_power_store() and nullb_update_nr_hw_queues() from configfs.(CVE-2024-36478)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
bnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq
|
|
|
|
Undefined behavior is triggered when bnxt_qplib_alloc_init_hwq is called
|
|
with hwq_attr->aux_depth != 0 and hwq_attr->aux_stride == 0.
|
|
In that case, "roundup_pow_of_two(hwq_attr->aux_stride)" gets called.
|
|
roundup_pow_of_two is documented as undefined for 0.
|
|
|
|
Fix it in the one caller that had this combination.
|
|
|
|
The undefined behavior was detected by UBSAN:
|
|
UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13
|
|
shift exponent 64 is too large for 64-bit type 'long unsigned int'
|
|
CPU: 24 PID: 1075 Comm: (udev-worker) Not tainted 6.9.0-rc6+ #4
|
|
Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.7 10/25/2023
|
|
Call Trace:
|
|
<TASK>
|
|
dump_stack_lvl+0x5d/0x80
|
|
ubsan_epilogue+0x5/0x30
|
|
__ubsan_handle_shift_out_of_bounds.cold+0x61/0xec
|
|
__roundup_pow_of_two+0x25/0x35 [bnxt_re]
|
|
bnxt_qplib_alloc_init_hwq+0xa1/0x470 [bnxt_re]
|
|
bnxt_qplib_create_qp+0x19e/0x840 [bnxt_re]
|
|
bnxt_re_create_qp+0x9b1/0xcd0 [bnxt_re]
|
|
? srso_alias_return_thunk+0x5/0xfbef5
|
|
? srso_alias_return_thunk+0x5/0xfbef5
|
|
? __kmalloc+0x1b6/0x4f0
|
|
? create_qp.part.0+0x128/0x1c0 [ib_core]
|
|
? __pfx_bnxt_re_create_qp+0x10/0x10 [bnxt_re]
|
|
create_qp.part.0+0x128/0x1c0 [ib_core]
|
|
ib_create_qp_kernel+0x50/0xd0 [ib_core]
|
|
create_mad_qp+0x8e/0xe0 [ib_core]
|
|
? __pfx_qp_event_handler+0x10/0x10 [ib_core]
|
|
ib_mad_init_device+0x2be/0x680 [ib_core]
|
|
add_client_context+0x10d/0x1a0 [ib_core]
|
|
enable_device_and_get+0xe0/0x1d0 [ib_core]
|
|
ib_register_device+0x53c/0x630 [ib_core]
|
|
? srso_alias_return_thunk+0x5/0xfbef5
|
|
bnxt_re_probe+0xbd8/0xe50 [bnxt_re]
|
|
? __pfx_bnxt_re_probe+0x10/0x10 [bnxt_re]
|
|
auxiliary_bus_probe+0x49/0x80
|
|
? driver_sysfs_add+0x57/0xc0
|
|
really_probe+0xde/0x340
|
|
? pm_runtime_barrier+0x54/0x90
|
|
? __pfx___driver_attach+0x10/0x10
|
|
__driver_probe_device+0x78/0x110
|
|
driver_probe_device+0x1f/0xa0
|
|
__driver_attach+0xba/0x1c0
|
|
bus_for_each_dev+0x8f/0xe0
|
|
bus_add_driver+0x146/0x220
|
|
driver_register+0x72/0xd0
|
|
__auxiliary_driver_register+0x6e/0xd0
|
|
? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re]
|
|
bnxt_re_mod_init+0x3e/0xff0 [bnxt_re]
|
|
? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re]
|
|
do_one_initcall+0x5b/0x310
|
|
do_init_module+0x90/0x250
|
|
init_module_from_file+0x86/0xc0
|
|
idempotent_init_module+0x121/0x2b0
|
|
__x64_sys_finit_module+0x5e/0xb0
|
|
do_syscall_64+0x82/0x160
|
|
? srso_alias_return_thunk+0x5/0xfbef5
|
|
? syscall_exit_to_user_mode_prepare+0x149/0x170
|
|
? srso_alias_return_thunk+0x5/0xfbef5
|
|
? syscall_exit_to_user_mode+0x75/0x230
|
|
? srso_alias_return_thunk+0x5/0xfbef5
|
|
? do_syscall_64+0x8e/0x160
|
|
? srso_alias_return_thunk+0x5/0xfbef5
|
|
? __count_memcg_events+0x69/0x100
|
|
? srso_alias_return_thunk+0x5/0xfbef5
|
|
? count_memcg_events.constprop.0+0x1a/0x30
|
|
? srso_alias_return_thunk+0x5/0xfbef5
|
|
? handle_mm_fault+0x1f0/0x300
|
|
? srso_alias_return_thunk+0x5/0xfbef5
|
|
? do_user_addr_fault+0x34e/0x640
|
|
? srso_alias_return_thunk+0x5/0xfbef5
|
|
? srso_alias_return_thunk+0x5/0xfbef5
|
|
entry_SYSCALL_64_after_hwframe+0x76/0x7e
|
|
RIP: 0033:0x7f4e5132821d
|
|
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e3 db 0c 00 f7 d8 64 89 01 48
|
|
RSP: 002b:00007ffca9c906a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
|
|
RAX: ffffffffffffffda RBX: 0000563ec8a8f130 RCX: 00007f4e5132821d
|
|
RDX: 0000000000000000 RSI: 00007f4e518fa07d RDI: 000000000000003b
|
|
RBP: 00007ffca9c90760 R08: 00007f4e513f6b20 R09: 00007ffca9c906f0
|
|
R10: 0000563ec8a8faa0 R11: 0000000000000246 R12: 00007f4e518fa07d
|
|
R13: 0000000000020000 R14: 0000563ec8409e90 R15: 0000563ec8a8fa60
|
|
</TASK>
|
|
---[ end trace ]---(CVE-2024-38540)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: openvswitch: fix overwriting ct original tuple for ICMPv6
|
|
|
|
OVS_PACKET_CMD_EXECUTE has 3 main attributes:
|
|
- OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format.
|
|
- OVS_PACKET_ATTR_PACKET - Binary packet content.
|
|
- OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet.
|
|
|
|
OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure
|
|
with the metadata like conntrack state, input port, recirculation id,
|
|
etc. Then the packet itself gets parsed to populate the rest of the
|
|
keys from the packet headers.
|
|
|
|
Whenever the packet parsing code starts parsing the ICMPv6 header, it
|
|
first zeroes out fields in the key corresponding to Neighbor Discovery
|
|
information even if it is not an ND packet.
|
|
|
|
It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares
|
|
the space between 'nd' and 'ct_orig' that holds the original tuple
|
|
conntrack metadata parsed from the OVS_PACKET_ATTR_KEY.
|
|
|
|
ND packets should not normally have conntrack state, so it's fine to
|
|
share the space, but normal ICMPv6 Echo packets or maybe other types of
|
|
ICMPv6 can have the state attached and it should not be overwritten.
|
|
|
|
The issue results in all but the last 4 bytes of the destination
|
|
address being wiped from the original conntrack tuple leading to
|
|
incorrect packet matching and potentially executing wrong actions
|
|
in case this packet recirculates within the datapath or goes back
|
|
to userspace.
|
|
|
|
ND fields should not be accessed in non-ND packets, so not clearing
|
|
them should be fine. Executing memset() only for actual ND packets to
|
|
avoid the issue.
|
|
|
|
Initializing the whole thing before parsing is needed because ND packet
|
|
may not contain all the options.
|
|
|
|
The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn't
|
|
affect packets entering OVS datapath from network interfaces, because
|
|
in this case CT metadata is populated from skb after the packet is
|
|
already parsed.(CVE-2024-38558)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
gfs2: Fix potential glock use-after-free on unmount
|
|
|
|
When a DLM lockspace is released and there ares still locks in that
|
|
lockspace, DLM will unlock those locks automatically. Commit
|
|
fb6791d100d1b started exploiting this behavior to speed up filesystem
|
|
unmount: gfs2 would simply free glocks it didn't want to unlock and then
|
|
release the lockspace. This didn't take the bast callbacks for
|
|
asynchronous lock contention notifications into account, which remain
|
|
active until until a lock is unlocked or its lockspace is released.
|
|
|
|
To prevent those callbacks from accessing deallocated objects, put the
|
|
glocks that should not be unlocked on the sd_dead_glocks list, release
|
|
the lockspace, and only then free those glocks.
|
|
|
|
As an additional measure, ignore unexpected ast and bast callbacks if
|
|
the receiving glock is dead.(CVE-2024-38570)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
r8169: Fix possible ring buffer corruption on fragmented Tx packets.
|
|
|
|
An issue was found on the RTL8125b when transmitting small fragmented
|
|
packets, whereby invalid entries were inserted into the transmit ring
|
|
buffer, subsequently leading to calls to dma_unmap_single() with a null
|
|
address.
|
|
|
|
This was caused by rtl8169_start_xmit() not noticing changes to nr_frags
|
|
which may occur when small packets are padded (to work around hardware
|
|
quirks) in rtl8169_tso_csum_v2().
|
|
|
|
To fix this, postpone inspecting nr_frags until after any padding has been
|
|
applied.(CVE-2024-38586)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
md: fix resync softlockup when bitmap size is less than array size
|
|
|
|
Is is reported that for dm-raid10, lvextend + lvchange --syncaction will
|
|
trigger following softlockup:
|
|
|
|
kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976]
|
|
CPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1
|
|
RIP: 0010:_raw_spin_unlock_irq+0x13/0x30
|
|
Call Trace:
|
|
<TASK>
|
|
md_bitmap_start_sync+0x6b/0xf0
|
|
raid10_sync_request+0x25c/0x1b40 [raid10]
|
|
md_do_sync+0x64b/0x1020
|
|
md_thread+0xa7/0x170
|
|
kthread+0xcf/0x100
|
|
ret_from_fork+0x30/0x50
|
|
ret_from_fork_asm+0x1a/0x30
|
|
|
|
And the detailed process is as follows:
|
|
|
|
md_do_sync
|
|
j = mddev->resync_min
|
|
while (j < max_sectors)
|
|
sectors = raid10_sync_request(mddev, j, &skipped)
|
|
if (!md_bitmap_start_sync(..., &sync_blocks))
|
|
// md_bitmap_start_sync set sync_blocks to 0
|
|
return sync_blocks + sectors_skippe;
|
|
// sectors = 0;
|
|
j += sectors;
|
|
// j never change
|
|
|
|
Root cause is that commit 301867b1c168 ("md/raid10: check
|
|
slab-out-of-bounds in md_bitmap_get_counter") return early from
|
|
md_bitmap_get_counter(), without setting returned blocks.
|
|
|
|
Fix this problem by always set returned blocks from
|
|
md_bitmap_get_counter"(), as it used to be.
|
|
|
|
Noted that this patch just fix the softlockup problem in kernel, the
|
|
case that bitmap size doesn't match array size still need to be fixed.(CVE-2024-38598)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ALSA: core: Fix NULL module pointer assignment at card init
|
|
|
|
The commit 81033c6b584b ("ALSA: core: Warn on empty module")
|
|
introduced a WARN_ON() for a NULL module pointer passed at snd_card
|
|
object creation, and it also wraps the code around it with '#ifdef
|
|
MODULE'. This works in most cases, but the devils are always in
|
|
details. "MODULE" is defined when the target code (i.e. the sound
|
|
core) is built as a module; but this doesn't mean that the caller is
|
|
also built-in or not. Namely, when only the sound core is built-in
|
|
(CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m),
|
|
the passed module pointer is ignored even if it's non-NULL, and
|
|
card->module remains as NULL. This would result in the missing module
|
|
reference up/down at the device open/close, leading to a race with the
|
|
code execution after the module removal.
|
|
|
|
For addressing the bug, move the assignment of card->module again out
|
|
of ifdef. The WARN_ON() is still wrapped with ifdef because the
|
|
module can be really NULL when all sound drivers are built-in.
|
|
|
|
Note that we keep 'ifdef MODULE' for WARN_ON(), otherwise it would
|
|
lead to a false-positive NULL module check. Admittedly it won't catch
|
|
perfectly, i.e. no check is performed when CONFIG_SND=y. But, it's no
|
|
real problem as it's only for debugging, and the condition is pretty
|
|
rare.(CVE-2024-38605)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
cpufreq: exit() callback is optional
|
|
|
|
The exit() callback is optional and shouldn't be called without checking
|
|
a valid pointer first.
|
|
|
|
Also, we must clear freq_table pointer even if the exit() callback isn't
|
|
present.(CVE-2024-38615)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
vfio/pci: fix potential memory leak in vfio_intx_enable()
|
|
|
|
If vfio_irq_ctx_alloc() failed will lead to 'name' memory leak.(CVE-2024-38632)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
kdb: Fix buffer overflow during tab-complete
|
|
|
|
Currently, when the user attempts symbol completion with the Tab key, kdb
|
|
will use strncpy() to insert the completed symbol into the command buffer.
|
|
Unfortunately it passes the size of the source buffer rather than the
|
|
destination to strncpy() with predictably horrible results. Most obviously
|
|
if the command buffer is already full but cp, the cursor position, is in
|
|
the middle of the buffer, then we will write past the end of the supplied
|
|
buffer.
|
|
|
|
Fix this by replacing the dubious strncpy() calls with memmove()/memcpy()
|
|
calls plus explicit boundary checks to make sure we have enough space
|
|
before we start moving characters around.(CVE-2024-39480)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()
|
|
|
|
In function bond_option_arp_ip_targets_set(), if newval->string is an
|
|
empty string, newval->string+1 will point to the byte after the
|
|
string, causing an out-of-bound read.
|
|
|
|
BUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418
|
|
Read of size 1 at addr ffff8881119c4781 by task syz-executor665/8107
|
|
CPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
|
|
print_address_description mm/kasan/report.c:364 [inline]
|
|
print_report+0xc1/0x5e0 mm/kasan/report.c:475
|
|
kasan_report+0xbe/0xf0 mm/kasan/report.c:588
|
|
strlen+0x7d/0xa0 lib/string.c:418
|
|
__fortify_strlen include/linux/fortify-string.h:210 [inline]
|
|
in4_pton+0xa3/0x3f0 net/core/utils.c:130
|
|
bond_option_arp_ip_targets_set+0xc2/0x910
|
|
drivers/net/bonding/bond_options.c:1201
|
|
__bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767
|
|
__bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792
|
|
bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817
|
|
bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156
|
|
dev_attr_store+0x54/0x80 drivers/base/core.c:2366
|
|
sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136
|
|
kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334
|
|
call_write_iter include/linux/fs.h:2020 [inline]
|
|
new_sync_write fs/read_write.c:491 [inline]
|
|
vfs_write+0x96a/0xd80 fs/read_write.c:584
|
|
ksys_write+0x122/0x250 fs/read_write.c:637
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b
|
|
---[ end trace ]---
|
|
|
|
Fix it by adding a check of string length before using it.(CVE-2024-39487)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY
|
|
|
|
When CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes
|
|
to bug_table entries, and as a result the last entry in a bug table will
|
|
be ignored, potentially leading to an unexpected panic(). All prior
|
|
entries in the table will be handled correctly.
|
|
|
|
The arm64 ABI requires that struct fields of up to 8 bytes are
|
|
naturally-aligned, with padding added within a struct such that struct
|
|
are suitably aligned within arrays.
|
|
|
|
When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is:
|
|
|
|
struct bug_entry {
|
|
signed int bug_addr_disp; // 4 bytes
|
|
signed int file_disp; // 4 bytes
|
|
unsigned short line; // 2 bytes
|
|
unsigned short flags; // 2 bytes
|
|
}
|
|
|
|
... with 12 bytes total, requiring 4-byte alignment.
|
|
|
|
When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is:
|
|
|
|
struct bug_entry {
|
|
signed int bug_addr_disp; // 4 bytes
|
|
unsigned short flags; // 2 bytes
|
|
< implicit padding > // 2 bytes
|
|
}
|
|
|
|
... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing
|
|
padding, requiring 4-byte alginment.
|
|
|
|
When we create a bug_entry in assembly, we align the start of the entry
|
|
to 4 bytes, which implicitly handles padding for any prior entries.
|
|
However, we do not align the end of the entry, and so when
|
|
CONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding
|
|
bytes.
|
|
|
|
For the main kernel image this is not a problem as find_bug() doesn't
|
|
depend on the trailing padding bytes when searching for entries:
|
|
|
|
for (bug = __start___bug_table; bug < __stop___bug_table; ++bug)
|
|
if (bugaddr == bug_addr(bug))
|
|
return bug;
|
|
|
|
However for modules, module_bug_finalize() depends on the trailing
|
|
bytes when calculating the number of entries:
|
|
|
|
mod->num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry);
|
|
|
|
... and as the last bug_entry lacks the necessary padding bytes, this entry
|
|
will not be counted, e.g. in the case of a single entry:
|
|
|
|
sechdrs[i].sh_size == 6
|
|
sizeof(struct bug_entry) == 8;
|
|
|
|
sechdrs[i].sh_size / sizeof(struct bug_entry) == 0;
|
|
|
|
Consequently module_find_bug() will miss the last bug_entry when it does:
|
|
|
|
for (i = 0; i < mod->num_bugs; ++i, ++bug)
|
|
if (bugaddr == bug_addr(bug))
|
|
goto out;
|
|
|
|
... which can lead to a kenrel panic due to an unhandled bug.
|
|
|
|
This can be demonstrated with the following module:
|
|
|
|
static int __init buginit(void)
|
|
{
|
|
WARN(1, "hello\n");
|
|
return 0;
|
|
}
|
|
|
|
static void __exit bugexit(void)
|
|
{
|
|
}
|
|
|
|
module_init(buginit);
|
|
module_exit(bugexit);
|
|
MODULE_LICENSE("GPL");
|
|
|
|
... which will trigger a kernel panic when loaded:
|
|
|
|
------------[ cut here ]------------
|
|
hello
|
|
Unexpected kernel BRK exception at EL1
|
|
Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP
|
|
Modules linked in: hello(O+)
|
|
CPU: 0 PID: 50 Comm: insmod Tainted: G O 6.9.1 #8
|
|
Hardware name: linux,dummy-virt (DT)
|
|
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
|
pc : buginit+0x18/0x1000 [hello]
|
|
lr : buginit+0x18/0x1000 [hello]
|
|
sp : ffff800080533ae0
|
|
x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000
|
|
x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58
|
|
x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0
|
|
x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006
|
|
x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720
|
|
x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312
|
|
x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8
|
|
x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000
|
|
x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000
|
|
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0
|
|
Call trace:
|
|
buginit+0x18/0x1000 [hello]
|
|
do_one_initcall+0x80/0x1c8
|
|
do_init_module+0x60/0x218
|
|
load_module+0x1ba4/0x1d70
|
|
__do_sys_init_module+0x198/0x1d0
|
|
__arm64_sys_init_module+0x1c/0x28
|
|
invoke_syscall+0x48/0x114
|
|
el0_svc
|
|
---truncated---(CVE-2024-39488)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ipv6: sr: fix memleak in seg6_hmac_init_algo
|
|
|
|
seg6_hmac_init_algo returns without cleaning up the previous allocations
|
|
if one fails, so it's going to leak all that memory and the crypto tfms.
|
|
|
|
Update seg6_hmac_exit to only free the memory when allocated, so we can
|
|
reuse the code directly.(CVE-2024-39489)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
sock_map: avoid race between sock_map_close and sk_psock_put
|
|
|
|
sk_psock_get will return NULL if the refcount of psock has gone to 0, which
|
|
will happen when the last call of sk_psock_put is done. However,
|
|
sk_psock_drop may not have finished yet, so the close callback will still
|
|
point to sock_map_close despite psock being NULL.
|
|
|
|
This can be reproduced with a thread deleting an element from the sock map,
|
|
while the second one creates a socket, adds it to the map and closes it.
|
|
|
|
That will trigger the WARN_ON_ONCE:
|
|
|
|
------------[ cut here ]------------
|
|
WARNING: CPU: 1 PID: 7220 at net/core/sock_map.c:1701 sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701
|
|
Modules linked in:
|
|
CPU: 1 PID: 7220 Comm: syz-executor380 Not tainted 6.9.0-syzkaller-07726-g3c999d1ae3c7 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
|
|
RIP: 0010:sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701
|
|
Code: df e8 92 29 88 f8 48 8b 1b 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 79 29 88 f8 4c 8b 23 eb 89 e8 4f 15 23 f8 90 <0f> 0b 90 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 13 26 3d 02
|
|
RSP: 0018:ffffc9000441fda8 EFLAGS: 00010293
|
|
RAX: ffffffff89731ae1 RBX: ffffffff94b87540 RCX: ffff888029470000
|
|
RDX: 0000000000000000 RSI: ffffffff8bcab5c0 RDI: ffffffff8c1faba0
|
|
RBP: 0000000000000000 R08: ffffffff92f9b61f R09: 1ffffffff25f36c3
|
|
R10: dffffc0000000000 R11: fffffbfff25f36c4 R12: ffffffff89731840
|
|
R13: ffff88804b587000 R14: ffff88804b587000 R15: ffffffff89731870
|
|
FS: 000055555e080380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000000000000000 CR3: 00000000207d4000 CR4: 0000000000350ef0
|
|
Call Trace:
|
|
<TASK>
|
|
unix_release+0x87/0xc0 net/unix/af_unix.c:1048
|
|
__sock_release net/socket.c:659 [inline]
|
|
sock_close+0xbe/0x240 net/socket.c:1421
|
|
__fput+0x42b/0x8a0 fs/file_table.c:422
|
|
__do_sys_close fs/open.c:1556 [inline]
|
|
__se_sys_close fs/open.c:1541 [inline]
|
|
__x64_sys_close+0x7f/0x110 fs/open.c:1541
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
|
RIP: 0033:0x7fb37d618070
|
|
Code: 00 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d4 e8 10 2c 00 00 80 3d 31 f0 07 00 00 74 17 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 48 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 7c
|
|
RSP: 002b:00007ffcd4a525d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000003
|
|
RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fb37d618070
|
|
RDX: 0000000000000010 RSI: 00000000200001c0 RDI: 0000000000000004
|
|
RBP: 0000000000000000 R08: 0000000100000000 R09: 0000000100000000
|
|
R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000
|
|
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
|
|
</TASK>
|
|
|
|
Use sk_psock, which will only check that the pointer is not been set to
|
|
NULL yet, which should only happen after the callbacks are restored. If,
|
|
then, a reference can still be gotten, we may call sk_psock_stop and cancel
|
|
psock->work.
|
|
|
|
As suggested by Paolo Abeni, reorder the condition so the control flow is
|
|
less convoluted.
|
|
|
|
After that change, the reproducer does not trigger the WARN_ON_ONCE
|
|
anymore.(CVE-2024-39500)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mptcp: ensure snd_una is properly initialized on connect
|
|
|
|
This is strictly related to commit fb7a0d334894 ("mptcp: ensure snd_nxt
|
|
is properly initialized on connect"). It turns out that syzkaller can
|
|
trigger the retransmit after fallback and before processing any other
|
|
incoming packet - so that snd_una is still left uninitialized.
|
|
|
|
Address the issue explicitly initializing snd_una together with snd_nxt
|
|
and write_seq.(CVE-2024-40931)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
f2fs: remove clear SB_INLINECRYPT flag in default_options
|
|
|
|
In f2fs_remount, SB_INLINECRYPT flag will be clear and re-set.
|
|
If create new file or open file during this gap, these files
|
|
will not use inlinecrypt. Worse case, it may lead to data
|
|
corruption if wrappedkey_v0 is enable.
|
|
|
|
Thread A: Thread B:
|
|
|
|
-f2fs_remount -f2fs_file_open or f2fs_new_inode
|
|
-default_options
|
|
<- clear SB_INLINECRYPT flag
|
|
|
|
-fscrypt_select_encryption_impl
|
|
|
|
-parse_options
|
|
<- set SB_INLINECRYPT again(CVE-2024-40971)</Note>
|
|
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-22.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/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1860</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2021-47391</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48721</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-52743</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-52755</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-52833</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-34027</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-36478</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38540</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38558</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38570</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38586</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38598</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38605</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38615</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38632</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39480</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39487</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39488</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39489</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39500</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40931</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40971</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47391</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48721</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52743</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52755</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52833</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-34027</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36478</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38540</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38558</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38570</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38586</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38598</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38605</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38615</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38632</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39480</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39487</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39488</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39489</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39500</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40931</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40971</URL>
|
|
</Reference>
|
|
</DocumentReferences>
|
|
<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
|
|
<Branch Type="Product Name" Name="openEuler">
|
|
<FullProductName ProductID="openEuler-22.03-LTS-SP1" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">openEuler-22.03-LTS-SP1</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="kernel-5.10.0-136.85.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-136.85.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debuginfo-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-136.85.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debugsource-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-136.85.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-devel-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-136.85.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-headers-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-136.85.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-source-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-136.85.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-136.85.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-debuginfo-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-136.85.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-devel-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-136.85.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-136.85.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-debuginfo-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-136.85.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-136.85.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-debuginfo-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-5.10.0-136.85.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-5.10.0-136.85.0.166.oe2203sp1.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="kernel-5.10.0-136.85.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-136.85.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debuginfo-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-136.85.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debugsource-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-136.85.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-devel-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-136.85.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-headers-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-136.85.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-source-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-136.85.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-136.85.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-debuginfo-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-136.85.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-devel-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-136.85.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-136.85.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-debuginfo-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-136.85.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-136.85.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-debuginfo-5.10.0-136.85.0.166.oe2203sp1.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:
|
|
|
|
RDMA/cma: Ensure rdma_addr_cancel() happens before issuing more requests
|
|
|
|
The FSM can run in a circle allowing rdma_resolve_ip() to be called twice
|
|
on the same id_priv. While this cannot happen without going through the
|
|
work, it violates the invariant that the same address resolution
|
|
background request cannot be active twice.
|
|
|
|
CPU 1 CPU 2
|
|
|
|
rdma_resolve_addr():
|
|
RDMA_CM_IDLE -> RDMA_CM_ADDR_QUERY
|
|
rdma_resolve_ip(addr_handler) #1
|
|
|
|
process_one_req(): for #1
|
|
addr_handler():
|
|
RDMA_CM_ADDR_QUERY -> RDMA_CM_ADDR_BOUND
|
|
mutex_unlock(&id_priv->handler_mutex);
|
|
[.. handler still running ..]
|
|
|
|
rdma_resolve_addr():
|
|
RDMA_CM_ADDR_BOUND -> RDMA_CM_ADDR_QUERY
|
|
rdma_resolve_ip(addr_handler)
|
|
!! two requests are now on the req_list
|
|
|
|
rdma_destroy_id():
|
|
destroy_id_handler_unlock():
|
|
_destroy_id():
|
|
cma_cancel_operation():
|
|
rdma_addr_cancel()
|
|
|
|
// process_one_req() self removes it
|
|
spin_lock_bh(&lock);
|
|
cancel_delayed_work(&req->work);
|
|
if (!list_empty(&req->list)) == true
|
|
|
|
! rdma_addr_cancel() returns after process_on_req #1 is done
|
|
|
|
kfree(id_priv)
|
|
|
|
process_one_req(): for #2
|
|
addr_handler():
|
|
mutex_lock(&id_priv->handler_mutex);
|
|
!! Use after free on id_priv
|
|
|
|
rdma_addr_cancel() expects there to be one req on the list and only
|
|
cancels the first one. The self-removal behavior of the work only happens
|
|
after the handler has returned. This yields a situations where the
|
|
req_list can have two reqs for the same "handle" but rdma_addr_cancel()
|
|
only cancels the first one.
|
|
|
|
The second req remains active beyond rdma_destroy_id() and will
|
|
use-after-free id_priv once it inevitably triggers.
|
|
|
|
Fix this by remembering if the id_priv has called rdma_resolve_ip() and
|
|
always cancel before calling it again. This ensures the req_list never
|
|
gets more than one item in it and doesn't cost anything in the normal flow
|
|
that never uses this strange error path.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2021-47391</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.9</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/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-07-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1860</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/smc: Forward wakeup to smc socket waitqueue after fallback
|
|
|
|
When we replace TCP with SMC and a fallback occurs, there may be
|
|
some socket waitqueue entries remaining in smc socket->wq, such
|
|
as eppoll_entries inserted by userspace applications.
|
|
|
|
After the fallback, data flows over TCP/IP and only clcsocket->wq
|
|
will be woken up. Applications can't be notified by the entries
|
|
which were inserted in smc socket->wq before fallback. So we need
|
|
a mechanism to wake up smc socket->wq at the same time if some
|
|
entries remaining in it.
|
|
|
|
The current workaround is to transfer the entries from smc socket->wq
|
|
to clcsock->wq during the fallback. But this may cause a crash
|
|
like this:
|
|
|
|
general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#1] PREEMPT SMP PTI
|
|
CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Tainted: G E 5.16.0+ #107
|
|
RIP: 0010:__wake_up_common+0x65/0x170
|
|
Call Trace:
|
|
<IRQ>
|
|
__wake_up_common_lock+0x7a/0xc0
|
|
sock_def_readable+0x3c/0x70
|
|
tcp_data_queue+0x4a7/0xc40
|
|
tcp_rcv_established+0x32f/0x660
|
|
? sk_filter_trim_cap+0xcb/0x2e0
|
|
tcp_v4_do_rcv+0x10b/0x260
|
|
tcp_v4_rcv+0xd2a/0xde0
|
|
ip_protocol_deliver_rcu+0x3b/0x1d0
|
|
ip_local_deliver_finish+0x54/0x60
|
|
ip_local_deliver+0x6a/0x110
|
|
? tcp_v4_early_demux+0xa2/0x140
|
|
? tcp_v4_early_demux+0x10d/0x140
|
|
ip_sublist_rcv_finish+0x49/0x60
|
|
ip_sublist_rcv+0x19d/0x230
|
|
ip_list_rcv+0x13e/0x170
|
|
__netif_receive_skb_list_core+0x1c2/0x240
|
|
netif_receive_skb_list_internal+0x1e6/0x320
|
|
napi_complete_done+0x11d/0x190
|
|
mlx5e_napi_poll+0x163/0x6b0 [mlx5_core]
|
|
__napi_poll+0x3c/0x1b0
|
|
net_rx_action+0x27c/0x300
|
|
__do_softirq+0x114/0x2d2
|
|
irq_exit_rcu+0xb4/0xe0
|
|
common_interrupt+0xba/0xe0
|
|
</IRQ>
|
|
<TASK>
|
|
|
|
The crash is caused by privately transferring waitqueue entries from
|
|
smc socket->wq to clcsock->wq. The owners of these entries, such as
|
|
epoll, have no idea that the entries have been transferred to a
|
|
different socket wait queue and still use original waitqueue spinlock
|
|
(smc socket->wq.wait.lock) to make the entries operation exclusive,
|
|
but it doesn't work. The operations to the entries, such as removing
|
|
from the waitqueue (now is clcsock->wq after fallback), may cause a
|
|
crash when clcsock waitqueue is being iterated over at the moment.
|
|
|
|
This patch tries to fix this by no longer transferring wait queue
|
|
entries privately, but introducing own implementations of clcsock's
|
|
callback functions in fallback situation. The callback functions will
|
|
forward the wakeup to smc socket->wq if clcsock->wq is actually woken
|
|
up and smc socket->wq has remaining entries.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2022-48721</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-07-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1860</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ice: Do not use WQ_MEM_RECLAIM flag for workqueue
|
|
|
|
When both ice and the irdma driver are loaded, a warning in
|
|
check_flush_dependency is being triggered. This is due to ice driver
|
|
workqueue being allocated with the WQ_MEM_RECLAIM flag and the irdma one
|
|
is not.
|
|
|
|
According to kernel documentation, this flag should be set if the
|
|
workqueue will be involved in the kernel's memory reclamation flow.
|
|
Since it is not, there is no need for the ice driver's WQ to have this
|
|
flag set so remove it.
|
|
|
|
Example trace:
|
|
|
|
[ +0.000004] workqueue: WQ_MEM_RECLAIM ice:ice_service_task [ice] is flushing !WQ_MEM_RECLAIM infiniband:0x0
|
|
[ +0.000139] WARNING: CPU: 0 PID: 728 at kernel/workqueue.c:2632 check_flush_dependency+0x178/0x1a0
|
|
[ +0.000011] Modules linked in: bonding tls xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_cha
|
|
in_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink bridge stp llc rfkill vfat fat intel_rapl_msr intel
|
|
_rapl_common isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct1
|
|
0dif_pclmul crc32_pclmul ghash_clmulni_intel rapl intel_cstate rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_
|
|
core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_cm iw_cm iTCO_wdt iTCO_vendor_support ipmi_ssif irdma mei_me ib_uverbs
|
|
ib_core intel_uncore joydev pcspkr i2c_i801 acpi_ipmi mei lpc_ich i2c_smbus intel_pch_thermal ioatdma ipmi_si acpi_power_meter
|
|
acpi_pad xfs libcrc32c sd_mod t10_pi crc64_rocksoft crc64 sg ahci ixgbe libahci ice i40e igb crc32c_intel mdio i2c_algo_bit liba
|
|
ta dca wmi dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse
|
|
[ +0.000161] [last unloaded: bonding]
|
|
[ +0.000006] CPU: 0 PID: 728 Comm: kworker/0:2 Tainted: G S 6.2.0-rc2_next-queue-13jan-00458-gc20aabd57164 #1
|
|
[ +0.000006] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0010.010620200716 01/06/2020
|
|
[ +0.000003] Workqueue: ice ice_service_task [ice]
|
|
[ +0.000127] RIP: 0010:check_flush_dependency+0x178/0x1a0
|
|
[ +0.000005] Code: 89 8e 02 01 e8 49 3d 40 00 49 8b 55 18 48 8d 8d d0 00 00 00 48 8d b3 d0 00 00 00 4d 89 e0 48 c7 c7 e0 3b 08
|
|
9f e8 bb d3 07 01 <0f> 0b e9 be fe ff ff 80 3d 24 89 8e 02 00 0f 85 6b ff ff ff e9 06
|
|
[ +0.000004] RSP: 0018:ffff88810a39f990 EFLAGS: 00010282
|
|
[ +0.000005] RAX: 0000000000000000 RBX: ffff888141bc2400 RCX: 0000000000000000
|
|
[ +0.000004] RDX: 0000000000000001 RSI: dffffc0000000000 RDI: ffffffffa1213a80
|
|
[ +0.000003] RBP: ffff888194bf3400 R08: ffffed117b306112 R09: ffffed117b306112
|
|
[ +0.000003] R10: ffff888bd983088b R11: ffffed117b306111 R12: 0000000000000000
|
|
[ +0.000003] R13: ffff888111f84d00 R14: ffff88810a3943ac R15: ffff888194bf3400
|
|
[ +0.000004] FS: 0000000000000000(0000) GS:ffff888bd9800000(0000) knlGS:0000000000000000
|
|
[ +0.000003] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ +0.000003] CR2: 000056035b208b60 CR3: 000000017795e005 CR4: 00000000007706f0
|
|
[ +0.000003] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
[ +0.000003] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
[ +0.000002] PKRU: 55555554
|
|
[ +0.000003] Call Trace:
|
|
[ +0.000002] <TASK>
|
|
[ +0.000003] __flush_workqueue+0x203/0x840
|
|
[ +0.000006] ? mutex_unlock+0x84/0xd0
|
|
[ +0.000008] ? __pfx_mutex_unlock+0x10/0x10
|
|
[ +0.000004] ? __pfx___flush_workqueue+0x10/0x10
|
|
[ +0.000006] ? mutex_lock+0xa3/0xf0
|
|
[ +0.000005] ib_cache_cleanup_one+0x39/0x190 [ib_core]
|
|
[ +0.000174] __ib_unregister_device+0x84/0xf0 [ib_core]
|
|
[ +0.000094] ib_unregister_device+0x25/0x30 [ib_core]
|
|
[ +0.000093] irdma_ib_unregister_device+0x97/0xc0 [irdma]
|
|
[ +0.000064] ? __pfx_irdma_ib_unregister_device+0x10/0x10 [irdma]
|
|
[ +0.000059] ? up_write+0x5c/0x90
|
|
[ +0.000005] irdma_remove+0x36/0x90 [irdma]
|
|
[ +0.000062] auxiliary_bus_remove+0x32/0x50
|
|
[ +0.000007] device_r
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2023-52743</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.0</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1860</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ksmbd: fix slab out of bounds write in smb_inherit_dacl()
|
|
|
|
slab out-of-bounds write is caused by that offsets is bigger than pntsd
|
|
allocation size. This patch add the check to validate 3 offsets using
|
|
allocation size.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2023-52755</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.8</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1860</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Bluetooth: btusb: Add date->evt_skb is NULL check
|
|
|
|
fix crash because of null pointers
|
|
|
|
[ 6104.969662] BUG: kernel NULL pointer dereference, address: 00000000000000c8
|
|
[ 6104.969667] #PF: supervisor read access in kernel mode
|
|
[ 6104.969668] #PF: error_code(0x0000) - not-present page
|
|
[ 6104.969670] PGD 0 P4D 0
|
|
[ 6104.969673] Oops: 0000 [#1] SMP NOPTI
|
|
[ 6104.969684] RIP: 0010:btusb_mtk_hci_wmt_sync+0x144/0x220 [btusb]
|
|
[ 6104.969688] RSP: 0018:ffffb8d681533d48 EFLAGS: 00010246
|
|
[ 6104.969689] RAX: 0000000000000000 RBX: ffff8ad560bb2000 RCX: 0000000000000006
|
|
[ 6104.969691] RDX: 0000000000000000 RSI: ffffb8d681533d08 RDI: 0000000000000000
|
|
[ 6104.969692] RBP: ffffb8d681533d70 R08: 0000000000000001 R09: 0000000000000001
|
|
[ 6104.969694] R10: 0000000000000001 R11: 00000000fa83b2da R12: ffff8ad461d1d7c0
|
|
[ 6104.969695] R13: 0000000000000000 R14: ffff8ad459618c18 R15: ffffb8d681533d90
|
|
[ 6104.969697] FS: 00007f5a1cab9d40(0000) GS:ffff8ad578200000(0000) knlGS:00000
|
|
[ 6104.969699] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 6104.969700] CR2: 00000000000000c8 CR3: 000000018620c001 CR4: 0000000000760ef0
|
|
[ 6104.969701] PKRU: 55555554
|
|
[ 6104.969702] Call Trace:
|
|
[ 6104.969708] btusb_mtk_shutdown+0x44/0x80 [btusb]
|
|
[ 6104.969732] hci_dev_do_close+0x470/0x5c0 [bluetooth]
|
|
[ 6104.969748] hci_rfkill_set_block+0x56/0xa0 [bluetooth]
|
|
[ 6104.969753] rfkill_set_block+0x92/0x160
|
|
[ 6104.969755] rfkill_fop_write+0x136/0x1e0
|
|
[ 6104.969759] __vfs_write+0x18/0x40
|
|
[ 6104.969761] vfs_write+0xdf/0x1c0
|
|
[ 6104.969763] ksys_write+0xb1/0xe0
|
|
[ 6104.969765] __x64_sys_write+0x1a/0x20
|
|
[ 6104.969769] do_syscall_64+0x51/0x180
|
|
[ 6104.969771] entry_SYSCALL_64_after_hwframe+0x44/0xa9
|
|
[ 6104.969773] RIP: 0033:0x7f5a21f18fef
|
|
[ 6104.9] RSP: 002b:00007ffeefe39010 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
|
|
[ 6104.969780] RAX: ffffffffffffffda RBX: 000055c10a7560a0 RCX: 00007f5a21f18fef
|
|
[ 6104.969781] RDX: 0000000000000008 RSI: 00007ffeefe39060 RDI: 0000000000000012
|
|
[ 6104.969782] RBP: 00007ffeefe39060 R08: 0000000000000000 R09: 0000000000000017
|
|
[ 6104.969784] R10: 00007ffeefe38d97 R11: 0000000000000293 R12: 0000000000000002
|
|
[ 6104.969785] R13: 00007ffeefe39220 R14: 00007ffeefe391a0 R15: 000055c10a72acf0</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2023-52833</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-07-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1860</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
f2fs: compress: fix to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock
|
|
|
|
It needs to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock
|
|
to avoid racing with checkpoint, otherwise, filesystem metadata including
|
|
blkaddr in dnode, inode fields and .total_valid_block_count may be
|
|
corrupted after SPO case.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-34027</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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:H/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1860</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
null_blk: fix null-ptr-dereference while configuring 'power' and 'submit_queues'
|
|
|
|
Writing 'power' and 'submit_queues' concurrently will trigger kernel
|
|
panic:
|
|
|
|
Test script:
|
|
|
|
modprobe null_blk nr_devices=0
|
|
mkdir -p /sys/kernel/config/nullb/nullb0
|
|
while true; do echo 1 > submit_queues; echo 4 > submit_queues; done &
|
|
while true; do echo 1 > power; echo 0 > power; done
|
|
|
|
Test result:
|
|
|
|
BUG: kernel NULL pointer dereference, address: 0000000000000148
|
|
Oops: 0000 [#1] PREEMPT SMP
|
|
RIP: 0010:__lock_acquire+0x41d/0x28f0
|
|
Call Trace:
|
|
<TASK>
|
|
lock_acquire+0x121/0x450
|
|
down_write+0x5f/0x1d0
|
|
simple_recursive_removal+0x12f/0x5c0
|
|
blk_mq_debugfs_unregister_hctxs+0x7c/0x100
|
|
blk_mq_update_nr_hw_queues+0x4a3/0x720
|
|
nullb_update_nr_hw_queues+0x71/0xf0 [null_blk]
|
|
nullb_device_submit_queues_store+0x79/0xf0 [null_blk]
|
|
configfs_write_iter+0x119/0x1e0
|
|
vfs_write+0x326/0x730
|
|
ksys_write+0x74/0x150
|
|
|
|
This is because del_gendisk() can concurrent with
|
|
blk_mq_update_nr_hw_queues():
|
|
|
|
nullb_device_power_store nullb_apply_submit_queues
|
|
null_del_dev
|
|
del_gendisk
|
|
nullb_update_nr_hw_queues
|
|
if (!dev->nullb)
|
|
// still set while gendisk is deleted
|
|
return 0
|
|
blk_mq_update_nr_hw_queues
|
|
dev->nullb = NULL
|
|
|
|
Fix this problem by resuing the global mutex to protect
|
|
nullb_device_power_store() and nullb_update_nr_hw_queues() from configfs.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-36478</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-07-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1860</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
bnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq
|
|
|
|
Undefined behavior is triggered when bnxt_qplib_alloc_init_hwq is called
|
|
with hwq_attr->aux_depth != 0 and hwq_attr->aux_stride == 0.
|
|
In that case, "roundup_pow_of_two(hwq_attr->aux_stride)" gets called.
|
|
roundup_pow_of_two is documented as undefined for 0.
|
|
|
|
Fix it in the one caller that had this combination.
|
|
|
|
The undefined behavior was detected by UBSAN:
|
|
UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13
|
|
shift exponent 64 is too large for 64-bit type 'long unsigned int'
|
|
CPU: 24 PID: 1075 Comm: (udev-worker) Not tainted 6.9.0-rc6+ #4
|
|
Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.7 10/25/2023
|
|
Call Trace:
|
|
<TASK>
|
|
dump_stack_lvl+0x5d/0x80
|
|
ubsan_epilogue+0x5/0x30
|
|
__ubsan_handle_shift_out_of_bounds.cold+0x61/0xec
|
|
__roundup_pow_of_two+0x25/0x35 [bnxt_re]
|
|
bnxt_qplib_alloc_init_hwq+0xa1/0x470 [bnxt_re]
|
|
bnxt_qplib_create_qp+0x19e/0x840 [bnxt_re]
|
|
bnxt_re_create_qp+0x9b1/0xcd0 [bnxt_re]
|
|
? srso_alias_return_thunk+0x5/0xfbef5
|
|
? srso_alias_return_thunk+0x5/0xfbef5
|
|
? __kmalloc+0x1b6/0x4f0
|
|
? create_qp.part.0+0x128/0x1c0 [ib_core]
|
|
? __pfx_bnxt_re_create_qp+0x10/0x10 [bnxt_re]
|
|
create_qp.part.0+0x128/0x1c0 [ib_core]
|
|
ib_create_qp_kernel+0x50/0xd0 [ib_core]
|
|
create_mad_qp+0x8e/0xe0 [ib_core]
|
|
? __pfx_qp_event_handler+0x10/0x10 [ib_core]
|
|
ib_mad_init_device+0x2be/0x680 [ib_core]
|
|
add_client_context+0x10d/0x1a0 [ib_core]
|
|
enable_device_and_get+0xe0/0x1d0 [ib_core]
|
|
ib_register_device+0x53c/0x630 [ib_core]
|
|
? srso_alias_return_thunk+0x5/0xfbef5
|
|
bnxt_re_probe+0xbd8/0xe50 [bnxt_re]
|
|
? __pfx_bnxt_re_probe+0x10/0x10 [bnxt_re]
|
|
auxiliary_bus_probe+0x49/0x80
|
|
? driver_sysfs_add+0x57/0xc0
|
|
really_probe+0xde/0x340
|
|
? pm_runtime_barrier+0x54/0x90
|
|
? __pfx___driver_attach+0x10/0x10
|
|
__driver_probe_device+0x78/0x110
|
|
driver_probe_device+0x1f/0xa0
|
|
__driver_attach+0xba/0x1c0
|
|
bus_for_each_dev+0x8f/0xe0
|
|
bus_add_driver+0x146/0x220
|
|
driver_register+0x72/0xd0
|
|
__auxiliary_driver_register+0x6e/0xd0
|
|
? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re]
|
|
bnxt_re_mod_init+0x3e/0xff0 [bnxt_re]
|
|
? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re]
|
|
do_one_initcall+0x5b/0x310
|
|
do_init_module+0x90/0x250
|
|
init_module_from_file+0x86/0xc0
|
|
idempotent_init_module+0x121/0x2b0
|
|
__x64_sys_finit_module+0x5e/0xb0
|
|
do_syscall_64+0x82/0x160
|
|
? srso_alias_return_thunk+0x5/0xfbef5
|
|
? syscall_exit_to_user_mode_prepare+0x149/0x170
|
|
? srso_alias_return_thunk+0x5/0xfbef5
|
|
? syscall_exit_to_user_mode+0x75/0x230
|
|
? srso_alias_return_thunk+0x5/0xfbef5
|
|
? do_syscall_64+0x8e/0x160
|
|
? srso_alias_return_thunk+0x5/0xfbef5
|
|
? __count_memcg_events+0x69/0x100
|
|
? srso_alias_return_thunk+0x5/0xfbef5
|
|
? count_memcg_events.constprop.0+0x1a/0x30
|
|
? srso_alias_return_thunk+0x5/0xfbef5
|
|
? handle_mm_fault+0x1f0/0x300
|
|
? srso_alias_return_thunk+0x5/0xfbef5
|
|
? do_user_addr_fault+0x34e/0x640
|
|
? srso_alias_return_thunk+0x5/0xfbef5
|
|
? srso_alias_return_thunk+0x5/0xfbef5
|
|
entry_SYSCALL_64_after_hwframe+0x76/0x7e
|
|
RIP: 0033:0x7f4e5132821d
|
|
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e3 db 0c 00 f7 d8 64 89 01 48
|
|
RSP: 002b:00007ffca9c906a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
|
|
RAX: ffffffffffffffda RBX: 0000563ec8a8f130 RCX: 00007f4e5132821d
|
|
RDX: 0000000000000000 RSI: 00007f4e518fa07d RDI: 000000000000003b
|
|
RBP: 00007ffca9c90760 R08: 00007f4e513f6b20 R09: 00007ffca9c906f0
|
|
R10: 0000563ec8a8faa0 R11: 0000000000000246 R12: 00007f4e518fa07d
|
|
R13: 0000000000020000 R14: 0000563ec8409e90 R15: 0000563ec8a8fa60
|
|
</TASK>
|
|
---[ end trace ]---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-38540</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-07-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1860</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: openvswitch: fix overwriting ct original tuple for ICMPv6
|
|
|
|
OVS_PACKET_CMD_EXECUTE has 3 main attributes:
|
|
- OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format.
|
|
- OVS_PACKET_ATTR_PACKET - Binary packet content.
|
|
- OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet.
|
|
|
|
OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure
|
|
with the metadata like conntrack state, input port, recirculation id,
|
|
etc. Then the packet itself gets parsed to populate the rest of the
|
|
keys from the packet headers.
|
|
|
|
Whenever the packet parsing code starts parsing the ICMPv6 header, it
|
|
first zeroes out fields in the key corresponding to Neighbor Discovery
|
|
information even if it is not an ND packet.
|
|
|
|
It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares
|
|
the space between 'nd' and 'ct_orig' that holds the original tuple
|
|
conntrack metadata parsed from the OVS_PACKET_ATTR_KEY.
|
|
|
|
ND packets should not normally have conntrack state, so it's fine to
|
|
share the space, but normal ICMPv6 Echo packets or maybe other types of
|
|
ICMPv6 can have the state attached and it should not be overwritten.
|
|
|
|
The issue results in all but the last 4 bytes of the destination
|
|
address being wiped from the original conntrack tuple leading to
|
|
incorrect packet matching and potentially executing wrong actions
|
|
in case this packet recirculates within the datapath or goes back
|
|
to userspace.
|
|
|
|
ND fields should not be accessed in non-ND packets, so not clearing
|
|
them should be fine. Executing memset() only for actual ND packets to
|
|
avoid the issue.
|
|
|
|
Initializing the whole thing before parsing is needed because ND packet
|
|
may not contain all the options.
|
|
|
|
The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn't
|
|
affect packets entering OVS datapath from network interfaces, because
|
|
in this case CT metadata is populated from skb after the packet is
|
|
already parsed.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-38558</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-07-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1860</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
gfs2: Fix potential glock use-after-free on unmount
|
|
|
|
When a DLM lockspace is released and there ares still locks in that
|
|
lockspace, DLM will unlock those locks automatically. Commit
|
|
fb6791d100d1b started exploiting this behavior to speed up filesystem
|
|
unmount: gfs2 would simply free glocks it didn't want to unlock and then
|
|
release the lockspace. This didn't take the bast callbacks for
|
|
asynchronous lock contention notifications into account, which remain
|
|
active until until a lock is unlocked or its lockspace is released.
|
|
|
|
To prevent those callbacks from accessing deallocated objects, put the
|
|
glocks that should not be unlocked on the sd_dead_glocks list, release
|
|
the lockspace, and only then free those glocks.
|
|
|
|
As an additional measure, ignore unexpected ast and bast callbacks if
|
|
the receiving glock is dead.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-38570</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.7</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1860</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
r8169: Fix possible ring buffer corruption on fragmented Tx packets.
|
|
|
|
An issue was found on the RTL8125b when transmitting small fragmented
|
|
packets, whereby invalid entries were inserted into the transmit ring
|
|
buffer, subsequently leading to calls to dma_unmap_single() with a null
|
|
address.
|
|
|
|
This was caused by rtl8169_start_xmit() not noticing changes to nr_frags
|
|
which may occur when small packets are padded (to work around hardware
|
|
quirks) in rtl8169_tso_csum_v2().
|
|
|
|
To fix this, postpone inspecting nr_frags until after any padding has been
|
|
applied.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-38586</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.7</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1860</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
md: fix resync softlockup when bitmap size is less than array size
|
|
|
|
Is is reported that for dm-raid10, lvextend + lvchange --syncaction will
|
|
trigger following softlockup:
|
|
|
|
kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976]
|
|
CPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1
|
|
RIP: 0010:_raw_spin_unlock_irq+0x13/0x30
|
|
Call Trace:
|
|
<TASK>
|
|
md_bitmap_start_sync+0x6b/0xf0
|
|
raid10_sync_request+0x25c/0x1b40 [raid10]
|
|
md_do_sync+0x64b/0x1020
|
|
md_thread+0xa7/0x170
|
|
kthread+0xcf/0x100
|
|
ret_from_fork+0x30/0x50
|
|
ret_from_fork_asm+0x1a/0x30
|
|
|
|
And the detailed process is as follows:
|
|
|
|
md_do_sync
|
|
j = mddev->resync_min
|
|
while (j < max_sectors)
|
|
sectors = raid10_sync_request(mddev, j, &skipped)
|
|
if (!md_bitmap_start_sync(..., &sync_blocks))
|
|
// md_bitmap_start_sync set sync_blocks to 0
|
|
return sync_blocks + sectors_skippe;
|
|
// sectors = 0;
|
|
j += sectors;
|
|
// j never change
|
|
|
|
Root cause is that commit 301867b1c168 ("md/raid10: check
|
|
slab-out-of-bounds in md_bitmap_get_counter") return early from
|
|
md_bitmap_get_counter(), without setting returned blocks.
|
|
|
|
Fix this problem by always set returned blocks from
|
|
md_bitmap_get_counter"(), as it used to be.
|
|
|
|
Noted that this patch just fix the softlockup problem in kernel, the
|
|
case that bitmap size doesn't match array size still need to be fixed.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-38598</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-07-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1860</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ALSA: core: Fix NULL module pointer assignment at card init
|
|
|
|
The commit 81033c6b584b ("ALSA: core: Warn on empty module")
|
|
introduced a WARN_ON() for a NULL module pointer passed at snd_card
|
|
object creation, and it also wraps the code around it with '#ifdef
|
|
MODULE'. This works in most cases, but the devils are always in
|
|
details. "MODULE" is defined when the target code (i.e. the sound
|
|
core) is built as a module; but this doesn't mean that the caller is
|
|
also built-in or not. Namely, when only the sound core is built-in
|
|
(CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m),
|
|
the passed module pointer is ignored even if it's non-NULL, and
|
|
card->module remains as NULL. This would result in the missing module
|
|
reference up/down at the device open/close, leading to a race with the
|
|
code execution after the module removal.
|
|
|
|
For addressing the bug, move the assignment of card->module again out
|
|
of ifdef. The WARN_ON() is still wrapped with ifdef because the
|
|
module can be really NULL when all sound drivers are built-in.
|
|
|
|
Note that we keep 'ifdef MODULE' for WARN_ON(), otherwise it would
|
|
lead to a false-positive NULL module check. Admittedly it won't catch
|
|
perfectly, i.e. no check is performed when CONFIG_SND=y. But, it's no
|
|
real problem as it's only for debugging, and the condition is pretty
|
|
rare.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-38605</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-07-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1860</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
cpufreq: exit() callback is optional
|
|
|
|
The exit() callback is optional and shouldn't be called without checking
|
|
a valid pointer first.
|
|
|
|
Also, we must clear freq_table pointer even if the exit() callback isn't
|
|
present.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-38615</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-07-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1860</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
vfio/pci: fix potential memory leak in vfio_intx_enable()
|
|
|
|
If vfio_irq_ctx_alloc() failed will lead to 'name' memory leak.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-38632</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-07-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1860</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:kdb: Fix buffer overflow during tab-completeCurrently, when the user attempts symbol completion with the Tab key, kdbwill use strncpy() to insert the completed symbol into the command buffer.Unfortunately it passes the size of the source buffer rather than thedestination to strncpy() with predictably horrible results. Most obviouslyif the command buffer is already full but cp, the cursor position, is inthe middle of the buffer, then we will write past the end of the suppliedbuffer.Fix this by replacing the dubious strncpy() calls with memmove()/memcpy()calls plus explicit boundary checks to make sure we have enough spacebefore we start moving characters around.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-39480</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-07-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1860</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()
|
|
|
|
In function bond_option_arp_ip_targets_set(), if newval->string is an
|
|
empty string, newval->string+1 will point to the byte after the
|
|
string, causing an out-of-bound read.
|
|
|
|
BUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418
|
|
Read of size 1 at addr ffff8881119c4781 by task syz-executor665/8107
|
|
CPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
|
|
print_address_description mm/kasan/report.c:364 [inline]
|
|
print_report+0xc1/0x5e0 mm/kasan/report.c:475
|
|
kasan_report+0xbe/0xf0 mm/kasan/report.c:588
|
|
strlen+0x7d/0xa0 lib/string.c:418
|
|
__fortify_strlen include/linux/fortify-string.h:210 [inline]
|
|
in4_pton+0xa3/0x3f0 net/core/utils.c:130
|
|
bond_option_arp_ip_targets_set+0xc2/0x910
|
|
drivers/net/bonding/bond_options.c:1201
|
|
__bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767
|
|
__bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792
|
|
bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817
|
|
bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156
|
|
dev_attr_store+0x54/0x80 drivers/base/core.c:2366
|
|
sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136
|
|
kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334
|
|
call_write_iter include/linux/fs.h:2020 [inline]
|
|
new_sync_write fs/read_write.c:491 [inline]
|
|
vfs_write+0x96a/0xd80 fs/read_write.c:584
|
|
ksys_write+0x122/0x250 fs/read_write.c:637
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b
|
|
---[ end trace ]---
|
|
|
|
Fix it by adding a check of string length before using it.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-39487</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-07-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1860</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY
|
|
|
|
When CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes
|
|
to bug_table entries, and as a result the last entry in a bug table will
|
|
be ignored, potentially leading to an unexpected panic(). All prior
|
|
entries in the table will be handled correctly.
|
|
|
|
The arm64 ABI requires that struct fields of up to 8 bytes are
|
|
naturally-aligned, with padding added within a struct such that struct
|
|
are suitably aligned within arrays.
|
|
|
|
When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is:
|
|
|
|
struct bug_entry {
|
|
signed int bug_addr_disp; // 4 bytes
|
|
signed int file_disp; // 4 bytes
|
|
unsigned short line; // 2 bytes
|
|
unsigned short flags; // 2 bytes
|
|
}
|
|
|
|
... with 12 bytes total, requiring 4-byte alignment.
|
|
|
|
When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is:
|
|
|
|
struct bug_entry {
|
|
signed int bug_addr_disp; // 4 bytes
|
|
unsigned short flags; // 2 bytes
|
|
< implicit padding > // 2 bytes
|
|
}
|
|
|
|
... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing
|
|
padding, requiring 4-byte alginment.
|
|
|
|
When we create a bug_entry in assembly, we align the start of the entry
|
|
to 4 bytes, which implicitly handles padding for any prior entries.
|
|
However, we do not align the end of the entry, and so when
|
|
CONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding
|
|
bytes.
|
|
|
|
For the main kernel image this is not a problem as find_bug() doesn't
|
|
depend on the trailing padding bytes when searching for entries:
|
|
|
|
for (bug = __start___bug_table; bug < __stop___bug_table; ++bug)
|
|
if (bugaddr == bug_addr(bug))
|
|
return bug;
|
|
|
|
However for modules, module_bug_finalize() depends on the trailing
|
|
bytes when calculating the number of entries:
|
|
|
|
mod->num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry);
|
|
|
|
... and as the last bug_entry lacks the necessary padding bytes, this entry
|
|
will not be counted, e.g. in the case of a single entry:
|
|
|
|
sechdrs[i].sh_size == 6
|
|
sizeof(struct bug_entry) == 8;
|
|
|
|
sechdrs[i].sh_size / sizeof(struct bug_entry) == 0;
|
|
|
|
Consequently module_find_bug() will miss the last bug_entry when it does:
|
|
|
|
for (i = 0; i < mod->num_bugs; ++i, ++bug)
|
|
if (bugaddr == bug_addr(bug))
|
|
goto out;
|
|
|
|
... which can lead to a kenrel panic due to an unhandled bug.
|
|
|
|
This can be demonstrated with the following module:
|
|
|
|
static int __init buginit(void)
|
|
{
|
|
WARN(1, "hello\n");
|
|
return 0;
|
|
}
|
|
|
|
static void __exit bugexit(void)
|
|
{
|
|
}
|
|
|
|
module_init(buginit);
|
|
module_exit(bugexit);
|
|
MODULE_LICENSE("GPL");
|
|
|
|
... which will trigger a kernel panic when loaded:
|
|
|
|
------------[ cut here ]------------
|
|
hello
|
|
Unexpected kernel BRK exception at EL1
|
|
Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP
|
|
Modules linked in: hello(O+)
|
|
CPU: 0 PID: 50 Comm: insmod Tainted: G O 6.9.1 #8
|
|
Hardware name: linux,dummy-virt (DT)
|
|
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
|
pc : buginit+0x18/0x1000 [hello]
|
|
lr : buginit+0x18/0x1000 [hello]
|
|
sp : ffff800080533ae0
|
|
x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000
|
|
x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58
|
|
x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0
|
|
x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006
|
|
x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720
|
|
x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312
|
|
x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8
|
|
x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000
|
|
x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000
|
|
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0
|
|
Call trace:
|
|
buginit+0x18/0x1000 [hello]
|
|
do_one_initcall+0x80/0x1c8
|
|
do_init_module+0x60/0x218
|
|
load_module+0x1ba4/0x1d70
|
|
__do_sys_init_module+0x198/0x1d0
|
|
__arm64_sys_init_module+0x1c/0x28
|
|
invoke_syscall+0x48/0x114
|
|
el0_svc
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-39488</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-07-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1860</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ipv6: sr: fix memleak in seg6_hmac_init_algo
|
|
|
|
seg6_hmac_init_algo returns without cleaning up the previous allocations
|
|
if one fails, so it's going to leak all that memory and the crypto tfms.
|
|
|
|
Update seg6_hmac_exit to only free the memory when allocated, so we can
|
|
reuse the code directly.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-39489</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.3</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1860</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
sock_map: avoid race between sock_map_close and sk_psock_put
|
|
|
|
sk_psock_get will return NULL if the refcount of psock has gone to 0, which
|
|
will happen when the last call of sk_psock_put is done. However,
|
|
sk_psock_drop may not have finished yet, so the close callback will still
|
|
point to sock_map_close despite psock being NULL.
|
|
|
|
This can be reproduced with a thread deleting an element from the sock map,
|
|
while the second one creates a socket, adds it to the map and closes it.
|
|
|
|
That will trigger the WARN_ON_ONCE:
|
|
|
|
------------[ cut here ]------------
|
|
WARNING: CPU: 1 PID: 7220 at net/core/sock_map.c:1701 sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701
|
|
Modules linked in:
|
|
CPU: 1 PID: 7220 Comm: syz-executor380 Not tainted 6.9.0-syzkaller-07726-g3c999d1ae3c7 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
|
|
RIP: 0010:sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701
|
|
Code: df e8 92 29 88 f8 48 8b 1b 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 79 29 88 f8 4c 8b 23 eb 89 e8 4f 15 23 f8 90 <0f> 0b 90 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 13 26 3d 02
|
|
RSP: 0018:ffffc9000441fda8 EFLAGS: 00010293
|
|
RAX: ffffffff89731ae1 RBX: ffffffff94b87540 RCX: ffff888029470000
|
|
RDX: 0000000000000000 RSI: ffffffff8bcab5c0 RDI: ffffffff8c1faba0
|
|
RBP: 0000000000000000 R08: ffffffff92f9b61f R09: 1ffffffff25f36c3
|
|
R10: dffffc0000000000 R11: fffffbfff25f36c4 R12: ffffffff89731840
|
|
R13: ffff88804b587000 R14: ffff88804b587000 R15: ffffffff89731870
|
|
FS: 000055555e080380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000000000000000 CR3: 00000000207d4000 CR4: 0000000000350ef0
|
|
Call Trace:
|
|
<TASK>
|
|
unix_release+0x87/0xc0 net/unix/af_unix.c:1048
|
|
__sock_release net/socket.c:659 [inline]
|
|
sock_close+0xbe/0x240 net/socket.c:1421
|
|
__fput+0x42b/0x8a0 fs/file_table.c:422
|
|
__do_sys_close fs/open.c:1556 [inline]
|
|
__se_sys_close fs/open.c:1541 [inline]
|
|
__x64_sys_close+0x7f/0x110 fs/open.c:1541
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
|
RIP: 0033:0x7fb37d618070
|
|
Code: 00 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d4 e8 10 2c 00 00 80 3d 31 f0 07 00 00 74 17 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 48 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 7c
|
|
RSP: 002b:00007ffcd4a525d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000003
|
|
RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fb37d618070
|
|
RDX: 0000000000000010 RSI: 00000000200001c0 RDI: 0000000000000004
|
|
RBP: 0000000000000000 R08: 0000000100000000 R09: 0000000100000000
|
|
R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000
|
|
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
|
|
</TASK>
|
|
|
|
Use sk_psock, which will only check that the pointer is not been set to
|
|
NULL yet, which should only happen after the callbacks are restored. If,
|
|
then, a reference can still be gotten, we may call sk_psock_stop and cancel
|
|
psock->work.
|
|
|
|
As suggested by Paolo Abeni, reorder the condition so the control flow is
|
|
less convoluted.
|
|
|
|
After that change, the reproducer does not trigger the WARN_ON_ONCE
|
|
anymore.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-39500</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-07-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1860</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="21" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mptcp: ensure snd_una is properly initialized on connect
|
|
|
|
This is strictly related to commit fb7a0d334894 ("mptcp: ensure snd_nxt
|
|
is properly initialized on connect"). It turns out that syzkaller can
|
|
trigger the retransmit after fallback and before processing any other
|
|
incoming packet - so that snd_una is still left uninitialized.
|
|
|
|
Address the issue explicitly initializing snd_una together with snd_nxt
|
|
and write_seq.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-40931</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-07-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1860</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="22" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
f2fs: remove clear SB_INLINECRYPT flag in default_options
|
|
|
|
In f2fs_remount, SB_INLINECRYPT flag will be clear and re-set.
|
|
If create new file or open file during this gap, these files
|
|
will not use inlinecrypt. Worse case, it may lead to data
|
|
corruption if wrappedkey_v0 is enable.
|
|
|
|
Thread A: Thread B:
|
|
|
|
-f2fs_remount -f2fs_file_open or f2fs_new_inode
|
|
-default_options
|
|
<- clear SB_INLINECRYPT flag
|
|
|
|
-fscrypt_select_encryption_impl
|
|
|
|
-parse_options
|
|
<- set SB_INLINECRYPT again</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-19</ReleaseDate>
|
|
<CVE>CVE-2024-40971</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-07-19</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1860</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |