2392 lines
103 KiB
XML
2392 lines
103 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
|
|
<DocumentTitle xml:lang="en">An update for kernel is now available for openEuler-20.03-LTS-SP4</DocumentTitle>
|
|
<DocumentType>Security Advisory</DocumentType>
|
|
<DocumentPublisher Type="Vendor">
|
|
<ContactDetails>openeuler-security@openeuler.org</ContactDetails>
|
|
<IssuingAuthority>openEuler security committee</IssuingAuthority>
|
|
</DocumentPublisher>
|
|
<DocumentTracking>
|
|
<Identification>
|
|
<ID>openEuler-SA-2024-1963</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-20.03-LTS-SP4</Note>
|
|
<Note Title="Description" Type="General" Ordinal="3" xml:lang="en">The Linux Kernel, the operating system core itself.
|
|
|
|
Security Fix(es):
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
thermal: Fix NULL pointer dereferences in of_thermal_ functions
|
|
|
|
of_parse_thermal_zones() parses the thermal-zones node and registers a
|
|
thermal_zone device for each subnode. However, if a thermal zone is
|
|
consuming a thermal sensor and that thermal sensor device hasn't probed
|
|
yet, an attempt to set trip_point_*_temp for that thermal zone device
|
|
can cause a NULL pointer dereference. Fix it.
|
|
|
|
console:/sys/class/thermal/thermal_zone87 # echo 120000 > trip_point_0_temp
|
|
...
|
|
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020
|
|
...
|
|
Call trace:
|
|
of_thermal_set_trip_temp+0x40/0xc4
|
|
trip_point_temp_store+0xc0/0x1dc
|
|
dev_attr_store+0x38/0x88
|
|
sysfs_kf_write+0x64/0xc0
|
|
kernfs_fop_write_iter+0x108/0x1d0
|
|
vfs_write+0x2f4/0x368
|
|
ksys_write+0x7c/0xec
|
|
__arm64_sys_write+0x20/0x30
|
|
el0_svc_common.llvm.7279915941325364641+0xbc/0x1bc
|
|
do_el0_svc+0x28/0xa0
|
|
el0_svc+0x14/0x24
|
|
el0_sync_handler+0x88/0xec
|
|
el0_sync+0x1c0/0x200
|
|
|
|
While at it, fix the possible NULL pointer dereference in other
|
|
functions as well: of_thermal_get_temp(), of_thermal_set_emul_temp(),
|
|
of_thermal_get_trend().(CVE-2021-47202)
|
|
|
|
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:
|
|
|
|
jfs: xattr: fix buffer overflow for invalid xattr
|
|
|
|
When an xattr size is not what is expected, it is printed out to the
|
|
kernel log in hex format as a form of debugging. But when that xattr
|
|
size is bigger than the expected size, printing it out can cause an
|
|
access off the end of the buffer.
|
|
|
|
Fix this all up by properly restricting the size of the debug hex dump
|
|
in the kernel log.(CVE-2024-40902)
|
|
|
|
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:
|
|
|
|
netrom: Fix a memory leak in nr_heartbeat_expiry()
|
|
|
|
syzbot reported a memory leak in nr_create() [0].
|
|
|
|
Commit 409db27e3a2e ("netrom: Fix use-after-free of a listening socket.")
|
|
added sock_hold() to the nr_heartbeat_expiry() function, where
|
|
a) a socket has a SOCK_DESTROY flag or
|
|
b) a listening socket has a SOCK_DEAD flag.
|
|
|
|
But in the case "a," when the SOCK_DESTROY flag is set, the file descriptor
|
|
has already been closed and the nr_release() function has been called.
|
|
So it makes no sense to hold the reference count because no one will
|
|
call another nr_destroy_socket() and put it as in the case "b."
|
|
|
|
nr_connect
|
|
nr_establish_data_link
|
|
nr_start_heartbeat
|
|
|
|
nr_release
|
|
switch (nr->state)
|
|
case NR_STATE_3
|
|
nr->state = NR_STATE_2
|
|
sock_set_flag(sk, SOCK_DESTROY);
|
|
|
|
nr_rx_frame
|
|
nr_process_rx_frame
|
|
switch (nr->state)
|
|
case NR_STATE_2
|
|
nr_state2_machine()
|
|
nr_disconnect()
|
|
nr_sk(sk)->state = NR_STATE_0
|
|
sock_set_flag(sk, SOCK_DEAD)
|
|
|
|
nr_heartbeat_expiry
|
|
switch (nr->state)
|
|
case NR_STATE_0
|
|
if (sock_flag(sk, SOCK_DESTROY) ||
|
|
(sk->sk_state == TCP_LISTEN
|
|
&& sock_flag(sk, SOCK_DEAD)))
|
|
sock_hold() // ( !!! )
|
|
nr_destroy_socket()
|
|
|
|
To fix the memory leak, let's call sock_hold() only for a listening socket.
|
|
|
|
Found by InfoTeCS on behalf of Linux Verification Center
|
|
(linuxtesting.org) with Syzkaller.
|
|
|
|
[0]: https://syzkaller.appspot.com/bug?extid=d327a1f3b12e1e206c16(CVE-2024-41006)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
xfs: 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:
|
|
|
|
jfs: don't walk off the end of ealist
|
|
|
|
Add a check before visiting the members of ea to
|
|
make sure each ea stays within the ealist.(CVE-2024-41017)
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes
|
|
|
|
In nv17_tv_get_ld_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-41095)
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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/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:
|
|
|
|
nilfs2: add missing check for inode numbers on directory entries
|
|
|
|
Syzbot reported that mounting and unmounting a specific pattern of
|
|
corrupted nilfs2 filesystem images causes a use-after-free of metadata
|
|
file inodes, which triggers a kernel bug in lru_add_fn().
|
|
|
|
As Jan Kara pointed out, this is because the link count of a metadata file
|
|
gets corrupted to 0, and nilfs_evict_inode(), which is called from iput(),
|
|
tries to delete that inode (ifile inode in this case).
|
|
|
|
The inconsistency occurs because directories containing the inode numbers
|
|
of these metadata files that should not be visible in the namespace are
|
|
read without checking.
|
|
|
|
Fix this issue by treating the inode numbers of these internal files as
|
|
errors in the sanity check helper when reading directory folios/pages.
|
|
|
|
Also thanks to Hillf Danton and Matthew Wilcox for their initial mm-layer
|
|
analysis.(CVE-2024-42104)
|
|
|
|
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:
|
|
|
|
drm/amd/display: Skip finding free audio for unknown engine_id
|
|
|
|
[WHY]
|
|
ENGINE_ID_UNKNOWN = -1 and can not be used as an array index. Plus, it
|
|
also means it is uninitialized and does not need free audio.
|
|
|
|
[HOW]
|
|
Skip and return NULL.
|
|
|
|
This fixes 2 OVERRUN issues reported by Coverity.(CVE-2024-42119)
|
|
|
|
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:
|
|
|
|
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-20.03-LTS-SP4.
|
|
|
|
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-1963</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2021-47202</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-40902</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-41006</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-41017</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-41044</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-41069</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-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-41095</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-42077</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-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-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-42104</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-42119</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-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-47202</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-33621</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40902</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40959</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41006</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41014</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41017</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41020</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41044</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41063</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41069</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41072</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-41095</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41097</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42077</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42086</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-42094</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42097</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42104</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-42119</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42145</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-20.03-LTS-SP4" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">openEuler-20.03-LTS-SP4</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="bpftool-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-4.19.90-2408.2.0.0289.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-debuginfo-4.19.90-2408.2.0.0289.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2408.2.0.0289.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debuginfo-4.19.90-2408.2.0.0289.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debugsource-4.19.90-2408.2.0.0289.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-devel-4.19.90-2408.2.0.0289.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-source-4.19.90-2408.2.0.0289.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-4.19.90-2408.2.0.0289.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-debuginfo-4.19.90-2408.2.0.0289.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-devel-4.19.90-2408.2.0.0289.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-4.19.90-2408.2.0.0289.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-debuginfo-4.19.90-2408.2.0.0289.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-4.19.90-2408.2.0.0289.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-debuginfo-4.19.90-2408.2.0.0289.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-4.19.90-2408.2.0.0289.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-debuginfo-4.19.90-2408.2.0.0289.oe2003sp4.x86_64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2408.2.0.0289.oe2003sp4.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="bpftool-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-4.19.90-2408.2.0.0289.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-debuginfo-4.19.90-2408.2.0.0289.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2408.2.0.0289.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debuginfo-4.19.90-2408.2.0.0289.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debugsource-4.19.90-2408.2.0.0289.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-devel-4.19.90-2408.2.0.0289.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-source-4.19.90-2408.2.0.0289.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-4.19.90-2408.2.0.0289.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-debuginfo-4.19.90-2408.2.0.0289.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-devel-4.19.90-2408.2.0.0289.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-4.19.90-2408.2.0.0289.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-debuginfo-4.19.90-2408.2.0.0289.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-4.19.90-2408.2.0.0289.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-debuginfo-4.19.90-2408.2.0.0289.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-4.19.90-2408.2.0.0289.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2408.2.0.0289" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-debuginfo-4.19.90-2408.2.0.0289.oe2003sp4.aarch64.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:
|
|
|
|
thermal: Fix NULL pointer dereferences in of_thermal_ functions
|
|
|
|
of_parse_thermal_zones() parses the thermal-zones node and registers a
|
|
thermal_zone device for each subnode. However, if a thermal zone is
|
|
consuming a thermal sensor and that thermal sensor device hasn't probed
|
|
yet, an attempt to set trip_point_*_temp for that thermal zone device
|
|
can cause a NULL pointer dereference. Fix it.
|
|
|
|
console:/sys/class/thermal/thermal_zone87 # echo 120000 > trip_point_0_temp
|
|
...
|
|
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020
|
|
...
|
|
Call trace:
|
|
of_thermal_set_trip_temp+0x40/0xc4
|
|
trip_point_temp_store+0xc0/0x1dc
|
|
dev_attr_store+0x38/0x88
|
|
sysfs_kf_write+0x64/0xc0
|
|
kernfs_fop_write_iter+0x108/0x1d0
|
|
vfs_write+0x2f4/0x368
|
|
ksys_write+0x7c/0xec
|
|
__arm64_sys_write+0x20/0x30
|
|
el0_svc_common.llvm.7279915941325364641+0xbc/0x1bc
|
|
do_el0_svc+0x28/0xa0
|
|
el0_svc+0x14/0x24
|
|
el0_sync_handler+0x88/0xec
|
|
el0_sync+0x1c0/0x200
|
|
|
|
While at it, fix the possible NULL pointer dereference in other
|
|
functions as well: of_thermal_get_temp(), of_thermal_set_emul_temp(),
|
|
of_thermal_get_trend().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-09</ReleaseDate>
|
|
<CVE>CVE-2021-47202</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>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-1963</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:
|
|
|
|
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-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1963</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:
|
|
|
|
jfs: xattr: fix buffer overflow for invalid xattr
|
|
|
|
When an xattr size is not what is expected, it is printed out to the
|
|
kernel log in hex format as a form of debugging. But when that xattr
|
|
size is bigger than the expected size, printing it out can cause an
|
|
access off the end of the buffer.
|
|
|
|
Fix this all up by properly restricting the size of the debug hex dump
|
|
in the kernel log.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-09</ReleaseDate>
|
|
<CVE>CVE-2024-40902</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</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-1963</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:
|
|
|
|
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-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1963</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:
|
|
|
|
netrom: Fix a memory leak in nr_heartbeat_expiry()
|
|
|
|
syzbot reported a memory leak in nr_create() [0].
|
|
|
|
Commit 409db27e3a2e ("netrom: Fix use-after-free of a listening socket.")
|
|
added sock_hold() to the nr_heartbeat_expiry() function, where
|
|
a) a socket has a SOCK_DESTROY flag or
|
|
b) a listening socket has a SOCK_DEAD flag.
|
|
|
|
But in the case "a," when the SOCK_DESTROY flag is set, the file descriptor
|
|
has already been closed and the nr_release() function has been called.
|
|
So it makes no sense to hold the reference count because no one will
|
|
call another nr_destroy_socket() and put it as in the case "b."
|
|
|
|
nr_connect
|
|
nr_establish_data_link
|
|
nr_start_heartbeat
|
|
|
|
nr_release
|
|
switch (nr->state)
|
|
case NR_STATE_3
|
|
nr->state = NR_STATE_2
|
|
sock_set_flag(sk, SOCK_DESTROY);
|
|
|
|
nr_rx_frame
|
|
nr_process_rx_frame
|
|
switch (nr->state)
|
|
case NR_STATE_2
|
|
nr_state2_machine()
|
|
nr_disconnect()
|
|
nr_sk(sk)->state = NR_STATE_0
|
|
sock_set_flag(sk, SOCK_DEAD)
|
|
|
|
nr_heartbeat_expiry
|
|
switch (nr->state)
|
|
case NR_STATE_0
|
|
if (sock_flag(sk, SOCK_DESTROY) ||
|
|
(sk->sk_state == TCP_LISTEN
|
|
&& sock_flag(sk, SOCK_DEAD)))
|
|
sock_hold() // ( !!! )
|
|
nr_destroy_socket()
|
|
|
|
To fix the memory leak, let's call sock_hold() only for a listening socket.
|
|
|
|
Found by InfoTeCS on behalf of Linux Verification Center
|
|
(linuxtesting.org) with Syzkaller.
|
|
|
|
[0]: https://syzkaller.appspot.com/bug?extid=d327a1f3b12e1e206c16</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-09</ReleaseDate>
|
|
<CVE>CVE-2024-41006</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</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-1963</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:
|
|
|
|
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-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1963</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:
|
|
|
|
jfs: don't walk off the end of ealist
|
|
|
|
Add a check before visiting the members of ea to
|
|
make sure each ea stays within the ealist.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-09</ReleaseDate>
|
|
<CVE>CVE-2024-41017</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1963</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:
|
|
|
|
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-20.03-LTS-SP4</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-1963</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:
|
|
|
|
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-20.03-LTS-SP4</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-1963</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:
|
|
|
|
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-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1963</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:
|
|
|
|
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-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1963</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:
|
|
|
|
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-20.03-LTS-SP4</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-1963</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:
|
|
|
|
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-20.03-LTS-SP4</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-1963</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:
|
|
|
|
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-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1963</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:
|
|
|
|
drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes
|
|
|
|
In nv17_tv_get_ld_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-41095</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1963</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:
|
|
|
|
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-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1963</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:
|
|
|
|
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-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1963</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:
|
|
|
|
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-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1963</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:
|
|
|
|
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-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1963</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:
|
|
|
|
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-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1963</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:
|
|
|
|
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-20.03-LTS-SP4</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-1963</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:
|
|
|
|
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-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1963</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:
|
|
|
|
nilfs2: add missing check for inode numbers on directory entries
|
|
|
|
Syzbot reported that mounting and unmounting a specific pattern of
|
|
corrupted nilfs2 filesystem images causes a use-after-free of metadata
|
|
file inodes, which triggers a kernel bug in lru_add_fn().
|
|
|
|
As Jan Kara pointed out, this is because the link count of a metadata file
|
|
gets corrupted to 0, and nilfs_evict_inode(), which is called from iput(),
|
|
tries to delete that inode (ifile inode in this case).
|
|
|
|
The inconsistency occurs because directories containing the inode numbers
|
|
of these metadata files that should not be visible in the namespace are
|
|
read without checking.
|
|
|
|
Fix this issue by treating the inode numbers of these internal files as
|
|
errors in the sanity check helper when reading directory folios/pages.
|
|
|
|
Also thanks to Hillf Danton and Matthew Wilcox for their initial mm-layer
|
|
analysis.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-09</ReleaseDate>
|
|
<CVE>CVE-2024-42104</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.1</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1963</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:
|
|
|
|
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-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1963</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:
|
|
|
|
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-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1963</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:
|
|
|
|
drm/amd/display: Skip finding free audio for unknown engine_id
|
|
|
|
[WHY]
|
|
ENGINE_ID_UNKNOWN = -1 and can not be used as an array index. Plus, it
|
|
also means it is uninitialized and does not need free audio.
|
|
|
|
[HOW]
|
|
Skip and return NULL.
|
|
|
|
This fixes 2 OVERRUN issues reported by Coverity.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-09</ReleaseDate>
|
|
<CVE>CVE-2024-42119</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1963</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:
|
|
|
|
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-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-09</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1963</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: 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-20.03-LTS-SP4</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-1963</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: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-20.03-LTS-SP4</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-1963</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |