6110 lines
250 KiB
XML
6110 lines
250 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
||
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
|
||
<DocumentTitle xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP3</DocumentTitle>
|
||
<DocumentType>Security Advisory</DocumentType>
|
||
<DocumentPublisher Type="Vendor">
|
||
<ContactDetails>openeuler-security@openeuler.org</ContactDetails>
|
||
<IssuingAuthority>openEuler security committee</IssuingAuthority>
|
||
</DocumentPublisher>
|
||
<DocumentTracking>
|
||
<Identification>
|
||
<ID>openEuler-SA-2024-1962</ID>
|
||
</Identification>
|
||
<Status>Final</Status>
|
||
<Version>1.0</Version>
|
||
<RevisionHistory>
|
||
<Revision>
|
||
<Number>1.0</Number>
|
||
<Date>2024-08-09</Date>
|
||
<Description>Initial</Description>
|
||
</Revision>
|
||
</RevisionHistory>
|
||
<InitialReleaseDate>2024-08-09</InitialReleaseDate>
|
||
<CurrentReleaseDate>2024-08-09</CurrentReleaseDate>
|
||
<Generator>
|
||
<Engine>openEuler SA Tool V1.0</Engine>
|
||
<Date>2024-08-09</Date>
|
||
</Generator>
|
||
</DocumentTracking>
|
||
<DocumentNotes>
|
||
<Note Title="Synopsis" Type="General" Ordinal="1" xml:lang="en">kernel security update</Note>
|
||
<Note Title="Summary" Type="General" Ordinal="2" xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP3</Note>
|
||
<Note Title="Description" Type="General" Ordinal="3" xml:lang="en">The Linux Kernel, the operating system core itself.
|
||
|
||
Security Fix(es):
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
s390/qeth: fix deadlock during failing recovery
|
||
|
||
Commit 0b9902c1fcc5 ("s390/qeth: fix deadlock during recovery") removed
|
||
taking discipline_mutex inside qeth_do_reset(), fixing potential
|
||
deadlocks. An error path was missed though, that still takes
|
||
discipline_mutex and thus has the original deadlock potential.
|
||
|
||
Intermittent deadlocks were seen when a qeth channel path is configured
|
||
offline, causing a race between qeth_do_reset and ccwgroup_remove.
|
||
Call qeth_set_offline() directly in the qeth_do_reset() error case and
|
||
then a new variant of ccwgroup_set_offline(), without taking
|
||
discipline_mutex.(CVE-2021-47382)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
NFSD: Fix the behavior of READ near OFFSET_MAX
|
||
|
||
Dan Aloni reports:
|
||
> Due to commit 8cfb9015280d ("NFS: Always provide aligned buffers to
|
||
> the RPC read layers") on the client, a read of 0xfff is aligned up
|
||
> to server rsize of 0x1000.
|
||
>
|
||
> As a result, in a test where the server has a file of size
|
||
> 0x7fffffffffffffff, and the client tries to read from the offset
|
||
> 0x7ffffffffffff000, the read causes loff_t overflow in the server
|
||
> and it returns an NFS code of EINVAL to the client. The client as
|
||
> a result indefinitely retries the request.
|
||
|
||
The Linux NFS client does not handle NFS?ERR_INVAL, even though all
|
||
NFS specifications permit servers to return that status code for a
|
||
READ.
|
||
|
||
Instead of NFS?ERR_INVAL, have out-of-range READ requests succeed
|
||
and return a short result. Set the EOF flag in the result to prevent
|
||
the client from retrying the READ request. This behavior appears to
|
||
be consistent with Solaris NFS servers.
|
||
|
||
Note that NFSv3 and NFSv4 use u64 offset values on the wire. These
|
||
must be converted to loff_t internally before use -- an implicit
|
||
type cast is not adequate for this purpose. Otherwise VFS checks
|
||
against sb->s_maxbytes do not work properly.(CVE-2022-48827)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
net: can: j1939: enhanced error handling for tightly received RTS messages in xtp_rx_rts_session_new
|
||
|
||
This patch enhances error handling in scenarios with RTS (Request to
|
||
Send) messages arriving closely. It replaces the less informative WARN_ON_ONCE
|
||
backtraces with a new error handling method. This provides clearer error
|
||
messages and allows for the early termination of problematic sessions.
|
||
Previously, sessions were only released at the end of j1939_xtp_rx_rts().
|
||
|
||
Potentially this could be reproduced with something like:
|
||
testj1939 -r vcan0:0x80 &
|
||
while true; do
|
||
# send first RTS
|
||
cansend vcan0 18EC8090#1014000303002301;
|
||
# send second RTS
|
||
cansend vcan0 18EC8090#1014000303002301;
|
||
# send abort
|
||
cansend vcan0 18EC8090#ff00000000002301;
|
||
done(CVE-2023-52887)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
ipvlan: Dont Use skb->sk in ipvlan_process_v{4,6}_outbound
|
||
|
||
Raw packet from PF_PACKET socket ontop of an IPv6-backed ipvlan device will
|
||
hit WARN_ON_ONCE() in sk_mc_loop() through sch_direct_xmit() path.
|
||
|
||
WARNING: CPU: 2 PID: 0 at net/core/sock.c:775 sk_mc_loop+0x2d/0x70
|
||
Modules linked in: sch_netem ipvlan rfkill cirrus drm_shmem_helper sg drm_kms_helper
|
||
CPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279
|
||
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
|
||
RIP: 0010:sk_mc_loop+0x2d/0x70
|
||
Code: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1c
|
||
RSP: 0018:ffffa9584015cd78 EFLAGS: 00010212
|
||
RAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001
|
||
RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000
|
||
RBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00
|
||
R10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000
|
||
R13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000
|
||
FS: 0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000
|
||
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
||
CR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0
|
||
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
||
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
||
Call Trace:
|
||
<IRQ>
|
||
? __warn (kernel/panic.c:693)
|
||
? sk_mc_loop (net/core/sock.c:760)
|
||
? report_bug (lib/bug.c:201 lib/bug.c:219)
|
||
? handle_bug (arch/x86/kernel/traps.c:239)
|
||
? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1))
|
||
? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)
|
||
? sk_mc_loop (net/core/sock.c:760)
|
||
ip6_finish_output2 (net/ipv6/ip6_output.c:83 (discriminator 1))
|
||
? nf_hook_slow (net/netfilter/core.c:626)
|
||
ip6_finish_output (net/ipv6/ip6_output.c:222)
|
||
? __pfx_ip6_finish_output (net/ipv6/ip6_output.c:215)
|
||
ipvlan_xmit_mode_l3 (drivers/net/ipvlan/ipvlan_core.c:602) ipvlan
|
||
ipvlan_start_xmit (drivers/net/ipvlan/ipvlan_main.c:226) ipvlan
|
||
dev_hard_start_xmit (net/core/dev.c:3594)
|
||
sch_direct_xmit (net/sched/sch_generic.c:343)
|
||
__qdisc_run (net/sched/sch_generic.c:416)
|
||
net_tx_action (net/core/dev.c:5286)
|
||
handle_softirqs (kernel/softirq.c:555)
|
||
__irq_exit_rcu (kernel/softirq.c:589)
|
||
sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1043)
|
||
|
||
The warning triggers as this:
|
||
packet_sendmsg
|
||
packet_snd //skb->sk is packet sk
|
||
__dev_queue_xmit
|
||
__dev_xmit_skb //q->enqueue is not NULL
|
||
__qdisc_run
|
||
sch_direct_xmit
|
||
dev_hard_start_xmit
|
||
ipvlan_start_xmit
|
||
ipvlan_xmit_mode_l3 //l3 mode
|
||
ipvlan_process_outbound //vepa flag
|
||
ipvlan_process_v6_outbound
|
||
ip6_local_out
|
||
__ip6_finish_output
|
||
ip6_finish_output2 //multicast packet
|
||
sk_mc_loop //sk->sk_family is AF_PACKET
|
||
|
||
Call ip{6}_local_out() with NULL sk in ipvlan as other tunnels to fix this.(CVE-2024-33621)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
usb: gadget: ncm: Fix handling of zero block length packets
|
||
|
||
While connecting to a Linux host with CDC_NCM_NTB_DEF_SIZE_TX
|
||
set to 65536, it has been observed that we receive short packets,
|
||
which come at interval of 5-10 seconds sometimes and have block
|
||
length zero but still contain 1-2 valid datagrams present.
|
||
|
||
According to the NCM spec:
|
||
|
||
"If wBlockLength = 0x0000, the block is terminated by a
|
||
short packet. In this case, the USB transfer must still
|
||
be shorter than dwNtbInMaxSize or dwNtbOutMaxSize. If
|
||
exactly dwNtbInMaxSize or dwNtbOutMaxSize bytes are sent,
|
||
and the size is a multiple of wMaxPacketSize for the
|
||
given pipe, then no ZLP shall be sent.
|
||
|
||
wBlockLength= 0x0000 must be used with extreme care, because
|
||
of the possibility that the host and device may get out of
|
||
sync, and because of test issues.
|
||
|
||
wBlockLength = 0x0000 allows the sender to reduce latency by
|
||
starting to send a very large NTB, and then shortening it when
|
||
the sender discovers that there’s not sufficient data to justify
|
||
sending a large NTB"
|
||
|
||
However, there is a potential issue with the current implementation,
|
||
as it checks for the occurrence of multiple NTBs in a single
|
||
giveback by verifying if the leftover bytes to be processed is zero
|
||
or not. If the block length reads zero, we would process the same
|
||
NTB infintely because the leftover bytes is never zero and it leads
|
||
to a crash. Fix this by bailing out if block length reads zero.(CVE-2024-35825)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
drm: vc4: Fix possible null pointer dereference
|
||
|
||
In vc4_hdmi_audio_init() of_get_address() may return
|
||
NULL which is later dereferenced. Fix this bug by adding NULL check.
|
||
|
||
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-38546)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
kunit: Fix kthread reference
|
||
|
||
There is a race condition when a kthread finishes after the deadline and
|
||
before the call to kthread_stop(), which may lead to use after free.(CVE-2024-38561)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
net: stmmac: move the EST lock to struct stmmac_priv
|
||
|
||
Reinitialize the whole EST structure would also reset the mutex
|
||
lock which is embedded in the EST structure, and then trigger
|
||
the following warning. To address this, move the lock to struct
|
||
stmmac_priv. We also need to reacquire the mutex lock when doing
|
||
this initialization.
|
||
|
||
DEBUG_LOCKS_WARN_ON(lock->magic != lock)
|
||
WARNING: CPU: 3 PID: 505 at kernel/locking/mutex.c:587 __mutex_lock+0xd84/0x1068
|
||
Modules linked in:
|
||
CPU: 3 PID: 505 Comm: tc Not tainted 6.9.0-rc6-00053-g0106679839f7-dirty #29
|
||
Hardware name: NXP i.MX8MPlus EVK board (DT)
|
||
pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
||
pc : __mutex_lock+0xd84/0x1068
|
||
lr : __mutex_lock+0xd84/0x1068
|
||
sp : ffffffc0864e3570
|
||
x29: ffffffc0864e3570 x28: ffffffc0817bdc78 x27: 0000000000000003
|
||
x26: ffffff80c54f1808 x25: ffffff80c9164080 x24: ffffffc080d723ac
|
||
x23: 0000000000000000 x22: 0000000000000002 x21: 0000000000000000
|
||
x20: 0000000000000000 x19: ffffffc083bc3000 x18: ffffffffffffffff
|
||
x17: ffffffc08117b080 x16: 0000000000000002 x15: ffffff80d2d40000
|
||
x14: 00000000000002da x13: ffffff80d2d404b8 x12: ffffffc082b5a5c8
|
||
x11: ffffffc082bca680 x10: ffffffc082bb2640 x9 : ffffffc082bb2698
|
||
x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001
|
||
x5 : ffffff8178fe0d48 x4 : 0000000000000000 x3 : 0000000000000027
|
||
x2 : ffffff8178fe0d50 x1 : 0000000000000000 x0 : 0000000000000000
|
||
Call trace:
|
||
__mutex_lock+0xd84/0x1068
|
||
mutex_lock_nested+0x28/0x34
|
||
tc_setup_taprio+0x118/0x68c
|
||
stmmac_setup_tc+0x50/0xf0
|
||
taprio_change+0x868/0xc9c(CVE-2024-38594)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
stm class: Fix a double free in stm_register_device()
|
||
|
||
The put_device(&stm->dev) call will trigger stm_device_release() which
|
||
frees "stm" so the vfree(stm) on the next line is a double free.(CVE-2024-38627)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
drm/shmem-helper: Fix BUG_ON() on mmap(PROT_WRITE, MAP_PRIVATE)
|
||
|
||
Lack of check for copy-on-write (COW) mapping in drm_gem_shmem_mmap
|
||
allows users to call mmap with PROT_WRITE and MAP_PRIVATE flag
|
||
causing a kernel panic due to BUG_ON in vmf_insert_pfn_prot:
|
||
BUG_ON((vma->vm_flags & VM_PFNMAP) && is_cow_mapping(vma->vm_flags));
|
||
|
||
Return -EINVAL early if COW mapping is detected.
|
||
|
||
This bug affects all drm drivers using default shmem helpers.
|
||
It can be reproduced by this simple example:
|
||
void *ptr = mmap(0, size, PROT_WRITE, MAP_PRIVATE, fd, mmap_offset);
|
||
ptr[0] = 0;(CVE-2024-39497)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
net: hns3: fix kernel crash problem in concurrent scenario
|
||
|
||
When link status change, the nic driver need to notify the roce
|
||
driver to handle this event, but at this time, the roce driver
|
||
may uninit, then cause kernel crash.
|
||
|
||
To fix the problem, when link status change, need to check
|
||
whether the roce registered, and when uninit, need to wait link
|
||
update finish.(CVE-2024-39507)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
ax25: Fix refcount imbalance on inbound connections
|
||
|
||
When releasing a socket in ax25_release(), we call netdev_put() to
|
||
decrease the refcount on the associated ax.25 device. However, the
|
||
execution path for accepting an incoming connection never calls
|
||
netdev_hold(). This imbalance leads to refcount errors, and ultimately
|
||
to kernel crashes.
|
||
|
||
A typical call trace for the above situation will start with one of the
|
||
following errors:
|
||
|
||
refcount_t: decrement hit 0; leaking memory.
|
||
refcount_t: underflow; use-after-free.
|
||
|
||
And will then have a trace like:
|
||
|
||
Call Trace:
|
||
<TASK>
|
||
? show_regs+0x64/0x70
|
||
? __warn+0x83/0x120
|
||
? refcount_warn_saturate+0xb2/0x100
|
||
? report_bug+0x158/0x190
|
||
? prb_read_valid+0x20/0x30
|
||
? handle_bug+0x3e/0x70
|
||
? exc_invalid_op+0x1c/0x70
|
||
? asm_exc_invalid_op+0x1f/0x30
|
||
? refcount_warn_saturate+0xb2/0x100
|
||
? refcount_warn_saturate+0xb2/0x100
|
||
ax25_release+0x2ad/0x360
|
||
__sock_release+0x35/0xa0
|
||
sock_close+0x19/0x20
|
||
[...]
|
||
|
||
On reboot (or any attempt to remove the interface), the kernel gets
|
||
stuck in an infinite loop:
|
||
|
||
unregister_netdevice: waiting for ax0 to become free. Usage count = 0
|
||
|
||
This patch corrects these issues by ensuring that we call netdev_hold()
|
||
and ax25_dev_hold() for new connections in ax25_accept(). This makes the
|
||
logic leading to ax25_accept() match the logic for ax25_bind(): in both
|
||
cases we increment the refcount, which is ultimately decremented in
|
||
ax25_release().(CVE-2024-40910)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin()
|
||
|
||
Use {READ,WRITE}_ONCE() to access kvm->last_boosted_vcpu to ensure the
|
||
loads and stores are atomic. In the extremely unlikely scenario the
|
||
compiler tears the stores, it's theoretically possible for KVM to attempt
|
||
to get a vCPU using an out-of-bounds index, e.g. if the write is split
|
||
into multiple 8-bit stores, and is paired with a 32-bit load on a VM with
|
||
257 vCPUs:
|
||
|
||
CPU0 CPU1
|
||
last_boosted_vcpu = 0xff;
|
||
|
||
(last_boosted_vcpu = 0x100)
|
||
last_boosted_vcpu[15:8] = 0x01;
|
||
i = (last_boosted_vcpu = 0x1ff)
|
||
last_boosted_vcpu[7:0] = 0x00;
|
||
|
||
vcpu = kvm->vcpu_array[0x1ff];
|
||
|
||
As detected by KCSAN:
|
||
|
||
BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm]
|
||
|
||
write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16:
|
||
kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm
|
||
handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel
|
||
vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:?
|
||
arch/x86/kvm/vmx/vmx.c:6606) kvm_intel
|
||
vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm
|
||
kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm
|
||
kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm
|
||
__se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890)
|
||
__x64_sys_ioctl (fs/ioctl.c:890)
|
||
x64_sys_call (arch/x86/entry/syscall_64.c:33)
|
||
do_syscall_64 (arch/x86/entry/common.c:?)
|
||
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
|
||
|
||
read to 0xffffc90025a92344 of 4 bytes by task 4342 on cpu 4:
|
||
kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4069) kvm
|
||
handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel
|
||
vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:?
|
||
arch/x86/kvm/vmx/vmx.c:6606) kvm_intel
|
||
vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm
|
||
kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm
|
||
kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm
|
||
__se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890)
|
||
__x64_sys_ioctl (fs/ioctl.c:890)
|
||
x64_sys_call (arch/x86/entry/syscall_64.c:33)
|
||
do_syscall_64 (arch/x86/entry/common.c:?)
|
||
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
|
||
|
||
value changed: 0x00000012 -> 0x00000000(CVE-2024-40953)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
xfrm6: check ip6_dst_idev() return value in xfrm6_get_saddr()
|
||
|
||
ip6_dst_idev() can return NULL, xfrm6_get_saddr() must act accordingly.
|
||
|
||
syzbot reported:
|
||
|
||
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI
|
||
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
|
||
CPU: 1 PID: 12 Comm: kworker/u8:1 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0
|
||
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
|
||
Workqueue: wg-kex-wg1 wg_packet_handshake_send_worker
|
||
RIP: 0010:xfrm6_get_saddr+0x93/0x130 net/ipv6/xfrm6_policy.c:64
|
||
Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 97 00 00 00 4c 8b ab d8 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 86 00 00 00 4d 8b 6d 00 e8 ca 13 47 01 48 b8 00
|
||
RSP: 0018:ffffc90000117378 EFLAGS: 00010246
|
||
RAX: dffffc0000000000 RBX: ffff88807b079dc0 RCX: ffffffff89a0d6d7
|
||
RDX: 0000000000000000 RSI: ffffffff89a0d6e9 RDI: ffff88807b079e98
|
||
RBP: ffff88807ad73248 R08: 0000000000000007 R09: fffffffffffff000
|
||
R10: ffff88807b079dc0 R11: 0000000000000007 R12: ffffc90000117480
|
||
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
|
||
FS: 0000000000000000(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000
|
||
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
||
CR2: 00007f4586d00440 CR3: 0000000079042000 CR4: 00000000003506f0
|
||
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
||
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
||
Call Trace:
|
||
<TASK>
|
||
xfrm_get_saddr net/xfrm/xfrm_policy.c:2452 [inline]
|
||
xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:2481 [inline]
|
||
xfrm_tmpl_resolve+0xa26/0xf10 net/xfrm/xfrm_policy.c:2541
|
||
xfrm_resolve_and_create_bundle+0x140/0x2570 net/xfrm/xfrm_policy.c:2835
|
||
xfrm_bundle_lookup net/xfrm/xfrm_policy.c:3070 [inline]
|
||
xfrm_lookup_with_ifid+0x4d1/0x1e60 net/xfrm/xfrm_policy.c:3201
|
||
xfrm_lookup net/xfrm/xfrm_policy.c:3298 [inline]
|
||
xfrm_lookup_route+0x3b/0x200 net/xfrm/xfrm_policy.c:3309
|
||
ip6_dst_lookup_flow+0x15c/0x1d0 net/ipv6/ip6_output.c:1256
|
||
send6+0x611/0xd20 drivers/net/wireguard/socket.c:139
|
||
wg_socket_send_skb_to_peer+0xf9/0x220 drivers/net/wireguard/socket.c:178
|
||
wg_socket_send_buffer_to_peer+0x12b/0x190 drivers/net/wireguard/socket.c:200
|
||
wg_packet_send_handshake_initiation+0x227/0x360 drivers/net/wireguard/send.c:40
|
||
wg_packet_handshake_send_worker+0x1c/0x30 drivers/net/wireguard/send.c:51
|
||
process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231
|
||
process_scheduled_works kernel/workqueue.c:3312 [inline]
|
||
worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393
|
||
kthread+0x2c1/0x3a0 kernel/kthread.c:389
|
||
ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
|
||
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244(CVE-2024-40959)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
ipv6: prevent possible NULL deref in fib6_nh_init()
|
||
|
||
syzbot reminds us that in6_dev_get() can return NULL.
|
||
|
||
fib6_nh_init()
|
||
ip6_validate_gw( &idev )
|
||
ip6_route_check_nh( idev )
|
||
*idev = in6_dev_get(dev); // can be NULL
|
||
|
||
Oops: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI
|
||
KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7]
|
||
CPU: 0 PID: 11237 Comm: syz-executor.3 Not tainted 6.10.0-rc2-syzkaller-00249-gbe27b8965297 #0
|
||
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024
|
||
RIP: 0010:fib6_nh_init+0x640/0x2160 net/ipv6/route.c:3606
|
||
Code: 00 00 fc ff df 4c 8b 64 24 58 48 8b 44 24 28 4c 8b 74 24 30 48 89 c1 48 89 44 24 28 48 8d 98 e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 0f 85 b3 17 00 00 8b 1b 31 ff 89 de e8 b8 8b
|
||
RSP: 0018:ffffc900032775a0 EFLAGS: 00010202
|
||
RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000000000
|
||
RDX: 0000000000000010 RSI: ffffc90003277a54 RDI: ffff88802b3a08d8
|
||
RBP: ffffc900032778b0 R08: 00000000000002fc R09: 0000000000000000
|
||
R10: 00000000000002fc R11: 0000000000000000 R12: ffff88802b3a08b8
|
||
R13: 1ffff9200064eec8 R14: ffffc90003277a00 R15: dffffc0000000000
|
||
FS: 00007f940feb06c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
|
||
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
||
CR2: 0000000000000000 CR3: 00000000245e8000 CR4: 00000000003506f0
|
||
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
||
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
||
Call Trace:
|
||
<TASK>
|
||
ip6_route_info_create+0x99e/0x12b0 net/ipv6/route.c:3809
|
||
ip6_route_add+0x28/0x160 net/ipv6/route.c:3853
|
||
ipv6_route_ioctl+0x588/0x870 net/ipv6/route.c:4483
|
||
inet6_ioctl+0x21a/0x280 net/ipv6/af_inet6.c:579
|
||
sock_do_ioctl+0x158/0x460 net/socket.c:1222
|
||
sock_ioctl+0x629/0x8e0 net/socket.c:1341
|
||
vfs_ioctl fs/ioctl.c:51 [inline]
|
||
__do_sys_ioctl fs/ioctl.c:907 [inline]
|
||
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
|
||
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
||
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
|
||
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
||
RIP: 0033:0x7f940f07cea9(CVE-2024-40961)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
drm/lima: mask irqs in timeout path before hard reset
|
||
|
||
There is a race condition in which a rendering job might take just long
|
||
enough to trigger the drm sched job timeout handler but also still
|
||
complete before the hard reset is done by the timeout handler.
|
||
This runs into race conditions not expected by the timeout handler.
|
||
In some very specific cases it currently may result in a refcount
|
||
imbalance on lima_pm_idle, with a stack dump such as:
|
||
|
||
[10136.669170] WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/lima/lima_devfreq.c:205 lima_devfreq_record_idle+0xa0/0xb0
|
||
...
|
||
[10136.669459] pc : lima_devfreq_record_idle+0xa0/0xb0
|
||
...
|
||
[10136.669628] Call trace:
|
||
[10136.669634] lima_devfreq_record_idle+0xa0/0xb0
|
||
[10136.669646] lima_sched_pipe_task_done+0x5c/0xb0
|
||
[10136.669656] lima_gp_irq_handler+0xa8/0x120
|
||
[10136.669666] __handle_irq_event_percpu+0x48/0x160
|
||
[10136.669679] handle_irq_event+0x4c/0xc0
|
||
|
||
We can prevent that race condition entirely by masking the irqs at the
|
||
beginning of the timeout handler, at which point we give up on waiting
|
||
for that job entirely.
|
||
The irqs will be enabled again at the next hard reset which is already
|
||
done as a recovery by the timeout handler.(CVE-2024-40976)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
drm/radeon: fix UBSAN warning in kv_dpm.c
|
||
|
||
Adds bounds check for sumo_vid_mapping_entry.(CVE-2024-40988)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
net: ena: Add validation for completion descriptors consistency
|
||
|
||
Validate that `first` flag is set only for the first
|
||
descriptor in multi-buffer packets.
|
||
In case of an invalid descriptor, a reset will occur.
|
||
A new reset reason for RX data corruption has been added.(CVE-2024-40999)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
netrom: Fix a memory leak in nr_heartbeat_expiry()
|
||
|
||
syzbot reported a memory leak in nr_create() [0].
|
||
|
||
Commit 409db27e3a2e ("netrom: Fix use-after-free of a listening socket.")
|
||
added sock_hold() to the nr_heartbeat_expiry() function, where
|
||
a) a socket has a SOCK_DESTROY flag or
|
||
b) a listening socket has a SOCK_DEAD flag.
|
||
|
||
But in the case "a," when the SOCK_DESTROY flag is set, the file descriptor
|
||
has already been closed and the nr_release() function has been called.
|
||
So it makes no sense to hold the reference count because no one will
|
||
call another nr_destroy_socket() and put it as in the case "b."
|
||
|
||
nr_connect
|
||
nr_establish_data_link
|
||
nr_start_heartbeat
|
||
|
||
nr_release
|
||
switch (nr->state)
|
||
case NR_STATE_3
|
||
nr->state = NR_STATE_2
|
||
sock_set_flag(sk, SOCK_DESTROY);
|
||
|
||
nr_rx_frame
|
||
nr_process_rx_frame
|
||
switch (nr->state)
|
||
case NR_STATE_2
|
||
nr_state2_machine()
|
||
nr_disconnect()
|
||
nr_sk(sk)->state = NR_STATE_0
|
||
sock_set_flag(sk, SOCK_DEAD)
|
||
|
||
nr_heartbeat_expiry
|
||
switch (nr->state)
|
||
case NR_STATE_0
|
||
if (sock_flag(sk, SOCK_DESTROY) ||
|
||
(sk->sk_state == TCP_LISTEN
|
||
&& sock_flag(sk, SOCK_DEAD)))
|
||
sock_hold() // ( !!! )
|
||
nr_destroy_socket()
|
||
|
||
To fix the memory leak, let's call sock_hold() only for a listening socket.
|
||
|
||
Found by InfoTeCS on behalf of Linux Verification Center
|
||
(linuxtesting.org) with Syzkaller.
|
||
|
||
[0]: https://syzkaller.appspot.com/bug?extid=d327a1f3b12e1e206c16(CVE-2024-41006)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
xfs: don't walk off the end of a directory data block
|
||
|
||
This adds sanity checks for xfs_dir2_data_unused and xfs_dir2_data_entry
|
||
to make sure don't stray beyond valid memory region. Before patching, the
|
||
loop simply checks that the start offset of the dup and dep is within the
|
||
range. So in a crafted image, if last entry is xfs_dir2_data_unused, we
|
||
can change dup->length to dup->length-1 and leave 1 byte of space. In the
|
||
next traversal, this space will be considered as dup or dep. We may
|
||
encounter an out of bound read when accessing the fixed members.
|
||
|
||
In the patch, we make sure that the remaining bytes large enough to hold
|
||
an unused entry before accessing xfs_dir2_data_unused and
|
||
xfs_dir2_data_unused is XFS_DIR2_DATA_ALIGN byte aligned. We also make
|
||
sure that the remaining bytes large enough to hold a dirent with a
|
||
single-byte name before accessing xfs_dir2_data_entry.(CVE-2024-41013)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
xfs: add bounds checking to xlog_recover_process_data
|
||
|
||
There is a lack of verification of the space occupied by fixed members
|
||
of xlog_op_header in the xlog_recover_process_data.
|
||
|
||
We can create a crafted image to trigger an out of bounds read by
|
||
following these steps:
|
||
1) Mount an image of xfs, and do some file operations to leave records
|
||
2) Before umounting, copy the image for subsequent steps to simulate
|
||
abnormal exit. Because umount will ensure that tail_blk and
|
||
head_blk are the same, which will result in the inability to enter
|
||
xlog_recover_process_data
|
||
3) Write a tool to parse and modify the copied image in step 2
|
||
4) Make the end of the xlog_op_header entries only 1 byte away from
|
||
xlog_rec_header->h_size
|
||
5) xlog_rec_header->h_num_logops++
|
||
6) Modify xlog_rec_header->h_crc
|
||
|
||
Fix:
|
||
Add a check to make sure there is sufficient space to access fixed members
|
||
of xlog_op_header.(CVE-2024-41014)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
fs/ntfs3: Validate ff offset
|
||
|
||
This adds sanity checks for ff offset. There is a check
|
||
on rt->first_free at first, but walking through by ff
|
||
without any check. If the second ff is a large offset.
|
||
We may encounter an out-of-bound read.(CVE-2024-41019)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
filelock: Fix fcntl/close race recovery compat path
|
||
|
||
When I wrote commit 3cad1bc01041 ("filelock: Remove locks reliably when
|
||
fcntl/close race is detected"), I missed that there are two copies of the
|
||
code I was patching: The normal version, and the version for 64-bit offsets
|
||
on 32-bit kernels.
|
||
Thanks to Greg KH for stumbling over this while doing the stable
|
||
backport...
|
||
|
||
Apply exactly the same fix to the compat path for 32-bit kernels.(CVE-2024-41020)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
drm/amdgpu: Fix signedness bug in sdma_v4_0_process_trap_irq()
|
||
|
||
The "instance" variable needs to be signed for the error handling to work.(CVE-2024-41022)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
sched/deadline: Fix task_struct reference leak
|
||
|
||
During the execution of the following stress test with linux-rt:
|
||
|
||
stress-ng --cyclic 30 --timeout 30 --minimize --quiet
|
||
|
||
kmemleak frequently reported a memory leak concerning the task_struct:
|
||
|
||
unreferenced object 0xffff8881305b8000 (size 16136):
|
||
comm "stress-ng", pid 614, jiffies 4294883961 (age 286.412s)
|
||
object hex dump (first 32 bytes):
|
||
02 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .@..............
|
||
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||
debug hex dump (first 16 bytes):
|
||
53 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 S...............
|
||
backtrace:
|
||
[<00000000046b6790>] dup_task_struct+0x30/0x540
|
||
[<00000000c5ca0f0b>] copy_process+0x3d9/0x50e0
|
||
[<00000000ced59777>] kernel_clone+0xb0/0x770
|
||
[<00000000a50befdc>] __do_sys_clone+0xb6/0xf0
|
||
[<000000001dbf2008>] do_syscall_64+0x5d/0xf0
|
||
[<00000000552900ff>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
||
|
||
The issue occurs in start_dl_timer(), which increments the task_struct
|
||
reference count and sets a timer. The timer callback, dl_task_timer,
|
||
is supposed to decrement the reference count upon expiration. However,
|
||
if enqueue_task_dl() is called before the timer expires and cancels it,
|
||
the reference count is not decremented, leading to the leak.
|
||
|
||
This patch fixes the reference leak by ensuring the task_struct
|
||
reference count is properly decremented when the timer is canceled.(CVE-2024-41023)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
Fix userfaultfd_api to return EINVAL as expected
|
||
|
||
Currently if we request a feature that is not set in the Kernel config we
|
||
fail silently and return all the available features. However, the man
|
||
page indicates we should return an EINVAL.
|
||
|
||
We need to fix this issue since we can end up with a Kernel warning should
|
||
a program request the feature UFFD_FEATURE_WP_UNPOPULATED on a kernel with
|
||
the config not set with this feature.
|
||
|
||
[ 200.812896] WARNING: CPU: 91 PID: 13634 at mm/memory.c:1660 zap_pte_range+0x43d/0x660
|
||
[ 200.820738] Modules linked in:
|
||
[ 200.869387] CPU: 91 PID: 13634 Comm: userfaultfd Kdump: loaded Not tainted 6.9.0-rc5+ #8
|
||
[ 200.877477] Hardware name: Dell Inc. PowerEdge R6525/0N7YGH, BIOS 2.7.3 03/30/2022
|
||
[ 200.885052] RIP: 0010:zap_pte_range+0x43d/0x660(CVE-2024-41027)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
net/sched: Fix UAF when resolving a clash
|
||
|
||
KASAN reports the following UAF:
|
||
|
||
BUG: KASAN: slab-use-after-free in tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct]
|
||
Read of size 1 at addr ffff888c07603600 by task handler130/6469
|
||
|
||
Call Trace:
|
||
<IRQ>
|
||
dump_stack_lvl+0x48/0x70
|
||
print_address_description.constprop.0+0x33/0x3d0
|
||
print_report+0xc0/0x2b0
|
||
kasan_report+0xd0/0x120
|
||
__asan_load1+0x6c/0x80
|
||
tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct]
|
||
tcf_ct_act+0x886/0x1350 [act_ct]
|
||
tcf_action_exec+0xf8/0x1f0
|
||
fl_classify+0x355/0x360 [cls_flower]
|
||
__tcf_classify+0x1fd/0x330
|
||
tcf_classify+0x21c/0x3c0
|
||
sch_handle_ingress.constprop.0+0x2c5/0x500
|
||
__netif_receive_skb_core.constprop.0+0xb25/0x1510
|
||
__netif_receive_skb_list_core+0x220/0x4c0
|
||
netif_receive_skb_list_internal+0x446/0x620
|
||
napi_complete_done+0x157/0x3d0
|
||
gro_cell_poll+0xcf/0x100
|
||
__napi_poll+0x65/0x310
|
||
net_rx_action+0x30c/0x5c0
|
||
__do_softirq+0x14f/0x491
|
||
__irq_exit_rcu+0x82/0xc0
|
||
irq_exit_rcu+0xe/0x20
|
||
common_interrupt+0xa1/0xb0
|
||
</IRQ>
|
||
<TASK>
|
||
asm_common_interrupt+0x27/0x40
|
||
|
||
Allocated by task 6469:
|
||
kasan_save_stack+0x38/0x70
|
||
kasan_set_track+0x25/0x40
|
||
kasan_save_alloc_info+0x1e/0x40
|
||
__kasan_krealloc+0x133/0x190
|
||
krealloc+0xaa/0x130
|
||
nf_ct_ext_add+0xed/0x230 [nf_conntrack]
|
||
tcf_ct_act+0x1095/0x1350 [act_ct]
|
||
tcf_action_exec+0xf8/0x1f0
|
||
fl_classify+0x355/0x360 [cls_flower]
|
||
__tcf_classify+0x1fd/0x330
|
||
tcf_classify+0x21c/0x3c0
|
||
sch_handle_ingress.constprop.0+0x2c5/0x500
|
||
__netif_receive_skb_core.constprop.0+0xb25/0x1510
|
||
__netif_receive_skb_list_core+0x220/0x4c0
|
||
netif_receive_skb_list_internal+0x446/0x620
|
||
napi_complete_done+0x157/0x3d0
|
||
gro_cell_poll+0xcf/0x100
|
||
__napi_poll+0x65/0x310
|
||
net_rx_action+0x30c/0x5c0
|
||
__do_softirq+0x14f/0x491
|
||
|
||
Freed by task 6469:
|
||
kasan_save_stack+0x38/0x70
|
||
kasan_set_track+0x25/0x40
|
||
kasan_save_free_info+0x2b/0x60
|
||
____kasan_slab_free+0x180/0x1f0
|
||
__kasan_slab_free+0x12/0x30
|
||
slab_free_freelist_hook+0xd2/0x1a0
|
||
__kmem_cache_free+0x1a2/0x2f0
|
||
kfree+0x78/0x120
|
||
nf_conntrack_free+0x74/0x130 [nf_conntrack]
|
||
nf_ct_destroy+0xb2/0x140 [nf_conntrack]
|
||
__nf_ct_resolve_clash+0x529/0x5d0 [nf_conntrack]
|
||
nf_ct_resolve_clash+0xf6/0x490 [nf_conntrack]
|
||
__nf_conntrack_confirm+0x2c6/0x770 [nf_conntrack]
|
||
tcf_ct_act+0x12ad/0x1350 [act_ct]
|
||
tcf_action_exec+0xf8/0x1f0
|
||
fl_classify+0x355/0x360 [cls_flower]
|
||
__tcf_classify+0x1fd/0x330
|
||
tcf_classify+0x21c/0x3c0
|
||
sch_handle_ingress.constprop.0+0x2c5/0x500
|
||
__netif_receive_skb_core.constprop.0+0xb25/0x1510
|
||
__netif_receive_skb_list_core+0x220/0x4c0
|
||
netif_receive_skb_list_internal+0x446/0x620
|
||
napi_complete_done+0x157/0x3d0
|
||
gro_cell_poll+0xcf/0x100
|
||
__napi_poll+0x65/0x310
|
||
net_rx_action+0x30c/0x5c0
|
||
__do_softirq+0x14f/0x491
|
||
|
||
The ct may be dropped if a clash has been resolved but is still passed to
|
||
the tcf_ct_flow_table_process_conn function for further usage. This issue
|
||
can be fixed by retrieving ct from skb again after confirming conntrack.(CVE-2024-41040)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
udp: Set SOCK_RCU_FREE earlier in udp_lib_get_port().
|
||
|
||
syzkaller triggered the warning [0] in udp_v4_early_demux().
|
||
|
||
In udp_v[46]_early_demux() and sk_lookup(), we do not touch the refcount
|
||
of the looked-up sk and use sock_pfree() as skb->destructor, so we check
|
||
SOCK_RCU_FREE to ensure that the sk is safe to access during the RCU grace
|
||
period.
|
||
|
||
Currently, SOCK_RCU_FREE is flagged for a bound socket after being put
|
||
into the hash table. Moreover, the SOCK_RCU_FREE check is done too early
|
||
in udp_v[46]_early_demux() and sk_lookup(), so there could be a small race
|
||
window:
|
||
|
||
CPU1 CPU2
|
||
---- ----
|
||
udp_v4_early_demux() udp_lib_get_port()
|
||
| |- hlist_add_head_rcu()
|
||
|- sk = __udp4_lib_demux_lookup() |
|
||
|- DEBUG_NET_WARN_ON_ONCE(sk_is_refcounted(sk));
|
||
`- sock_set_flag(sk, SOCK_RCU_FREE)
|
||
|
||
We had the same bug in TCP and fixed it in commit 871019b22d1b ("net:
|
||
set SOCK_RCU_FREE before inserting socket into hashtable").
|
||
|
||
Let's apply the same fix for UDP.
|
||
|
||
[0]:
|
||
WARNING: CPU: 0 PID: 11198 at net/ipv4/udp.c:2599 udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599
|
||
Modules linked in:
|
||
CPU: 0 PID: 11198 Comm: syz-executor.1 Not tainted 6.9.0-g93bda33046e7 #13
|
||
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
|
||
RIP: 0010:udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599
|
||
Code: c5 7a 15 fe bb 01 00 00 00 44 89 e9 31 ff d3 e3 81 e3 bf ef ff ff 89 de e8 2c 74 15 fe 85 db 0f 85 02 06 00 00 e8 9f 7a 15 fe <0f> 0b e8 98 7a 15 fe 49 8d 7e 60 e8 4f 39 2f fe 49 c7 46 60 20 52
|
||
RSP: 0018:ffffc9000ce3fa58 EFLAGS: 00010293
|
||
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8318c92c
|
||
RDX: ffff888036ccde00 RSI: ffffffff8318c2f1 RDI: 0000000000000001
|
||
RBP: ffff88805a2dd6e0 R08: 0000000000000001 R09: 0000000000000000
|
||
R10: 0000000000000000 R11: 0001ffffffffffff R12: ffff88805a2dd680
|
||
R13: 0000000000000007 R14: ffff88800923f900 R15: ffff88805456004e
|
||
FS: 00007fc449127640(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000
|
||
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
||
CR2: 00007fc449126e38 CR3: 000000003de4b002 CR4: 0000000000770ef0
|
||
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
||
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
|
||
PKRU: 55555554
|
||
Call Trace:
|
||
<TASK>
|
||
ip_rcv_finish_core.constprop.0+0xbdd/0xd20 net/ipv4/ip_input.c:349
|
||
ip_rcv_finish+0xda/0x150 net/ipv4/ip_input.c:447
|
||
NF_HOOK include/linux/netfilter.h:314 [inline]
|
||
NF_HOOK include/linux/netfilter.h:308 [inline]
|
||
ip_rcv+0x16c/0x180 net/ipv4/ip_input.c:569
|
||
__netif_receive_skb_one_core+0xb3/0xe0 net/core/dev.c:5624
|
||
__netif_receive_skb+0x21/0xd0 net/core/dev.c:5738
|
||
netif_receive_skb_internal net/core/dev.c:5824 [inline]
|
||
netif_receive_skb+0x271/0x300 net/core/dev.c:5884
|
||
tun_rx_batched drivers/net/tun.c:1549 [inline]
|
||
tun_get_user+0x24db/0x2c50 drivers/net/tun.c:2002
|
||
tun_chr_write_iter+0x107/0x1a0 drivers/net/tun.c:2048
|
||
new_sync_write fs/read_write.c:497 [inline]
|
||
vfs_write+0x76f/0x8d0 fs/read_write.c:590
|
||
ksys_write+0xbf/0x190 fs/read_write.c:643
|
||
__do_sys_write fs/read_write.c:655 [inline]
|
||
__se_sys_write fs/read_write.c:652 [inline]
|
||
__x64_sys_write+0x41/0x50 fs/read_write.c:652
|
||
x64_sys_call+0xe66/0x1990 arch/x86/include/generated/asm/syscalls_64.h:2
|
||
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
||
do_syscall_64+0x4b/0x110 arch/x86/entry/common.c:83
|
||
entry_SYSCALL_64_after_hwframe+0x4b/0x53
|
||
RIP: 0033:0x7fc44a68bc1f
|
||
Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 e9 cf f5 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 3c d0 f5 ff 48
|
||
RSP: 002b:00007fc449126c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
|
||
RAX: ffffffffffffffda RBX: 00000000004bc050 RCX: 00007fc44a68bc1f
|
||
R
|
||
---truncated---(CVE-2024-41041)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
ppp: reject claimed-as-LCP but actually malformed packets
|
||
|
||
Since 'ppp_async_encode()' assumes valid LCP packets (with code
|
||
from 1 to 7 inclusive), add 'ppp_check_packet()' to ensure that
|
||
LCP packet has an actual body beyond PPP_LCP header bytes, and
|
||
reject claimed-as-LCP but actually malformed data otherwise.(CVE-2024-41044)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
skmsg: Skip zero length skb in sk_msg_recvmsg
|
||
|
||
When running BPF selftests (./test_progs -t sockmap_basic) on a Loongarch
|
||
platform, the following kernel panic occurs:
|
||
|
||
[...]
|
||
Oops[#1]:
|
||
CPU: 22 PID: 2824 Comm: test_progs Tainted: G OE 6.10.0-rc2+ #18
|
||
Hardware name: LOONGSON Dabieshan/Loongson-TC542F0, BIOS Loongson-UDK2018
|
||
... ...
|
||
ra: 90000000048bf6c0 sk_msg_recvmsg+0x120/0x560
|
||
ERA: 9000000004162774 copy_page_to_iter+0x74/0x1c0
|
||
CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
|
||
PRMD: 0000000c (PPLV0 +PIE +PWE)
|
||
EUEN: 00000007 (+FPE +SXE +ASXE -BTE)
|
||
ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)
|
||
ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)
|
||
BADV: 0000000000000040
|
||
PRID: 0014c011 (Loongson-64bit, Loongson-3C5000)
|
||
Modules linked in: bpf_testmod(OE) xt_CHECKSUM xt_MASQUERADE xt_conntrack
|
||
Process test_progs (pid: 2824, threadinfo=0000000000863a31, task=...)
|
||
Stack : ...
|
||
Call Trace:
|
||
[<9000000004162774>] copy_page_to_iter+0x74/0x1c0
|
||
[<90000000048bf6c0>] sk_msg_recvmsg+0x120/0x560
|
||
[<90000000049f2b90>] tcp_bpf_recvmsg_parser+0x170/0x4e0
|
||
[<90000000049aae34>] inet_recvmsg+0x54/0x100
|
||
[<900000000481ad5c>] sock_recvmsg+0x7c/0xe0
|
||
[<900000000481e1a8>] __sys_recvfrom+0x108/0x1c0
|
||
[<900000000481e27c>] sys_recvfrom+0x1c/0x40
|
||
[<9000000004c076ec>] do_syscall+0x8c/0xc0
|
||
[<9000000003731da4>] handle_syscall+0xc4/0x160
|
||
Code: ...
|
||
---[ end trace 0000000000000000 ]---
|
||
Kernel panic - not syncing: Fatal exception
|
||
Kernel relocated by 0x3510000
|
||
.text @ 0x9000000003710000
|
||
.data @ 0x9000000004d70000
|
||
.bss @ 0x9000000006469400
|
||
---[ end Kernel panic - not syncing: Fatal exception ]---
|
||
[...]
|
||
|
||
This crash happens every time when running sockmap_skb_verdict_shutdown
|
||
subtest in sockmap_basic.
|
||
|
||
This crash is because a NULL pointer is passed to page_address() in the
|
||
sk_msg_recvmsg(). Due to the different implementations depending on the
|
||
architecture, page_address(NULL) will trigger a panic on Loongarch
|
||
platform but not on x86 platform. So this bug was hidden on x86 platform
|
||
for a while, but now it is exposed on Loongarch platform. The root cause
|
||
is that a zero length skb (skb->len == 0) was put on the queue.
|
||
|
||
This zero length skb is a TCP FIN packet, which was sent by shutdown(),
|
||
invoked in test_sockmap_skb_verdict_shutdown():
|
||
|
||
shutdown(p1, SHUT_WR);
|
||
|
||
In this case, in sk_psock_skb_ingress_enqueue(), num_sge is zero, and no
|
||
page is put to this sge (see sg_set_page in sg_set_page), but this empty
|
||
sge is queued into ingress_msg list.
|
||
|
||
And in sk_msg_recvmsg(), this empty sge is used, and a NULL page is got by
|
||
sg_page(sge). Pass this NULL page to copy_page_to_iter(), which passes it
|
||
to kmap_local_page() and to page_address(), then kernel panics.
|
||
|
||
To solve this, we should skip this zero length skb. So in sk_msg_recvmsg(),
|
||
if copy is zero, that means it's a zero length skb, skip invoking
|
||
copy_page_to_iter(). We are using the EFAULT return triggered by
|
||
copy_page_to_iter to check for is_fin in tcp_bpf.c.(CVE-2024-41048)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
filelock: fix potential use-after-free in posix_lock_inode
|
||
|
||
Light Hsieh reported a KASAN UAF warning in trace_posix_lock_inode().
|
||
The request pointer had been changed earlier to point to a lock entry
|
||
that was added to the inode's list. However, before the tracepoint could
|
||
fire, another task raced in and freed that lock.
|
||
|
||
Fix this by moving the tracepoint inside the spinlock, which should
|
||
ensure that this doesn't happen.(CVE-2024-41049)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
mm: prevent derefencing NULL ptr in pfn_section_valid()
|
||
|
||
Commit 5ec8e8ea8b77 ("mm/sparsemem: fix race in accessing
|
||
memory_section->usage") changed pfn_section_valid() to add a READ_ONCE()
|
||
call around "ms->usage" to fix a race with section_deactivate() where
|
||
ms->usage can be cleared. The READ_ONCE() call, by itself, is not enough
|
||
to prevent NULL pointer dereference. We need to check its value before
|
||
dereferencing it.(CVE-2024-41055)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
bluetooth/l2cap: sync sock recv cb and release
|
||
|
||
The problem occurs between the system call to close the sock and hci_rx_work,
|
||
where the former releases the sock and the latter accesses it without lock protection.
|
||
|
||
CPU0 CPU1
|
||
---- ----
|
||
sock_close hci_rx_work
|
||
l2cap_sock_release hci_acldata_packet
|
||
l2cap_sock_kill l2cap_recv_frame
|
||
sk_free l2cap_conless_channel
|
||
l2cap_sock_recv_cb
|
||
|
||
If hci_rx_work processes the data that needs to be received before the sock is
|
||
closed, then everything is normal; Otherwise, the work thread may access the
|
||
released sock when receiving data.
|
||
|
||
Add a chan mutex in the rx callback of the sock to achieve synchronization between
|
||
the sock release and recv cb.
|
||
|
||
Sock is dead, so set chan data to NULL, avoid others use invalid sock pointer.(CVE-2024-41062)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
Bluetooth: hci_core: cancel all works upon hci_unregister_dev()
|
||
|
||
syzbot is reporting that calling hci_release_dev() from hci_error_reset()
|
||
due to hci_dev_put() from hci_error_reset() can cause deadlock at
|
||
destroy_workqueue(), for hci_error_reset() is called from
|
||
hdev->req_workqueue which destroy_workqueue() needs to flush.
|
||
|
||
We need to make sure that hdev->{rx_work,cmd_work,tx_work} which are
|
||
queued into hdev->workqueue and hdev->{power_on,error_reset} which are
|
||
queued into hdev->req_workqueue are no longer running by the moment
|
||
|
||
destroy_workqueue(hdev->workqueue);
|
||
destroy_workqueue(hdev->req_workqueue);
|
||
|
||
are called from hci_release_dev().
|
||
|
||
Call cancel_work_sync() on these work items from hci_unregister_dev()
|
||
as soon as hdev->list is removed from hci_dev_list.(CVE-2024-41063)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
powerpc/eeh: avoid possible crash when edev->pdev changes
|
||
|
||
If a PCI device is removed during eeh_pe_report_edev(), edev->pdev
|
||
will change and can cause a crash, hold the PCI rescan/remove lock
|
||
while taking a copy of edev->pdev->bus.(CVE-2024-41064)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
ibmvnic: Add tx check to prevent skb leak
|
||
|
||
Below is a summary of how the driver stores a reference to an skb during
|
||
transmit:
|
||
tx_buff[free_map[consumer_index]]->skb = new_skb;
|
||
free_map[consumer_index] = IBMVNIC_INVALID_MAP;
|
||
consumer_index ++;
|
||
Where variable data looks like this:
|
||
free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3]
|
||
consumer_index^
|
||
tx_buff == [skb=null, skb=<ptr>, skb=<ptr>, skb=null, skb=null]
|
||
|
||
The driver has checks to ensure that free_map[consumer_index] pointed to
|
||
a valid index but there was no check to ensure that this index pointed
|
||
to an unused/null skb address. So, if, by some chance, our free_map and
|
||
tx_buff lists become out of sync then we were previously risking an
|
||
skb memory leak. This could then cause tcp congestion control to stop
|
||
sending packets, eventually leading to ETIMEDOUT.
|
||
|
||
Therefore, add a conditional to ensure that the skb address is null. If
|
||
not then warn the user (because this is still a bug that should be
|
||
patched) and free the old pointer to prevent memleak/tcp problems.(CVE-2024-41066)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
ASoC: topology: Fix references to freed memory
|
||
|
||
Most users after parsing a topology file, release memory used by it, so
|
||
having pointer references directly into topology file contents is wrong.
|
||
Use devm_kmemdup(), to allocate memory as needed.(CVE-2024-41069)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
KVM: PPC: Book3S HV: Prevent UAF in kvm_spapr_tce_attach_iommu_group()
|
||
|
||
Al reported a possible use-after-free (UAF) in kvm_spapr_tce_attach_iommu_group().
|
||
|
||
It looks up `stt` from tablefd, but then continues to use it after doing
|
||
fdput() on the returned fd. After the fdput() the tablefd is free to be
|
||
closed by another thread. The close calls kvm_spapr_tce_release() and
|
||
then release_spapr_tce_table() (via call_rcu()) which frees `stt`.
|
||
|
||
Although there are calls to rcu_read_lock() in
|
||
kvm_spapr_tce_attach_iommu_group() they are not sufficient to prevent
|
||
the UAF, because `stt` is used outside the locked regions.
|
||
|
||
With an artifcial delay after the fdput() and a userspace program which
|
||
triggers the race, KASAN detects the UAF:
|
||
|
||
BUG: KASAN: slab-use-after-free in kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]
|
||
Read of size 4 at addr c000200027552c30 by task kvm-vfio/2505
|
||
CPU: 54 PID: 2505 Comm: kvm-vfio Not tainted 6.10.0-rc3-next-20240612-dirty #1
|
||
Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV
|
||
Call Trace:
|
||
dump_stack_lvl+0xb4/0x108 (unreliable)
|
||
print_report+0x2b4/0x6ec
|
||
kasan_report+0x118/0x2b0
|
||
__asan_load4+0xb8/0xd0
|
||
kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]
|
||
kvm_vfio_set_attr+0x524/0xac0 [kvm]
|
||
kvm_device_ioctl+0x144/0x240 [kvm]
|
||
sys_ioctl+0x62c/0x1810
|
||
system_call_exception+0x190/0x440
|
||
system_call_vectored_common+0x15c/0x2ec
|
||
...
|
||
Freed by task 0:
|
||
...
|
||
kfree+0xec/0x3e0
|
||
release_spapr_tce_table+0xd4/0x11c [kvm]
|
||
rcu_core+0x568/0x16a0
|
||
handle_softirqs+0x23c/0x920
|
||
do_softirq_own_stack+0x6c/0x90
|
||
do_softirq_own_stack+0x58/0x90
|
||
__irq_exit_rcu+0x218/0x2d0
|
||
irq_exit+0x30/0x80
|
||
arch_local_irq_restore+0x128/0x230
|
||
arch_local_irq_enable+0x1c/0x30
|
||
cpuidle_enter_state+0x134/0x5cc
|
||
cpuidle_enter+0x6c/0xb0
|
||
call_cpuidle+0x7c/0x100
|
||
do_idle+0x394/0x410
|
||
cpu_startup_entry+0x60/0x70
|
||
start_secondary+0x3fc/0x410
|
||
start_secondary_prolog+0x10/0x14
|
||
|
||
Fix it by delaying the fdput() until `stt` is no longer in use, which
|
||
is effectively the entire function. To keep the patch minimal add a call
|
||
to fdput() at each of the existing return paths. Future work can convert
|
||
the function to goto or __cleanup style cleanup.
|
||
|
||
With the fix in place the test case no longer triggers the UAF.(CVE-2024-41070)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
wifi: cfg80211: wext: add extra SIOCSIWSCAN data check
|
||
|
||
In 'cfg80211_wext_siwscan()', add extra check whether number of
|
||
channels passed via 'ioctl(sock, SIOCSIWSCAN, ...)' doesn't exceed
|
||
IW_MAX_FREQUENCIES and reject invalid request with -EINVAL otherwise.(CVE-2024-41072)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
nvme: avoid double free special payload
|
||
|
||
If a discard request needs to be retried, and that retry may fail before
|
||
a new special payload is added, a double free will result. Clear the
|
||
RQF_SPECIAL_LOAD when the request is cleaned.(CVE-2024-41073)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
null_blk: fix validation of block size
|
||
|
||
Block size should be between 512 and PAGE_SIZE and be a power of 2. The current
|
||
check does not validate this, so update the check.
|
||
|
||
Without this patch, null_blk would Oops due to a null pointer deref when
|
||
loaded with bs=1536 [1].
|
||
|
||
|
||
[axboe: remove unnecessary braces and != 0 check](CVE-2024-41077)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
nvmet: always initialize cqe.result
|
||
|
||
The spec doesn't mandate that the first two double words (aka results)
|
||
for the command queue entry need to be set to 0 when they are not
|
||
used (not specified). Though, the target implemention returns 0 for TCP
|
||
and FC but not for RDMA.
|
||
|
||
Let's make RDMA behave the same and thus explicitly initializing the
|
||
result field. This prevents leaking any data from the stack.(CVE-2024-41079)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
io_uring: fix possible deadlock in io_register_iowq_max_workers()
|
||
|
||
The io_register_iowq_max_workers() function calls io_put_sq_data(),
|
||
which acquires the sqd->lock without releasing the uring_lock.
|
||
Similar to the commit 009ad9f0c6ee ("io_uring: drop ctx->uring_lock
|
||
before acquiring sqd->lock"), this can lead to a potential deadlock
|
||
situation.
|
||
|
||
To resolve this issue, the uring_lock is released before calling
|
||
io_put_sq_data(), and then it is re-acquired after the function call.
|
||
|
||
This change ensures that the locks are acquired in the correct
|
||
order, preventing the possibility of a deadlock.(CVE-2024-41080)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
ila: block BH in ila_output()
|
||
|
||
As explained in commit 1378817486d6 ("tipc: block BH
|
||
before using dst_cache"), net/core/dst_cache.c
|
||
helpers need to be called with BH disabled.
|
||
|
||
ila_output() is called from lwtunnel_output()
|
||
possibly from process context, and under rcu_read_lock().
|
||
|
||
We might be interrupted by a softirq, re-enter ila_output()
|
||
and corrupt dst_cache data structures.
|
||
|
||
Fix the race by using local_bh_disable().(CVE-2024-41081)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
ata: libata-core: Fix double free on error
|
||
|
||
If e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jump
|
||
to the err_out label, which will call devres_release_group().
|
||
devres_release_group() will trigger a call to ata_host_release().
|
||
ata_host_release() calls kfree(host), so executing the kfree(host) in
|
||
ata_host_alloc() will lead to a double free:
|
||
|
||
kernel BUG at mm/slub.c:553!
|
||
Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
|
||
CPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47
|
||
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
|
||
RIP: 0010:kfree+0x2cf/0x2f0
|
||
Code: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da
|
||
RSP: 0018:ffffc90000f377f0 EFLAGS: 00010246
|
||
RAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320
|
||
RDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0
|
||
RBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000
|
||
R10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780
|
||
R13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006
|
||
FS: 00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000
|
||
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
||
CR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0
|
||
PKRU: 55555554
|
||
Call Trace:
|
||
<TASK>
|
||
? __die_body.cold+0x19/0x27
|
||
? die+0x2e/0x50
|
||
? do_trap+0xca/0x110
|
||
? do_error_trap+0x6a/0x90
|
||
? kfree+0x2cf/0x2f0
|
||
? exc_invalid_op+0x50/0x70
|
||
? kfree+0x2cf/0x2f0
|
||
? asm_exc_invalid_op+0x1a/0x20
|
||
? ata_host_alloc+0xf5/0x120 [libata]
|
||
? ata_host_alloc+0xf5/0x120 [libata]
|
||
? kfree+0x2cf/0x2f0
|
||
ata_host_alloc+0xf5/0x120 [libata]
|
||
ata_host_alloc_pinfo+0x14/0xa0 [libata]
|
||
ahci_init_one+0x6c9/0xd20 [ahci]
|
||
|
||
Ensure that we will not call kfree(host) twice, by performing the kfree()
|
||
only if the devres_open_group() call failed.(CVE-2024-41087)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes
|
||
|
||
In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is
|
||
assigned to mode, which will lead to a possible NULL pointer dereference
|
||
on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode().
|
||
Add a check to avoid null pointer dereference.(CVE-2024-41089)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
tap: add missing verification for short frame
|
||
|
||
The cited commit missed to check against the validity of the frame length
|
||
in the tap_get_user_xdp() path, which could cause a corrupted skb to be
|
||
sent downstack. Even before the skb is transmitted, the
|
||
tap_get_user_xdp()-->skb_set_network_header() may assume the size is more
|
||
than ETH_HLEN. Once transmitted, this could either cause out-of-bound
|
||
access beyond the actual length, or confuse the underlayer with incorrect
|
||
or inconsistent header length in the skb metadata.
|
||
|
||
In the alternative path, tap_get_user() already prohibits short frame which
|
||
has the length less than Ethernet header size from being transmitted.
|
||
|
||
This is to drop any frame shorter than the Ethernet header size just like
|
||
how tap_get_user() does.
|
||
|
||
CVE: CVE-2024-41090(CVE-2024-41090)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
tun: add missing verification for short frame
|
||
|
||
The cited commit missed to check against the validity of the frame length
|
||
in the tun_xdp_one() path, which could cause a corrupted skb to be sent
|
||
downstack. Even before the skb is transmitted, the
|
||
tun_xdp_one-->eth_type_trans() may access the Ethernet header although it
|
||
can be less than ETH_HLEN. Once transmitted, this could either cause
|
||
out-of-bound access beyond the actual length, or confuse the underlayer
|
||
with incorrect or inconsistent header length in the skb metadata.
|
||
|
||
In the alternative path, tun_get_user() already prohibits short frame which
|
||
has the length less than Ethernet header size from being transmitted for
|
||
IFF_TAP.
|
||
|
||
This is to drop any frame shorter than the Ethernet header size just like
|
||
how tun_get_user() does.
|
||
|
||
CVE: CVE-2024-41091(CVE-2024-41091)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
usb: atm: cxacru: fix endpoint checking in cxacru_bind()
|
||
|
||
Syzbot is still reporting quite an old issue [1] that occurs due to
|
||
incomplete checking of present usb endpoints. As such, wrong
|
||
endpoints types may be used at urb sumbitting stage which in turn
|
||
triggers a warning in usb_submit_urb().
|
||
|
||
Fix the issue by verifying that required endpoint types are present
|
||
for both in and out endpoints, taking into account cmd endpoint type.
|
||
|
||
Unfortunately, this patch has not been tested on real hardware.
|
||
|
||
[1] Syzbot report:
|
||
usb 1-1: BOGUS urb xfer, pipe 1 != type 3
|
||
WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502
|
||
Modules linked in:
|
||
CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0
|
||
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
|
||
Workqueue: usb_hub_wq hub_event
|
||
RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502
|
||
...
|
||
Call Trace:
|
||
cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649
|
||
cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760
|
||
cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209
|
||
usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055
|
||
cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363
|
||
usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396
|
||
call_driver_probe drivers/base/dd.c:517 [inline]
|
||
really_probe+0x23c/0xcd0 drivers/base/dd.c:595
|
||
__driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747
|
||
driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777
|
||
__device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894
|
||
bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427
|
||
__device_attach+0x228/0x4a0 drivers/base/dd.c:965
|
||
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487
|
||
device_add+0xc2f/0x2180 drivers/base/core.c:3354
|
||
usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170
|
||
usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238
|
||
usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293(CVE-2024-41097)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
bpf: Take return from set_memory_ro() into account with bpf_prog_lock_ro()
|
||
|
||
set_memory_ro() can fail, leaving memory unprotected.
|
||
|
||
Check its return and take it into account as an error.(CVE-2024-42068)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
net: can: j1939: Initialize unused data in j1939_send_one()
|
||
|
||
syzbot reported kernel-infoleak in raw_recvmsg() [1]. j1939_send_one()
|
||
creates full frame including unused data, but it doesn't initialize
|
||
it. This causes the kernel-infoleak issue. Fix this by initializing
|
||
unused data.
|
||
|
||
[1]
|
||
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
||
BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]
|
||
BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]
|
||
BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
|
||
BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]
|
||
BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
|
||
instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
||
copy_to_user_iter lib/iov_iter.c:24 [inline]
|
||
iterate_ubuf include/linux/iov_iter.h:29 [inline]
|
||
iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
|
||
iterate_and_advance include/linux/iov_iter.h:271 [inline]
|
||
_copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
|
||
copy_to_iter include/linux/uio.h:196 [inline]
|
||
memcpy_to_msg include/linux/skbuff.h:4113 [inline]
|
||
raw_recvmsg+0x2b8/0x9e0 net/can/raw.c:1008
|
||
sock_recvmsg_nosec net/socket.c:1046 [inline]
|
||
sock_recvmsg+0x2c4/0x340 net/socket.c:1068
|
||
____sys_recvmsg+0x18a/0x620 net/socket.c:2803
|
||
___sys_recvmsg+0x223/0x840 net/socket.c:2845
|
||
do_recvmmsg+0x4fc/0xfd0 net/socket.c:2939
|
||
__sys_recvmmsg net/socket.c:3018 [inline]
|
||
__do_sys_recvmmsg net/socket.c:3041 [inline]
|
||
__se_sys_recvmmsg net/socket.c:3034 [inline]
|
||
__x64_sys_recvmmsg+0x397/0x490 net/socket.c:3034
|
||
x64_sys_call+0xf6c/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:300
|
||
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
||
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
|
||
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
||
|
||
Uninit was created at:
|
||
slab_post_alloc_hook mm/slub.c:3804 [inline]
|
||
slab_alloc_node mm/slub.c:3845 [inline]
|
||
kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888
|
||
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577
|
||
__alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668
|
||
alloc_skb include/linux/skbuff.h:1313 [inline]
|
||
alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504
|
||
sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795
|
||
sock_alloc_send_skb include/net/sock.h:1842 [inline]
|
||
j1939_sk_alloc_skb net/can/j1939/socket.c:878 [inline]
|
||
j1939_sk_send_loop net/can/j1939/socket.c:1142 [inline]
|
||
j1939_sk_sendmsg+0xc0a/0x2730 net/can/j1939/socket.c:1277
|
||
sock_sendmsg_nosec net/socket.c:730 [inline]
|
||
__sock_sendmsg+0x30f/0x380 net/socket.c:745
|
||
____sys_sendmsg+0x877/0xb60 net/socket.c:2584
|
||
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
|
||
__sys_sendmsg net/socket.c:2667 [inline]
|
||
__do_sys_sendmsg net/socket.c:2676 [inline]
|
||
__se_sys_sendmsg net/socket.c:2674 [inline]
|
||
__x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674
|
||
x64_sys_call+0xc4b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:47
|
||
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
||
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
|
||
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
||
|
||
Bytes 12-15 of 16 are uninitialized
|
||
Memory access of size 16 starts at ffff888120969690
|
||
Data copied to user address 00000000200017c0
|
||
|
||
CPU: 1 PID: 5050 Comm: syz-executor198 Not tainted 6.9.0-rc5-syzkaller-00031-g71b1543c83d6 #0
|
||
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024(CVE-2024-42076)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
ocfs2: fix DIO failure due to insufficient transaction credits
|
||
|
||
The code in ocfs2_dio_end_io_write() estimates number of necessary
|
||
transaction credits using ocfs2_calc_extend_credits(). This however does
|
||
not take into account that the IO could be arbitrarily large and can
|
||
contain arbitrary number of extents.
|
||
|
||
Extent tree manipulations do often extend the current transaction but not
|
||
in all of the cases. For example if we have only single block extents in
|
||
the tree, ocfs2_mark_extent_written() will end up calling
|
||
ocfs2_replace_extent_rec() all the time and we will never extend the
|
||
current transaction and eventually exhaust all the transaction credits if
|
||
the IO contains many single block extents. Once that happens a
|
||
WARN_ON(jbd2_handle_buffer_credits(handle) <= 0) is triggered in
|
||
jbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response to
|
||
this error. This was actually triggered by one of our customers on a
|
||
heavily fragmented OCFS2 filesystem.
|
||
|
||
To fix the issue make sure the transaction always has enough credits for
|
||
one extent insert before each call of ocfs2_mark_extent_written().
|
||
|
||
Heming Zhao said:
|
||
|
||
------
|
||
PANIC: "Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error"
|
||
|
||
PID: xxx TASK: xxxx CPU: 5 COMMAND: "SubmitThread-CA"
|
||
#0 machine_kexec at ffffffff8c069932
|
||
#1 __crash_kexec at ffffffff8c1338fa
|
||
#2 panic at ffffffff8c1d69b9
|
||
#3 ocfs2_handle_error at ffffffffc0c86c0c [ocfs2]
|
||
#4 __ocfs2_abort at ffffffffc0c88387 [ocfs2]
|
||
#5 ocfs2_journal_dirty at ffffffffc0c51e98 [ocfs2]
|
||
#6 ocfs2_split_extent at ffffffffc0c27ea3 [ocfs2]
|
||
#7 ocfs2_change_extent_flag at ffffffffc0c28053 [ocfs2]
|
||
#8 ocfs2_mark_extent_written at ffffffffc0c28347 [ocfs2]
|
||
#9 ocfs2_dio_end_io_write at ffffffffc0c2bef9 [ocfs2]
|
||
#10 ocfs2_dio_end_io at ffffffffc0c2c0f5 [ocfs2]
|
||
#11 dio_complete at ffffffff8c2b9fa7
|
||
#12 do_blockdev_direct_IO at ffffffff8c2bc09f
|
||
#13 ocfs2_direct_IO at ffffffffc0c2b653 [ocfs2]
|
||
#14 generic_file_direct_write at ffffffff8c1dcf14
|
||
#15 __generic_file_write_iter at ffffffff8c1dd07b
|
||
#16 ocfs2_file_write_iter at ffffffffc0c49f1f [ocfs2]
|
||
#17 aio_write at ffffffff8c2cc72e
|
||
#18 kmem_cache_alloc at ffffffff8c248dde
|
||
#19 do_io_submit at ffffffff8c2ccada
|
||
#20 do_syscall_64 at ffffffff8c004984
|
||
#21 entry_SYSCALL_64_after_hwframe at ffffffff8c8000ba(CVE-2024-42077)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
RDMA/restrack: Fix potential invalid address access
|
||
|
||
struct rdma_restrack_entry's kern_name was set to KBUILD_MODNAME
|
||
in ib_create_cq(), while if the module exited but forgot del this
|
||
rdma_restrack_entry, it would cause a invalid address access in
|
||
rdma_restrack_clean() when print the owner of this rdma_restrack_entry.
|
||
|
||
These code is used to help find one forgotten PD release in one of the
|
||
ULPs. But it is not needed anymore, so delete them.(CVE-2024-42080)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
xdp: Remove WARN() from __xdp_reg_mem_model()
|
||
|
||
syzkaller reports a warning in __xdp_reg_mem_model().
|
||
|
||
The warning occurs only if __mem_id_init_hash_table() returns an error. It
|
||
returns the error in two cases:
|
||
|
||
1. memory allocation fails;
|
||
2. rhashtable_init() fails when some fields of rhashtable_params
|
||
struct are not initialized properly.
|
||
|
||
The second case cannot happen since there is a static const rhashtable_params
|
||
struct with valid fields. So, warning is only triggered when there is a
|
||
problem with memory allocation.
|
||
|
||
Thus, there is no sense in using WARN() to handle this error and it can be
|
||
safely removed.
|
||
|
||
WARNING: CPU: 0 PID: 5065 at net/core/xdp.c:299 __xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299
|
||
|
||
CPU: 0 PID: 5065 Comm: syz-executor883 Not tainted 6.8.0-syzkaller-05271-gf99c5f563c17 #0
|
||
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
|
||
RIP: 0010:__xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299
|
||
|
||
Call Trace:
|
||
xdp_reg_mem_model+0x22/0x40 net/core/xdp.c:344
|
||
xdp_test_run_setup net/bpf/test_run.c:188 [inline]
|
||
bpf_test_run_xdp_live+0x365/0x1e90 net/bpf/test_run.c:377
|
||
bpf_prog_test_run_xdp+0x813/0x11b0 net/bpf/test_run.c:1267
|
||
bpf_prog_test_run+0x33a/0x3b0 kernel/bpf/syscall.c:4240
|
||
__sys_bpf+0x48d/0x810 kernel/bpf/syscall.c:5649
|
||
__do_sys_bpf kernel/bpf/syscall.c:5738 [inline]
|
||
__se_sys_bpf kernel/bpf/syscall.c:5736 [inline]
|
||
__x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5736
|
||
do_syscall_64+0xfb/0x240
|
||
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
||
|
||
Found by Linux Verification Center (linuxtesting.org) with syzkaller.(CVE-2024-42082)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
ftruncate: pass a signed offset
|
||
|
||
The old ftruncate() syscall, using the 32-bit off_t misses a sign
|
||
extension when called in compat mode on 64-bit architectures. As a
|
||
result, passing a negative length accidentally succeeds in truncating
|
||
to file size between 2GiB and 4GiB.
|
||
|
||
Changing the type of the compat syscall to the signed compat_off_t
|
||
changes the behavior so it instead returns -EINVAL.
|
||
|
||
The native entry point, the truncate() syscall and the corresponding
|
||
loff_t based variants are all correct already and do not suffer
|
||
from this mistake.(CVE-2024-42084)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
iio: chemical: bme680: Fix overflows in compensate() functions
|
||
|
||
There are cases in the compensate functions of the driver that
|
||
there could be overflows of variables due to bit shifting ops.
|
||
These implications were initially discussed here [1] and they
|
||
were mentioned in log message of Commit 1b3bd8592780 ("iio:
|
||
chemical: Add support for Bosch BME680 sensor").
|
||
|
||
[1]: https://lore.kernel.org/linux-iio/20180728114028.3c1bbe81@archlinux/(CVE-2024-42086)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
ASoC: fsl-asoc-card: set priv->pdev before using it
|
||
|
||
priv->pdev pointer was set after being used in
|
||
fsl_asoc_card_audmux_init().
|
||
Move this assignment at the start of the probe function, so
|
||
sub-functions can correctly use pdev through priv.
|
||
|
||
fsl_asoc_card_audmux_init() dereferences priv->pdev to get access to the
|
||
dev struct, used with dev_err macros.
|
||
As priv is zero-initialised, there would be a NULL pointer dereference.
|
||
Note that if priv->dev is dereferenced before assignment but never used,
|
||
for example if there is no error to be printed, the driver won't crash
|
||
probably due to compiler optimisations.(CVE-2024-42089)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER
|
||
|
||
In create_pinctrl(), pinctrl_maps_mutex is acquired before calling
|
||
add_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl()
|
||
calls pinctrl_free(). However, pinctrl_free() attempts to acquire
|
||
pinctrl_maps_mutex, which is already held by create_pinctrl(), leading to
|
||
a potential deadlock.
|
||
|
||
This patch resolves the issue by releasing pinctrl_maps_mutex before
|
||
calling pinctrl_free(), preventing the deadlock.
|
||
|
||
This bug was discovered and resolved using Coverity Static Analysis
|
||
Security Testing (SAST) by Synopsys, Inc.(CVE-2024-42090)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
gpio: davinci: Validate the obtained number of IRQs
|
||
|
||
Value of pdata->gpio_unbanked is taken from Device Tree. In case of broken
|
||
DT due to any error this value can be any. Without this value validation
|
||
there can be out of chips->irqs array boundaries access in
|
||
davinci_gpio_probe().
|
||
|
||
Validate the obtained nirq value so that it won't exceed the maximum
|
||
number of IRQs per bank.
|
||
|
||
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-42092)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
net/dpaa2: Avoid explicit cpumask var allocation on stack
|
||
|
||
For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask
|
||
variable on stack is not recommended since it can cause potential stack
|
||
overflow.
|
||
|
||
Instead, kernel code should always use *cpumask_var API(s) to allocate
|
||
cpumask var in config-neutral way, leaving allocation strategy to
|
||
CONFIG_CPUMASK_OFFSTACK.
|
||
|
||
Use *cpumask_var API(s) to address it.(CVE-2024-42093)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
net/iucv: Avoid explicit cpumask var allocation on stack
|
||
|
||
For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask
|
||
variable on stack is not recommended since it can cause potential stack
|
||
overflow.
|
||
|
||
Instead, kernel code should always use *cpumask_var API(s) to allocate
|
||
cpumask var in config-neutral way, leaving allocation strategy to
|
||
CONFIG_CPUMASK_OFFSTACK.
|
||
|
||
Use *cpumask_var API(s) to address it.(CVE-2024-42094)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
ALSA: emux: improve patch ioctl data validation
|
||
|
||
In load_data(), make the validation of and skipping over the main info
|
||
block match that in load_guspatch().
|
||
|
||
In load_guspatch(), add checking that the specified patch length matches
|
||
the actually supplied data, like load_data() already did.(CVE-2024-42097)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
drm/nouveau: fix null pointer dereference in nouveau_connector_get_modes
|
||
|
||
In nouveau_connector_get_modes(), the return value of drm_mode_duplicate()
|
||
is assigned to mode, which will lead to a possible NULL pointer
|
||
dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-42101)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
inet_diag: Initialize pad field in struct inet_diag_req_v2
|
||
|
||
KMSAN reported uninit-value access in raw_lookup() [1]. Diag for raw
|
||
sockets uses the pad field in struct inet_diag_req_v2 for the
|
||
underlying protocol. This field corresponds to the sdiag_raw_protocol
|
||
field in struct inet_diag_req_raw.
|
||
|
||
inet_diag_get_exact_compat() converts inet_diag_req to
|
||
inet_diag_req_v2, but leaves the pad field uninitialized. So the issue
|
||
occurs when raw_lookup() accesses the sdiag_raw_protocol field.
|
||
|
||
Fix this by initializing the pad field in
|
||
inet_diag_get_exact_compat(). Also, do the same fix in
|
||
inet_diag_dump_compat() to avoid the similar issue in the future.
|
||
|
||
[1]
|
||
BUG: KMSAN: uninit-value in raw_lookup net/ipv4/raw_diag.c:49 [inline]
|
||
BUG: KMSAN: uninit-value in raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71
|
||
raw_lookup net/ipv4/raw_diag.c:49 [inline]
|
||
raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71
|
||
raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99
|
||
inet_diag_cmd_exact+0x7d9/0x980
|
||
inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline]
|
||
inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426
|
||
sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282
|
||
netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564
|
||
sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297
|
||
netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]
|
||
netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361
|
||
netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905
|
||
sock_sendmsg_nosec net/socket.c:730 [inline]
|
||
__sock_sendmsg+0x332/0x3d0 net/socket.c:745
|
||
____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585
|
||
___sys_sendmsg+0x271/0x3b0 net/socket.c:2639
|
||
__sys_sendmsg net/socket.c:2668 [inline]
|
||
__do_sys_sendmsg net/socket.c:2677 [inline]
|
||
__se_sys_sendmsg net/socket.c:2675 [inline]
|
||
__x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675
|
||
x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47
|
||
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
||
do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83
|
||
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
||
|
||
Uninit was stored to memory at:
|
||
raw_sock_get+0x650/0x800 net/ipv4/raw_diag.c:71
|
||
raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99
|
||
inet_diag_cmd_exact+0x7d9/0x980
|
||
inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline]
|
||
inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426
|
||
sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282
|
||
netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564
|
||
sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297
|
||
netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]
|
||
netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361
|
||
netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905
|
||
sock_sendmsg_nosec net/socket.c:730 [inline]
|
||
__sock_sendmsg+0x332/0x3d0 net/socket.c:745
|
||
____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585
|
||
___sys_sendmsg+0x271/0x3b0 net/socket.c:2639
|
||
__sys_sendmsg net/socket.c:2668 [inline]
|
||
__do_sys_sendmsg net/socket.c:2677 [inline]
|
||
__se_sys_sendmsg net/socket.c:2675 [inline]
|
||
__x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675
|
||
x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47
|
||
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
||
do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83
|
||
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
||
|
||
Local variable req.i created at:
|
||
inet_diag_get_exact_compat net/ipv4/inet_diag.c:1396 [inline]
|
||
inet_diag_rcv_msg_compat+0x2a6/0x530 net/ipv4/inet_diag.c:1426
|
||
sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282
|
||
|
||
CPU: 1 PID: 8888 Comm: syz-executor.6 Not tainted 6.10.0-rc4-00217-g35bb670d65fc #32
|
||
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014(CVE-2024-42106)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
jffs2: Fix potential illegal address access in jffs2_free_inode
|
||
|
||
During the stress testing of the jffs2 file system,the following
|
||
abnormal printouts were found:
|
||
[ 2430.649000] Unable to handle kernel paging request at virtual address 0069696969696948
|
||
[ 2430.649622] Mem abort info:
|
||
[ 2430.649829] ESR = 0x96000004
|
||
[ 2430.650115] EC = 0x25: DABT (current EL), IL = 32 bits
|
||
[ 2430.650564] SET = 0, FnV = 0
|
||
[ 2430.650795] EA = 0, S1PTW = 0
|
||
[ 2430.651032] FSC = 0x04: level 0 translation fault
|
||
[ 2430.651446] Data abort info:
|
||
[ 2430.651683] ISV = 0, ISS = 0x00000004
|
||
[ 2430.652001] CM = 0, WnR = 0
|
||
[ 2430.652558] [0069696969696948] address between user and kernel address ranges
|
||
[ 2430.653265] Internal error: Oops: 96000004 [#1] PREEMPT SMP
|
||
[ 2430.654512] CPU: 2 PID: 20919 Comm: cat Not tainted 5.15.25-g512f31242bf6 #33
|
||
[ 2430.655008] Hardware name: linux,dummy-virt (DT)
|
||
[ 2430.655517] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
||
[ 2430.656142] pc : kfree+0x78/0x348
|
||
[ 2430.656630] lr : jffs2_free_inode+0x24/0x48
|
||
[ 2430.657051] sp : ffff800009eebd10
|
||
[ 2430.657355] x29: ffff800009eebd10 x28: 0000000000000001 x27: 0000000000000000
|
||
[ 2430.658327] x26: ffff000038f09d80 x25: 0080000000000000 x24: ffff800009d38000
|
||
[ 2430.658919] x23: 5a5a5a5a5a5a5a5a x22: ffff000038f09d80 x21: ffff8000084f0d14
|
||
[ 2430.659434] x20: ffff0000bf9a6ac0 x19: 0169696969696940 x18: 0000000000000000
|
||
[ 2430.659969] x17: ffff8000b6506000 x16: ffff800009eec000 x15: 0000000000004000
|
||
[ 2430.660637] x14: 0000000000000000 x13: 00000001000820a1 x12: 00000000000d1b19
|
||
[ 2430.661345] x11: 0004000800000000 x10: 0000000000000001 x9 : ffff8000084f0d14
|
||
[ 2430.662025] x8 : ffff0000bf9a6b40 x7 : ffff0000bf9a6b48 x6 : 0000000003470302
|
||
[ 2430.662695] x5 : ffff00002e41dcc0 x4 : ffff0000bf9aa3b0 x3 : 0000000003470342
|
||
[ 2430.663486] x2 : 0000000000000000 x1 : ffff8000084f0d14 x0 : fffffc0000000000
|
||
[ 2430.664217] Call trace:
|
||
[ 2430.664528] kfree+0x78/0x348
|
||
[ 2430.664855] jffs2_free_inode+0x24/0x48
|
||
[ 2430.665233] i_callback+0x24/0x50
|
||
[ 2430.665528] rcu_do_batch+0x1ac/0x448
|
||
[ 2430.665892] rcu_core+0x28c/0x3c8
|
||
[ 2430.666151] rcu_core_si+0x18/0x28
|
||
[ 2430.666473] __do_softirq+0x138/0x3cc
|
||
[ 2430.666781] irq_exit+0xf0/0x110
|
||
[ 2430.667065] handle_domain_irq+0x6c/0x98
|
||
[ 2430.667447] gic_handle_irq+0xac/0xe8
|
||
[ 2430.667739] call_on_irq_stack+0x28/0x54
|
||
The parameter passed to kfree was 5a5a5a5a, which corresponds to the target field of
|
||
the jffs_inode_info structure. It was found that all variables in the jffs_inode_info
|
||
structure were 5a5a5a5a, except for the first member sem. It is suspected that these
|
||
variables are not initialized because they were set to 5a5a5a5a during memory testing,
|
||
which is meant to detect uninitialized memory.The sem variable is initialized in the
|
||
function jffs2_i_init_once, while other members are initialized in
|
||
the function jffs2_init_inode_info.
|
||
|
||
The function jffs2_init_inode_info is called after iget_locked,
|
||
but in the iget_locked function, the destroy_inode process is triggered,
|
||
which releases the inode and consequently, the target member of the inode
|
||
is not initialized.In concurrent high pressure scenarios, iget_locked
|
||
may enter the destroy_inode branch as described in the code.
|
||
|
||
Since the destroy_inode functionality of jffs2 only releases the target,
|
||
the fix method is to set target to NULL in jffs2_i_init_once.(CVE-2024-42115)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
scsi: qedf: Make qedf_execute_tmf() non-preemptible
|
||
|
||
Stop calling smp_processor_id() from preemptible code in
|
||
qedf_execute_tmf90. This results in BUG_ON() when running an RT kernel.
|
||
|
||
[ 659.343280] BUG: using smp_processor_id() in preemptible [00000000] code: sg_reset/3646
|
||
[ 659.343282] caller is qedf_execute_tmf+0x8b/0x360 [qedf](CVE-2024-42124)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
leds: mlxreg: Use devm_mutex_init() for mutex initialization
|
||
|
||
In this driver LEDs are registered using devm_led_classdev_register()
|
||
so they are automatically unregistered after module's remove() is done.
|
||
led_classdev_unregister() calls module's led_set_brightness() to turn off
|
||
the LEDs and that callback uses mutex which was destroyed already
|
||
in module's remove() so use devm API instead.(CVE-2024-42129)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
Bluetooth: qca: Fix BT enable failure again for QCA6390 after warm reboot
|
||
|
||
Commit 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed
|
||
serdev") will cause below regression issue:
|
||
|
||
BT can't be enabled after below steps:
|
||
cold boot -> enable BT -> disable BT -> warm reboot -> BT enable failure
|
||
if property enable-gpios is not configured within DT|ACPI for QCA6390.
|
||
|
||
The commit is to fix a use-after-free issue within qca_serdev_shutdown()
|
||
by adding condition to avoid the serdev is flushed or wrote after closed
|
||
but also introduces this regression issue regarding above steps since the
|
||
VSC is not sent to reset controller during warm reboot.
|
||
|
||
Fixed by sending the VSC to reset controller within qca_serdev_shutdown()
|
||
once BT was ever enabled, and the use-after-free issue is also fixed by
|
||
this change since the serdev is still opened before it is flushed or wrote.
|
||
|
||
Verified by the reported machine Dell XPS 13 9310 laptop over below two
|
||
kernel commits:
|
||
commit e00fc2700a3f ("Bluetooth: btusb: Fix triggering coredump
|
||
implementation for QCA") of bluetooth-next tree.
|
||
commit b23d98d46d28 ("Bluetooth: btusb: Fix triggering coredump
|
||
implementation for QCA") of linus mainline tree.(CVE-2024-42137)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
IB/core: Implement a limit on UMAD receive List
|
||
|
||
The existing behavior of ib_umad, which maintains received MAD
|
||
packets in an unbounded list, poses a risk of uncontrolled growth.
|
||
As user-space applications extract packets from this list, the rate
|
||
of extraction may not match the rate of incoming packets, leading
|
||
to potential list overflow.
|
||
|
||
To address this, we introduce a limit to the size of the list. After
|
||
considering typical scenarios, such as OpenSM processing, which can
|
||
handle approximately 100k packets per second, and the 1-second retry
|
||
timeout for most packets, we set the list size limit to 200k. Packets
|
||
received beyond this limit are dropped, assuming they are likely timed
|
||
out by the time they are handled by user-space.
|
||
|
||
Notably, packets queued on the receive list due to reasons like
|
||
timed-out sends are preserved even when the list is full.(CVE-2024-42145)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
s390/pkey: Wipe copies of protected- and secure-keys
|
||
|
||
Although the clear-key of neither protected- nor secure-keys is
|
||
accessible, this key material should only be visible to the calling
|
||
process. So wipe all copies of protected- or secure-keys from stack,
|
||
even in case of an error.(CVE-2024-42155)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
f2fs: check validation of fault attrs in f2fs_build_fault_attr()
|
||
|
||
- It missed to check validation of fault attrs in parse_options(),
|
||
let's fix to add check condition in f2fs_build_fault_attr().
|
||
- Use f2fs_build_fault_attr() in __sbi_store() to clean up code.(CVE-2024-42160)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
bpf: Avoid uninitialized value in BPF_CORE_READ_BITFIELD
|
||
|
||
[Changes from V1:
|
||
- Use a default branch in the switch statement to initialize `val'.]
|
||
|
||
GCC warns that `val' may be used uninitialized in the
|
||
BPF_CRE_READ_BITFIELD macro, defined in bpf_core_read.h as:
|
||
|
||
[...]
|
||
unsigned long long val; \
|
||
[...] \
|
||
switch (__CORE_RELO(s, field, BYTE_SIZE)) { \
|
||
case 1: val = *(const unsigned char *)p; break; \
|
||
case 2: val = *(const unsigned short *)p; break; \
|
||
case 4: val = *(const unsigned int *)p; break; \
|
||
case 8: val = *(const unsigned long long *)p; break; \
|
||
} \
|
||
[...]
|
||
val; \
|
||
} \
|
||
|
||
This patch adds a default entry in the switch statement that sets
|
||
`val' to zero in order to avoid the warning, and random values to be
|
||
used in case __builtin_preserve_field_info returns unexpected values
|
||
for BPF_FIELD_BYTE_SIZE.
|
||
|
||
Tested in bpf-next master.
|
||
No regressions.(CVE-2024-42161)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
gve: Account for stopped queues when reading NIC stats
|
||
|
||
We now account for the fact that the NIC might send us stats for a
|
||
subset of queues. Without this change, gve_get_ethtool_stats might make
|
||
an invalid access on the priv->stats_report->stats array.(CVE-2024-42162)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
net: dsa: mv88e6xxx: Correct check for empty list
|
||
|
||
Since commit a3c53be55c95 ("net: dsa: mv88e6xxx: Support multiple MDIO
|
||
busses") mv88e6xxx_default_mdio_bus() has checked that the
|
||
return value of list_first_entry() is non-NULL.
|
||
|
||
This appears to be intended to guard against the list chip->mdios being
|
||
empty. However, it is not the correct check as the implementation of
|
||
list_first_entry is not designed to return NULL for empty lists.
|
||
|
||
Instead, use list_first_entry_or_null() which does return NULL if the
|
||
list is empty.
|
||
|
||
Flagged by Smatch.
|
||
Compile tested only.(CVE-2024-42224)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc
|
||
|
||
Initialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001.
|
||
V2: To really improve the handling we would actually
|
||
need to have a separate value of 0xffffffff.(Christian)(CVE-2024-42228)</Note>
|
||
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP3.
|
||
|
||
openEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.</Note>
|
||
<Note Title="Severity" Type="General" Ordinal="5" xml:lang="en">High</Note>
|
||
<Note Title="Affected Component" Type="General" Ordinal="6" xml:lang="en">kernel</Note>
|
||
</DocumentNotes>
|
||
<DocumentReferences>
|
||
<Reference Type="Self">
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Reference>
|
||
<Reference Type="openEuler CVE">
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2021-47382</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48827</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-52887</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-33621</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-35825</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38546</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38561</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38594</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38627</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39497</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39507</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40910</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40953</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40959</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40961</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40976</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40988</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40999</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41006</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41013</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41014</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41019</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41020</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41022</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41023</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41027</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41040</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41041</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41044</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41048</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41049</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41055</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41062</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41063</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41064</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41066</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41069</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41070</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41072</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41073</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41077</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41079</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41080</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41081</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41087</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41089</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41090</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41091</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41097</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42068</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42076</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42077</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42080</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42082</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42084</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42086</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42089</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42090</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42092</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42093</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42094</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42097</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42101</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42106</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42115</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42124</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42129</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42137</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42145</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42155</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42160</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42161</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42162</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42224</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42228</URL>
|
||
</Reference>
|
||
<Reference Type="Other">
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47382</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48827</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52887</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-33621</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35825</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38546</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38561</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38594</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38627</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39497</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39507</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40910</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40953</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40959</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40961</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40976</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40988</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40999</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41006</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41013</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41014</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41019</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41020</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41022</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41023</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41027</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41040</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41041</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41044</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41048</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41049</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41055</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41062</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41063</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41064</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41066</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41069</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41070</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41072</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41073</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41077</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41079</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41080</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41081</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41087</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41089</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41090</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41091</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41097</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42068</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42076</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42077</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42080</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42082</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42084</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42086</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42089</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42090</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42092</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42093</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42094</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42097</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42101</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42106</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42115</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42124</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42129</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42137</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42145</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42155</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42160</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42161</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42162</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42224</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42228</URL>
|
||
</Reference>
|
||
</DocumentReferences>
|
||
<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
|
||
<Branch Type="Product Name" Name="openEuler">
|
||
<FullProductName ProductID="openEuler-22.03-LTS-SP3" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">openEuler-22.03-LTS-SP3</FullProductName>
|
||
</Branch>
|
||
<Branch Type="Package Arch" Name="aarch64">
|
||
<FullProductName ProductID="kernel-5.10.0-222.0.0.125" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-222.0.0.125.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-debuginfo-5.10.0-222.0.0.125" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debuginfo-5.10.0-222.0.0.125.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-debugsource-5.10.0-222.0.0.125" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debugsource-5.10.0-222.0.0.125.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-devel-5.10.0-222.0.0.125" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-devel-5.10.0-222.0.0.125.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-headers-5.10.0-222.0.0.125" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-headers-5.10.0-222.0.0.125.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-source-5.10.0-222.0.0.125" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-source-5.10.0-222.0.0.125.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-tools-5.10.0-222.0.0.125" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-5.10.0-222.0.0.125.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-222.0.0.125" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-debuginfo-5.10.0-222.0.0.125.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-tools-devel-5.10.0-222.0.0.125" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-devel-5.10.0-222.0.0.125.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="perf-5.10.0-222.0.0.125" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-5.10.0-222.0.0.125.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="perf-debuginfo-5.10.0-222.0.0.125" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-debuginfo-5.10.0-222.0.0.125.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="python3-perf-5.10.0-222.0.0.125" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-5.10.0-222.0.0.125.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-222.0.0.125" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-debuginfo-5.10.0-222.0.0.125.oe2203sp3.aarch64.rpm</FullProductName>
|
||
</Branch>
|
||
<Branch Type="Package Arch" Name="src">
|
||
<FullProductName ProductID="kernel-5.10.0-222.0.0.125" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-222.0.0.125.oe2203sp3.src.rpm</FullProductName>
|
||
</Branch>
|
||
<Branch Type="Package Arch" Name="x86_64">
|
||
<FullProductName ProductID="kernel-5.10.0-222.0.0.125" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-222.0.0.125.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-debuginfo-5.10.0-222.0.0.125" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debuginfo-5.10.0-222.0.0.125.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-debugsource-5.10.0-222.0.0.125" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debugsource-5.10.0-222.0.0.125.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-devel-5.10.0-222.0.0.125" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-devel-5.10.0-222.0.0.125.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-headers-5.10.0-222.0.0.125" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-headers-5.10.0-222.0.0.125.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-source-5.10.0-222.0.0.125" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-source-5.10.0-222.0.0.125.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-tools-5.10.0-222.0.0.125" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-5.10.0-222.0.0.125.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-222.0.0.125" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-debuginfo-5.10.0-222.0.0.125.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-tools-devel-5.10.0-222.0.0.125" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-devel-5.10.0-222.0.0.125.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="perf-5.10.0-222.0.0.125" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-5.10.0-222.0.0.125.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="perf-debuginfo-5.10.0-222.0.0.125" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-debuginfo-5.10.0-222.0.0.125.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="python3-perf-5.10.0-222.0.0.125" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-5.10.0-222.0.0.125.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-222.0.0.125" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-debuginfo-5.10.0-222.0.0.125.oe2203sp3.x86_64.rpm</FullProductName>
|
||
</Branch>
|
||
</ProductTree>
|
||
<Vulnerability Ordinal="1" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
||
<Notes>
|
||
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
s390/qeth: fix deadlock during failing recovery
|
||
|
||
Commit 0b9902c1fcc5 ("s390/qeth: fix deadlock during recovery") removed
|
||
taking discipline_mutex inside qeth_do_reset(), fixing potential
|
||
deadlocks. An error path was missed though, that still takes
|
||
discipline_mutex and thus has the original deadlock potential.
|
||
|
||
Intermittent deadlocks were seen when a qeth channel path is configured
|
||
offline, causing a race between qeth_do_reset and ccwgroup_remove.
|
||
Call qeth_set_offline() directly in the qeth_do_reset() error case and
|
||
then a new variant of ccwgroup_set_offline(), without taking
|
||
discipline_mutex.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2021-47382</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>4.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-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</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:
|
||
|
||
NFSD: Fix the behavior of READ near OFFSET_MAX
|
||
|
||
Dan Aloni reports:
|
||
> Due to commit 8cfb9015280d ("NFS: Always provide aligned buffers to
|
||
> the RPC read layers") on the client, a read of 0xfff is aligned up
|
||
> to server rsize of 0x1000.
|
||
>
|
||
> As a result, in a test where the server has a file of size
|
||
> 0x7fffffffffffffff, and the client tries to read from the offset
|
||
> 0x7ffffffffffff000, the read causes loff_t overflow in the server
|
||
> and it returns an NFS code of EINVAL to the client. The client as
|
||
> a result indefinitely retries the request.
|
||
|
||
The Linux NFS client does not handle NFS?ERR_INVAL, even though all
|
||
NFS specifications permit servers to return that status code for a
|
||
READ.
|
||
|
||
Instead of NFS?ERR_INVAL, have out-of-range READ requests succeed
|
||
and return a short result. Set the EOF flag in the result to prevent
|
||
the client from retrying the READ request. This behavior appears to
|
||
be consistent with Solaris NFS servers.
|
||
|
||
Note that NFSv3 and NFSv4 use u64 offset values on the wire. These
|
||
must be converted to loff_t internally before use -- an implicit
|
||
type cast is not adequate for this purpose. Otherwise VFS checks
|
||
against sb->s_maxbytes do not work properly.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2022-48827</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</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:
|
||
|
||
net: can: j1939: enhanced error handling for tightly received RTS messages in xtp_rx_rts_session_new
|
||
|
||
This patch enhances error handling in scenarios with RTS (Request to
|
||
Send) messages arriving closely. It replaces the less informative WARN_ON_ONCE
|
||
backtraces with a new error handling method. This provides clearer error
|
||
messages and allows for the early termination of problematic sessions.
|
||
Previously, sessions were only released at the end of j1939_xtp_rx_rts().
|
||
|
||
Potentially this could be reproduced with something like:
|
||
testj1939 -r vcan0:0x80 &
|
||
while true; do
|
||
# send first RTS
|
||
cansend vcan0 18EC8090#1014000303002301;
|
||
# send second RTS
|
||
cansend vcan0 18EC8090#1014000303002301;
|
||
# send abort
|
||
cansend vcan0 18EC8090#ff00000000002301;
|
||
done</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2023-52887</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>4.6</BaseScore>
|
||
<Vector>AV:A/AC:H/PR:L/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-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</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:
|
||
|
||
ipvlan: Dont Use skb->sk in ipvlan_process_v{4,6}_outbound
|
||
|
||
Raw packet from PF_PACKET socket ontop of an IPv6-backed ipvlan device will
|
||
hit WARN_ON_ONCE() in sk_mc_loop() through sch_direct_xmit() path.
|
||
|
||
WARNING: CPU: 2 PID: 0 at net/core/sock.c:775 sk_mc_loop+0x2d/0x70
|
||
Modules linked in: sch_netem ipvlan rfkill cirrus drm_shmem_helper sg drm_kms_helper
|
||
CPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279
|
||
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
|
||
RIP: 0010:sk_mc_loop+0x2d/0x70
|
||
Code: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1c
|
||
RSP: 0018:ffffa9584015cd78 EFLAGS: 00010212
|
||
RAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001
|
||
RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000
|
||
RBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00
|
||
R10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000
|
||
R13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000
|
||
FS: 0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000
|
||
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
||
CR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0
|
||
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
||
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
||
Call Trace:
|
||
<IRQ>
|
||
? __warn (kernel/panic.c:693)
|
||
? sk_mc_loop (net/core/sock.c:760)
|
||
? report_bug (lib/bug.c:201 lib/bug.c:219)
|
||
? handle_bug (arch/x86/kernel/traps.c:239)
|
||
? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1))
|
||
? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)
|
||
? sk_mc_loop (net/core/sock.c:760)
|
||
ip6_finish_output2 (net/ipv6/ip6_output.c:83 (discriminator 1))
|
||
? nf_hook_slow (net/netfilter/core.c:626)
|
||
ip6_finish_output (net/ipv6/ip6_output.c:222)
|
||
? __pfx_ip6_finish_output (net/ipv6/ip6_output.c:215)
|
||
ipvlan_xmit_mode_l3 (drivers/net/ipvlan/ipvlan_core.c:602) ipvlan
|
||
ipvlan_start_xmit (drivers/net/ipvlan/ipvlan_main.c:226) ipvlan
|
||
dev_hard_start_xmit (net/core/dev.c:3594)
|
||
sch_direct_xmit (net/sched/sch_generic.c:343)
|
||
__qdisc_run (net/sched/sch_generic.c:416)
|
||
net_tx_action (net/core/dev.c:5286)
|
||
handle_softirqs (kernel/softirq.c:555)
|
||
__irq_exit_rcu (kernel/softirq.c:589)
|
||
sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1043)
|
||
|
||
The warning triggers as this:
|
||
packet_sendmsg
|
||
packet_snd //skb->sk is packet sk
|
||
__dev_queue_xmit
|
||
__dev_xmit_skb //q->enqueue is not NULL
|
||
__qdisc_run
|
||
sch_direct_xmit
|
||
dev_hard_start_xmit
|
||
ipvlan_start_xmit
|
||
ipvlan_xmit_mode_l3 //l3 mode
|
||
ipvlan_process_outbound //vepa flag
|
||
ipvlan_process_v6_outbound
|
||
ip6_local_out
|
||
__ip6_finish_output
|
||
ip6_finish_output2 //multicast packet
|
||
sk_mc_loop //sk->sk_family is AF_PACKET
|
||
|
||
Call ip{6}_local_out() with NULL sk in ipvlan as other tunnels to fix this.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-33621</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</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:
|
||
|
||
usb: gadget: ncm: Fix handling of zero block length packets
|
||
|
||
While connecting to a Linux host with CDC_NCM_NTB_DEF_SIZE_TX
|
||
set to 65536, it has been observed that we receive short packets,
|
||
which come at interval of 5-10 seconds sometimes and have block
|
||
length zero but still contain 1-2 valid datagrams present.
|
||
|
||
According to the NCM spec:
|
||
|
||
"If wBlockLength = 0x0000, the block is terminated by a
|
||
short packet. In this case, the USB transfer must still
|
||
be shorter than dwNtbInMaxSize or dwNtbOutMaxSize. If
|
||
exactly dwNtbInMaxSize or dwNtbOutMaxSize bytes are sent,
|
||
and the size is a multiple of wMaxPacketSize for the
|
||
given pipe, then no ZLP shall be sent.
|
||
|
||
wBlockLength= 0x0000 must be used with extreme care, because
|
||
of the possibility that the host and device may get out of
|
||
sync, and because of test issues.
|
||
|
||
wBlockLength = 0x0000 allows the sender to reduce latency by
|
||
starting to send a very large NTB, and then shortening it when
|
||
the sender discovers that there’s not sufficient data to justify
|
||
sending a large NTB"
|
||
|
||
However, there is a potential issue with the current implementation,
|
||
as it checks for the occurrence of multiple NTBs in a single
|
||
giveback by verifying if the leftover bytes to be processed is zero
|
||
or not. If the block length reads zero, we would process the same
|
||
NTB infintely because the leftover bytes is never zero and it leads
|
||
to a crash. Fix this by bailing out if block length reads zero.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-35825</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</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:
|
||
|
||
drm: vc4: Fix possible null pointer dereference
|
||
|
||
In vc4_hdmi_audio_init() of_get_address() may return
|
||
NULL which is later dereferenced. Fix this bug by adding NULL check.
|
||
|
||
Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-38546</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>4.4</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</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:
|
||
|
||
kunit: Fix kthread reference
|
||
|
||
There is a race condition when a kthread finishes after the deadline and
|
||
before the call to kthread_stop(), which may lead to use after free.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-38561</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.8</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</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:
|
||
|
||
net: stmmac: move the EST lock to struct stmmac_priv
|
||
|
||
Reinitialize the whole EST structure would also reset the mutex
|
||
lock which is embedded in the EST structure, and then trigger
|
||
the following warning. To address this, move the lock to struct
|
||
stmmac_priv. We also need to reacquire the mutex lock when doing
|
||
this initialization.
|
||
|
||
DEBUG_LOCKS_WARN_ON(lock->magic != lock)
|
||
WARNING: CPU: 3 PID: 505 at kernel/locking/mutex.c:587 __mutex_lock+0xd84/0x1068
|
||
Modules linked in:
|
||
CPU: 3 PID: 505 Comm: tc Not tainted 6.9.0-rc6-00053-g0106679839f7-dirty #29
|
||
Hardware name: NXP i.MX8MPlus EVK board (DT)
|
||
pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
||
pc : __mutex_lock+0xd84/0x1068
|
||
lr : __mutex_lock+0xd84/0x1068
|
||
sp : ffffffc0864e3570
|
||
x29: ffffffc0864e3570 x28: ffffffc0817bdc78 x27: 0000000000000003
|
||
x26: ffffff80c54f1808 x25: ffffff80c9164080 x24: ffffffc080d723ac
|
||
x23: 0000000000000000 x22: 0000000000000002 x21: 0000000000000000
|
||
x20: 0000000000000000 x19: ffffffc083bc3000 x18: ffffffffffffffff
|
||
x17: ffffffc08117b080 x16: 0000000000000002 x15: ffffff80d2d40000
|
||
x14: 00000000000002da x13: ffffff80d2d404b8 x12: ffffffc082b5a5c8
|
||
x11: ffffffc082bca680 x10: ffffffc082bb2640 x9 : ffffffc082bb2698
|
||
x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001
|
||
x5 : ffffff8178fe0d48 x4 : 0000000000000000 x3 : 0000000000000027
|
||
x2 : ffffff8178fe0d50 x1 : 0000000000000000 x0 : 0000000000000000
|
||
Call trace:
|
||
__mutex_lock+0xd84/0x1068
|
||
mutex_lock_nested+0x28/0x34
|
||
tc_setup_taprio+0x118/0x68c
|
||
stmmac_setup_tc+0x50/0xf0
|
||
taprio_change+0x868/0xc9c</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-38594</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>6.1</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</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:
|
||
|
||
stm class: Fix a double free in stm_register_device()
|
||
|
||
The put_device(&stm->dev) call will trigger stm_device_release() which
|
||
frees "stm" so the vfree(stm) on the next line is a double free.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-38627</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</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:
|
||
|
||
drm/shmem-helper: Fix BUG_ON() on mmap(PROT_WRITE, MAP_PRIVATE)
|
||
|
||
Lack of check for copy-on-write (COW) mapping in drm_gem_shmem_mmap
|
||
allows users to call mmap with PROT_WRITE and MAP_PRIVATE flag
|
||
causing a kernel panic due to BUG_ON in vmf_insert_pfn_prot:
|
||
BUG_ON((vma->vm_flags & VM_PFNMAP) && is_cow_mapping(vma->vm_flags));
|
||
|
||
Return -EINVAL early if COW mapping is detected.
|
||
|
||
This bug affects all drm drivers using default shmem helpers.
|
||
It can be reproduced by this simple example:
|
||
void *ptr = mmap(0, size, PROT_WRITE, MAP_PRIVATE, fd, mmap_offset);
|
||
ptr[0] = 0;</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-39497</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Low</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>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-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</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:
|
||
|
||
net: hns3: fix kernel crash problem in concurrent scenario
|
||
|
||
When link status change, the nic driver need to notify the roce
|
||
driver to handle this event, but at this time, the roce driver
|
||
may uninit, then cause kernel crash.
|
||
|
||
To fix the problem, when link status change, need to check
|
||
whether the roce registered, and when uninit, need to wait link
|
||
update finish.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-39507</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Low</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>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-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</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:
|
||
|
||
ax25: Fix refcount imbalance on inbound connections
|
||
|
||
When releasing a socket in ax25_release(), we call netdev_put() to
|
||
decrease the refcount on the associated ax.25 device. However, the
|
||
execution path for accepting an incoming connection never calls
|
||
netdev_hold(). This imbalance leads to refcount errors, and ultimately
|
||
to kernel crashes.
|
||
|
||
A typical call trace for the above situation will start with one of the
|
||
following errors:
|
||
|
||
refcount_t: decrement hit 0; leaking memory.
|
||
refcount_t: underflow; use-after-free.
|
||
|
||
And will then have a trace like:
|
||
|
||
Call Trace:
|
||
<TASK>
|
||
? show_regs+0x64/0x70
|
||
? __warn+0x83/0x120
|
||
? refcount_warn_saturate+0xb2/0x100
|
||
? report_bug+0x158/0x190
|
||
? prb_read_valid+0x20/0x30
|
||
? handle_bug+0x3e/0x70
|
||
? exc_invalid_op+0x1c/0x70
|
||
? asm_exc_invalid_op+0x1f/0x30
|
||
? refcount_warn_saturate+0xb2/0x100
|
||
? refcount_warn_saturate+0xb2/0x100
|
||
ax25_release+0x2ad/0x360
|
||
__sock_release+0x35/0xa0
|
||
sock_close+0x19/0x20
|
||
[...]
|
||
|
||
On reboot (or any attempt to remove the interface), the kernel gets
|
||
stuck in an infinite loop:
|
||
|
||
unregister_netdevice: waiting for ax0 to become free. Usage count = 0
|
||
|
||
This patch corrects these issues by ensuring that we call netdev_hold()
|
||
and ax25_dev_hold() for new connections in ax25_accept(). This makes the
|
||
logic leading to ax25_accept() match the logic for ax25_bind(): in both
|
||
cases we increment the refcount, which is ultimately decremented in
|
||
ax25_release().</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-40910</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>4.4</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</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:
|
||
|
||
KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin()
|
||
|
||
Use {READ,WRITE}_ONCE() to access kvm->last_boosted_vcpu to ensure the
|
||
loads and stores are atomic. In the extremely unlikely scenario the
|
||
compiler tears the stores, it's theoretically possible for KVM to attempt
|
||
to get a vCPU using an out-of-bounds index, e.g. if the write is split
|
||
into multiple 8-bit stores, and is paired with a 32-bit load on a VM with
|
||
257 vCPUs:
|
||
|
||
CPU0 CPU1
|
||
last_boosted_vcpu = 0xff;
|
||
|
||
(last_boosted_vcpu = 0x100)
|
||
last_boosted_vcpu[15:8] = 0x01;
|
||
i = (last_boosted_vcpu = 0x1ff)
|
||
last_boosted_vcpu[7:0] = 0x00;
|
||
|
||
vcpu = kvm->vcpu_array[0x1ff];
|
||
|
||
As detected by KCSAN:
|
||
|
||
BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm]
|
||
|
||
write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16:
|
||
kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm
|
||
handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel
|
||
vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:?
|
||
arch/x86/kvm/vmx/vmx.c:6606) kvm_intel
|
||
vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm
|
||
kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm
|
||
kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm
|
||
__se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890)
|
||
__x64_sys_ioctl (fs/ioctl.c:890)
|
||
x64_sys_call (arch/x86/entry/syscall_64.c:33)
|
||
do_syscall_64 (arch/x86/entry/common.c:?)
|
||
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
|
||
|
||
read to 0xffffc90025a92344 of 4 bytes by task 4342 on cpu 4:
|
||
kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4069) kvm
|
||
handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel
|
||
vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:?
|
||
arch/x86/kvm/vmx/vmx.c:6606) kvm_intel
|
||
vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm
|
||
kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm
|
||
kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm
|
||
__se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890)
|
||
__x64_sys_ioctl (fs/ioctl.c:890)
|
||
x64_sys_call (arch/x86/entry/syscall_64.c:33)
|
||
do_syscall_64 (arch/x86/entry/common.c:?)
|
||
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
|
||
|
||
value changed: 0x00000012 -> 0x00000000</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-40953</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Low</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>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-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</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:
|
||
|
||
xfrm6: check ip6_dst_idev() return value in xfrm6_get_saddr()
|
||
|
||
ip6_dst_idev() can return NULL, xfrm6_get_saddr() must act accordingly.
|
||
|
||
syzbot reported:
|
||
|
||
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI
|
||
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
|
||
CPU: 1 PID: 12 Comm: kworker/u8:1 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0
|
||
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
|
||
Workqueue: wg-kex-wg1 wg_packet_handshake_send_worker
|
||
RIP: 0010:xfrm6_get_saddr+0x93/0x130 net/ipv6/xfrm6_policy.c:64
|
||
Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 97 00 00 00 4c 8b ab d8 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 86 00 00 00 4d 8b 6d 00 e8 ca 13 47 01 48 b8 00
|
||
RSP: 0018:ffffc90000117378 EFLAGS: 00010246
|
||
RAX: dffffc0000000000 RBX: ffff88807b079dc0 RCX: ffffffff89a0d6d7
|
||
RDX: 0000000000000000 RSI: ffffffff89a0d6e9 RDI: ffff88807b079e98
|
||
RBP: ffff88807ad73248 R08: 0000000000000007 R09: fffffffffffff000
|
||
R10: ffff88807b079dc0 R11: 0000000000000007 R12: ffffc90000117480
|
||
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
|
||
FS: 0000000000000000(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000
|
||
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
||
CR2: 00007f4586d00440 CR3: 0000000079042000 CR4: 00000000003506f0
|
||
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
||
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
||
Call Trace:
|
||
<TASK>
|
||
xfrm_get_saddr net/xfrm/xfrm_policy.c:2452 [inline]
|
||
xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:2481 [inline]
|
||
xfrm_tmpl_resolve+0xa26/0xf10 net/xfrm/xfrm_policy.c:2541
|
||
xfrm_resolve_and_create_bundle+0x140/0x2570 net/xfrm/xfrm_policy.c:2835
|
||
xfrm_bundle_lookup net/xfrm/xfrm_policy.c:3070 [inline]
|
||
xfrm_lookup_with_ifid+0x4d1/0x1e60 net/xfrm/xfrm_policy.c:3201
|
||
xfrm_lookup net/xfrm/xfrm_policy.c:3298 [inline]
|
||
xfrm_lookup_route+0x3b/0x200 net/xfrm/xfrm_policy.c:3309
|
||
ip6_dst_lookup_flow+0x15c/0x1d0 net/ipv6/ip6_output.c:1256
|
||
send6+0x611/0xd20 drivers/net/wireguard/socket.c:139
|
||
wg_socket_send_skb_to_peer+0xf9/0x220 drivers/net/wireguard/socket.c:178
|
||
wg_socket_send_buffer_to_peer+0x12b/0x190 drivers/net/wireguard/socket.c:200
|
||
wg_packet_send_handshake_initiation+0x227/0x360 drivers/net/wireguard/send.c:40
|
||
wg_packet_handshake_send_worker+0x1c/0x30 drivers/net/wireguard/send.c:51
|
||
process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231
|
||
process_scheduled_works kernel/workqueue.c:3312 [inline]
|
||
worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393
|
||
kthread+0x2c1/0x3a0 kernel/kthread.c:389
|
||
ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
|
||
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-40959</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</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:
|
||
|
||
ipv6: prevent possible NULL deref in fib6_nh_init()
|
||
|
||
syzbot reminds us that in6_dev_get() can return NULL.
|
||
|
||
fib6_nh_init()
|
||
ip6_validate_gw( &idev )
|
||
ip6_route_check_nh( idev )
|
||
*idev = in6_dev_get(dev); // can be NULL
|
||
|
||
Oops: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI
|
||
KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7]
|
||
CPU: 0 PID: 11237 Comm: syz-executor.3 Not tainted 6.10.0-rc2-syzkaller-00249-gbe27b8965297 #0
|
||
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024
|
||
RIP: 0010:fib6_nh_init+0x640/0x2160 net/ipv6/route.c:3606
|
||
Code: 00 00 fc ff df 4c 8b 64 24 58 48 8b 44 24 28 4c 8b 74 24 30 48 89 c1 48 89 44 24 28 48 8d 98 e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 0f 85 b3 17 00 00 8b 1b 31 ff 89 de e8 b8 8b
|
||
RSP: 0018:ffffc900032775a0 EFLAGS: 00010202
|
||
RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000000000
|
||
RDX: 0000000000000010 RSI: ffffc90003277a54 RDI: ffff88802b3a08d8
|
||
RBP: ffffc900032778b0 R08: 00000000000002fc R09: 0000000000000000
|
||
R10: 00000000000002fc R11: 0000000000000000 R12: ffff88802b3a08b8
|
||
R13: 1ffff9200064eec8 R14: ffffc90003277a00 R15: dffffc0000000000
|
||
FS: 00007f940feb06c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
|
||
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
||
CR2: 0000000000000000 CR3: 00000000245e8000 CR4: 00000000003506f0
|
||
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
||
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
||
Call Trace:
|
||
<TASK>
|
||
ip6_route_info_create+0x99e/0x12b0 net/ipv6/route.c:3809
|
||
ip6_route_add+0x28/0x160 net/ipv6/route.c:3853
|
||
ipv6_route_ioctl+0x588/0x870 net/ipv6/route.c:4483
|
||
inet6_ioctl+0x21a/0x280 net/ipv6/af_inet6.c:579
|
||
sock_do_ioctl+0x158/0x460 net/socket.c:1222
|
||
sock_ioctl+0x629/0x8e0 net/socket.c:1341
|
||
vfs_ioctl fs/ioctl.c:51 [inline]
|
||
__do_sys_ioctl fs/ioctl.c:907 [inline]
|
||
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
|
||
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
||
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
|
||
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
||
RIP: 0033:0x7f940f07cea9</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-40961</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</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:
|
||
|
||
drm/lima: mask irqs in timeout path before hard reset
|
||
|
||
There is a race condition in which a rendering job might take just long
|
||
enough to trigger the drm sched job timeout handler but also still
|
||
complete before the hard reset is done by the timeout handler.
|
||
This runs into race conditions not expected by the timeout handler.
|
||
In some very specific cases it currently may result in a refcount
|
||
imbalance on lima_pm_idle, with a stack dump such as:
|
||
|
||
[10136.669170] WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/lima/lima_devfreq.c:205 lima_devfreq_record_idle+0xa0/0xb0
|
||
...
|
||
[10136.669459] pc : lima_devfreq_record_idle+0xa0/0xb0
|
||
...
|
||
[10136.669628] Call trace:
|
||
[10136.669634] lima_devfreq_record_idle+0xa0/0xb0
|
||
[10136.669646] lima_sched_pipe_task_done+0x5c/0xb0
|
||
[10136.669656] lima_gp_irq_handler+0xa8/0x120
|
||
[10136.669666] __handle_irq_event_percpu+0x48/0x160
|
||
[10136.669679] handle_irq_event+0x4c/0xc0
|
||
|
||
We can prevent that race condition entirely by masking the irqs at the
|
||
beginning of the timeout handler, at which point we give up on waiting
|
||
for that job entirely.
|
||
The irqs will be enabled again at the next hard reset which is already
|
||
done as a recovery by the timeout handler.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-40976</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</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:
|
||
|
||
drm/radeon: fix UBSAN warning in kv_dpm.c
|
||
|
||
Adds bounds check for sumo_vid_mapping_entry.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-40988</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</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:
|
||
|
||
net: ena: Add validation for completion descriptors consistency
|
||
|
||
Validate that `first` flag is set only for the first
|
||
descriptor in multi-buffer packets.
|
||
In case of an invalid descriptor, a reset will occur.
|
||
A new reset reason for RX data corruption has been added.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-40999</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Low</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>3.6</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:L</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</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:
|
||
|
||
netrom: Fix a memory leak in nr_heartbeat_expiry()
|
||
|
||
syzbot reported a memory leak in nr_create() [0].
|
||
|
||
Commit 409db27e3a2e ("netrom: Fix use-after-free of a listening socket.")
|
||
added sock_hold() to the nr_heartbeat_expiry() function, where
|
||
a) a socket has a SOCK_DESTROY flag or
|
||
b) a listening socket has a SOCK_DEAD flag.
|
||
|
||
But in the case "a," when the SOCK_DESTROY flag is set, the file descriptor
|
||
has already been closed and the nr_release() function has been called.
|
||
So it makes no sense to hold the reference count because no one will
|
||
call another nr_destroy_socket() and put it as in the case "b."
|
||
|
||
nr_connect
|
||
nr_establish_data_link
|
||
nr_start_heartbeat
|
||
|
||
nr_release
|
||
switch (nr->state)
|
||
case NR_STATE_3
|
||
nr->state = NR_STATE_2
|
||
sock_set_flag(sk, SOCK_DESTROY);
|
||
|
||
nr_rx_frame
|
||
nr_process_rx_frame
|
||
switch (nr->state)
|
||
case NR_STATE_2
|
||
nr_state2_machine()
|
||
nr_disconnect()
|
||
nr_sk(sk)->state = NR_STATE_0
|
||
sock_set_flag(sk, SOCK_DEAD)
|
||
|
||
nr_heartbeat_expiry
|
||
switch (nr->state)
|
||
case NR_STATE_0
|
||
if (sock_flag(sk, SOCK_DESTROY) ||
|
||
(sk->sk_state == TCP_LISTEN
|
||
&& sock_flag(sk, SOCK_DEAD)))
|
||
sock_hold() // ( !!! )
|
||
nr_destroy_socket()
|
||
|
||
To fix the memory leak, let's call sock_hold() only for a listening socket.
|
||
|
||
Found by InfoTeCS on behalf of Linux Verification Center
|
||
(linuxtesting.org) with Syzkaller.
|
||
|
||
[0]: https://syzkaller.appspot.com/bug?extid=d327a1f3b12e1e206c16</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-41006</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Low</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>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-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</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:
|
||
|
||
xfs: don't walk off the end of a directory data block
|
||
|
||
This adds sanity checks for xfs_dir2_data_unused and xfs_dir2_data_entry
|
||
to make sure don't stray beyond valid memory region. Before patching, the
|
||
loop simply checks that the start offset of the dup and dep is within the
|
||
range. So in a crafted image, if last entry is xfs_dir2_data_unused, we
|
||
can change dup->length to dup->length-1 and leave 1 byte of space. In the
|
||
next traversal, this space will be considered as dup or dep. We may
|
||
encounter an out of bound read when accessing the fixed members.
|
||
|
||
In the patch, we make sure that the remaining bytes large enough to hold
|
||
an unused entry before accessing xfs_dir2_data_unused and
|
||
xfs_dir2_data_unused is XFS_DIR2_DATA_ALIGN byte aligned. We also make
|
||
sure that the remaining bytes large enough to hold a dirent with a
|
||
single-byte name before accessing xfs_dir2_data_entry.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-41013</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Low</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>3.3</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</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:
|
||
|
||
xfs: add bounds checking to xlog_recover_process_data
|
||
|
||
There is a lack of verification of the space occupied by fixed members
|
||
of xlog_op_header in the xlog_recover_process_data.
|
||
|
||
We can create a crafted image to trigger an out of bounds read by
|
||
following these steps:
|
||
1) Mount an image of xfs, and do some file operations to leave records
|
||
2) Before umounting, copy the image for subsequent steps to simulate
|
||
abnormal exit. Because umount will ensure that tail_blk and
|
||
head_blk are the same, which will result in the inability to enter
|
||
xlog_recover_process_data
|
||
3) Write a tool to parse and modify the copied image in step 2
|
||
4) Make the end of the xlog_op_header entries only 1 byte away from
|
||
xlog_rec_header->h_size
|
||
5) xlog_rec_header->h_num_logops++
|
||
6) Modify xlog_rec_header->h_crc
|
||
|
||
Fix:
|
||
Add a check to make sure there is sufficient space to access fixed members
|
||
of xlog_op_header.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-41014</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</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:
|
||
|
||
fs/ntfs3: Validate ff offset
|
||
|
||
This adds sanity checks for ff offset. There is a check
|
||
on rt->first_free at first, but walking through by ff
|
||
without any check. If the second ff is a large offset.
|
||
We may encounter an out-of-bound read.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-41019</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="23" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
||
<Notes>
|
||
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
filelock: Fix fcntl/close race recovery compat path
|
||
|
||
When I wrote commit 3cad1bc01041 ("filelock: Remove locks reliably when
|
||
fcntl/close race is detected"), I missed that there are two copies of the
|
||
code I was patching: The normal version, and the version for 64-bit offsets
|
||
on 32-bit kernels.
|
||
Thanks to Greg KH for stumbling over this while doing the stable
|
||
backport...
|
||
|
||
Apply exactly the same fix to the compat path for 32-bit kernels.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-41020</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>6.3</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="24" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
||
<Notes>
|
||
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
drm/amdgpu: Fix signedness bug in sdma_v4_0_process_trap_irq()
|
||
|
||
The "instance" variable needs to be signed for the error handling to work.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-41022</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="25" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
||
<Notes>
|
||
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
sched/deadline: Fix task_struct reference leak
|
||
|
||
During the execution of the following stress test with linux-rt:
|
||
|
||
stress-ng --cyclic 30 --timeout 30 --minimize --quiet
|
||
|
||
kmemleak frequently reported a memory leak concerning the task_struct:
|
||
|
||
unreferenced object 0xffff8881305b8000 (size 16136):
|
||
comm "stress-ng", pid 614, jiffies 4294883961 (age 286.412s)
|
||
object hex dump (first 32 bytes):
|
||
02 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .@..............
|
||
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||
debug hex dump (first 16 bytes):
|
||
53 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 S...............
|
||
backtrace:
|
||
[<00000000046b6790>] dup_task_struct+0x30/0x540
|
||
[<00000000c5ca0f0b>] copy_process+0x3d9/0x50e0
|
||
[<00000000ced59777>] kernel_clone+0xb0/0x770
|
||
[<00000000a50befdc>] __do_sys_clone+0xb6/0xf0
|
||
[<000000001dbf2008>] do_syscall_64+0x5d/0xf0
|
||
[<00000000552900ff>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
||
|
||
The issue occurs in start_dl_timer(), which increments the task_struct
|
||
reference count and sets a timer. The timer callback, dl_task_timer,
|
||
is supposed to decrement the reference count upon expiration. However,
|
||
if enqueue_task_dl() is called before the timer expires and cancels it,
|
||
the reference count is not decremented, leading to the leak.
|
||
|
||
This patch fixes the reference leak by ensuring the task_struct
|
||
reference count is properly decremented when the timer is canceled.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-41023</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="26" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
||
<Notes>
|
||
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
Fix userfaultfd_api to return EINVAL as expected
|
||
|
||
Currently if we request a feature that is not set in the Kernel config we
|
||
fail silently and return all the available features. However, the man
|
||
page indicates we should return an EINVAL.
|
||
|
||
We need to fix this issue since we can end up with a Kernel warning should
|
||
a program request the feature UFFD_FEATURE_WP_UNPOPULATED on a kernel with
|
||
the config not set with this feature.
|
||
|
||
[ 200.812896] WARNING: CPU: 91 PID: 13634 at mm/memory.c:1660 zap_pte_range+0x43d/0x660
|
||
[ 200.820738] Modules linked in:
|
||
[ 200.869387] CPU: 91 PID: 13634 Comm: userfaultfd Kdump: loaded Not tainted 6.9.0-rc5+ #8
|
||
[ 200.877477] Hardware name: Dell Inc. PowerEdge R6525/0N7YGH, BIOS 2.7.3 03/30/2022
|
||
[ 200.885052] RIP: 0010:zap_pte_range+0x43d/0x660</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-41027</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="27" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
||
<Notes>
|
||
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
net/sched: Fix UAF when resolving a clash
|
||
|
||
KASAN reports the following UAF:
|
||
|
||
BUG: KASAN: slab-use-after-free in tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct]
|
||
Read of size 1 at addr ffff888c07603600 by task handler130/6469
|
||
|
||
Call Trace:
|
||
<IRQ>
|
||
dump_stack_lvl+0x48/0x70
|
||
print_address_description.constprop.0+0x33/0x3d0
|
||
print_report+0xc0/0x2b0
|
||
kasan_report+0xd0/0x120
|
||
__asan_load1+0x6c/0x80
|
||
tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct]
|
||
tcf_ct_act+0x886/0x1350 [act_ct]
|
||
tcf_action_exec+0xf8/0x1f0
|
||
fl_classify+0x355/0x360 [cls_flower]
|
||
__tcf_classify+0x1fd/0x330
|
||
tcf_classify+0x21c/0x3c0
|
||
sch_handle_ingress.constprop.0+0x2c5/0x500
|
||
__netif_receive_skb_core.constprop.0+0xb25/0x1510
|
||
__netif_receive_skb_list_core+0x220/0x4c0
|
||
netif_receive_skb_list_internal+0x446/0x620
|
||
napi_complete_done+0x157/0x3d0
|
||
gro_cell_poll+0xcf/0x100
|
||
__napi_poll+0x65/0x310
|
||
net_rx_action+0x30c/0x5c0
|
||
__do_softirq+0x14f/0x491
|
||
__irq_exit_rcu+0x82/0xc0
|
||
irq_exit_rcu+0xe/0x20
|
||
common_interrupt+0xa1/0xb0
|
||
</IRQ>
|
||
<TASK>
|
||
asm_common_interrupt+0x27/0x40
|
||
|
||
Allocated by task 6469:
|
||
kasan_save_stack+0x38/0x70
|
||
kasan_set_track+0x25/0x40
|
||
kasan_save_alloc_info+0x1e/0x40
|
||
__kasan_krealloc+0x133/0x190
|
||
krealloc+0xaa/0x130
|
||
nf_ct_ext_add+0xed/0x230 [nf_conntrack]
|
||
tcf_ct_act+0x1095/0x1350 [act_ct]
|
||
tcf_action_exec+0xf8/0x1f0
|
||
fl_classify+0x355/0x360 [cls_flower]
|
||
__tcf_classify+0x1fd/0x330
|
||
tcf_classify+0x21c/0x3c0
|
||
sch_handle_ingress.constprop.0+0x2c5/0x500
|
||
__netif_receive_skb_core.constprop.0+0xb25/0x1510
|
||
__netif_receive_skb_list_core+0x220/0x4c0
|
||
netif_receive_skb_list_internal+0x446/0x620
|
||
napi_complete_done+0x157/0x3d0
|
||
gro_cell_poll+0xcf/0x100
|
||
__napi_poll+0x65/0x310
|
||
net_rx_action+0x30c/0x5c0
|
||
__do_softirq+0x14f/0x491
|
||
|
||
Freed by task 6469:
|
||
kasan_save_stack+0x38/0x70
|
||
kasan_set_track+0x25/0x40
|
||
kasan_save_free_info+0x2b/0x60
|
||
____kasan_slab_free+0x180/0x1f0
|
||
__kasan_slab_free+0x12/0x30
|
||
slab_free_freelist_hook+0xd2/0x1a0
|
||
__kmem_cache_free+0x1a2/0x2f0
|
||
kfree+0x78/0x120
|
||
nf_conntrack_free+0x74/0x130 [nf_conntrack]
|
||
nf_ct_destroy+0xb2/0x140 [nf_conntrack]
|
||
__nf_ct_resolve_clash+0x529/0x5d0 [nf_conntrack]
|
||
nf_ct_resolve_clash+0xf6/0x490 [nf_conntrack]
|
||
__nf_conntrack_confirm+0x2c6/0x770 [nf_conntrack]
|
||
tcf_ct_act+0x12ad/0x1350 [act_ct]
|
||
tcf_action_exec+0xf8/0x1f0
|
||
fl_classify+0x355/0x360 [cls_flower]
|
||
__tcf_classify+0x1fd/0x330
|
||
tcf_classify+0x21c/0x3c0
|
||
sch_handle_ingress.constprop.0+0x2c5/0x500
|
||
__netif_receive_skb_core.constprop.0+0xb25/0x1510
|
||
__netif_receive_skb_list_core+0x220/0x4c0
|
||
netif_receive_skb_list_internal+0x446/0x620
|
||
napi_complete_done+0x157/0x3d0
|
||
gro_cell_poll+0xcf/0x100
|
||
__napi_poll+0x65/0x310
|
||
net_rx_action+0x30c/0x5c0
|
||
__do_softirq+0x14f/0x491
|
||
|
||
The ct may be dropped if a clash has been resolved but is still passed to
|
||
the tcf_ct_flow_table_process_conn function for further usage. This issue
|
||
can be fixed by retrieving ct from skb again after confirming conntrack.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-41040</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="28" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
||
<Notes>
|
||
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
udp: Set SOCK_RCU_FREE earlier in udp_lib_get_port().
|
||
|
||
syzkaller triggered the warning [0] in udp_v4_early_demux().
|
||
|
||
In udp_v[46]_early_demux() and sk_lookup(), we do not touch the refcount
|
||
of the looked-up sk and use sock_pfree() as skb->destructor, so we check
|
||
SOCK_RCU_FREE to ensure that the sk is safe to access during the RCU grace
|
||
period.
|
||
|
||
Currently, SOCK_RCU_FREE is flagged for a bound socket after being put
|
||
into the hash table. Moreover, the SOCK_RCU_FREE check is done too early
|
||
in udp_v[46]_early_demux() and sk_lookup(), so there could be a small race
|
||
window:
|
||
|
||
CPU1 CPU2
|
||
---- ----
|
||
udp_v4_early_demux() udp_lib_get_port()
|
||
| |- hlist_add_head_rcu()
|
||
|- sk = __udp4_lib_demux_lookup() |
|
||
|- DEBUG_NET_WARN_ON_ONCE(sk_is_refcounted(sk));
|
||
`- sock_set_flag(sk, SOCK_RCU_FREE)
|
||
|
||
We had the same bug in TCP and fixed it in commit 871019b22d1b ("net:
|
||
set SOCK_RCU_FREE before inserting socket into hashtable").
|
||
|
||
Let's apply the same fix for UDP.
|
||
|
||
[0]:
|
||
WARNING: CPU: 0 PID: 11198 at net/ipv4/udp.c:2599 udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599
|
||
Modules linked in:
|
||
CPU: 0 PID: 11198 Comm: syz-executor.1 Not tainted 6.9.0-g93bda33046e7 #13
|
||
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
|
||
RIP: 0010:udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599
|
||
Code: c5 7a 15 fe bb 01 00 00 00 44 89 e9 31 ff d3 e3 81 e3 bf ef ff ff 89 de e8 2c 74 15 fe 85 db 0f 85 02 06 00 00 e8 9f 7a 15 fe <0f> 0b e8 98 7a 15 fe 49 8d 7e 60 e8 4f 39 2f fe 49 c7 46 60 20 52
|
||
RSP: 0018:ffffc9000ce3fa58 EFLAGS: 00010293
|
||
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8318c92c
|
||
RDX: ffff888036ccde00 RSI: ffffffff8318c2f1 RDI: 0000000000000001
|
||
RBP: ffff88805a2dd6e0 R08: 0000000000000001 R09: 0000000000000000
|
||
R10: 0000000000000000 R11: 0001ffffffffffff R12: ffff88805a2dd680
|
||
R13: 0000000000000007 R14: ffff88800923f900 R15: ffff88805456004e
|
||
FS: 00007fc449127640(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000
|
||
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
||
CR2: 00007fc449126e38 CR3: 000000003de4b002 CR4: 0000000000770ef0
|
||
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
||
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
|
||
PKRU: 55555554
|
||
Call Trace:
|
||
<TASK>
|
||
ip_rcv_finish_core.constprop.0+0xbdd/0xd20 net/ipv4/ip_input.c:349
|
||
ip_rcv_finish+0xda/0x150 net/ipv4/ip_input.c:447
|
||
NF_HOOK include/linux/netfilter.h:314 [inline]
|
||
NF_HOOK include/linux/netfilter.h:308 [inline]
|
||
ip_rcv+0x16c/0x180 net/ipv4/ip_input.c:569
|
||
__netif_receive_skb_one_core+0xb3/0xe0 net/core/dev.c:5624
|
||
__netif_receive_skb+0x21/0xd0 net/core/dev.c:5738
|
||
netif_receive_skb_internal net/core/dev.c:5824 [inline]
|
||
netif_receive_skb+0x271/0x300 net/core/dev.c:5884
|
||
tun_rx_batched drivers/net/tun.c:1549 [inline]
|
||
tun_get_user+0x24db/0x2c50 drivers/net/tun.c:2002
|
||
tun_chr_write_iter+0x107/0x1a0 drivers/net/tun.c:2048
|
||
new_sync_write fs/read_write.c:497 [inline]
|
||
vfs_write+0x76f/0x8d0 fs/read_write.c:590
|
||
ksys_write+0xbf/0x190 fs/read_write.c:643
|
||
__do_sys_write fs/read_write.c:655 [inline]
|
||
__se_sys_write fs/read_write.c:652 [inline]
|
||
__x64_sys_write+0x41/0x50 fs/read_write.c:652
|
||
x64_sys_call+0xe66/0x1990 arch/x86/include/generated/asm/syscalls_64.h:2
|
||
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
||
do_syscall_64+0x4b/0x110 arch/x86/entry/common.c:83
|
||
entry_SYSCALL_64_after_hwframe+0x4b/0x53
|
||
RIP: 0033:0x7fc44a68bc1f
|
||
Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 e9 cf f5 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 3c d0 f5 ff 48
|
||
RSP: 002b:00007fc449126c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
|
||
RAX: ffffffffffffffda RBX: 00000000004bc050 RCX: 00007fc44a68bc1f
|
||
R
|
||
---truncated---</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-41041</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="29" 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:
|
||
|
||
ppp: reject claimed-as-LCP but actually malformed packets
|
||
|
||
Since 'ppp_async_encode()' assumes valid LCP packets (with code
|
||
from 1 to 7 inclusive), add 'ppp_check_packet()' to ensure that
|
||
LCP packet has an actual body beyond PPP_LCP header bytes, and
|
||
reject claimed-as-LCP but actually malformed data otherwise.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-41044</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>6.3</BaseScore>
|
||
<Vector>AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="30" 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:
|
||
|
||
skmsg: Skip zero length skb in sk_msg_recvmsg
|
||
|
||
When running BPF selftests (./test_progs -t sockmap_basic) on a Loongarch
|
||
platform, the following kernel panic occurs:
|
||
|
||
[...]
|
||
Oops[#1]:
|
||
CPU: 22 PID: 2824 Comm: test_progs Tainted: G OE 6.10.0-rc2+ #18
|
||
Hardware name: LOONGSON Dabieshan/Loongson-TC542F0, BIOS Loongson-UDK2018
|
||
... ...
|
||
ra: 90000000048bf6c0 sk_msg_recvmsg+0x120/0x560
|
||
ERA: 9000000004162774 copy_page_to_iter+0x74/0x1c0
|
||
CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
|
||
PRMD: 0000000c (PPLV0 +PIE +PWE)
|
||
EUEN: 00000007 (+FPE +SXE +ASXE -BTE)
|
||
ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)
|
||
ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)
|
||
BADV: 0000000000000040
|
||
PRID: 0014c011 (Loongson-64bit, Loongson-3C5000)
|
||
Modules linked in: bpf_testmod(OE) xt_CHECKSUM xt_MASQUERADE xt_conntrack
|
||
Process test_progs (pid: 2824, threadinfo=0000000000863a31, task=...)
|
||
Stack : ...
|
||
Call Trace:
|
||
[<9000000004162774>] copy_page_to_iter+0x74/0x1c0
|
||
[<90000000048bf6c0>] sk_msg_recvmsg+0x120/0x560
|
||
[<90000000049f2b90>] tcp_bpf_recvmsg_parser+0x170/0x4e0
|
||
[<90000000049aae34>] inet_recvmsg+0x54/0x100
|
||
[<900000000481ad5c>] sock_recvmsg+0x7c/0xe0
|
||
[<900000000481e1a8>] __sys_recvfrom+0x108/0x1c0
|
||
[<900000000481e27c>] sys_recvfrom+0x1c/0x40
|
||
[<9000000004c076ec>] do_syscall+0x8c/0xc0
|
||
[<9000000003731da4>] handle_syscall+0xc4/0x160
|
||
Code: ...
|
||
---[ end trace 0000000000000000 ]---
|
||
Kernel panic - not syncing: Fatal exception
|
||
Kernel relocated by 0x3510000
|
||
.text @ 0x9000000003710000
|
||
.data @ 0x9000000004d70000
|
||
.bss @ 0x9000000006469400
|
||
---[ end Kernel panic - not syncing: Fatal exception ]---
|
||
[...]
|
||
|
||
This crash happens every time when running sockmap_skb_verdict_shutdown
|
||
subtest in sockmap_basic.
|
||
|
||
This crash is because a NULL pointer is passed to page_address() in the
|
||
sk_msg_recvmsg(). Due to the different implementations depending on the
|
||
architecture, page_address(NULL) will trigger a panic on Loongarch
|
||
platform but not on x86 platform. So this bug was hidden on x86 platform
|
||
for a while, but now it is exposed on Loongarch platform. The root cause
|
||
is that a zero length skb (skb->len == 0) was put on the queue.
|
||
|
||
This zero length skb is a TCP FIN packet, which was sent by shutdown(),
|
||
invoked in test_sockmap_skb_verdict_shutdown():
|
||
|
||
shutdown(p1, SHUT_WR);
|
||
|
||
In this case, in sk_psock_skb_ingress_enqueue(), num_sge is zero, and no
|
||
page is put to this sge (see sg_set_page in sg_set_page), but this empty
|
||
sge is queued into ingress_msg list.
|
||
|
||
And in sk_msg_recvmsg(), this empty sge is used, and a NULL page is got by
|
||
sg_page(sge). Pass this NULL page to copy_page_to_iter(), which passes it
|
||
to kmap_local_page() and to page_address(), then kernel panics.
|
||
|
||
To solve this, we should skip this zero length skb. So in sk_msg_recvmsg(),
|
||
if copy is zero, that means it's a zero length skb, skip invoking
|
||
copy_page_to_iter(). We are using the EFAULT return triggered by
|
||
copy_page_to_iter to check for is_fin in tcp_bpf.c.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-41048</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="31" 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:
|
||
|
||
filelock: fix potential use-after-free in posix_lock_inode
|
||
|
||
Light Hsieh reported a KASAN UAF warning in trace_posix_lock_inode().
|
||
The request pointer had been changed earlier to point to a lock entry
|
||
that was added to the inode's list. However, before the tracepoint could
|
||
fire, another task raced in and freed that lock.
|
||
|
||
Fix this by moving the tracepoint inside the spinlock, which should
|
||
ensure that this doesn't happen.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-41049</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="32" 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:
|
||
|
||
mm: prevent derefencing NULL ptr in pfn_section_valid()
|
||
|
||
Commit 5ec8e8ea8b77 ("mm/sparsemem: fix race in accessing
|
||
memory_section->usage") changed pfn_section_valid() to add a READ_ONCE()
|
||
call around "ms->usage" to fix a race with section_deactivate() where
|
||
ms->usage can be cleared. The READ_ONCE() call, by itself, is not enough
|
||
to prevent NULL pointer dereference. We need to check its value before
|
||
dereferencing it.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-41055</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="33" 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/l2cap: sync sock recv cb and release
|
||
|
||
The problem occurs between the system call to close the sock and hci_rx_work,
|
||
where the former releases the sock and the latter accesses it without lock protection.
|
||
|
||
CPU0 CPU1
|
||
---- ----
|
||
sock_close hci_rx_work
|
||
l2cap_sock_release hci_acldata_packet
|
||
l2cap_sock_kill l2cap_recv_frame
|
||
sk_free l2cap_conless_channel
|
||
l2cap_sock_recv_cb
|
||
|
||
If hci_rx_work processes the data that needs to be received before the sock is
|
||
closed, then everything is normal; Otherwise, the work thread may access the
|
||
released sock when receiving data.
|
||
|
||
Add a chan mutex in the rx callback of the sock to achieve synchronization between
|
||
the sock release and recv cb.
|
||
|
||
Sock is dead, so set chan data to NULL, avoid others use invalid sock pointer.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-41062</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="34" 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: hci_core: cancel all works upon hci_unregister_dev()
|
||
|
||
syzbot is reporting that calling hci_release_dev() from hci_error_reset()
|
||
due to hci_dev_put() from hci_error_reset() can cause deadlock at
|
||
destroy_workqueue(), for hci_error_reset() is called from
|
||
hdev->req_workqueue which destroy_workqueue() needs to flush.
|
||
|
||
We need to make sure that hdev->{rx_work,cmd_work,tx_work} which are
|
||
queued into hdev->workqueue and hdev->{power_on,error_reset} which are
|
||
queued into hdev->req_workqueue are no longer running by the moment
|
||
|
||
destroy_workqueue(hdev->workqueue);
|
||
destroy_workqueue(hdev->req_workqueue);
|
||
|
||
are called from hci_release_dev().
|
||
|
||
Call cancel_work_sync() on these work items from hci_unregister_dev()
|
||
as soon as hdev->list is removed from hci_dev_list.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-41063</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="35" 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:
|
||
|
||
powerpc/eeh: avoid possible crash when edev->pdev changes
|
||
|
||
If a PCI device is removed during eeh_pe_report_edev(), edev->pdev
|
||
will change and can cause a crash, hold the PCI rescan/remove lock
|
||
while taking a copy of edev->pdev->bus.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-41064</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="36" 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:
|
||
|
||
ibmvnic: Add tx check to prevent skb leak
|
||
|
||
Below is a summary of how the driver stores a reference to an skb during
|
||
transmit:
|
||
tx_buff[free_map[consumer_index]]->skb = new_skb;
|
||
free_map[consumer_index] = IBMVNIC_INVALID_MAP;
|
||
consumer_index ++;
|
||
Where variable data looks like this:
|
||
free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3]
|
||
consumer_index^
|
||
tx_buff == [skb=null, skb=<ptr>, skb=<ptr>, skb=null, skb=null]
|
||
|
||
The driver has checks to ensure that free_map[consumer_index] pointed to
|
||
a valid index but there was no check to ensure that this index pointed
|
||
to an unused/null skb address. So, if, by some chance, our free_map and
|
||
tx_buff lists become out of sync then we were previously risking an
|
||
skb memory leak. This could then cause tcp congestion control to stop
|
||
sending packets, eventually leading to ETIMEDOUT.
|
||
|
||
Therefore, add a conditional to ensure that the skb address is null. If
|
||
not then warn the user (because this is still a bug that should be
|
||
patched) and free the old pointer to prevent memleak/tcp problems.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-41066</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>High</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>7.0</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="37" 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:
|
||
|
||
ASoC: topology: Fix references to freed memory
|
||
|
||
Most users after parsing a topology file, release memory used by it, so
|
||
having pointer references directly into topology file contents is wrong.
|
||
Use devm_kmemdup(), to allocate memory as needed.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-41069</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="38" 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:
|
||
|
||
KVM: PPC: Book3S HV: Prevent UAF in kvm_spapr_tce_attach_iommu_group()
|
||
|
||
Al reported a possible use-after-free (UAF) in kvm_spapr_tce_attach_iommu_group().
|
||
|
||
It looks up `stt` from tablefd, but then continues to use it after doing
|
||
fdput() on the returned fd. After the fdput() the tablefd is free to be
|
||
closed by another thread. The close calls kvm_spapr_tce_release() and
|
||
then release_spapr_tce_table() (via call_rcu()) which frees `stt`.
|
||
|
||
Although there are calls to rcu_read_lock() in
|
||
kvm_spapr_tce_attach_iommu_group() they are not sufficient to prevent
|
||
the UAF, because `stt` is used outside the locked regions.
|
||
|
||
With an artifcial delay after the fdput() and a userspace program which
|
||
triggers the race, KASAN detects the UAF:
|
||
|
||
BUG: KASAN: slab-use-after-free in kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]
|
||
Read of size 4 at addr c000200027552c30 by task kvm-vfio/2505
|
||
CPU: 54 PID: 2505 Comm: kvm-vfio Not tainted 6.10.0-rc3-next-20240612-dirty #1
|
||
Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV
|
||
Call Trace:
|
||
dump_stack_lvl+0xb4/0x108 (unreliable)
|
||
print_report+0x2b4/0x6ec
|
||
kasan_report+0x118/0x2b0
|
||
__asan_load4+0xb8/0xd0
|
||
kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]
|
||
kvm_vfio_set_attr+0x524/0xac0 [kvm]
|
||
kvm_device_ioctl+0x144/0x240 [kvm]
|
||
sys_ioctl+0x62c/0x1810
|
||
system_call_exception+0x190/0x440
|
||
system_call_vectored_common+0x15c/0x2ec
|
||
...
|
||
Freed by task 0:
|
||
...
|
||
kfree+0xec/0x3e0
|
||
release_spapr_tce_table+0xd4/0x11c [kvm]
|
||
rcu_core+0x568/0x16a0
|
||
handle_softirqs+0x23c/0x920
|
||
do_softirq_own_stack+0x6c/0x90
|
||
do_softirq_own_stack+0x58/0x90
|
||
__irq_exit_rcu+0x218/0x2d0
|
||
irq_exit+0x30/0x80
|
||
arch_local_irq_restore+0x128/0x230
|
||
arch_local_irq_enable+0x1c/0x30
|
||
cpuidle_enter_state+0x134/0x5cc
|
||
cpuidle_enter+0x6c/0xb0
|
||
call_cpuidle+0x7c/0x100
|
||
do_idle+0x394/0x410
|
||
cpu_startup_entry+0x60/0x70
|
||
start_secondary+0x3fc/0x410
|
||
start_secondary_prolog+0x10/0x14
|
||
|
||
Fix it by delaying the fdput() until `stt` is no longer in use, which
|
||
is effectively the entire function. To keep the patch minimal add a call
|
||
to fdput() at each of the existing return paths. Future work can convert
|
||
the function to goto or __cleanup style cleanup.
|
||
|
||
With the fix in place the test case no longer triggers the UAF.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-41070</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="39" 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:
|
||
|
||
wifi: cfg80211: wext: add extra SIOCSIWSCAN data check
|
||
|
||
In 'cfg80211_wext_siwscan()', add extra check whether number of
|
||
channels passed via 'ioctl(sock, SIOCSIWSCAN, ...)' doesn't exceed
|
||
IW_MAX_FREQUENCIES and reject invalid request with -EINVAL otherwise.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-41072</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>4.4</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="40" 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:
|
||
|
||
nvme: avoid double free special payload
|
||
|
||
If a discard request needs to be retried, and that retry may fail before
|
||
a new special payload is added, a double free will result. Clear the
|
||
RQF_SPECIAL_LOAD when the request is cleaned.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-41073</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>6.4</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="41" 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 validation of block size
|
||
|
||
Block size should be between 512 and PAGE_SIZE and be a power of 2. The current
|
||
check does not validate this, so update the check.
|
||
|
||
Without this patch, null_blk would Oops due to a null pointer deref when
|
||
loaded with bs=1536 [1].
|
||
|
||
|
||
[axboe: remove unnecessary braces and != 0 check]</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-41077</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>4.8</BaseScore>
|
||
<Vector>AV:A/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-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="42" 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:
|
||
|
||
nvmet: always initialize cqe.result
|
||
|
||
The spec doesn't mandate that the first two double words (aka results)
|
||
for the command queue entry need to be set to 0 when they are not
|
||
used (not specified). Though, the target implemention returns 0 for TCP
|
||
and FC but not for RDMA.
|
||
|
||
Let's make RDMA behave the same and thus explicitly initializing the
|
||
result field. This prevents leaking any data from the stack.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-41079</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="43" 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:
|
||
|
||
io_uring: fix possible deadlock in io_register_iowq_max_workers()
|
||
|
||
The io_register_iowq_max_workers() function calls io_put_sq_data(),
|
||
which acquires the sqd->lock without releasing the uring_lock.
|
||
Similar to the commit 009ad9f0c6ee ("io_uring: drop ctx->uring_lock
|
||
before acquiring sqd->lock"), this can lead to a potential deadlock
|
||
situation.
|
||
|
||
To resolve this issue, the uring_lock is released before calling
|
||
io_put_sq_data(), and then it is re-acquired after the function call.
|
||
|
||
This change ensures that the locks are acquired in the correct
|
||
order, preventing the possibility of a deadlock.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-41080</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.7</BaseScore>
|
||
<Vector>AV:A/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-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="44" 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:
|
||
|
||
ila: block BH in ila_output()
|
||
|
||
As explained in commit 1378817486d6 ("tipc: block BH
|
||
before using dst_cache"), net/core/dst_cache.c
|
||
helpers need to be called with BH disabled.
|
||
|
||
ila_output() is called from lwtunnel_output()
|
||
possibly from process context, and under rcu_read_lock().
|
||
|
||
We might be interrupted by a softirq, re-enter ila_output()
|
||
and corrupt dst_cache data structures.
|
||
|
||
Fix the race by using local_bh_disable().</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-41081</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Low</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>2.6</BaseScore>
|
||
<Vector>AV:A/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="45" 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:
|
||
|
||
ata: libata-core: Fix double free on error
|
||
|
||
If e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jump
|
||
to the err_out label, which will call devres_release_group().
|
||
devres_release_group() will trigger a call to ata_host_release().
|
||
ata_host_release() calls kfree(host), so executing the kfree(host) in
|
||
ata_host_alloc() will lead to a double free:
|
||
|
||
kernel BUG at mm/slub.c:553!
|
||
Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
|
||
CPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47
|
||
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
|
||
RIP: 0010:kfree+0x2cf/0x2f0
|
||
Code: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da
|
||
RSP: 0018:ffffc90000f377f0 EFLAGS: 00010246
|
||
RAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320
|
||
RDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0
|
||
RBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000
|
||
R10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780
|
||
R13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006
|
||
FS: 00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000
|
||
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
||
CR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0
|
||
PKRU: 55555554
|
||
Call Trace:
|
||
<TASK>
|
||
? __die_body.cold+0x19/0x27
|
||
? die+0x2e/0x50
|
||
? do_trap+0xca/0x110
|
||
? do_error_trap+0x6a/0x90
|
||
? kfree+0x2cf/0x2f0
|
||
? exc_invalid_op+0x50/0x70
|
||
? kfree+0x2cf/0x2f0
|
||
? asm_exc_invalid_op+0x1a/0x20
|
||
? ata_host_alloc+0xf5/0x120 [libata]
|
||
? ata_host_alloc+0xf5/0x120 [libata]
|
||
? kfree+0x2cf/0x2f0
|
||
ata_host_alloc+0xf5/0x120 [libata]
|
||
ata_host_alloc_pinfo+0x14/0xa0 [libata]
|
||
ahci_init_one+0x6c9/0xd20 [ahci]
|
||
|
||
Ensure that we will not call kfree(host) twice, by performing the kfree()
|
||
only if the devres_open_group() call failed.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-41087</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>High</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>7.0</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="46" 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:
|
||
|
||
drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes
|
||
|
||
In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is
|
||
assigned to mode, which will lead to a possible NULL pointer dereference
|
||
on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode().
|
||
Add a check to avoid null pointer dereference.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-41089</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="47" 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:
|
||
|
||
tap: add missing verification for short frame
|
||
|
||
The cited commit missed to check against the validity of the frame length
|
||
in the tap_get_user_xdp() path, which could cause a corrupted skb to be
|
||
sent downstack. Even before the skb is transmitted, the
|
||
tap_get_user_xdp()-->skb_set_network_header() may assume the size is more
|
||
than ETH_HLEN. Once transmitted, this could either cause out-of-bound
|
||
access beyond the actual length, or confuse the underlayer with incorrect
|
||
or inconsistent header length in the skb metadata.
|
||
|
||
In the alternative path, tap_get_user() already prohibits short frame which
|
||
has the length less than Ethernet header size from being transmitted.
|
||
|
||
This is to drop any frame shorter than the Ethernet header size just like
|
||
how tap_get_user() does.
|
||
|
||
CVE: CVE-2024-41090</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-41090</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>High</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>7.1</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="48" 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:
|
||
|
||
tun: add missing verification for short frame
|
||
|
||
The cited commit missed to check against the validity of the frame length
|
||
in the tun_xdp_one() path, which could cause a corrupted skb to be sent
|
||
downstack. Even before the skb is transmitted, the
|
||
tun_xdp_one-->eth_type_trans() may access the Ethernet header although it
|
||
can be less than ETH_HLEN. Once transmitted, this could either cause
|
||
out-of-bound access beyond the actual length, or confuse the underlayer
|
||
with incorrect or inconsistent header length in the skb metadata.
|
||
|
||
In the alternative path, tun_get_user() already prohibits short frame which
|
||
has the length less than Ethernet header size from being transmitted for
|
||
IFF_TAP.
|
||
|
||
This is to drop any frame shorter than the Ethernet header size just like
|
||
how tun_get_user() does.
|
||
|
||
CVE: CVE-2024-41091</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-41091</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>High</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>7.1</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="49" 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:
|
||
|
||
usb: atm: cxacru: fix endpoint checking in cxacru_bind()
|
||
|
||
Syzbot is still reporting quite an old issue [1] that occurs due to
|
||
incomplete checking of present usb endpoints. As such, wrong
|
||
endpoints types may be used at urb sumbitting stage which in turn
|
||
triggers a warning in usb_submit_urb().
|
||
|
||
Fix the issue by verifying that required endpoint types are present
|
||
for both in and out endpoints, taking into account cmd endpoint type.
|
||
|
||
Unfortunately, this patch has not been tested on real hardware.
|
||
|
||
[1] Syzbot report:
|
||
usb 1-1: BOGUS urb xfer, pipe 1 != type 3
|
||
WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502
|
||
Modules linked in:
|
||
CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0
|
||
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
|
||
Workqueue: usb_hub_wq hub_event
|
||
RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502
|
||
...
|
||
Call Trace:
|
||
cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649
|
||
cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760
|
||
cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209
|
||
usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055
|
||
cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363
|
||
usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396
|
||
call_driver_probe drivers/base/dd.c:517 [inline]
|
||
really_probe+0x23c/0xcd0 drivers/base/dd.c:595
|
||
__driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747
|
||
driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777
|
||
__device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894
|
||
bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427
|
||
__device_attach+0x228/0x4a0 drivers/base/dd.c:965
|
||
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487
|
||
device_add+0xc2f/0x2180 drivers/base/core.c:3354
|
||
usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170
|
||
usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238
|
||
usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-41097</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="50" 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:
|
||
|
||
bpf: Take return from set_memory_ro() into account with bpf_prog_lock_ro()
|
||
|
||
set_memory_ro() can fail, leaving memory unprotected.
|
||
|
||
Check its return and take it into account as an error.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-42068</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="51" 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: can: j1939: Initialize unused data in j1939_send_one()
|
||
|
||
syzbot reported kernel-infoleak in raw_recvmsg() [1]. j1939_send_one()
|
||
creates full frame including unused data, but it doesn't initialize
|
||
it. This causes the kernel-infoleak issue. Fix this by initializing
|
||
unused data.
|
||
|
||
[1]
|
||
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
||
BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]
|
||
BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]
|
||
BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
|
||
BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]
|
||
BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
|
||
instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
||
copy_to_user_iter lib/iov_iter.c:24 [inline]
|
||
iterate_ubuf include/linux/iov_iter.h:29 [inline]
|
||
iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
|
||
iterate_and_advance include/linux/iov_iter.h:271 [inline]
|
||
_copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
|
||
copy_to_iter include/linux/uio.h:196 [inline]
|
||
memcpy_to_msg include/linux/skbuff.h:4113 [inline]
|
||
raw_recvmsg+0x2b8/0x9e0 net/can/raw.c:1008
|
||
sock_recvmsg_nosec net/socket.c:1046 [inline]
|
||
sock_recvmsg+0x2c4/0x340 net/socket.c:1068
|
||
____sys_recvmsg+0x18a/0x620 net/socket.c:2803
|
||
___sys_recvmsg+0x223/0x840 net/socket.c:2845
|
||
do_recvmmsg+0x4fc/0xfd0 net/socket.c:2939
|
||
__sys_recvmmsg net/socket.c:3018 [inline]
|
||
__do_sys_recvmmsg net/socket.c:3041 [inline]
|
||
__se_sys_recvmmsg net/socket.c:3034 [inline]
|
||
__x64_sys_recvmmsg+0x397/0x490 net/socket.c:3034
|
||
x64_sys_call+0xf6c/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:300
|
||
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
||
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
|
||
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
||
|
||
Uninit was created at:
|
||
slab_post_alloc_hook mm/slub.c:3804 [inline]
|
||
slab_alloc_node mm/slub.c:3845 [inline]
|
||
kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888
|
||
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577
|
||
__alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668
|
||
alloc_skb include/linux/skbuff.h:1313 [inline]
|
||
alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504
|
||
sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795
|
||
sock_alloc_send_skb include/net/sock.h:1842 [inline]
|
||
j1939_sk_alloc_skb net/can/j1939/socket.c:878 [inline]
|
||
j1939_sk_send_loop net/can/j1939/socket.c:1142 [inline]
|
||
j1939_sk_sendmsg+0xc0a/0x2730 net/can/j1939/socket.c:1277
|
||
sock_sendmsg_nosec net/socket.c:730 [inline]
|
||
__sock_sendmsg+0x30f/0x380 net/socket.c:745
|
||
____sys_sendmsg+0x877/0xb60 net/socket.c:2584
|
||
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
|
||
__sys_sendmsg net/socket.c:2667 [inline]
|
||
__do_sys_sendmsg net/socket.c:2676 [inline]
|
||
__se_sys_sendmsg net/socket.c:2674 [inline]
|
||
__x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674
|
||
x64_sys_call+0xc4b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:47
|
||
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
||
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
|
||
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
||
|
||
Bytes 12-15 of 16 are uninitialized
|
||
Memory access of size 16 starts at ffff888120969690
|
||
Data copied to user address 00000000200017c0
|
||
|
||
CPU: 1 PID: 5050 Comm: syz-executor198 Not tainted 6.9.0-rc5-syzkaller-00031-g71b1543c83d6 #0
|
||
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-42076</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="52" 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:
|
||
|
||
ocfs2: fix DIO failure due to insufficient transaction credits
|
||
|
||
The code in ocfs2_dio_end_io_write() estimates number of necessary
|
||
transaction credits using ocfs2_calc_extend_credits(). This however does
|
||
not take into account that the IO could be arbitrarily large and can
|
||
contain arbitrary number of extents.
|
||
|
||
Extent tree manipulations do often extend the current transaction but not
|
||
in all of the cases. For example if we have only single block extents in
|
||
the tree, ocfs2_mark_extent_written() will end up calling
|
||
ocfs2_replace_extent_rec() all the time and we will never extend the
|
||
current transaction and eventually exhaust all the transaction credits if
|
||
the IO contains many single block extents. Once that happens a
|
||
WARN_ON(jbd2_handle_buffer_credits(handle) <= 0) is triggered in
|
||
jbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response to
|
||
this error. This was actually triggered by one of our customers on a
|
||
heavily fragmented OCFS2 filesystem.
|
||
|
||
To fix the issue make sure the transaction always has enough credits for
|
||
one extent insert before each call of ocfs2_mark_extent_written().
|
||
|
||
Heming Zhao said:
|
||
|
||
------
|
||
PANIC: "Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error"
|
||
|
||
PID: xxx TASK: xxxx CPU: 5 COMMAND: "SubmitThread-CA"
|
||
#0 machine_kexec at ffffffff8c069932
|
||
#1 __crash_kexec at ffffffff8c1338fa
|
||
#2 panic at ffffffff8c1d69b9
|
||
#3 ocfs2_handle_error at ffffffffc0c86c0c [ocfs2]
|
||
#4 __ocfs2_abort at ffffffffc0c88387 [ocfs2]
|
||
#5 ocfs2_journal_dirty at ffffffffc0c51e98 [ocfs2]
|
||
#6 ocfs2_split_extent at ffffffffc0c27ea3 [ocfs2]
|
||
#7 ocfs2_change_extent_flag at ffffffffc0c28053 [ocfs2]
|
||
#8 ocfs2_mark_extent_written at ffffffffc0c28347 [ocfs2]
|
||
#9 ocfs2_dio_end_io_write at ffffffffc0c2bef9 [ocfs2]
|
||
#10 ocfs2_dio_end_io at ffffffffc0c2c0f5 [ocfs2]
|
||
#11 dio_complete at ffffffff8c2b9fa7
|
||
#12 do_blockdev_direct_IO at ffffffff8c2bc09f
|
||
#13 ocfs2_direct_IO at ffffffffc0c2b653 [ocfs2]
|
||
#14 generic_file_direct_write at ffffffff8c1dcf14
|
||
#15 __generic_file_write_iter at ffffffff8c1dd07b
|
||
#16 ocfs2_file_write_iter at ffffffffc0c49f1f [ocfs2]
|
||
#17 aio_write at ffffffff8c2cc72e
|
||
#18 kmem_cache_alloc at ffffffff8c248dde
|
||
#19 do_io_submit at ffffffff8c2ccada
|
||
#20 do_syscall_64 at ffffffff8c004984
|
||
#21 entry_SYSCALL_64_after_hwframe at ffffffff8c8000ba</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-42077</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="53" 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/restrack: Fix potential invalid address access
|
||
|
||
struct rdma_restrack_entry's kern_name was set to KBUILD_MODNAME
|
||
in ib_create_cq(), while if the module exited but forgot del this
|
||
rdma_restrack_entry, it would cause a invalid address access in
|
||
rdma_restrack_clean() when print the owner of this rdma_restrack_entry.
|
||
|
||
These code is used to help find one forgotten PD release in one of the
|
||
ULPs. But it is not needed anymore, so delete them.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-42080</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="54" 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:
|
||
|
||
xdp: Remove WARN() from __xdp_reg_mem_model()
|
||
|
||
syzkaller reports a warning in __xdp_reg_mem_model().
|
||
|
||
The warning occurs only if __mem_id_init_hash_table() returns an error. It
|
||
returns the error in two cases:
|
||
|
||
1. memory allocation fails;
|
||
2. rhashtable_init() fails when some fields of rhashtable_params
|
||
struct are not initialized properly.
|
||
|
||
The second case cannot happen since there is a static const rhashtable_params
|
||
struct with valid fields. So, warning is only triggered when there is a
|
||
problem with memory allocation.
|
||
|
||
Thus, there is no sense in using WARN() to handle this error and it can be
|
||
safely removed.
|
||
|
||
WARNING: CPU: 0 PID: 5065 at net/core/xdp.c:299 __xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299
|
||
|
||
CPU: 0 PID: 5065 Comm: syz-executor883 Not tainted 6.8.0-syzkaller-05271-gf99c5f563c17 #0
|
||
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
|
||
RIP: 0010:__xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299
|
||
|
||
Call Trace:
|
||
xdp_reg_mem_model+0x22/0x40 net/core/xdp.c:344
|
||
xdp_test_run_setup net/bpf/test_run.c:188 [inline]
|
||
bpf_test_run_xdp_live+0x365/0x1e90 net/bpf/test_run.c:377
|
||
bpf_prog_test_run_xdp+0x813/0x11b0 net/bpf/test_run.c:1267
|
||
bpf_prog_test_run+0x33a/0x3b0 kernel/bpf/syscall.c:4240
|
||
__sys_bpf+0x48d/0x810 kernel/bpf/syscall.c:5649
|
||
__do_sys_bpf kernel/bpf/syscall.c:5738 [inline]
|
||
__se_sys_bpf kernel/bpf/syscall.c:5736 [inline]
|
||
__x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5736
|
||
do_syscall_64+0xfb/0x240
|
||
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
||
|
||
Found by Linux Verification Center (linuxtesting.org) with syzkaller.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-42082</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="55" 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:
|
||
|
||
ftruncate: pass a signed offset
|
||
|
||
The old ftruncate() syscall, using the 32-bit off_t misses a sign
|
||
extension when called in compat mode on 64-bit architectures. As a
|
||
result, passing a negative length accidentally succeeds in truncating
|
||
to file size between 2GiB and 4GiB.
|
||
|
||
Changing the type of the compat syscall to the signed compat_off_t
|
||
changes the behavior so it instead returns -EINVAL.
|
||
|
||
The native entry point, the truncate() syscall and the corresponding
|
||
loff_t based variants are all correct already and do not suffer
|
||
from this mistake.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-42084</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:A/AC:L/PR:L/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-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="56" 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:
|
||
|
||
iio: chemical: bme680: Fix overflows in compensate() functions
|
||
|
||
There are cases in the compensate functions of the driver that
|
||
there could be overflows of variables due to bit shifting ops.
|
||
These implications were initially discussed here [1] and they
|
||
were mentioned in log message of Commit 1b3bd8592780 ("iio:
|
||
chemical: Add support for Bosch BME680 sensor").
|
||
|
||
[1]: https://lore.kernel.org/linux-iio/20180728114028.3c1bbe81@archlinux/</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-42086</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="57" 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:
|
||
|
||
ASoC: fsl-asoc-card: set priv->pdev before using it
|
||
|
||
priv->pdev pointer was set after being used in
|
||
fsl_asoc_card_audmux_init().
|
||
Move this assignment at the start of the probe function, so
|
||
sub-functions can correctly use pdev through priv.
|
||
|
||
fsl_asoc_card_audmux_init() dereferences priv->pdev to get access to the
|
||
dev struct, used with dev_err macros.
|
||
As priv is zero-initialised, there would be a NULL pointer dereference.
|
||
Note that if priv->dev is dereferenced before assignment but never used,
|
||
for example if there is no error to be printed, the driver won't crash
|
||
probably due to compiler optimisations.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-42089</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="58" 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:
|
||
|
||
pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER
|
||
|
||
In create_pinctrl(), pinctrl_maps_mutex is acquired before calling
|
||
add_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl()
|
||
calls pinctrl_free(). However, pinctrl_free() attempts to acquire
|
||
pinctrl_maps_mutex, which is already held by create_pinctrl(), leading to
|
||
a potential deadlock.
|
||
|
||
This patch resolves the issue by releasing pinctrl_maps_mutex before
|
||
calling pinctrl_free(), preventing the deadlock.
|
||
|
||
This bug was discovered and resolved using Coverity Static Analysis
|
||
Security Testing (SAST) by Synopsys, Inc.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-42090</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="59" 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:
|
||
|
||
gpio: davinci: Validate the obtained number of IRQs
|
||
|
||
Value of pdata->gpio_unbanked is taken from Device Tree. In case of broken
|
||
DT due to any error this value can be any. Without this value validation
|
||
there can be out of chips->irqs array boundaries access in
|
||
davinci_gpio_probe().
|
||
|
||
Validate the obtained nirq value so that it won't exceed the maximum
|
||
number of IRQs per bank.
|
||
|
||
Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-42092</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="60" 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/dpaa2: Avoid explicit cpumask var allocation on stack
|
||
|
||
For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask
|
||
variable on stack is not recommended since it can cause potential stack
|
||
overflow.
|
||
|
||
Instead, kernel code should always use *cpumask_var API(s) to allocate
|
||
cpumask var in config-neutral way, leaving allocation strategy to
|
||
CONFIG_CPUMASK_OFFSTACK.
|
||
|
||
Use *cpumask_var API(s) to address it.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-42093</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>6.6</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="61" 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/iucv: Avoid explicit cpumask var allocation on stack
|
||
|
||
For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask
|
||
variable on stack is not recommended since it can cause potential stack
|
||
overflow.
|
||
|
||
Instead, kernel code should always use *cpumask_var API(s) to allocate
|
||
cpumask var in config-neutral way, leaving allocation strategy to
|
||
CONFIG_CPUMASK_OFFSTACK.
|
||
|
||
Use *cpumask_var API(s) to address it.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-42094</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>6.6</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="62" 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: emux: improve patch ioctl data validation
|
||
|
||
In load_data(), make the validation of and skipping over the main info
|
||
block match that in load_guspatch().
|
||
|
||
In load_guspatch(), add checking that the specified patch length matches
|
||
the actually supplied data, like load_data() already did.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-42097</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="63" 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:
|
||
|
||
drm/nouveau: fix null pointer dereference in nouveau_connector_get_modes
|
||
|
||
In nouveau_connector_get_modes(), the return value of drm_mode_duplicate()
|
||
is assigned to mode, which will lead to a possible NULL pointer
|
||
dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-42101</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="64" 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:
|
||
|
||
inet_diag: Initialize pad field in struct inet_diag_req_v2
|
||
|
||
KMSAN reported uninit-value access in raw_lookup() [1]. Diag for raw
|
||
sockets uses the pad field in struct inet_diag_req_v2 for the
|
||
underlying protocol. This field corresponds to the sdiag_raw_protocol
|
||
field in struct inet_diag_req_raw.
|
||
|
||
inet_diag_get_exact_compat() converts inet_diag_req to
|
||
inet_diag_req_v2, but leaves the pad field uninitialized. So the issue
|
||
occurs when raw_lookup() accesses the sdiag_raw_protocol field.
|
||
|
||
Fix this by initializing the pad field in
|
||
inet_diag_get_exact_compat(). Also, do the same fix in
|
||
inet_diag_dump_compat() to avoid the similar issue in the future.
|
||
|
||
[1]
|
||
BUG: KMSAN: uninit-value in raw_lookup net/ipv4/raw_diag.c:49 [inline]
|
||
BUG: KMSAN: uninit-value in raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71
|
||
raw_lookup net/ipv4/raw_diag.c:49 [inline]
|
||
raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71
|
||
raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99
|
||
inet_diag_cmd_exact+0x7d9/0x980
|
||
inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline]
|
||
inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426
|
||
sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282
|
||
netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564
|
||
sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297
|
||
netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]
|
||
netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361
|
||
netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905
|
||
sock_sendmsg_nosec net/socket.c:730 [inline]
|
||
__sock_sendmsg+0x332/0x3d0 net/socket.c:745
|
||
____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585
|
||
___sys_sendmsg+0x271/0x3b0 net/socket.c:2639
|
||
__sys_sendmsg net/socket.c:2668 [inline]
|
||
__do_sys_sendmsg net/socket.c:2677 [inline]
|
||
__se_sys_sendmsg net/socket.c:2675 [inline]
|
||
__x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675
|
||
x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47
|
||
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
||
do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83
|
||
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
||
|
||
Uninit was stored to memory at:
|
||
raw_sock_get+0x650/0x800 net/ipv4/raw_diag.c:71
|
||
raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99
|
||
inet_diag_cmd_exact+0x7d9/0x980
|
||
inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline]
|
||
inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426
|
||
sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282
|
||
netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564
|
||
sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297
|
||
netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]
|
||
netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361
|
||
netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905
|
||
sock_sendmsg_nosec net/socket.c:730 [inline]
|
||
__sock_sendmsg+0x332/0x3d0 net/socket.c:745
|
||
____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585
|
||
___sys_sendmsg+0x271/0x3b0 net/socket.c:2639
|
||
__sys_sendmsg net/socket.c:2668 [inline]
|
||
__do_sys_sendmsg net/socket.c:2677 [inline]
|
||
__se_sys_sendmsg net/socket.c:2675 [inline]
|
||
__x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675
|
||
x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47
|
||
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
||
do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83
|
||
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
||
|
||
Local variable req.i created at:
|
||
inet_diag_get_exact_compat net/ipv4/inet_diag.c:1396 [inline]
|
||
inet_diag_rcv_msg_compat+0x2a6/0x530 net/ipv4/inet_diag.c:1426
|
||
sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282
|
||
|
||
CPU: 1 PID: 8888 Comm: syz-executor.6 Not tainted 6.10.0-rc4-00217-g35bb670d65fc #32
|
||
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-42106</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="65" 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:
|
||
|
||
jffs2: Fix potential illegal address access in jffs2_free_inode
|
||
|
||
During the stress testing of the jffs2 file system,the following
|
||
abnormal printouts were found:
|
||
[ 2430.649000] Unable to handle kernel paging request at virtual address 0069696969696948
|
||
[ 2430.649622] Mem abort info:
|
||
[ 2430.649829] ESR = 0x96000004
|
||
[ 2430.650115] EC = 0x25: DABT (current EL), IL = 32 bits
|
||
[ 2430.650564] SET = 0, FnV = 0
|
||
[ 2430.650795] EA = 0, S1PTW = 0
|
||
[ 2430.651032] FSC = 0x04: level 0 translation fault
|
||
[ 2430.651446] Data abort info:
|
||
[ 2430.651683] ISV = 0, ISS = 0x00000004
|
||
[ 2430.652001] CM = 0, WnR = 0
|
||
[ 2430.652558] [0069696969696948] address between user and kernel address ranges
|
||
[ 2430.653265] Internal error: Oops: 96000004 [#1] PREEMPT SMP
|
||
[ 2430.654512] CPU: 2 PID: 20919 Comm: cat Not tainted 5.15.25-g512f31242bf6 #33
|
||
[ 2430.655008] Hardware name: linux,dummy-virt (DT)
|
||
[ 2430.655517] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
||
[ 2430.656142] pc : kfree+0x78/0x348
|
||
[ 2430.656630] lr : jffs2_free_inode+0x24/0x48
|
||
[ 2430.657051] sp : ffff800009eebd10
|
||
[ 2430.657355] x29: ffff800009eebd10 x28: 0000000000000001 x27: 0000000000000000
|
||
[ 2430.658327] x26: ffff000038f09d80 x25: 0080000000000000 x24: ffff800009d38000
|
||
[ 2430.658919] x23: 5a5a5a5a5a5a5a5a x22: ffff000038f09d80 x21: ffff8000084f0d14
|
||
[ 2430.659434] x20: ffff0000bf9a6ac0 x19: 0169696969696940 x18: 0000000000000000
|
||
[ 2430.659969] x17: ffff8000b6506000 x16: ffff800009eec000 x15: 0000000000004000
|
||
[ 2430.660637] x14: 0000000000000000 x13: 00000001000820a1 x12: 00000000000d1b19
|
||
[ 2430.661345] x11: 0004000800000000 x10: 0000000000000001 x9 : ffff8000084f0d14
|
||
[ 2430.662025] x8 : ffff0000bf9a6b40 x7 : ffff0000bf9a6b48 x6 : 0000000003470302
|
||
[ 2430.662695] x5 : ffff00002e41dcc0 x4 : ffff0000bf9aa3b0 x3 : 0000000003470342
|
||
[ 2430.663486] x2 : 0000000000000000 x1 : ffff8000084f0d14 x0 : fffffc0000000000
|
||
[ 2430.664217] Call trace:
|
||
[ 2430.664528] kfree+0x78/0x348
|
||
[ 2430.664855] jffs2_free_inode+0x24/0x48
|
||
[ 2430.665233] i_callback+0x24/0x50
|
||
[ 2430.665528] rcu_do_batch+0x1ac/0x448
|
||
[ 2430.665892] rcu_core+0x28c/0x3c8
|
||
[ 2430.666151] rcu_core_si+0x18/0x28
|
||
[ 2430.666473] __do_softirq+0x138/0x3cc
|
||
[ 2430.666781] irq_exit+0xf0/0x110
|
||
[ 2430.667065] handle_domain_irq+0x6c/0x98
|
||
[ 2430.667447] gic_handle_irq+0xac/0xe8
|
||
[ 2430.667739] call_on_irq_stack+0x28/0x54
|
||
The parameter passed to kfree was 5a5a5a5a, which corresponds to the target field of
|
||
the jffs_inode_info structure. It was found that all variables in the jffs_inode_info
|
||
structure were 5a5a5a5a, except for the first member sem. It is suspected that these
|
||
variables are not initialized because they were set to 5a5a5a5a during memory testing,
|
||
which is meant to detect uninitialized memory.The sem variable is initialized in the
|
||
function jffs2_i_init_once, while other members are initialized in
|
||
the function jffs2_init_inode_info.
|
||
|
||
The function jffs2_init_inode_info is called after iget_locked,
|
||
but in the iget_locked function, the destroy_inode process is triggered,
|
||
which releases the inode and consequently, the target member of the inode
|
||
is not initialized.In concurrent high pressure scenarios, iget_locked
|
||
may enter the destroy_inode branch as described in the code.
|
||
|
||
Since the destroy_inode functionality of jffs2 only releases the target,
|
||
the fix method is to set target to NULL in jffs2_i_init_once.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-42115</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="66" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
||
<Notes>
|
||
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
scsi: qedf: Make qedf_execute_tmf() non-preemptible
|
||
|
||
Stop calling smp_processor_id() from preemptible code in
|
||
qedf_execute_tmf90. This results in BUG_ON() when running an RT kernel.
|
||
|
||
[ 659.343280] BUG: using smp_processor_id() in preemptible [00000000] code: sg_reset/3646
|
||
[ 659.343282] caller is qedf_execute_tmf+0x8b/0x360 [qedf]</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-42124</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="67" 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:
|
||
|
||
leds: mlxreg: Use devm_mutex_init() for mutex initialization
|
||
|
||
In this driver LEDs are registered using devm_led_classdev_register()
|
||
so they are automatically unregistered after module's remove() is done.
|
||
led_classdev_unregister() calls module's led_set_brightness() to turn off
|
||
the LEDs and that callback uses mutex which was destroyed already
|
||
in module's remove() so use devm API instead.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-42129</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Low</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>3.3</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="68" 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: qca: Fix BT enable failure again for QCA6390 after warm reboot
|
||
|
||
Commit 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed
|
||
serdev") will cause below regression issue:
|
||
|
||
BT can't be enabled after below steps:
|
||
cold boot -> enable BT -> disable BT -> warm reboot -> BT enable failure
|
||
if property enable-gpios is not configured within DT|ACPI for QCA6390.
|
||
|
||
The commit is to fix a use-after-free issue within qca_serdev_shutdown()
|
||
by adding condition to avoid the serdev is flushed or wrote after closed
|
||
but also introduces this regression issue regarding above steps since the
|
||
VSC is not sent to reset controller during warm reboot.
|
||
|
||
Fixed by sending the VSC to reset controller within qca_serdev_shutdown()
|
||
once BT was ever enabled, and the use-after-free issue is also fixed by
|
||
this change since the serdev is still opened before it is flushed or wrote.
|
||
|
||
Verified by the reported machine Dell XPS 13 9310 laptop over below two
|
||
kernel commits:
|
||
commit e00fc2700a3f ("Bluetooth: btusb: Fix triggering coredump
|
||
implementation for QCA") of bluetooth-next tree.
|
||
commit b23d98d46d28 ("Bluetooth: btusb: Fix triggering coredump
|
||
implementation for QCA") of linus mainline tree.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-42137</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="69" 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:
|
||
|
||
IB/core: Implement a limit on UMAD receive List
|
||
|
||
The existing behavior of ib_umad, which maintains received MAD
|
||
packets in an unbounded list, poses a risk of uncontrolled growth.
|
||
As user-space applications extract packets from this list, the rate
|
||
of extraction may not match the rate of incoming packets, leading
|
||
to potential list overflow.
|
||
|
||
To address this, we introduce a limit to the size of the list. After
|
||
considering typical scenarios, such as OpenSM processing, which can
|
||
handle approximately 100k packets per second, and the 1-second retry
|
||
timeout for most packets, we set the list size limit to 200k. Packets
|
||
received beyond this limit are dropped, assuming they are likely timed
|
||
out by the time they are handled by user-space.
|
||
|
||
Notably, packets queued on the receive list due to reasons like
|
||
timed-out sends are preserved even when the list is full.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-42145</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="70" 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:
|
||
|
||
s390/pkey: Wipe copies of protected- and secure-keys
|
||
|
||
Although the clear-key of neither protected- nor secure-keys is
|
||
accessible, this key material should only be visible to the calling
|
||
process. So wipe all copies of protected- or secure-keys from stack,
|
||
even in case of an error.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-42155</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>4.1</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="71" 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: check validation of fault attrs in f2fs_build_fault_attr()
|
||
|
||
- It missed to check validation of fault attrs in parse_options(),
|
||
let's fix to add check condition in f2fs_build_fault_attr().
|
||
- Use f2fs_build_fault_attr() in __sbi_store() to clean up code.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-42160</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>High</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>7.8</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="72" 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:
|
||
|
||
bpf: Avoid uninitialized value in BPF_CORE_READ_BITFIELD
|
||
|
||
[Changes from V1:
|
||
- Use a default branch in the switch statement to initialize `val'.]
|
||
|
||
GCC warns that `val' may be used uninitialized in the
|
||
BPF_CRE_READ_BITFIELD macro, defined in bpf_core_read.h as:
|
||
|
||
[...]
|
||
unsigned long long val; \
|
||
[...] \
|
||
switch (__CORE_RELO(s, field, BYTE_SIZE)) { \
|
||
case 1: val = *(const unsigned char *)p; break; \
|
||
case 2: val = *(const unsigned short *)p; break; \
|
||
case 4: val = *(const unsigned int *)p; break; \
|
||
case 8: val = *(const unsigned long long *)p; break; \
|
||
} \
|
||
[...]
|
||
val; \
|
||
} \
|
||
|
||
This patch adds a default entry in the switch statement that sets
|
||
`val' to zero in order to avoid the warning, and random values to be
|
||
used in case __builtin_preserve_field_info returns unexpected values
|
||
for BPF_FIELD_BYTE_SIZE.
|
||
|
||
Tested in bpf-next master.
|
||
No regressions.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-42161</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>High</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>7.8</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="73" 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:gve: Account for stopped queues when reading NIC statsWe now account for the fact that the NIC might send us stats for asubset of queues. Without this change, gve_get_ethtool_stats might makean invalid access on the priv->stats_report->stats array.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-42162</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>High</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>7.0</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="74" 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: dsa: mv88e6xxx: Correct check for empty list
|
||
|
||
Since commit a3c53be55c95 ("net: dsa: mv88e6xxx: Support multiple MDIO
|
||
busses") mv88e6xxx_default_mdio_bus() has checked that the
|
||
return value of list_first_entry() is non-NULL.
|
||
|
||
This appears to be intended to guard against the list chip->mdios being
|
||
empty. However, it is not the correct check as the implementation of
|
||
list_first_entry is not designed to return NULL for empty lists.
|
||
|
||
Instead, use list_first_entry_or_null() which does return NULL if the
|
||
list is empty.
|
||
|
||
Flagged by Smatch.
|
||
Compile tested only.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-42224</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>High</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>7.8</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="75" 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:drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_relocInitialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001.V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian)</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-09</ReleaseDate>
|
||
<CVE>CVE-2024-42228</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>High</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>7.0</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-09</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1962</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
</cvrfdoc> |