1398 lines
65 KiB
XML
1398 lines
65 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-24.03-LTS</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-1943</ID>
|
|
</Identification>
|
|
<Status>Final</Status>
|
|
<Version>1.0</Version>
|
|
<RevisionHistory>
|
|
<Revision>
|
|
<Number>1.0</Number>
|
|
<Date>2024-08-02</Date>
|
|
<Description>Initial</Description>
|
|
</Revision>
|
|
</RevisionHistory>
|
|
<InitialReleaseDate>2024-08-02</InitialReleaseDate>
|
|
<CurrentReleaseDate>2024-08-02</CurrentReleaseDate>
|
|
<Generator>
|
|
<Engine>openEuler SA Tool V1.0</Engine>
|
|
<Date>2024-08-02</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-24.03-LTS.</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:
|
|
|
|
drm/amdgpu: Skip do PCI error slot reset during RAS recovery
|
|
|
|
Why:
|
|
The PCI error slot reset maybe triggered after inject ue to UMC multi times, this
|
|
caused system hang.
|
|
[ 557.371857] amdgpu 0000:af:00.0: amdgpu: GPU reset succeeded, trying to resume
|
|
[ 557.373718] [drm] PCIE GART of 512M enabled.
|
|
[ 557.373722] [drm] PTB located at 0x0000031FED700000
|
|
[ 557.373788] [drm] VRAM is lost due to GPU reset!
|
|
[ 557.373789] [drm] PSP is resuming...
|
|
[ 557.547012] mlx5_core 0000:55:00.0: mlx5_pci_err_detected Device state = 1 pci_status: 0. Exit, result = 3, need reset
|
|
[ 557.547067] [drm] PCI error: detected callback, state(1)!!
|
|
[ 557.547069] [drm] No support for XGMI hive yet...
|
|
[ 557.548125] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 0. Enter
|
|
[ 557.607763] mlx5_core 0000:55:00.0: wait vital counter value 0x16b5b after 1 iterations
|
|
[ 557.607777] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 1. Exit, err = 0, result = 5, recovered
|
|
[ 557.610492] [drm] PCI error: slot reset callback!!
|
|
...
|
|
[ 560.689382] amdgpu 0000:3f:00.0: amdgpu: GPU reset(2) succeeded!
|
|
[ 560.689546] amdgpu 0000:5a:00.0: amdgpu: GPU reset(2) succeeded!
|
|
[ 560.689562] general protection fault, probably for non-canonical address 0x5f080b54534f611f: 0000 [#1] SMP NOPTI
|
|
[ 560.701008] CPU: 16 PID: 2361 Comm: kworker/u448:9 Tainted: G OE 5.15.0-91-generic #101-Ubuntu
|
|
[ 560.712057] Hardware name: Microsoft C278A/C278A, BIOS C2789.5.BS.1C11.AG.1 11/08/2023
|
|
[ 560.720959] Workqueue: amdgpu-reset-hive amdgpu_ras_do_recovery [amdgpu]
|
|
[ 560.728887] RIP: 0010:amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu]
|
|
[ 560.736891] Code: ff 41 89 c6 e9 1b ff ff ff 44 0f b6 45 b0 e9 4f ff ff ff be 01 00 00 00 4c 89 e7 e8 76 c9 8b ff 44 0f b6 45 b0 e9 3c fd ff ff <48> 83 ba 18 02 00 00 00 0f 84 6a f8 ff ff 48 8d 7a 78 be 01 00 00
|
|
[ 560.757967] RSP: 0018:ffa0000032e53d80 EFLAGS: 00010202
|
|
[ 560.763848] RAX: ffa00000001dfd10 RBX: ffa0000000197090 RCX: ffa0000032e53db0
|
|
[ 560.771856] RDX: 5f080b54534f5f07 RSI: 0000000000000000 RDI: ff11000128100010
|
|
[ 560.779867] RBP: ffa0000032e53df0 R08: 0000000000000000 R09: ffffffffffe77f08
|
|
[ 560.787879] R10: 0000000000ffff0a R11: 0000000000000001 R12: 0000000000000000
|
|
[ 560.795889] R13: ffa0000032e53e00 R14: 0000000000000000 R15: 0000000000000000
|
|
[ 560.803889] FS: 0000000000000000(0000) GS:ff11007e7e800000(0000) knlGS:0000000000000000
|
|
[ 560.812973] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 560.819422] CR2: 000055a04c118e68 CR3: 0000000007410005 CR4: 0000000000771ee0
|
|
[ 560.827433] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
[ 560.835433] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
|
|
[ 560.843444] PKRU: 55555554
|
|
[ 560.846480] Call Trace:
|
|
[ 560.849225] <TASK>
|
|
[ 560.851580] ? show_trace_log_lvl+0x1d6/0x2ea
|
|
[ 560.856488] ? show_trace_log_lvl+0x1d6/0x2ea
|
|
[ 560.861379] ? amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu]
|
|
[ 560.867778] ? show_regs.part.0+0x23/0x29
|
|
[ 560.872293] ? __die_body.cold+0x8/0xd
|
|
[ 560.876502] ? die_addr+0x3e/0x60
|
|
[ 560.880238] ? exc_general_protection+0x1c5/0x410
|
|
[ 560.885532] ? asm_exc_general_protection+0x27/0x30
|
|
[ 560.891025] ? amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu]
|
|
[ 560.898323] amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu]
|
|
[ 560.904520] process_one_work+0x228/0x3d0
|
|
How:
|
|
In RAS recovery, mode-1 reset is issued from RAS fatal error handling and expected
|
|
all the nodes in a hive to be reset. no need to issue another mode-1 during this procedure.(CVE-2024-35931)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fs/9p: fix uninitialized values during inode evict
|
|
|
|
If an iget fails due to not being able to retrieve information
|
|
from the server then the inode structure is only partially
|
|
initialized. When the inode gets evicted, references to
|
|
uninitialized structures (like fscache cookies) were being
|
|
made.
|
|
|
|
This patch checks for a bad_inode before doing anything other
|
|
than clearing the inode from the cache. Since the inode is
|
|
bad, it shouldn't have any state associated with it that needs
|
|
to be written back (and there really isn't a way to complete
|
|
those anyways).(CVE-2024-36923)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference
|
|
|
|
In cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() is
|
|
assigned to mhdp_state->current_mode, and there is a dereference of it in
|
|
drm_mode_set_name(), which will lead to a NULL pointer dereference on
|
|
failure of drm_mode_duplicate().
|
|
|
|
Fix this bug add a check of mhdp_state->current_mode.(CVE-2024-38548)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: carl9170: add a proper sanity check for endpoints
|
|
|
|
Syzkaller reports [1] hitting a warning which is caused by presence
|
|
of a wrong endpoint type at the URB sumbitting stage. While there
|
|
was a check for a specific 4th endpoint, since it can switch types
|
|
between bulk and interrupt, other endpoints are trusted implicitly.
|
|
Similar warning is triggered in a couple of other syzbot issues [2].
|
|
|
|
Fix the issue by doing a comprehensive check of all endpoints
|
|
taking into account difference between high- and full-speed
|
|
configuration.
|
|
|
|
[1] Syzkaller report:
|
|
...
|
|
WARNING: CPU: 0 PID: 4721 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504
|
|
...
|
|
Call Trace:
|
|
<TASK>
|
|
carl9170_usb_send_rx_irq_urb+0x273/0x340 drivers/net/wireless/ath/carl9170/usb.c:504
|
|
carl9170_usb_init_device drivers/net/wireless/ath/carl9170/usb.c:939 [inline]
|
|
carl9170_usb_firmware_finish drivers/net/wireless/ath/carl9170/usb.c:999 [inline]
|
|
carl9170_usb_firmware_step2+0x175/0x240 drivers/net/wireless/ath/carl9170/usb.c:1028
|
|
request_firmware_work_func+0x130/0x240 drivers/base/firmware_loader/main.c:1107
|
|
process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289
|
|
worker_thread+0x669/0x1090 kernel/workqueue.c:2436
|
|
kthread+0x2e8/0x3a0 kernel/kthread.c:376
|
|
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
|
|
</TASK>
|
|
|
|
[2] Related syzkaller crashes:(CVE-2024-38567)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mmc: davinci: Don't strip remove function when driver is builtin
|
|
|
|
Using __exit for the remove function results in the remove callback being
|
|
discarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g.
|
|
using sysfs or hotplug), the driver is just removed without the cleanup
|
|
being performed. This results in resource leaks. Fix it by compiling in the
|
|
remove callback unconditionally.
|
|
|
|
This also fixes a W=1 modpost warning:
|
|
|
|
WARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch in
|
|
reference: davinci_mmcsd_driver+0x10 (section: .data) ->
|
|
davinci_mmcsd_remove (section: .exit.text)(CVE-2024-39484)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet
|
|
|
|
In lio_vf_rep_copy_packet() pg_info->page is compared to a NULL value,
|
|
but then it is unconditionally passed to skb_add_rx_frag() which looks
|
|
strange and could lead to null pointer dereference.
|
|
|
|
lio_vf_rep_copy_packet() call trace looks like:
|
|
octeon_droq_process_packets
|
|
octeon_droq_fast_process_packets
|
|
octeon_droq_dispatch_pkt
|
|
octeon_create_recv_info
|
|
...search in the dispatch_list...
|
|
->disp_fn(rdisp->rinfo, ...)
|
|
lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...)
|
|
In this path there is no code which sets pg_info->page to NULL.
|
|
So this check looks unneeded and doesn't solve potential problem.
|
|
But I guess the author had reason to add a check and I have no such card
|
|
and can't do real test.
|
|
In addition, the code in the function liquidio_push_packet() in
|
|
liquidio/lio_core.c does exactly the same.
|
|
|
|
Based on this, I consider the most acceptable compromise solution to
|
|
adjust this issue by moving skb_add_rx_frag() into conditional scope.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-39506)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
io_uring/io-wq: Use set_bit() and test_bit() at worker->flags
|
|
|
|
Utilize set_bit() and test_bit() on worker->flags within io_uring/io-wq
|
|
to address potential data races.
|
|
|
|
The structure io_worker->flags may be accessed through various data
|
|
paths, leading to concurrency issues. When KCSAN is enabled, it reveals
|
|
data races occurring in io_worker_handle_work and
|
|
io_wq_activate_free_worker functions.
|
|
|
|
BUG: KCSAN: data-race in io_worker_handle_work / io_wq_activate_free_worker
|
|
write to 0xffff8885c4246404 of 4 bytes by task 49071 on cpu 28:
|
|
io_worker_handle_work (io_uring/io-wq.c:434 io_uring/io-wq.c:569)
|
|
io_wq_worker (io_uring/io-wq.c:?)
|
|
<snip>
|
|
|
|
read to 0xffff8885c4246404 of 4 bytes by task 49024 on cpu 5:
|
|
io_wq_activate_free_worker (io_uring/io-wq.c:? io_uring/io-wq.c:285)
|
|
io_wq_enqueue (io_uring/io-wq.c:947)
|
|
io_queue_iowq (io_uring/io_uring.c:524)
|
|
io_req_task_submit (io_uring/io_uring.c:1511)
|
|
io_handle_tw_list (io_uring/io_uring.c:1198)
|
|
<snip>
|
|
|
|
Line numbers against commit 18daea77cca6 ("Merge tag 'for-linus' of
|
|
git://git.kernel.org/pub/scm/virt/kvm/kvm").
|
|
|
|
These races involve writes and reads to the same memory location by
|
|
different tasks running on different CPUs. To mitigate this, refactor
|
|
the code to use atomic operations such as set_bit(), test_bit(), and
|
|
clear_bit() instead of basic "and" and "or" operations. This ensures
|
|
thread-safe manipulation of worker flags.
|
|
|
|
Also, move `create_index` to avoid holes in the structure.(CVE-2024-39508)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
riscv: rewrite __kernel_map_pages() to fix sleeping in invalid context
|
|
|
|
__kernel_map_pages() is a debug function which clears the valid bit in page
|
|
table entry for deallocated pages to detect illegal memory accesses to
|
|
freed pages.
|
|
|
|
This function set/clear the valid bit using __set_memory(). __set_memory()
|
|
acquires init_mm's semaphore, and this operation may sleep. This is
|
|
problematic, because __kernel_map_pages() can be called in atomic context,
|
|
and thus is illegal to sleep. An example warning that this causes:
|
|
|
|
BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1578
|
|
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2, name: kthreadd
|
|
preempt_count: 2, expected: 0
|
|
CPU: 0 PID: 2 Comm: kthreadd Not tainted 6.9.0-g1d4c6d784ef6 #37
|
|
Hardware name: riscv-virtio,qemu (DT)
|
|
Call Trace:
|
|
[<ffffffff800060dc>] dump_backtrace+0x1c/0x24
|
|
[<ffffffff8091ef6e>] show_stack+0x2c/0x38
|
|
[<ffffffff8092baf8>] dump_stack_lvl+0x5a/0x72
|
|
[<ffffffff8092bb24>] dump_stack+0x14/0x1c
|
|
[<ffffffff8003b7ac>] __might_resched+0x104/0x10e
|
|
[<ffffffff8003b7f4>] __might_sleep+0x3e/0x62
|
|
[<ffffffff8093276a>] down_write+0x20/0x72
|
|
[<ffffffff8000cf00>] __set_memory+0x82/0x2fa
|
|
[<ffffffff8000d324>] __kernel_map_pages+0x5a/0xd4
|
|
[<ffffffff80196cca>] __alloc_pages_bulk+0x3b2/0x43a
|
|
[<ffffffff8018ee82>] __vmalloc_node_range+0x196/0x6ba
|
|
[<ffffffff80011904>] copy_process+0x72c/0x17ec
|
|
[<ffffffff80012ab4>] kernel_clone+0x60/0x2fe
|
|
[<ffffffff80012f62>] kernel_thread+0x82/0xa0
|
|
[<ffffffff8003552c>] kthreadd+0x14a/0x1be
|
|
[<ffffffff809357de>] ret_from_fork+0xe/0x1c
|
|
|
|
Rewrite this function with apply_to_existing_page_range(). It is fine to
|
|
not have any locking, because __kernel_map_pages() works with pages being
|
|
allocated/deallocated and those pages are not changed by anyone else in the
|
|
meantime.(CVE-2024-40915)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ipv6: prevent possible NULL dereference in rt6_probe()
|
|
|
|
syzbot caught a NULL dereference in rt6_probe() [1]
|
|
|
|
Bail out if __in6_dev_get() returns NULL.
|
|
|
|
[1]
|
|
Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cb: 0000 [#1] PREEMPT SMP KASAN PTI
|
|
KASAN: null-ptr-deref in range [0x0000000000000658-0x000000000000065f]
|
|
CPU: 1 PID: 22444 Comm: syz-executor.0 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
|
|
RIP: 0010:rt6_probe net/ipv6/route.c:656 [inline]
|
|
RIP: 0010:find_match+0x8c4/0xf50 net/ipv6/route.c:758
|
|
Code: 14 fd f7 48 8b 85 38 ff ff ff 48 c7 45 b0 00 00 00 00 48 8d b8 5c 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 19
|
|
RSP: 0018:ffffc900034af070 EFLAGS: 00010203
|
|
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004521000
|
|
RDX: 00000000000000cb RSI: ffffffff8990d0cd RDI: 000000000000065c
|
|
RBP: ffffc900034af150 R08: 0000000000000005 R09: 0000000000000000
|
|
R10: 0000000000000001 R11: 0000000000000002 R12: 000000000000000a
|
|
R13: 1ffff92000695e18 R14: ffff8880244a1d20 R15: 0000000000000000
|
|
FS: 00007f4844a5a6c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000001b31b27000 CR3: 000000002d42c000 CR4: 00000000003506f0
|
|
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
Call Trace:
|
|
<TASK>
|
|
rt6_nh_find_match+0xfa/0x1a0 net/ipv6/route.c:784
|
|
nexthop_for_each_fib6_nh+0x26d/0x4a0 net/ipv4/nexthop.c:1496
|
|
__find_rr_leaf+0x6e7/0xe00 net/ipv6/route.c:825
|
|
find_rr_leaf net/ipv6/route.c:853 [inline]
|
|
rt6_select net/ipv6/route.c:897 [inline]
|
|
fib6_table_lookup+0x57e/0xa30 net/ipv6/route.c:2195
|
|
ip6_pol_route+0x1cd/0x1150 net/ipv6/route.c:2231
|
|
pol_lookup_func include/net/ip6_fib.h:616 [inline]
|
|
fib6_rule_lookup+0x386/0x720 net/ipv6/fib6_rules.c:121
|
|
ip6_route_output_flags_noref net/ipv6/route.c:2639 [inline]
|
|
ip6_route_output_flags+0x1d0/0x640 net/ipv6/route.c:2651
|
|
ip6_dst_lookup_tail.constprop.0+0x961/0x1760 net/ipv6/ip6_output.c:1147
|
|
ip6_dst_lookup_flow+0x99/0x1d0 net/ipv6/ip6_output.c:1250
|
|
rawv6_sendmsg+0xdab/0x4340 net/ipv6/raw.c:898
|
|
inet_sendmsg+0x119/0x140 net/ipv4/af_inet.c:853
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg net/socket.c:745 [inline]
|
|
sock_write_iter+0x4b8/0x5c0 net/socket.c:1160
|
|
new_sync_write fs/read_write.c:497 [inline]
|
|
vfs_write+0x6b6/0x1140 fs/read_write.c:590
|
|
ksys_write+0x1f8/0x260 fs/read_write.c:643
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-40960)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mips: bmips: BCM6358: make sure CBR is correctly set
|
|
|
|
It was discovered that some device have CBR address set to 0 causing
|
|
kernel panic when arch_sync_dma_for_cpu_all is called.
|
|
|
|
This was notice in situation where the system is booted from TP1 and
|
|
BMIPS_GET_CBR() returns 0 instead of a valid address and
|
|
!!(read_c0_brcm_cmt_local() & (1 << 31)); not failing.
|
|
|
|
The current check whether RAC flush should be disabled or not are not
|
|
enough hence lets check if CBR is a valid address or not.(CVE-2024-40963)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ext4: do not create EA inode under buffer lock
|
|
|
|
ext4_xattr_set_entry() creates new EA inodes while holding buffer lock
|
|
on the external xattr block. This is problematic as it nests all the
|
|
allocation locking (which acquires locks on other buffers) under the
|
|
buffer lock. This can even deadlock when the filesystem is corrupted and
|
|
e.g. quota file is setup to contain xattr block as data block. Move the
|
|
allocation of EA inode out of ext4_xattr_set_entry() into the callers.(CVE-2024-40972)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drop_monitor: replace spin_lock by raw_spin_lock
|
|
|
|
trace_drop_common() is called with preemption disabled, and it acquires
|
|
a spin_lock. This is problematic for RT kernels because spin_locks are
|
|
sleeping locks in this configuration, which causes the following splat:
|
|
|
|
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
|
|
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 449, name: rcuc/47
|
|
preempt_count: 1, expected: 0
|
|
RCU nest depth: 2, expected: 2
|
|
5 locks held by rcuc/47/449:
|
|
#0: ff1100086ec30a60 ((softirq_ctrl.lock)){+.+.}-{2:2}, at: __local_bh_disable_ip+0x105/0x210
|
|
#1: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: rt_spin_lock+0xbf/0x130
|
|
#2: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: __local_bh_disable_ip+0x11c/0x210
|
|
#3: ffffffffb394a160 (rcu_callback){....}-{0:0}, at: rcu_do_batch+0x360/0xc70
|
|
#4: ff1100086ee07520 (&data->lock){+.+.}-{2:2}, at: trace_drop_common.constprop.0+0xb5/0x290
|
|
irq event stamp: 139909
|
|
hardirqs last enabled at (139908): [<ffffffffb1df2b33>] _raw_spin_unlock_irqrestore+0x63/0x80
|
|
hardirqs last disabled at (139909): [<ffffffffb19bd03d>] trace_drop_common.constprop.0+0x26d/0x290
|
|
softirqs last enabled at (139892): [<ffffffffb07a1083>] __local_bh_enable_ip+0x103/0x170
|
|
softirqs last disabled at (139898): [<ffffffffb0909b33>] rcu_cpu_kthread+0x93/0x1f0
|
|
Preemption disabled at:
|
|
[<ffffffffb1de786b>] rt_mutex_slowunlock+0xab/0x2e0
|
|
CPU: 47 PID: 449 Comm: rcuc/47 Not tainted 6.9.0-rc2-rt1+ #7
|
|
Hardware name: Dell Inc. PowerEdge R650/0Y2G81, BIOS 1.6.5 04/15/2022
|
|
Call Trace:
|
|
<TASK>
|
|
dump_stack_lvl+0x8c/0xd0
|
|
dump_stack+0x14/0x20
|
|
__might_resched+0x21e/0x2f0
|
|
rt_spin_lock+0x5e/0x130
|
|
? trace_drop_common.constprop.0+0xb5/0x290
|
|
? skb_queue_purge_reason.part.0+0x1bf/0x230
|
|
trace_drop_common.constprop.0+0xb5/0x290
|
|
? preempt_count_sub+0x1c/0xd0
|
|
? _raw_spin_unlock_irqrestore+0x4a/0x80
|
|
? __pfx_trace_drop_common.constprop.0+0x10/0x10
|
|
? rt_mutex_slowunlock+0x26a/0x2e0
|
|
? skb_queue_purge_reason.part.0+0x1bf/0x230
|
|
? __pfx_rt_mutex_slowunlock+0x10/0x10
|
|
? skb_queue_purge_reason.part.0+0x1bf/0x230
|
|
trace_kfree_skb_hit+0x15/0x20
|
|
trace_kfree_skb+0xe9/0x150
|
|
kfree_skb_reason+0x7b/0x110
|
|
skb_queue_purge_reason.part.0+0x1bf/0x230
|
|
? __pfx_skb_queue_purge_reason.part.0+0x10/0x10
|
|
? mark_lock.part.0+0x8a/0x520
|
|
...
|
|
|
|
trace_drop_common() also disables interrupts, but this is a minor issue
|
|
because we could easily replace it with a local_lock.
|
|
|
|
Replace the spin_lock with raw_spin_lock to avoid sleeping in atomic
|
|
context.(CVE-2024-40980)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ssb: Fix potential NULL pointer dereference in ssb_device_uevent()
|
|
|
|
The ssb_device_uevent() function first attempts to convert the 'dev' pointer
|
|
to 'struct ssb_device *'. However, it mistakenly dereferences 'dev' before
|
|
performing the NULL check, potentially leading to a NULL pointer
|
|
dereference if 'dev' is NULL.
|
|
|
|
To fix this issue, move the NULL check before dereferencing the 'dev' pointer,
|
|
ensuring that the pointer is valid before attempting to use it.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-40982)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc()
|
|
|
|
syzbot found hanging tasks waiting on rtnl_lock [1]
|
|
|
|
A reproducer is available in the syzbot bug.
|
|
|
|
When a request to add multiple actions with the same index is sent, the
|
|
second request will block forever on the first request. This holds
|
|
rtnl_lock, and causes tasks to hang.
|
|
|
|
Return -EAGAIN to prevent infinite looping, while keeping documented
|
|
behavior.
|
|
|
|
[1]
|
|
|
|
INFO: task kworker/1:0:5088 blocked for more than 143 seconds.
|
|
Not tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0
|
|
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
|
|
task:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000
|
|
Workqueue: events_power_efficient reg_check_chans_work
|
|
Call Trace:
|
|
<TASK>
|
|
context_switch kernel/sched/core.c:5409 [inline]
|
|
__schedule+0xf15/0x5d00 kernel/sched/core.c:6746
|
|
__schedule_loop kernel/sched/core.c:6823 [inline]
|
|
schedule+0xe7/0x350 kernel/sched/core.c:6838
|
|
schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6895
|
|
__mutex_lock_common kernel/locking/mutex.c:684 [inline]
|
|
__mutex_lock+0x5b8/0x9c0 kernel/locking/mutex.c:752
|
|
wiphy_lock include/net/cfg80211.h:5953 [inline]
|
|
reg_leave_invalid_chans net/wireless/reg.c:2466 [inline]
|
|
reg_check_chans_work+0x10a/0x10e0 net/wireless/reg.c:2481(CVE-2024-40995)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amdkfd: don't allow mapping the MMIO HDP page with large pages
|
|
|
|
We don't get the right offset in that case. The GPU has
|
|
an unused 4K area of the register BAR space into which you can
|
|
remap registers. We remap the HDP flush registers into this
|
|
space to allow userspace (CPU or GPU) to flush the HDP when it
|
|
updates VRAM. However, on systems with >4K pages, we end up
|
|
exposing PAGE_SIZE of MMIO space.(CVE-2024-41011)</Note>
|
|
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-24.03-LTS.
|
|
|
|
openEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.</Note>
|
|
<Note Title="Severity" Type="General" Ordinal="5" xml:lang="en">High</Note>
|
|
<Note Title="Affected Component" Type="General" Ordinal="6" xml:lang="en">kernel</Note>
|
|
</DocumentNotes>
|
|
<DocumentReferences>
|
|
<Reference Type="Self">
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail?id=openEuler-SA-2024-1943</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-35931</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-36923</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38548</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38567</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39484</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39506</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39508</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40915</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40960</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40963</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40972</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40980</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40982</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40995</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41011</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35931</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36923</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38548</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38567</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39484</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39506</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39508</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40915</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40960</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40963</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40972</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40980</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40982</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40995</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41011</URL>
|
|
</Reference>
|
|
</DocumentReferences>
|
|
<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
|
|
<Branch Type="Product Name" Name="openEuler">
|
|
<FullProductName ProductID="openEuler-24.03-LTS" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">openEuler-24.03-LTS</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="kernel-tools-debuginfo-6.6.0-35.0.0.43" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-debuginfo-6.6.0-35.0.0.43.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-6.6.0-35.0.0.43" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">bpftool-debuginfo-6.6.0-35.0.0.43.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-6.6.0-35.0.0.43" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-debuginfo-6.6.0-35.0.0.43.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-6.6.0-35.0.0.43" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-6.6.0-35.0.0.43.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-6.6.0-35.0.0.43" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-6.6.0-35.0.0.43.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-6.6.0-35.0.0.43" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">perf-debuginfo-6.6.0-35.0.0.43.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-6.6.0-35.0.0.43" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">python3-perf-6.6.0-35.0.0.43.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-6.6.0-35.0.0.43" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">python3-perf-debuginfo-6.6.0-35.0.0.43.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-6.6.0-35.0.0.43" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-headers-6.6.0-35.0.0.43.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-6.6.0-35.0.0.43" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-devel-6.6.0-35.0.0.43.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-6.6.0-35.0.0.43" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-debugsource-6.6.0-35.0.0.43.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-6.6.0-35.0.0.43" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">bpftool-6.6.0-35.0.0.43.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-6.6.0-35.0.0.43" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-devel-6.6.0-35.0.0.43.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-6.6.0-35.0.0.43" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">perf-6.6.0-35.0.0.43.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-6.6.0-35.0.0.43" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-source-6.6.0-35.0.0.43.oe2403.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-6.6.0-35.0.0.43" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-6.6.0-35.0.0.43.oe2403.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="kernel-tools-6.6.0-35.0.0.43" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-6.6.0-35.0.0.43.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-6.6.0-35.0.0.43" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">python3-perf-6.6.0-35.0.0.43.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-6.6.0-35.0.0.43" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-devel-6.6.0-35.0.0.43.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-6.6.0-35.0.0.43" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">python3-perf-debuginfo-6.6.0-35.0.0.43.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-6.6.0-35.0.0.43" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-debuginfo-6.6.0-35.0.0.43.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-6.6.0-35.0.0.43" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">perf-debuginfo-6.6.0-35.0.0.43.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-6.6.0-35.0.0.43" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-6.6.0-35.0.0.43.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-6.6.0-35.0.0.43" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">perf-6.6.0-35.0.0.43.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-6.6.0-35.0.0.43" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-source-6.6.0-35.0.0.43.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-6.6.0-35.0.0.43" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">bpftool-debuginfo-6.6.0-35.0.0.43.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-6.6.0-35.0.0.43" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">bpftool-6.6.0-35.0.0.43.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-6.6.0-35.0.0.43" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-devel-6.6.0-35.0.0.43.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-6.6.0-35.0.0.43" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-headers-6.6.0-35.0.0.43.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-6.6.0-35.0.0.43" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-debugsource-6.6.0-35.0.0.43.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-6.6.0-35.0.0.43" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-debuginfo-6.6.0-35.0.0.43.oe2403.x86_64.rpm</FullProductName>
|
|
</Branch>
|
|
</ProductTree>
|
|
<Vulnerability Ordinal="1" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amdgpu: Skip do PCI error slot reset during RAS recovery
|
|
|
|
Why:
|
|
The PCI error slot reset maybe triggered after inject ue to UMC multi times, this
|
|
caused system hang.
|
|
[ 557.371857] amdgpu 0000:af:00.0: amdgpu: GPU reset succeeded, trying to resume
|
|
[ 557.373718] [drm] PCIE GART of 512M enabled.
|
|
[ 557.373722] [drm] PTB located at 0x0000031FED700000
|
|
[ 557.373788] [drm] VRAM is lost due to GPU reset!
|
|
[ 557.373789] [drm] PSP is resuming...
|
|
[ 557.547012] mlx5_core 0000:55:00.0: mlx5_pci_err_detected Device state = 1 pci_status: 0. Exit, result = 3, need reset
|
|
[ 557.547067] [drm] PCI error: detected callback, state(1)!!
|
|
[ 557.547069] [drm] No support for XGMI hive yet...
|
|
[ 557.548125] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 0. Enter
|
|
[ 557.607763] mlx5_core 0000:55:00.0: wait vital counter value 0x16b5b after 1 iterations
|
|
[ 557.607777] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 1. Exit, err = 0, result = 5, recovered
|
|
[ 557.610492] [drm] PCI error: slot reset callback!!
|
|
...
|
|
[ 560.689382] amdgpu 0000:3f:00.0: amdgpu: GPU reset(2) succeeded!
|
|
[ 560.689546] amdgpu 0000:5a:00.0: amdgpu: GPU reset(2) succeeded!
|
|
[ 560.689562] general protection fault, probably for non-canonical address 0x5f080b54534f611f: 0000 [#1] SMP NOPTI
|
|
[ 560.701008] CPU: 16 PID: 2361 Comm: kworker/u448:9 Tainted: G OE 5.15.0-91-generic #101-Ubuntu
|
|
[ 560.712057] Hardware name: Microsoft C278A/C278A, BIOS C2789.5.BS.1C11.AG.1 11/08/2023
|
|
[ 560.720959] Workqueue: amdgpu-reset-hive amdgpu_ras_do_recovery [amdgpu]
|
|
[ 560.728887] RIP: 0010:amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu]
|
|
[ 560.736891] Code: ff 41 89 c6 e9 1b ff ff ff 44 0f b6 45 b0 e9 4f ff ff ff be 01 00 00 00 4c 89 e7 e8 76 c9 8b ff 44 0f b6 45 b0 e9 3c fd ff ff <48> 83 ba 18 02 00 00 00 0f 84 6a f8 ff ff 48 8d 7a 78 be 01 00 00
|
|
[ 560.757967] RSP: 0018:ffa0000032e53d80 EFLAGS: 00010202
|
|
[ 560.763848] RAX: ffa00000001dfd10 RBX: ffa0000000197090 RCX: ffa0000032e53db0
|
|
[ 560.771856] RDX: 5f080b54534f5f07 RSI: 0000000000000000 RDI: ff11000128100010
|
|
[ 560.779867] RBP: ffa0000032e53df0 R08: 0000000000000000 R09: ffffffffffe77f08
|
|
[ 560.787879] R10: 0000000000ffff0a R11: 0000000000000001 R12: 0000000000000000
|
|
[ 560.795889] R13: ffa0000032e53e00 R14: 0000000000000000 R15: 0000000000000000
|
|
[ 560.803889] FS: 0000000000000000(0000) GS:ff11007e7e800000(0000) knlGS:0000000000000000
|
|
[ 560.812973] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 560.819422] CR2: 000055a04c118e68 CR3: 0000000007410005 CR4: 0000000000771ee0
|
|
[ 560.827433] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
[ 560.835433] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
|
|
[ 560.843444] PKRU: 55555554
|
|
[ 560.846480] Call Trace:
|
|
[ 560.849225] <TASK>
|
|
[ 560.851580] ? show_trace_log_lvl+0x1d6/0x2ea
|
|
[ 560.856488] ? show_trace_log_lvl+0x1d6/0x2ea
|
|
[ 560.861379] ? amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu]
|
|
[ 560.867778] ? show_regs.part.0+0x23/0x29
|
|
[ 560.872293] ? __die_body.cold+0x8/0xd
|
|
[ 560.876502] ? die_addr+0x3e/0x60
|
|
[ 560.880238] ? exc_general_protection+0x1c5/0x410
|
|
[ 560.885532] ? asm_exc_general_protection+0x27/0x30
|
|
[ 560.891025] ? amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu]
|
|
[ 560.898323] amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu]
|
|
[ 560.904520] process_one_work+0x228/0x3d0
|
|
How:
|
|
In RAS recovery, mode-1 reset is issued from RAS fatal error handling and expected
|
|
all the nodes in a hive to be reset. no need to issue another mode-1 during this procedure.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-35931</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1943</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="2" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="2" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fs/9p: fix uninitialized values during inode evict
|
|
|
|
If an iget fails due to not being able to retrieve information
|
|
from the server then the inode structure is only partially
|
|
initialized. When the inode gets evicted, references to
|
|
uninitialized structures (like fscache cookies) were being
|
|
made.
|
|
|
|
This patch checks for a bad_inode before doing anything other
|
|
than clearing the inode from the cache. Since the inode is
|
|
bad, it shouldn't have any state associated with it that needs
|
|
to be written back (and there really isn't a way to complete
|
|
those anyways).</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-36923</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.3</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1943</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="3" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="3" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference
|
|
|
|
In cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() is
|
|
assigned to mhdp_state->current_mode, and there is a dereference of it in
|
|
drm_mode_set_name(), which will lead to a NULL pointer dereference on
|
|
failure of drm_mode_duplicate().
|
|
|
|
Fix this bug add a check of mhdp_state->current_mode.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-38548</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1943</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="4" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="4" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: carl9170: add a proper sanity check for endpoints
|
|
|
|
Syzkaller reports [1] hitting a warning which is caused by presence
|
|
of a wrong endpoint type at the URB sumbitting stage. While there
|
|
was a check for a specific 4th endpoint, since it can switch types
|
|
between bulk and interrupt, other endpoints are trusted implicitly.
|
|
Similar warning is triggered in a couple of other syzbot issues [2].
|
|
|
|
Fix the issue by doing a comprehensive check of all endpoints
|
|
taking into account difference between high- and full-speed
|
|
configuration.
|
|
|
|
[1] Syzkaller report:
|
|
...
|
|
WARNING: CPU: 0 PID: 4721 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504
|
|
...
|
|
Call Trace:
|
|
<TASK>
|
|
carl9170_usb_send_rx_irq_urb+0x273/0x340 drivers/net/wireless/ath/carl9170/usb.c:504
|
|
carl9170_usb_init_device drivers/net/wireless/ath/carl9170/usb.c:939 [inline]
|
|
carl9170_usb_firmware_finish drivers/net/wireless/ath/carl9170/usb.c:999 [inline]
|
|
carl9170_usb_firmware_step2+0x175/0x240 drivers/net/wireless/ath/carl9170/usb.c:1028
|
|
request_firmware_work_func+0x130/0x240 drivers/base/firmware_loader/main.c:1107
|
|
process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289
|
|
worker_thread+0x669/0x1090 kernel/workqueue.c:2436
|
|
kthread+0x2e8/0x3a0 kernel/kthread.c:376
|
|
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
|
|
</TASK>
|
|
|
|
[2] Related syzkaller crashes:</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-38567</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1943</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="5" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="5" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:mmc: davinci: Don t strip remove function when driver is builtinUsing __exit for the remove function results in the remove callback beingdiscarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g.using sysfs or hotplug), the driver is just removed without the cleanupbeing performed. This results in resource leaks. Fix it by compiling in theremove callback unconditionally.This also fixes a W=1 modpost warning:WARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch inreference: davinci_mmcsd_driver+0x10 (section: .data) ->davinci_mmcsd_remove (section: .exit.text)</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-39484</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1943</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="6" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="6" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet
|
|
|
|
In lio_vf_rep_copy_packet() pg_info->page is compared to a NULL value,
|
|
but then it is unconditionally passed to skb_add_rx_frag() which looks
|
|
strange and could lead to null pointer dereference.
|
|
|
|
lio_vf_rep_copy_packet() call trace looks like:
|
|
octeon_droq_process_packets
|
|
octeon_droq_fast_process_packets
|
|
octeon_droq_dispatch_pkt
|
|
octeon_create_recv_info
|
|
...search in the dispatch_list...
|
|
->disp_fn(rdisp->rinfo, ...)
|
|
lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...)
|
|
In this path there is no code which sets pg_info->page to NULL.
|
|
So this check looks unneeded and doesn't solve potential problem.
|
|
But I guess the author had reason to add a check and I have no such card
|
|
and can't do real test.
|
|
In addition, the code in the function liquidio_push_packet() in
|
|
liquidio/lio_core.c does exactly the same.
|
|
|
|
Based on this, I consider the most acceptable compromise solution to
|
|
adjust this issue by moving skb_add_rx_frag() into conditional scope.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-39506</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1943</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="7" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="7" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
io_uring/io-wq: Use set_bit() and test_bit() at worker->flags
|
|
|
|
Utilize set_bit() and test_bit() on worker->flags within io_uring/io-wq
|
|
to address potential data races.
|
|
|
|
The structure io_worker->flags may be accessed through various data
|
|
paths, leading to concurrency issues. When KCSAN is enabled, it reveals
|
|
data races occurring in io_worker_handle_work and
|
|
io_wq_activate_free_worker functions.
|
|
|
|
BUG: KCSAN: data-race in io_worker_handle_work / io_wq_activate_free_worker
|
|
write to 0xffff8885c4246404 of 4 bytes by task 49071 on cpu 28:
|
|
io_worker_handle_work (io_uring/io-wq.c:434 io_uring/io-wq.c:569)
|
|
io_wq_worker (io_uring/io-wq.c:?)
|
|
<snip>
|
|
|
|
read to 0xffff8885c4246404 of 4 bytes by task 49024 on cpu 5:
|
|
io_wq_activate_free_worker (io_uring/io-wq.c:? io_uring/io-wq.c:285)
|
|
io_wq_enqueue (io_uring/io-wq.c:947)
|
|
io_queue_iowq (io_uring/io_uring.c:524)
|
|
io_req_task_submit (io_uring/io_uring.c:1511)
|
|
io_handle_tw_list (io_uring/io_uring.c:1198)
|
|
<snip>
|
|
|
|
Line numbers against commit 18daea77cca6 ("Merge tag 'for-linus' of
|
|
git://git.kernel.org/pub/scm/virt/kvm/kvm").
|
|
|
|
These races involve writes and reads to the same memory location by
|
|
different tasks running on different CPUs. To mitigate this, refactor
|
|
the code to use atomic operations such as set_bit(), test_bit(), and
|
|
clear_bit() instead of basic "and" and "or" operations. This ensures
|
|
thread-safe manipulation of worker flags.
|
|
|
|
Also, move `create_index` to avoid holes in the structure.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-39508</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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:H/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1943</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="8" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="8" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
riscv: rewrite __kernel_map_pages() to fix sleeping in invalid context
|
|
|
|
__kernel_map_pages() is a debug function which clears the valid bit in page
|
|
table entry for deallocated pages to detect illegal memory accesses to
|
|
freed pages.
|
|
|
|
This function set/clear the valid bit using __set_memory(). __set_memory()
|
|
acquires init_mm's semaphore, and this operation may sleep. This is
|
|
problematic, because __kernel_map_pages() can be called in atomic context,
|
|
and thus is illegal to sleep. An example warning that this causes:
|
|
|
|
BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1578
|
|
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2, name: kthreadd
|
|
preempt_count: 2, expected: 0
|
|
CPU: 0 PID: 2 Comm: kthreadd Not tainted 6.9.0-g1d4c6d784ef6 #37
|
|
Hardware name: riscv-virtio,qemu (DT)
|
|
Call Trace:
|
|
[<ffffffff800060dc>] dump_backtrace+0x1c/0x24
|
|
[<ffffffff8091ef6e>] show_stack+0x2c/0x38
|
|
[<ffffffff8092baf8>] dump_stack_lvl+0x5a/0x72
|
|
[<ffffffff8092bb24>] dump_stack+0x14/0x1c
|
|
[<ffffffff8003b7ac>] __might_resched+0x104/0x10e
|
|
[<ffffffff8003b7f4>] __might_sleep+0x3e/0x62
|
|
[<ffffffff8093276a>] down_write+0x20/0x72
|
|
[<ffffffff8000cf00>] __set_memory+0x82/0x2fa
|
|
[<ffffffff8000d324>] __kernel_map_pages+0x5a/0xd4
|
|
[<ffffffff80196cca>] __alloc_pages_bulk+0x3b2/0x43a
|
|
[<ffffffff8018ee82>] __vmalloc_node_range+0x196/0x6ba
|
|
[<ffffffff80011904>] copy_process+0x72c/0x17ec
|
|
[<ffffffff80012ab4>] kernel_clone+0x60/0x2fe
|
|
[<ffffffff80012f62>] kernel_thread+0x82/0xa0
|
|
[<ffffffff8003552c>] kthreadd+0x14a/0x1be
|
|
[<ffffffff809357de>] ret_from_fork+0xe/0x1c
|
|
|
|
Rewrite this function with apply_to_existing_page_range(). It is fine to
|
|
not have any locking, because __kernel_map_pages() works with pages being
|
|
allocated/deallocated and those pages are not changed by anyone else in the
|
|
meantime.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-40915</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1943</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="9" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="9" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ipv6: prevent possible NULL dereference in rt6_probe()
|
|
|
|
syzbot caught a NULL dereference in rt6_probe() [1]
|
|
|
|
Bail out if __in6_dev_get() returns NULL.
|
|
|
|
[1]
|
|
Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cb: 0000 [#1] PREEMPT SMP KASAN PTI
|
|
KASAN: null-ptr-deref in range [0x0000000000000658-0x000000000000065f]
|
|
CPU: 1 PID: 22444 Comm: syz-executor.0 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
|
|
RIP: 0010:rt6_probe net/ipv6/route.c:656 [inline]
|
|
RIP: 0010:find_match+0x8c4/0xf50 net/ipv6/route.c:758
|
|
Code: 14 fd f7 48 8b 85 38 ff ff ff 48 c7 45 b0 00 00 00 00 48 8d b8 5c 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 19
|
|
RSP: 0018:ffffc900034af070 EFLAGS: 00010203
|
|
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004521000
|
|
RDX: 00000000000000cb RSI: ffffffff8990d0cd RDI: 000000000000065c
|
|
RBP: ffffc900034af150 R08: 0000000000000005 R09: 0000000000000000
|
|
R10: 0000000000000001 R11: 0000000000000002 R12: 000000000000000a
|
|
R13: 1ffff92000695e18 R14: ffff8880244a1d20 R15: 0000000000000000
|
|
FS: 00007f4844a5a6c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000001b31b27000 CR3: 000000002d42c000 CR4: 00000000003506f0
|
|
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
Call Trace:
|
|
<TASK>
|
|
rt6_nh_find_match+0xfa/0x1a0 net/ipv6/route.c:784
|
|
nexthop_for_each_fib6_nh+0x26d/0x4a0 net/ipv4/nexthop.c:1496
|
|
__find_rr_leaf+0x6e7/0xe00 net/ipv6/route.c:825
|
|
find_rr_leaf net/ipv6/route.c:853 [inline]
|
|
rt6_select net/ipv6/route.c:897 [inline]
|
|
fib6_table_lookup+0x57e/0xa30 net/ipv6/route.c:2195
|
|
ip6_pol_route+0x1cd/0x1150 net/ipv6/route.c:2231
|
|
pol_lookup_func include/net/ip6_fib.h:616 [inline]
|
|
fib6_rule_lookup+0x386/0x720 net/ipv6/fib6_rules.c:121
|
|
ip6_route_output_flags_noref net/ipv6/route.c:2639 [inline]
|
|
ip6_route_output_flags+0x1d0/0x640 net/ipv6/route.c:2651
|
|
ip6_dst_lookup_tail.constprop.0+0x961/0x1760 net/ipv6/ip6_output.c:1147
|
|
ip6_dst_lookup_flow+0x99/0x1d0 net/ipv6/ip6_output.c:1250
|
|
rawv6_sendmsg+0xdab/0x4340 net/ipv6/raw.c:898
|
|
inet_sendmsg+0x119/0x140 net/ipv4/af_inet.c:853
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg net/socket.c:745 [inline]
|
|
sock_write_iter+0x4b8/0x5c0 net/socket.c:1160
|
|
new_sync_write fs/read_write.c:497 [inline]
|
|
vfs_write+0x6b6/0x1140 fs/read_write.c:590
|
|
ksys_write+0x1f8/0x260 fs/read_write.c:643
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-40960</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1943</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="10" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="10" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mips: bmips: BCM6358: make sure CBR is correctly set
|
|
|
|
It was discovered that some device have CBR address set to 0 causing
|
|
kernel panic when arch_sync_dma_for_cpu_all is called.
|
|
|
|
This was notice in situation where the system is booted from TP1 and
|
|
BMIPS_GET_CBR() returns 0 instead of a valid address and
|
|
!!(read_c0_brcm_cmt_local() & (1 << 31)); not failing.
|
|
|
|
The current check whether RAC flush should be disabled or not are not
|
|
enough hence lets check if CBR is a valid address or not.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-40963</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1943</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="11" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="11" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ext4: do not create EA inode under buffer lock
|
|
|
|
ext4_xattr_set_entry() creates new EA inodes while holding buffer lock
|
|
on the external xattr block. This is problematic as it nests all the
|
|
allocation locking (which acquires locks on other buffers) under the
|
|
buffer lock. This can even deadlock when the filesystem is corrupted and
|
|
e.g. quota file is setup to contain xattr block as data block. Move the
|
|
allocation of EA inode out of ext4_xattr_set_entry() into the callers.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-40972</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.7</BaseScore>
|
|
<Vector></Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1943</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="12" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="12" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drop_monitor: replace spin_lock by raw_spin_lock
|
|
|
|
trace_drop_common() is called with preemption disabled, and it acquires
|
|
a spin_lock. This is problematic for RT kernels because spin_locks are
|
|
sleeping locks in this configuration, which causes the following splat:
|
|
|
|
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
|
|
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 449, name: rcuc/47
|
|
preempt_count: 1, expected: 0
|
|
RCU nest depth: 2, expected: 2
|
|
5 locks held by rcuc/47/449:
|
|
#0: ff1100086ec30a60 ((softirq_ctrl.lock)){+.+.}-{2:2}, at: __local_bh_disable_ip+0x105/0x210
|
|
#1: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: rt_spin_lock+0xbf/0x130
|
|
#2: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: __local_bh_disable_ip+0x11c/0x210
|
|
#3: ffffffffb394a160 (rcu_callback){....}-{0:0}, at: rcu_do_batch+0x360/0xc70
|
|
#4: ff1100086ee07520 (&data->lock){+.+.}-{2:2}, at: trace_drop_common.constprop.0+0xb5/0x290
|
|
irq event stamp: 139909
|
|
hardirqs last enabled at (139908): [<ffffffffb1df2b33>] _raw_spin_unlock_irqrestore+0x63/0x80
|
|
hardirqs last disabled at (139909): [<ffffffffb19bd03d>] trace_drop_common.constprop.0+0x26d/0x290
|
|
softirqs last enabled at (139892): [<ffffffffb07a1083>] __local_bh_enable_ip+0x103/0x170
|
|
softirqs last disabled at (139898): [<ffffffffb0909b33>] rcu_cpu_kthread+0x93/0x1f0
|
|
Preemption disabled at:
|
|
[<ffffffffb1de786b>] rt_mutex_slowunlock+0xab/0x2e0
|
|
CPU: 47 PID: 449 Comm: rcuc/47 Not tainted 6.9.0-rc2-rt1+ #7
|
|
Hardware name: Dell Inc. PowerEdge R650/0Y2G81, BIOS 1.6.5 04/15/2022
|
|
Call Trace:
|
|
<TASK>
|
|
dump_stack_lvl+0x8c/0xd0
|
|
dump_stack+0x14/0x20
|
|
__might_resched+0x21e/0x2f0
|
|
rt_spin_lock+0x5e/0x130
|
|
? trace_drop_common.constprop.0+0xb5/0x290
|
|
? skb_queue_purge_reason.part.0+0x1bf/0x230
|
|
trace_drop_common.constprop.0+0xb5/0x290
|
|
? preempt_count_sub+0x1c/0xd0
|
|
? _raw_spin_unlock_irqrestore+0x4a/0x80
|
|
? __pfx_trace_drop_common.constprop.0+0x10/0x10
|
|
? rt_mutex_slowunlock+0x26a/0x2e0
|
|
? skb_queue_purge_reason.part.0+0x1bf/0x230
|
|
? __pfx_rt_mutex_slowunlock+0x10/0x10
|
|
? skb_queue_purge_reason.part.0+0x1bf/0x230
|
|
trace_kfree_skb_hit+0x15/0x20
|
|
trace_kfree_skb+0xe9/0x150
|
|
kfree_skb_reason+0x7b/0x110
|
|
skb_queue_purge_reason.part.0+0x1bf/0x230
|
|
? __pfx_skb_queue_purge_reason.part.0+0x10/0x10
|
|
? mark_lock.part.0+0x8a/0x520
|
|
...
|
|
|
|
trace_drop_common() also disables interrupts, but this is a minor issue
|
|
because we could easily replace it with a local_lock.
|
|
|
|
Replace the spin_lock with raw_spin_lock to avoid sleeping in atomic
|
|
context.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-40980</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.7</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1943</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="13" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="13" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ssb: Fix potential NULL pointer dereference in ssb_device_uevent()
|
|
|
|
The ssb_device_uevent() function first attempts to convert the 'dev' pointer
|
|
to 'struct ssb_device *'. However, it mistakenly dereferences 'dev' before
|
|
performing the NULL check, potentially leading to a NULL pointer
|
|
dereference if 'dev' is NULL.
|
|
|
|
To fix this issue, move the NULL check before dereferencing the 'dev' pointer,
|
|
ensuring that the pointer is valid before attempting to use it.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-40982</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1943</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="14" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="14" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc()
|
|
|
|
syzbot found hanging tasks waiting on rtnl_lock [1]
|
|
|
|
A reproducer is available in the syzbot bug.
|
|
|
|
When a request to add multiple actions with the same index is sent, the
|
|
second request will block forever on the first request. This holds
|
|
rtnl_lock, and causes tasks to hang.
|
|
|
|
Return -EAGAIN to prevent infinite looping, while keeping documented
|
|
behavior.
|
|
|
|
[1]
|
|
|
|
INFO: task kworker/1:0:5088 blocked for more than 143 seconds.
|
|
Not tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0
|
|
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
|
|
task:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000
|
|
Workqueue: events_power_efficient reg_check_chans_work
|
|
Call Trace:
|
|
<TASK>
|
|
context_switch kernel/sched/core.c:5409 [inline]
|
|
__schedule+0xf15/0x5d00 kernel/sched/core.c:6746
|
|
__schedule_loop kernel/sched/core.c:6823 [inline]
|
|
schedule+0xe7/0x350 kernel/sched/core.c:6838
|
|
schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6895
|
|
__mutex_lock_common kernel/locking/mutex.c:684 [inline]
|
|
__mutex_lock+0x5b8/0x9c0 kernel/locking/mutex.c:752
|
|
wiphy_lock include/net/cfg80211.h:5953 [inline]
|
|
reg_leave_invalid_chans net/wireless/reg.c:2466 [inline]
|
|
reg_check_chans_work+0x10a/0x10e0 net/wireless/reg.c:2481</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-40995</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1943</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="15" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="15" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amdkfd: don't allow mapping the MMIO HDP page with large pages
|
|
|
|
We don't get the right offset in that case. The GPU has
|
|
an unused 4K area of the register BAR space into which you can
|
|
remap registers. We remap the HDP flush registers into this
|
|
space to allow userspace (CPU or GPU) to flush the HDP when it
|
|
updates VRAM. However, on systems with >4K pages, we end up
|
|
exposing PAGE_SIZE of MMIO space.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-41011</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</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-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1943</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |