5554 lines
227 KiB
XML
5554 lines
227 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
|
|
<DocumentTitle xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP1</DocumentTitle>
|
|
<DocumentType>Security Advisory</DocumentType>
|
|
<DocumentPublisher Type="Vendor">
|
|
<ContactDetails>openeuler-security@openeuler.org</ContactDetails>
|
|
<IssuingAuthority>openEuler security committee</IssuingAuthority>
|
|
</DocumentPublisher>
|
|
<DocumentTracking>
|
|
<Identification>
|
|
<ID>openEuler-SA-2024-1964</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-SP1</Note>
|
|
<Note Title="Description" Type="General" Ordinal="3" xml:lang="en">The Linux Kernel, the operating system core itself.
|
|
|
|
Security Fix(es):
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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:
|
|
|
|
ALSA: scarlett2: Add clamp() in scarlett2_mixer_ctl_put()
|
|
|
|
Ensure the value passed to scarlett2_mixer_ctl_put() is between 0 and
|
|
SCARLETT2_MIXER_MAX_VALUE so we don't attempt to access outside
|
|
scarlett2_mixer_values[].(CVE-2023-52674)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: gspca: cpia1: shift-out-of-bounds in set_flicker
|
|
|
|
Syzkaller reported the following issue:
|
|
UBSAN: shift-out-of-bounds in drivers/media/usb/gspca/cpia1.c:1031:27
|
|
shift exponent 245 is too large for 32-bit type 'int'
|
|
|
|
When the value of the variable "sd->params.exposure.gain" exceeds the
|
|
number of bits in an integer, a shift-out-of-bounds error is reported. It
|
|
is triggered because the variable "currentexp" cannot be left-shifted by
|
|
more than the number of bits in an integer. In order to avoid invalid
|
|
range during left-shift, the conditional expression is added.(CVE-2023-52764)
|
|
|
|
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:
|
|
|
|
selinux: avoid dereference of garbage after mount failure
|
|
|
|
In case kern_mount() fails and returns an error pointer return in the
|
|
error branch instead of continuing and dereferencing the error pointer.
|
|
|
|
While on it drop the never read static variable selinuxfs_mount.(CVE-2024-35904)
|
|
|
|
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/amdgpu: add error handle to avoid out-of-bounds
|
|
|
|
if the sdma_v4_0_irq_id_to_seq return -EINVAL, the process should
|
|
be stop to avoid out-of-bounds read, so directly return -EINVAL.(CVE-2024-39471)
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
ssb: Fix potential NULL pointer dereference in ssb_device_uevent()
|
|
|
|
The ssb_device_uevent() function first attempts to convert the 'dev' pointer
|
|
to 'struct ssb_device *'. However, it mistakenly dereferences 'dev' before
|
|
performing the NULL check, potentially leading to a NULL pointer
|
|
dereference if 'dev' is NULL.
|
|
|
|
To fix this issue, move the NULL check before dereferencing the 'dev' pointer,
|
|
ensuring that the pointer is valid before attempting to use it.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-40982)
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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-SP1.
|
|
|
|
openEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.</Note>
|
|
<Note Title="Severity" Type="General" Ordinal="5" xml:lang="en">High</Note>
|
|
<Note Title="Affected Component" Type="General" Ordinal="6" xml:lang="en">kernel</Note>
|
|
</DocumentNotes>
|
|
<DocumentReferences>
|
|
<Reference Type="Self">
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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-2023-52674</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-52764</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-35904</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-39471</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-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-40982</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-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-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-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-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-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-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-2023-52674</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52764</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-35904</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-39471</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39497</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-40982</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-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-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-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-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-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-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-SP1" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">openEuler-22.03-LTS-SP1</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="kernel-5.10.0-136.88.0.169" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-136.88.0.169" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debuginfo-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-136.88.0.169" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debugsource-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-136.88.0.169" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-devel-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-136.88.0.169" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-headers-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-136.88.0.169" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-source-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-136.88.0.169" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-136.88.0.169" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-debuginfo-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-136.88.0.169" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-devel-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-136.88.0.169" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-136.88.0.169" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-debuginfo-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-136.88.0.169" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-136.88.0.169" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-debuginfo-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="kernel-5.10.0-136.88.0.169" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-136.88.0.169" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debuginfo-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-136.88.0.169" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debugsource-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-136.88.0.169" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-devel-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-136.88.0.169" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-headers-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-136.88.0.169" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-source-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-136.88.0.169" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-136.88.0.169" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-debuginfo-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-136.88.0.169" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-devel-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-136.88.0.169" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-136.88.0.169" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-debuginfo-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-136.88.0.169" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-136.88.0.169" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-debuginfo-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-5.10.0-136.88.0.169" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-5.10.0-136.88.0.169.oe2203sp1.src.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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.7</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
ALSA: scarlett2: Add clamp() in scarlett2_mixer_ctl_put()
|
|
|
|
Ensure the value passed to scarlett2_mixer_ctl_put() is between 0 and
|
|
SCARLETT2_MIXER_MAX_VALUE so we don't attempt to access outside
|
|
scarlett2_mixer_values[].</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-09</ReleaseDate>
|
|
<CVE>CVE-2023-52674</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
media: gspca: cpia1: shift-out-of-bounds in set_flicker
|
|
|
|
Syzkaller reported the following issue:
|
|
UBSAN: shift-out-of-bounds in drivers/media/usb/gspca/cpia1.c:1031:27
|
|
shift exponent 245 is too large for 32-bit type 'int'
|
|
|
|
When the value of the variable "sd->params.exposure.gain" exceeds the
|
|
number of bits in an integer, a shift-out-of-bounds error is reported. It
|
|
is triggered because the variable "currentexp" cannot be left-shifted by
|
|
more than the number of bits in an integer. In order to avoid invalid
|
|
range during left-shift, the conditional expression is added.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-09</ReleaseDate>
|
|
<CVE>CVE-2023-52764</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</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-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
selinux: avoid dereference of garbage after mount failure
|
|
|
|
In case kern_mount() fails and returns an error pointer return in the
|
|
error branch instead of continuing and dereferencing the error pointer.
|
|
|
|
While on it drop the never read static variable selinuxfs_mount.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-09</ReleaseDate>
|
|
<CVE>CVE-2024-35904</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</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-1964</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="9" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: 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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.1</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C: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-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
drm/amdgpu: add error handle to avoid out-of-bounds
|
|
|
|
if the sdma_v4_0_irq_id_to_seq return -EINVAL, the process should
|
|
be stop to avoid out-of-bounds read, so directly return -EINVAL.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-09</ReleaseDate>
|
|
<CVE>CVE-2024-39471</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.9</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.9</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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/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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
ssb: Fix potential NULL pointer dereference in ssb_device_uevent()
|
|
|
|
The ssb_device_uevent() function first attempts to convert the 'dev' pointer
|
|
to 'struct ssb_device *'. However, it mistakenly dereferences 'dev' before
|
|
performing the NULL check, potentially leading to a NULL pointer
|
|
dereference if 'dev' is NULL.
|
|
|
|
To fix this issue, move the NULL check before dereferencing the 'dev' pointer,
|
|
ensuring that the pointer is valid before attempting to use it.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-09</ReleaseDate>
|
|
<CVE>CVE-2024-40982</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</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-1964</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: 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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.3</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C: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-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</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-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</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-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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: 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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</BaseScore>
|
|
<Vector>AV:L/AC:L/PR: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-1964</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:
|
|
|
|
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-SP1</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-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</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-1964</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:
|
|
|
|
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-SP1</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-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</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-1964</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:
|
|
|
|
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-SP1</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-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</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-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</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-1964</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:
|
|
|
|
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-SP1</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-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.3</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I: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-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.1</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C: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-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.8</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.8</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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: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-SP1</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-1964</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:
|
|
|
|
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-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.8</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1964</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: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-SP1</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-1964</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |