2451 lines
112 KiB
XML
2451 lines
112 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-1944</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-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:
|
||
|
||
usb: musb: tusb6010: check return value after calling platform_get_resource()
|
||
|
||
It will cause null-ptr-deref if platform_get_resource() returns NULL,
|
||
we need check the return value.(CVE-2021-47181)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
btrfs: fix memory ordering between normal and ordered work functions
|
||
|
||
Ordered work functions aren't guaranteed to be handled by the same thread
|
||
which executed the normal work functions. The only way execution between
|
||
normal/ordered functions is synchronized is via the WORK_DONE_BIT,
|
||
unfortunately the used bitops don't guarantee any ordering whatsoever.
|
||
|
||
This manifested as seemingly inexplicable crashes on ARM64, where
|
||
async_chunk::inode is seen as non-null in async_cow_submit which causes
|
||
submit_compressed_extents to be called and crash occurs because
|
||
async_chunk::inode suddenly became NULL. The call trace was similar to:
|
||
|
||
pc : submit_compressed_extents+0x38/0x3d0
|
||
lr : async_cow_submit+0x50/0xd0
|
||
sp : ffff800015d4bc20
|
||
|
||
<registers omitted for brevity>
|
||
|
||
Call trace:
|
||
submit_compressed_extents+0x38/0x3d0
|
||
async_cow_submit+0x50/0xd0
|
||
run_ordered_work+0xc8/0x280
|
||
btrfs_work_helper+0x98/0x250
|
||
process_one_work+0x1f0/0x4ac
|
||
worker_thread+0x188/0x504
|
||
kthread+0x110/0x114
|
||
ret_from_fork+0x10/0x18
|
||
|
||
Fix this by adding respective barrier calls which ensure that all
|
||
accesses preceding setting of WORK_DONE_BIT are strictly ordered before
|
||
setting the flag. At the same time add a read barrier after reading of
|
||
WORK_DONE_BIT in run_ordered_work which ensures all subsequent loads
|
||
would be strictly ordered after reading the bit. This in turn ensures
|
||
are all accesses before WORK_DONE_BIT are going to be strictly ordered
|
||
before any access that can occur in ordered_func.(CVE-2021-47189)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
net: dpaa2-eth: fix use-after-free in dpaa2_eth_remove
|
||
|
||
Access to netdev after free_netdev() will cause use-after-free bug.
|
||
Move debug log before free_netdev() call to avoid it.(CVE-2021-47204)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
usb: host: ohci-tmio: check return value after calling platform_get_resource()
|
||
|
||
It will cause null-ptr-deref if platform_get_resource() returns NULL,
|
||
we need check the return value.(CVE-2021-47206)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
vsock: remove vsock from connected table when connect is interrupted by a signal
|
||
|
||
vsock_connect() expects that the socket could already be in the
|
||
TCP_ESTABLISHED state when the connecting task wakes up with a signal
|
||
pending. If this happens the socket will be in the connected table, and
|
||
it is not removed when the socket state is reset. In this situation it's
|
||
common for the process to retry connect(), and if the connection is
|
||
successful the socket will be added to the connected table a second
|
||
time, corrupting the list.
|
||
|
||
Prevent this by calling vsock_remove_connected() if a signal is received
|
||
while waiting for a connection. This is harmless if the socket is not in
|
||
the connected table, and if it is in the table then removing it will
|
||
prevent list corruption from a double add.
|
||
|
||
Note for backporting: this patch requires d5afa82c977e ("vsock: correct
|
||
removal of socket from the list"), which is in all current stable trees
|
||
except 4.9.y.(CVE-2022-48786)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
net: ieee802154: at86rf230: Stop leaking skb's
|
||
|
||
Upon error the ieee802154_xmit_complete() helper is not called. Only
|
||
ieee802154_wake_queue() is called manually. In the Tx case we then leak
|
||
the skb structure.
|
||
|
||
Free the skb structure upon error before returning when appropriate.
|
||
|
||
As the 'is_tx = 0' cannot be moved in the complete handler because of a
|
||
possible race between the delay in switching to STATE_RX_AACK_ON and a
|
||
new interrupt, we introduce an intermediate 'was_tx' boolean just for
|
||
this purpose.
|
||
|
||
There is no Fixes tag applying here, many changes have been made on this
|
||
area and the issue kind of always existed.(CVE-2022-48794)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
vt_ioctl: fix array_index_nospec in vt_setactivate
|
||
|
||
array_index_nospec ensures that an out-of-bounds value is set to zero
|
||
on the transient path. Decreasing the value by one afterwards causes
|
||
a transient integer underflow. vsa.console should be decreased first
|
||
and then sanitized with array_index_nospec.
|
||
|
||
Kasper Acknowledgements: Jakob Koschel, Brian Johannesmeyer, Kaveh
|
||
Razavi, Herbert Bos, Cristiano Giuffrida from the VUSec group at VU
|
||
Amsterdam.(CVE-2022-48804)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
usb: f_fs: Fix use-after-free for epfile
|
||
|
||
Consider a case where ffs_func_eps_disable is called from
|
||
ffs_func_disable as part of composition switch and at the
|
||
same time ffs_epfile_release get called from userspace.
|
||
ffs_epfile_release will free up the read buffer and call
|
||
ffs_data_closed which in turn destroys ffs->epfiles and
|
||
mark it as NULL. While this was happening the driver has
|
||
already initialized the local epfile in ffs_func_eps_disable
|
||
which is now freed and waiting to acquire the spinlock. Once
|
||
spinlock is acquired the driver proceeds with the stale value
|
||
of epfile and tries to free the already freed read buffer
|
||
causing use-after-free.
|
||
|
||
Following is the illustration of the race:
|
||
|
||
CPU1 CPU2
|
||
|
||
ffs_func_eps_disable
|
||
epfiles (local copy)
|
||
ffs_epfile_release
|
||
ffs_data_closed
|
||
if (last file closed)
|
||
ffs_data_reset
|
||
ffs_data_clear
|
||
ffs_epfiles_destroy
|
||
spin_lock
|
||
dereference epfiles
|
||
|
||
Fix this races by taking epfiles local copy & assigning it under
|
||
spinlock and if epfiles(local) is null then update it in ffs->epfiles
|
||
then finally destroy it.
|
||
Extending the scope further from the race, protecting the ep related
|
||
structures, and concurrent accesses.(CVE-2022-48822)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
NFSD: Fix ia_size underflow
|
||
|
||
iattr::ia_size is a loff_t, which is a signed 64-bit type. NFSv3 and
|
||
NFSv4 both define file size as an unsigned 64-bit type. Thus there
|
||
is a range of valid file size values an NFS client can send that is
|
||
already larger than Linux can handle.
|
||
|
||
Currently decode_fattr4() dumps a full u64 value into ia_size. If
|
||
that value happens to be larger than S64_MAX, then ia_size
|
||
underflows. I'm about to fix up the NFSv3 behavior as well, so let's
|
||
catch the underflow in the common code path: nfsd_setattr().(CVE-2022-48828)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
Input: aiptek - properly check endpoint type
|
||
|
||
Syzbot reported warning in usb_submit_urb() which is caused by wrong
|
||
endpoint type. There was a check for the number of endpoints, but not
|
||
for the type of endpoint.
|
||
|
||
Fix it by replacing old desc.bNumEndpoints check with
|
||
usb_find_common_endpoints() helper for finding endpoints
|
||
|
||
Fail log:
|
||
|
||
usb 5-1: BOGUS urb xfer, pipe 1 != type 3
|
||
WARNING: CPU: 2 PID: 48 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502
|
||
Modules linked in:
|
||
CPU: 2 PID: 48 Comm: kworker/2:2 Not tainted 5.17.0-rc6-syzkaller-00226-g07ebd38a0da2 #0
|
||
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
|
||
Workqueue: usb_hub_wq hub_event
|
||
...
|
||
Call Trace:
|
||
<TASK>
|
||
aiptek_open+0xd5/0x130 drivers/input/tablet/aiptek.c:830
|
||
input_open_device+0x1bb/0x320 drivers/input/input.c:629
|
||
kbd_connect+0xfe/0x160 drivers/tty/vt/keyboard.c:1593(CVE-2022-48836)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
MIPS: smp: fill in sibling and core maps earlier
|
||
|
||
After enabling CONFIG_SCHED_CORE (landed during 5.14 cycle),
|
||
2-core 2-thread-per-core interAptiv (CPS-driven) started emitting
|
||
the following:
|
||
|
||
[ 0.025698] CPU1 revision is: 0001a120 (MIPS interAptiv (multi))
|
||
[ 0.048183] ------------[ cut here ]------------
|
||
[ 0.048187] WARNING: CPU: 1 PID: 0 at kernel/sched/core.c:6025 sched_core_cpu_starting+0x198/0x240
|
||
[ 0.048220] Modules linked in:
|
||
[ 0.048233] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.17.0-rc3+ #35 b7b319f24073fd9a3c2aa7ad15fb7993eec0b26f
|
||
[ 0.048247] Stack : 817f0000 00000004 327804c8 810eb050 00000000 00000004 00000000 c314fdd1
|
||
[ 0.048278] 830cbd64 819c0000 81800000 817f0000 83070bf4 00000001 830cbd08 00000000
|
||
[ 0.048307] 00000000 00000000 815fcbc4 00000000 00000000 00000000 00000000 00000000
|
||
[ 0.048334] 00000000 00000000 00000000 00000000 817f0000 00000000 00000000 817f6f34
|
||
[ 0.048361] 817f0000 818a3c00 817f0000 00000004 00000000 00000000 4dc33260 0018c933
|
||
[ 0.048389] ...
|
||
[ 0.048396] Call Trace:
|
||
[ 0.048399] [<8105a7bc>] show_stack+0x3c/0x140
|
||
[ 0.048424] [<8131c2a0>] dump_stack_lvl+0x60/0x80
|
||
[ 0.048440] [<8108b5c0>] __warn+0xc0/0xf4
|
||
[ 0.048454] [<8108b658>] warn_slowpath_fmt+0x64/0x10c
|
||
[ 0.048467] [<810bd418>] sched_core_cpu_starting+0x198/0x240
|
||
[ 0.048483] [<810c6514>] sched_cpu_starting+0x14/0x80
|
||
[ 0.048497] [<8108c0f8>] cpuhp_invoke_callback_range+0x78/0x140
|
||
[ 0.048510] [<8108d914>] notify_cpu_starting+0x94/0x140
|
||
[ 0.048523] [<8106593c>] start_secondary+0xbc/0x280
|
||
[ 0.048539]
|
||
[ 0.048543] ---[ end trace 0000000000000000 ]---
|
||
[ 0.048636] Synchronize counters for CPU 1: done.
|
||
|
||
...for each but CPU 0/boot.
|
||
Basic debug printks right before the mentioned line say:
|
||
|
||
[ 0.048170] CPU: 1, smt_mask:
|
||
|
||
So smt_mask, which is sibling mask obviously, is empty when entering
|
||
the function.
|
||
This is critical, as sched_core_cpu_starting() calculates
|
||
core-scheduling parameters only once per CPU start, and it's crucial
|
||
to have all the parameters filled in at that moment (at least it
|
||
uses cpu_smt_mask() which in fact is `&cpu_sibling_map[cpu]` on
|
||
MIPS).
|
||
|
||
A bit of debugging led me to that set_cpu_sibling_map() performing
|
||
the actual map calculation, was being invocated after
|
||
notify_cpu_start(), and exactly the latter function starts CPU HP
|
||
callback round (sched_core_cpu_starting() is basically a CPU HP
|
||
callback).
|
||
While the flow is same on ARM64 (maps after the notifier, although
|
||
before calling set_cpu_online()), x86 started calculating sibling
|
||
maps earlier than starting the CPU HP callbacks in Linux 4.14 (see
|
||
[0] for the reference). Neither me nor my brief tests couldn't find
|
||
any potential caveats in calculating the maps right after performing
|
||
delay calibration, but the WARN splat is now gone.
|
||
The very same debug prints now yield exactly what I expected from
|
||
them:
|
||
|
||
[ 0.048433] CPU: 1, smt_mask: 0-1
|
||
|
||
[0] https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=76ce7cfe35ef(CVE-2022-48845)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
staging: gdm724x: fix use after free in gdm_lte_rx()
|
||
|
||
The netif_rx_ni() function frees the skb so we can't dereference it to
|
||
save the skb->len.(CVE-2022-48851)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
NFC: port100: fix use-after-free in port100_send_complete
|
||
|
||
Syzbot reported UAF in port100_send_complete(). The root case is in
|
||
missing usb_kill_urb() calls on error handling path of ->probe function.
|
||
|
||
port100_send_complete() accesses devm allocated memory which will be
|
||
freed on probe failure. We should kill this urbs before returning an
|
||
error from probe function to prevent reported use-after-free
|
||
|
||
Fail log:
|
||
|
||
BUG: KASAN: use-after-free in port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935
|
||
Read of size 1 at addr ffff88801bb59540 by task ksoftirqd/2/26
|
||
...
|
||
Call Trace:
|
||
<TASK>
|
||
__dump_stack lib/dump_stack.c:88 [inline]
|
||
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
|
||
print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255
|
||
__kasan_report mm/kasan/report.c:442 [inline]
|
||
kasan_report.cold+0x83/0xdf mm/kasan/report.c:459
|
||
port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935
|
||
__usb_hcd_giveback_urb+0x2b0/0x5c0 drivers/usb/core/hcd.c:1670
|
||
|
||
...
|
||
|
||
Allocated by task 1255:
|
||
kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
|
||
kasan_set_track mm/kasan/common.c:45 [inline]
|
||
set_alloc_info mm/kasan/common.c:436 [inline]
|
||
____kasan_kmalloc mm/kasan/common.c:515 [inline]
|
||
____kasan_kmalloc mm/kasan/common.c:474 [inline]
|
||
__kasan_kmalloc+0xa6/0xd0 mm/kasan/common.c:524
|
||
alloc_dr drivers/base/devres.c:116 [inline]
|
||
devm_kmalloc+0x96/0x1d0 drivers/base/devres.c:823
|
||
devm_kzalloc include/linux/device.h:209 [inline]
|
||
port100_probe+0x8a/0x1320 drivers/nfc/port100.c:1502
|
||
|
||
Freed by task 1255:
|
||
kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
|
||
kasan_set_track+0x21/0x30 mm/kasan/common.c:45
|
||
kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370
|
||
____kasan_slab_free mm/kasan/common.c:366 [inline]
|
||
____kasan_slab_free+0xff/0x140 mm/kasan/common.c:328
|
||
kasan_slab_free include/linux/kasan.h:236 [inline]
|
||
__cache_free mm/slab.c:3437 [inline]
|
||
kfree+0xf8/0x2b0 mm/slab.c:3794
|
||
release_nodes+0x112/0x1a0 drivers/base/devres.c:501
|
||
devres_release_all+0x114/0x190 drivers/base/devres.c:530
|
||
really_probe+0x626/0xcc0 drivers/base/dd.c:670(CVE-2022-48857)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
of: Fix double free in of_parse_phandle_with_args_map
|
||
|
||
In of_parse_phandle_with_args_map() the inner loop that
|
||
iterates through the map entries calls of_node_put(new)
|
||
to free the reference acquired by the previous iteration
|
||
of the inner loop. This assumes that the value of "new" is
|
||
NULL on the first iteration of the inner loop.
|
||
|
||
Make sure that this is true in all iterations of the outer
|
||
loop by setting "new" to NULL after its value is assigned to "cur".
|
||
|
||
Extend the unittest to detect the double free and add an additional
|
||
test case that actually triggers this path.(CVE-2023-52679)
|
||
|
||
A race condition was found in the Linux kernel's drm/exynos device driver in exynos_drm_crtc_atomic_disable() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.
|
||
|
||
|
||
(CVE-2024-22386)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
nilfs2: fix potential kernel bug due to lack of writeback flag waiting
|
||
|
||
Destructive writes to a block device on which nilfs2 is mounted can cause
|
||
a kernel bug in the folio/page writeback start routine or writeback end
|
||
routine (__folio_start_writeback in the log below):
|
||
|
||
kernel BUG at mm/page-writeback.c:3070!
|
||
Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
|
||
...
|
||
RIP: 0010:__folio_start_writeback+0xbaa/0x10e0
|
||
Code: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff
|
||
e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 <0f>
|
||
0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00
|
||
...
|
||
Call Trace:
|
||
<TASK>
|
||
nilfs_segctor_do_construct+0x4654/0x69d0 [nilfs2]
|
||
nilfs_segctor_construct+0x181/0x6b0 [nilfs2]
|
||
nilfs_segctor_thread+0x548/0x11c0 [nilfs2]
|
||
kthread+0x2f0/0x390
|
||
ret_from_fork+0x4b/0x80
|
||
ret_from_fork_asm+0x1a/0x30
|
||
</TASK>
|
||
|
||
This is because when the log writer starts a writeback for segment summary
|
||
blocks or a super root block that use the backing device's page cache, it
|
||
does not wait for the ongoing folio/page writeback, resulting in an
|
||
inconsistent writeback state.
|
||
|
||
Fix this issue by waiting for ongoing writebacks when putting
|
||
folios/pages on the backing device into writeback state.(CVE-2024-37078)
|
||
|
||
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:
|
||
|
||
media: i2c: et8ek8: Don't strip remove function when driver is builtin
|
||
|
||
Using __exit for the remove function results in the remove callback
|
||
being discarded with CONFIG_VIDEO_ET8EK8=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/media/i2c/et8ek8/et8ek8: section mismatch in reference: et8ek8_i2c_driver+0x10 (section: .data) -> et8ek8_remove (section: .exit.text)(CVE-2024-38611)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
stm class: Fix a double free in stm_register_device()
|
||
|
||
The put_device(&stm->dev) call will trigger stm_device_release() which
|
||
frees "stm" so the vfree(stm) on the next line is a double free.(CVE-2024-38627)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
fbdev: savage: Handle err return when savagefb_check_var failed
|
||
|
||
The commit 04e5eac8f3ab("fbdev: savage: Error out if pixclock equals zero")
|
||
checks the value of pixclock to avoid divide-by-zero error. However
|
||
the function savagefb_probe doesn't handle the error return of
|
||
savagefb_check_var. When pixclock is 0, it will cause divide-by-zero error.(CVE-2024-39475)
|
||
|
||
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:
|
||
|
||
wifi: mac80211: mesh: Fix leak of mesh_preq_queue objects
|
||
|
||
The hwmp code use objects of type mesh_preq_queue, added to a list in
|
||
ieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpath
|
||
gets deleted, ex mesh interface is removed, the entries in that list will
|
||
never get cleaned. Fix this by flushing all corresponding items of the
|
||
preq_queue in mesh_path_flush_pending().
|
||
|
||
This should take care of KASAN reports like this:
|
||
|
||
unreferenced object 0xffff00000668d800 (size 128):
|
||
comm "kworker/u8:4", pid 67, jiffies 4295419552 (age 1836.444s)
|
||
hex dump (first 32 bytes):
|
||
00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff ..........h.....
|
||
8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00 ....>...........
|
||
backtrace:
|
||
[<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c
|
||
[<00000000049bd418>] kmalloc_trace+0x34/0x80
|
||
[<0000000000d792bb>] mesh_queue_preq+0x44/0x2a8
|
||
[<00000000c99c3696>] mesh_nexthop_resolve+0x198/0x19c
|
||
[<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4
|
||
[<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764
|
||
[<000000005926ee38>] ieee80211_subif_start_xmit+0x9c/0x7a4
|
||
[<000000004c86e916>] dev_hard_start_xmit+0x174/0x440
|
||
[<0000000023495647>] __dev_queue_xmit+0xe24/0x111c
|
||
[<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4
|
||
[<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508
|
||
[<00000000adc3cd94>] process_one_work+0x4b8/0xa1c
|
||
[<00000000b36425d1>] worker_thread+0x9c/0x634
|
||
[<0000000005852dd5>] kthread+0x1bc/0x1c4
|
||
[<000000005fccd770>] ret_from_fork+0x10/0x20
|
||
unreferenced object 0xffff000009051f00 (size 128):
|
||
comm "kworker/u8:4", pid 67, jiffies 4295419553 (age 1836.440s)
|
||
hex dump (first 32 bytes):
|
||
90 d6 92 0d 00 00 ff ff 00 d8 68 06 00 00 ff ff ..........h.....
|
||
36 27 92 e4 02 e0 01 00 00 58 79 06 00 00 ff ff 6'.......Xy.....
|
||
backtrace:
|
||
[<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c
|
||
[<00000000049bd418>] kmalloc_trace+0x34/0x80
|
||
[<0000000000d792bb>] mesh_queue_preq+0x44/0x2a8
|
||
[<00000000c99c3696>] mesh_nexthop_resolve+0x198/0x19c
|
||
[<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4
|
||
[<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764
|
||
[<000000005926ee38>] ieee80211_subif_start_xmit+0x9c/0x7a4
|
||
[<000000004c86e916>] dev_hard_start_xmit+0x174/0x440
|
||
[<0000000023495647>] __dev_queue_xmit+0xe24/0x111c
|
||
[<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4
|
||
[<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508
|
||
[<00000000adc3cd94>] process_one_work+0x4b8/0xa1c
|
||
[<00000000b36425d1>] worker_thread+0x9c/0x634
|
||
[<0000000005852dd5>] kthread+0x1bc/0x1c4
|
||
[<000000005fccd770>] ret_from_fork+0x10/0x20(CVE-2024-40942)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
ima: Avoid blocking in RCU read-side critical section
|
||
|
||
A panic happens in ima_match_policy:
|
||
|
||
BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
|
||
PGD 42f873067 P4D 0
|
||
Oops: 0000 [#1] SMP NOPTI
|
||
CPU: 5 PID: 1286325 Comm: kubeletmonit.sh
|
||
Kdump: loaded Tainted: P
|
||
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
|
||
BIOS 0.0.0 02/06/2015
|
||
RIP: 0010:ima_match_policy+0x84/0x450
|
||
Code: 49 89 fc 41 89 cf 31 ed 89 44 24 14 eb 1c 44 39
|
||
7b 18 74 26 41 83 ff 05 74 20 48 8b 1b 48 3b 1d
|
||
f2 b9 f4 00 0f 84 9c 01 00 00 <44> 85 73 10 74 ea
|
||
44 8b 6b 14 41 f6 c5 01 75 d4 41 f6 c5 02 74 0f
|
||
RSP: 0018:ff71570009e07a80 EFLAGS: 00010207
|
||
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000200
|
||
RDX: ffffffffad8dc7c0 RSI: 0000000024924925 RDI: ff3e27850dea2000
|
||
RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffffabfce739
|
||
R10: ff3e27810cc42400 R11: 0000000000000000 R12: ff3e2781825ef970
|
||
R13: 00000000ff3e2785 R14: 000000000000000c R15: 0000000000000001
|
||
FS: 00007f5195b51740(0000)
|
||
GS:ff3e278b12d40000(0000) knlGS:0000000000000000
|
||
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
||
CR2: 0000000000000010 CR3: 0000000626d24002 CR4: 0000000000361ee0
|
||
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
||
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
||
Call Trace:
|
||
ima_get_action+0x22/0x30
|
||
process_measurement+0xb0/0x830
|
||
? page_add_file_rmap+0x15/0x170
|
||
? alloc_set_pte+0x269/0x4c0
|
||
? prep_new_page+0x81/0x140
|
||
? simple_xattr_get+0x75/0xa0
|
||
? selinux_file_open+0x9d/0xf0
|
||
ima_file_check+0x64/0x90
|
||
path_openat+0x571/0x1720
|
||
do_filp_open+0x9b/0x110
|
||
? page_counter_try_charge+0x57/0xc0
|
||
? files_cgroup_alloc_fd+0x38/0x60
|
||
? __alloc_fd+0xd4/0x250
|
||
? do_sys_open+0x1bd/0x250
|
||
do_sys_open+0x1bd/0x250
|
||
do_syscall_64+0x5d/0x1d0
|
||
entry_SYSCALL_64_after_hwframe+0x65/0xca
|
||
|
||
Commit c7423dbdbc9e ("ima: Handle -ESTALE returned by
|
||
ima_filter_rule_match()") introduced call to ima_lsm_copy_rule within a
|
||
RCU read-side critical section which contains kmalloc with GFP_KERNEL.
|
||
This implies a possible sleep and violates limitations of RCU read-side
|
||
critical sections on non-PREEMPT systems.
|
||
|
||
Sleeping within RCU read-side critical section might cause
|
||
synchronize_rcu() returning early and break RCU protection, allowing a
|
||
UAF to happen.
|
||
|
||
The root cause of this issue could be described as follows:
|
||
| Thread A | Thread B |
|
||
| |ima_match_policy |
|
||
| | rcu_read_lock |
|
||
|ima_lsm_update_rule | |
|
||
| synchronize_rcu | |
|
||
| | kmalloc(GFP_KERNEL)|
|
||
| | sleep |
|
||
==> synchronize_rcu returns early
|
||
| kfree(entry) | |
|
||
| | entry = entry->next|
|
||
==> UAF happens and entry now becomes NULL (or could be anything).
|
||
| | entry->action |
|
||
==> Accessing entry might cause panic.
|
||
|
||
To fix this issue, we are converting all kmalloc that is called within
|
||
RCU read-side critical section to use GFP_ATOMIC.
|
||
|
||
[PM: fixed missing comment, long lines, !CONFIG_IMA_LSM_RULES case](CVE-2024-40947)
|
||
|
||
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:
|
||
|
||
scsi: qedi: Fix crash while reading debugfs attribute
|
||
|
||
The qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directly
|
||
on a __user pointer, which results into the crash.
|
||
|
||
To fix this issue, use a small local stack buffer for sprintf() and then
|
||
call simple_read_from_buffer(), which in turns make the copy_to_user()
|
||
call.
|
||
|
||
BUG: unable to handle page fault for address: 00007f4801111000
|
||
PGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0
|
||
Oops: 0002 [#1] PREEMPT SMP PTI
|
||
Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023
|
||
RIP: 0010:memcpy_orig+0xcd/0x130
|
||
RSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202
|
||
RAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f
|
||
RDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000
|
||
RBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572
|
||
R10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff
|
||
R13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af
|
||
FS: 00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000
|
||
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
||
CR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0
|
||
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
||
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
||
PKRU: 55555554
|
||
Call Trace:
|
||
<TASK>
|
||
? __die_body+0x1a/0x60
|
||
? page_fault_oops+0x183/0x510
|
||
? exc_page_fault+0x69/0x150
|
||
? asm_exc_page_fault+0x22/0x30
|
||
? memcpy_orig+0xcd/0x130
|
||
vsnprintf+0x102/0x4c0
|
||
sprintf+0x51/0x80
|
||
qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324]
|
||
full_proxy_read+0x50/0x80
|
||
vfs_read+0xa5/0x2e0
|
||
? folio_add_new_anon_rmap+0x44/0xa0
|
||
? set_pte_at+0x15/0x30
|
||
? do_pte_missing+0x426/0x7f0
|
||
ksys_read+0xa5/0xe0
|
||
do_syscall_64+0x58/0x80
|
||
? __count_memcg_events+0x46/0x90
|
||
? count_memcg_event_mm+0x3d/0x60
|
||
? handle_mm_fault+0x196/0x2f0
|
||
? do_user_addr_fault+0x267/0x890
|
||
? exc_page_fault+0x69/0x150
|
||
entry_SYSCALL_64_after_hwframe+0x72/0xdc
|
||
RIP: 0033:0x7f4800f20b4d(CVE-2024-40978)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
batman-adv: bypass empty buckets in batadv_purge_orig_ref()
|
||
|
||
Many syzbot reports are pointing to soft lockups in
|
||
batadv_purge_orig_ref() [1]
|
||
|
||
Root cause is unknown, but we can avoid spending too much
|
||
time there and perhaps get more interesting reports.
|
||
|
||
[1]
|
||
|
||
watchdog: BUG: soft lockup - CPU#0 stuck for 27s! [kworker/u4:6:621]
|
||
Modules linked in:
|
||
irq event stamp: 6182794
|
||
hardirqs last enabled at (6182793): [<ffff8000801dae10>] __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386
|
||
hardirqs last disabled at (6182794): [<ffff80008ad66a78>] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]
|
||
hardirqs last disabled at (6182794): [<ffff80008ad66a78>] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551
|
||
softirqs last enabled at (6182792): [<ffff80008aab71c4>] spin_unlock_bh include/linux/spinlock.h:396 [inline]
|
||
softirqs last enabled at (6182792): [<ffff80008aab71c4>] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287
|
||
softirqs last disabled at (6182790): [<ffff80008aab61dc>] spin_lock_bh include/linux/spinlock.h:356 [inline]
|
||
softirqs last disabled at (6182790): [<ffff80008aab61dc>] batadv_purge_orig_ref+0x164/0x1228 net/batman-adv/originator.c:1271
|
||
CPU: 0 PID: 621 Comm: kworker/u4:6 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0
|
||
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
|
||
Workqueue: bat_events batadv_purge_orig
|
||
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
||
pc : should_resched arch/arm64/include/asm/preempt.h:79 [inline]
|
||
pc : __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:388
|
||
lr : __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386
|
||
sp : ffff800099007970
|
||
x29: ffff800099007980 x28: 1fffe00018fce1bd x27: dfff800000000000
|
||
x26: ffff0000d2620008 x25: ffff0000c7e70de8 x24: 0000000000000001
|
||
x23: 1fffe00018e57781 x22: dfff800000000000 x21: ffff80008aab71c4
|
||
x20: ffff0001b40136c0 x19: ffff0000c72bbc08 x18: 1fffe0001a817bb0
|
||
x17: ffff800125414000 x16: ffff80008032116c x15: 0000000000000001
|
||
x14: 1fffe0001ee9d610 x13: 0000000000000000 x12: 0000000000000003
|
||
x11: 0000000000000000 x10: 0000000000ff0100 x9 : 0000000000000000
|
||
x8 : 00000000005e5789 x7 : ffff80008aab61dc x6 : 0000000000000000
|
||
x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000
|
||
x2 : 0000000000000006 x1 : 0000000000000080 x0 : ffff800125414000
|
||
Call trace:
|
||
__daif_local_irq_enable arch/arm64/include/asm/irqflags.h:27 [inline]
|
||
arch_local_irq_enable arch/arm64/include/asm/irqflags.h:49 [inline]
|
||
__local_bh_enable_ip+0x228/0x44c kernel/softirq.c:386
|
||
__raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline]
|
||
_raw_spin_unlock_bh+0x3c/0x4c kernel/locking/spinlock.c:210
|
||
spin_unlock_bh include/linux/spinlock.h:396 [inline]
|
||
batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287
|
||
batadv_purge_orig+0x20/0x70 net/batman-adv/originator.c:1300
|
||
process_one_work+0x694/0x1204 kernel/workqueue.c:2633
|
||
process_scheduled_works kernel/workqueue.c:2706 [inline]
|
||
worker_thread+0x938/0xef4 kernel/workqueue.c:2787
|
||
kthread+0x288/0x310 kernel/kthread.c:388
|
||
ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860
|
||
Sending NMI from CPU 0 to CPUs 1:
|
||
NMI backtrace for cpu 1
|
||
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0
|
||
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
|
||
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
||
pc : arch_local_irq_enable+0x8/0xc arch/arm64/include/asm/irqflags.h:51
|
||
lr : default_idle_call+0xf8/0x128 kernel/sched/idle.c:103
|
||
sp : ffff800093a17d30
|
||
x29: ffff800093a17d30 x28: dfff800000000000 x27: 1ffff00012742fb4
|
||
x26: ffff80008ec9d000 x25: 0000000000000000 x24: 0000000000000002
|
||
x23: 1ffff00011d93a74 x22: ffff80008ec9d3a0 x21: 0000000000000000
|
||
x20: ffff0000c19dbc00 x19: ffff8000802d0fd8 x18: 1fffe00036804396
|
||
x17: ffff80008ec9d000 x16: ffff8000802d089c x15: 0000000000000001
|
||
---truncated---(CVE-2024-40981)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
drm/radeon: fix UBSAN warning in kv_dpm.c
|
||
|
||
Adds bounds check for sumo_vid_mapping_entry.(CVE-2024-40988)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
net/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)</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/en/security/security-bulletins/detail?id=openEuler-SA-2024-1944</URL>
|
||
</Reference>
|
||
<Reference Type="openEuler CVE">
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2021-47181</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2021-47189</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2021-47204</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2021-47206</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48786</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48794</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48804</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48822</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48828</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48836</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48845</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48851</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48857</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-52679</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-22386</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-37078</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-38611</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38627</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39475</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-40942</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40947</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-40978</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40981</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40988</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40995</URL>
|
||
</Reference>
|
||
<Reference Type="Other">
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47181</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47189</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47204</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47206</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48786</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48794</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48804</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48822</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48828</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48836</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48845</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48851</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48857</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52679</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-22386</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-37078</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38567</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38611</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38627</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39475</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-40942</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40947</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40960</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40978</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40981</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40988</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40995</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="aarch64">
|
||
<FullProductName ProductID="kernel-debuginfo-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-devel-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-devel-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="python3-perf-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-debugsource-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debugsource-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-source-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-source-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="perf-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="python2-perf-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-tools-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="bpftool-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="perf-debuginfo-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-tools-devel-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-devel-4.19.90-2408.1.0.0288.oe2003sp4.aarch64.rpm</FullProductName>
|
||
</Branch>
|
||
<Branch Type="Package Arch" Name="src">
|
||
<FullProductName ProductID="kernel-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2408.1.0.0288.oe2003sp4.src.rpm</FullProductName>
|
||
</Branch>
|
||
<Branch Type="Package Arch" Name="x86_64">
|
||
<FullProductName ProductID="kernel-debugsource-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debugsource-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="bpftool-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-tools-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-devel-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-devel-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="perf-debuginfo-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="perf-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-source-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-source-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-tools-devel-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-devel-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-debuginfo-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="python2-perf-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-debuginfo-4.19.90-2408.1.0.0288.oe2003sp4.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="python3-perf-4.19.90-2408.1.0.0288" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-4.19.90-2408.1.0.0288.oe2003sp4.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:
|
||
|
||
usb: musb: tusb6010: check return value after calling platform_get_resource()
|
||
|
||
It will cause null-ptr-deref if platform_get_resource() returns NULL,
|
||
we need check the return value.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-02</ReleaseDate>
|
||
<CVE>CVE-2021-47181</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-02</DATE>
|
||
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1944</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:
|
||
|
||
btrfs: fix memory ordering between normal and ordered work functions
|
||
|
||
Ordered work functions aren't guaranteed to be handled by the same thread
|
||
which executed the normal work functions. The only way execution between
|
||
normal/ordered functions is synchronized is via the WORK_DONE_BIT,
|
||
unfortunately the used bitops don't guarantee any ordering whatsoever.
|
||
|
||
This manifested as seemingly inexplicable crashes on ARM64, where
|
||
async_chunk::inode is seen as non-null in async_cow_submit which causes
|
||
submit_compressed_extents to be called and crash occurs because
|
||
async_chunk::inode suddenly became NULL. The call trace was similar to:
|
||
|
||
pc : submit_compressed_extents+0x38/0x3d0
|
||
lr : async_cow_submit+0x50/0xd0
|
||
sp : ffff800015d4bc20
|
||
|
||
<registers omitted for brevity>
|
||
|
||
Call trace:
|
||
submit_compressed_extents+0x38/0x3d0
|
||
async_cow_submit+0x50/0xd0
|
||
run_ordered_work+0xc8/0x280
|
||
btrfs_work_helper+0x98/0x250
|
||
process_one_work+0x1f0/0x4ac
|
||
worker_thread+0x188/0x504
|
||
kthread+0x110/0x114
|
||
ret_from_fork+0x10/0x18
|
||
|
||
Fix this by adding respective barrier calls which ensure that all
|
||
accesses preceding setting of WORK_DONE_BIT are strictly ordered before
|
||
setting the flag. At the same time add a read barrier after reading of
|
||
WORK_DONE_BIT in run_ordered_work which ensures all subsequent loads
|
||
would be strictly ordered after reading the bit. This in turn ensures
|
||
are all accesses before WORK_DONE_BIT are going to be strictly ordered
|
||
before any access that can occur in ordered_func.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-02</ReleaseDate>
|
||
<CVE>CVE-2021-47189</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-02</DATE>
|
||
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1944</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:
|
||
|
||
net: dpaa2-eth: fix use-after-free in dpaa2_eth_remove
|
||
|
||
Access to netdev after free_netdev() will cause use-after-free bug.
|
||
Move debug log before free_netdev() call to avoid it.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-02</ReleaseDate>
|
||
<CVE>CVE-2021-47204</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-02</DATE>
|
||
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1944</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:
|
||
|
||
usb: host: ohci-tmio: check return value after calling platform_get_resource()
|
||
|
||
It will cause null-ptr-deref if platform_get_resource() returns NULL,
|
||
we need check the return value.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-02</ReleaseDate>
|
||
<CVE>CVE-2021-47206</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-02</DATE>
|
||
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1944</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:
|
||
|
||
vsock: remove vsock from connected table when connect is interrupted by a signal
|
||
|
||
vsock_connect() expects that the socket could already be in the
|
||
TCP_ESTABLISHED state when the connecting task wakes up with a signal
|
||
pending. If this happens the socket will be in the connected table, and
|
||
it is not removed when the socket state is reset. In this situation it's
|
||
common for the process to retry connect(), and if the connection is
|
||
successful the socket will be added to the connected table a second
|
||
time, corrupting the list.
|
||
|
||
Prevent this by calling vsock_remove_connected() if a signal is received
|
||
while waiting for a connection. This is harmless if the socket is not in
|
||
the connected table, and if it is in the table then removing it will
|
||
prevent list corruption from a double add.
|
||
|
||
Note for backporting: this patch requires d5afa82c977e ("vsock: correct
|
||
removal of socket from the list"), which is in all current stable trees
|
||
except 4.9.y.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-02</ReleaseDate>
|
||
<CVE>CVE-2022-48786</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:N/I:L/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-1944</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:
|
||
|
||
net: ieee802154: at86rf230: Stop leaking skb's
|
||
|
||
Upon error the ieee802154_xmit_complete() helper is not called. Only
|
||
ieee802154_wake_queue() is called manually. In the Tx case we then leak
|
||
the skb structure.
|
||
|
||
Free the skb structure upon error before returning when appropriate.
|
||
|
||
As the 'is_tx = 0' cannot be moved in the complete handler because of a
|
||
possible race between the delay in switching to STATE_RX_AACK_ON and a
|
||
new interrupt, we introduce an intermediate 'was_tx' boolean just for
|
||
this purpose.
|
||
|
||
There is no Fixes tag applying here, many changes have been made on this
|
||
area and the issue kind of always existed.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-02</ReleaseDate>
|
||
<CVE>CVE-2022-48794</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.3</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-02</DATE>
|
||
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1944</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:
|
||
|
||
vt_ioctl: fix array_index_nospec in vt_setactivate
|
||
|
||
array_index_nospec ensures that an out-of-bounds value is set to zero
|
||
on the transient path. Decreasing the value by one afterwards causes
|
||
a transient integer underflow. vsa.console should be decreased first
|
||
and then sanitized with array_index_nospec.
|
||
|
||
Kasper Acknowledgements: Jakob Koschel, Brian Johannesmeyer, Kaveh
|
||
Razavi, Herbert Bos, Cristiano Giuffrida from the VUSec group at VU
|
||
Amsterdam.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-02</ReleaseDate>
|
||
<CVE>CVE-2022-48804</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.7</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-02</DATE>
|
||
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1944</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:
|
||
|
||
usb: f_fs: Fix use-after-free for epfile
|
||
|
||
Consider a case where ffs_func_eps_disable is called from
|
||
ffs_func_disable as part of composition switch and at the
|
||
same time ffs_epfile_release get called from userspace.
|
||
ffs_epfile_release will free up the read buffer and call
|
||
ffs_data_closed which in turn destroys ffs->epfiles and
|
||
mark it as NULL. While this was happening the driver has
|
||
already initialized the local epfile in ffs_func_eps_disable
|
||
which is now freed and waiting to acquire the spinlock. Once
|
||
spinlock is acquired the driver proceeds with the stale value
|
||
of epfile and tries to free the already freed read buffer
|
||
causing use-after-free.
|
||
|
||
Following is the illustration of the race:
|
||
|
||
CPU1 CPU2
|
||
|
||
ffs_func_eps_disable
|
||
epfiles (local copy)
|
||
ffs_epfile_release
|
||
ffs_data_closed
|
||
if (last file closed)
|
||
ffs_data_reset
|
||
ffs_data_clear
|
||
ffs_epfiles_destroy
|
||
spin_lock
|
||
dereference epfiles
|
||
|
||
Fix this races by taking epfiles local copy & assigning it under
|
||
spinlock and if epfiles(local) is null then update it in ffs->epfiles
|
||
then finally destroy it.
|
||
Extending the scope further from the race, protecting the ep related
|
||
structures, and concurrent accesses.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-02</ReleaseDate>
|
||
<CVE>CVE-2022-48822</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-02</DATE>
|
||
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1944</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:
|
||
|
||
NFSD: Fix ia_size underflow
|
||
|
||
iattr::ia_size is a loff_t, which is a signed 64-bit type. NFSv3 and
|
||
NFSv4 both define file size as an unsigned 64-bit type. Thus there
|
||
is a range of valid file size values an NFS client can send that is
|
||
already larger than Linux can handle.
|
||
|
||
Currently decode_fattr4() dumps a full u64 value into ia_size. If
|
||
that value happens to be larger than S64_MAX, then ia_size
|
||
underflows. I'm about to fix up the NFSv3 behavior as well, so let's
|
||
catch the underflow in the common code path: nfsd_setattr().</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-02</ReleaseDate>
|
||
<CVE>CVE-2022-48828</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: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-1944</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:Input: aiptek - properly check endpoint typeSyzbot reported warning in usb_submit_urb() which is caused by wrongendpoint type. There was a check for the number of endpoints, but notfor the type of endpoint.Fix it by replacing old desc.bNumEndpoints check withusb_find_common_endpoints() helper for finding endpointsFail log:usb 5-1: BOGUS urb xfer, pipe 1 != type 3WARNING: CPU: 2 PID: 48 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502Modules linked in:CPU: 2 PID: 48 Comm: kworker/2:2 Not tainted 5.17.0-rc6-syzkaller-00226-g07ebd38a0da2 #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014Workqueue: usb_hub_wq hub_event...Call Trace: <TASK> aiptek_open+0xd5/0x130 drivers/input/tablet/aiptek.c:830 input_open_device+0x1bb/0x320 drivers/input/input.c:629 kbd_connect+0xfe/0x160 drivers/tty/vt/keyboard.c:1593</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-02</ReleaseDate>
|
||
<CVE>CVE-2022-48836</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-02</DATE>
|
||
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1944</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:MIPS: smp: fill in sibling and core maps earlierAfter enabling CONFIG_SCHED_CORE (landed during 5.14 cycle),2-core 2-thread-per-core interAptiv (CPS-driven) started emittingthe following:[ 0.025698] CPU1 revision is: 0001a120 (MIPS interAptiv (multi))[ 0.048183] ------------[ cut here ]------------[ 0.048187] WARNING: CPU: 1 PID: 0 at kernel/sched/core.c:6025 sched_core_cpu_starting+0x198/0x240[ 0.048220] Modules linked in:[ 0.048233] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.17.0-rc3+ #35 b7b319f24073fd9a3c2aa7ad15fb7993eec0b26f[ 0.048247] Stack : 817f0000 00000004 327804c8 810eb050 00000000 00000004 00000000 c314fdd1[ 0.048278] 830cbd64 819c0000 81800000 817f0000 83070bf4 00000001 830cbd08 00000000[ 0.048307] 00000000 00000000 815fcbc4 00000000 00000000 00000000 00000000 00000000[ 0.048334] 00000000 00000000 00000000 00000000 817f0000 00000000 00000000 817f6f34[ 0.048361] 817f0000 818a3c00 817f0000 00000004 00000000 00000000 4dc33260 0018c933[ 0.048389] ...[ 0.048396] Call Trace:[ 0.048399] [<8105a7bc>] show_stack+0x3c/0x140[ 0.048424] [<8131c2a0>] dump_stack_lvl+0x60/0x80[ 0.048440] [<8108b5c0>] __warn+0xc0/0xf4[ 0.048454] [<8108b658>] warn_slowpath_fmt+0x64/0x10c[ 0.048467] [<810bd418>] sched_core_cpu_starting+0x198/0x240[ 0.048483] [<810c6514>] sched_cpu_starting+0x14/0x80[ 0.048497] [<8108c0f8>] cpuhp_invoke_callback_range+0x78/0x140[ 0.048510] [<8108d914>] notify_cpu_starting+0x94/0x140[ 0.048523] [<8106593c>] start_secondary+0xbc/0x280[ 0.048539][ 0.048543] ---[ end trace 0000000000000000 ]---[ 0.048636] Synchronize counters for CPU 1: done....for each but CPU 0/boot.Basic debug printks right before the mentioned line say:[ 0.048170] CPU: 1, smt_mask:So smt_mask, which is sibling mask obviously, is empty when enteringthe function.This is critical, as sched_core_cpu_starting() calculatescore-scheduling parameters only once per CPU start, and it s crucialto have all the parameters filled in at that moment (at least ituses cpu_smt_mask() which in fact is `&cpu_sibling_map[cpu]` onMIPS).A bit of debugging led me to that set_cpu_sibling_map() performingthe actual map calculation, was being invocated afternotify_cpu_start(), and exactly the latter function starts CPU HPcallback round (sched_core_cpu_starting() is basically a CPU HPcallback).While the flow is same on ARM64 (maps after the notifier, althoughbefore calling set_cpu_online()), x86 started calculating siblingmaps earlier than starting the CPU HP callbacks in Linux 4.14 (see[0] for the reference). Neither me nor my brief tests couldn t findany potential caveats in calculating the maps right after performingdelay calibration, but the WARN splat is now gone.The very same debug prints now yield exactly what I expected fromthem:[ 0.048433] CPU: 1, smt_mask: 0-1[0] https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=76ce7cfe35ef</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-02</ReleaseDate>
|
||
<CVE>CVE-2022-48845</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-02</DATE>
|
||
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1944</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:staging: gdm724x: fix use after free in gdm_lte_rx()The netif_rx_ni() function frees the skb so we can t dereference it tosave the skb->len.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-02</ReleaseDate>
|
||
<CVE>CVE-2022-48851</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-02</DATE>
|
||
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1944</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:NFC: port100: fix use-after-free in port100_send_completeSyzbot reported UAF in port100_send_complete(). The root case is inmissing usb_kill_urb() calls on error handling path of ->probe function.port100_send_complete() accesses devm allocated memory which will befreed on probe failure. We should kill this urbs before returning anerror from probe function to prevent reported use-after-freeFail log:BUG: KASAN: use-after-free in port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935Read of size 1 at addr ffff88801bb59540 by task ksoftirqd/2/26...Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255 __kasan_report mm/kasan/report.c:442 [inline] kasan_report.cold+0x83/0xdf mm/kasan/report.c:459 port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935 __usb_hcd_giveback_urb+0x2b0/0x5c0 drivers/usb/core/hcd.c:1670...Allocated by task 1255: kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:45 [inline] set_alloc_info mm/kasan/common.c:436 [inline] ____kasan_kmalloc mm/kasan/common.c:515 [inline] ____kasan_kmalloc mm/kasan/common.c:474 [inline] __kasan_kmalloc+0xa6/0xd0 mm/kasan/common.c:524 alloc_dr drivers/base/devres.c:116 [inline] devm_kmalloc+0x96/0x1d0 drivers/base/devres.c:823 devm_kzalloc include/linux/device.h:209 [inline] port100_probe+0x8a/0x1320 drivers/nfc/port100.c:1502Freed by task 1255: kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track+0x21/0x30 mm/kasan/common.c:45 kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370 ____kasan_slab_free mm/kasan/common.c:366 [inline] ____kasan_slab_free+0xff/0x140 mm/kasan/common.c:328 kasan_slab_free include/linux/kasan.h:236 [inline] __cache_free mm/slab.c:3437 [inline] kfree+0xf8/0x2b0 mm/slab.c:3794 release_nodes+0x112/0x1a0 drivers/base/devres.c:501 devres_release_all+0x114/0x190 drivers/base/devres.c:530 really_probe+0x626/0xcc0 drivers/base/dd.c:670</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-02</ReleaseDate>
|
||
<CVE>CVE-2022-48857</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-02</DATE>
|
||
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1944</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:
|
||
|
||
of: Fix double free in of_parse_phandle_with_args_map
|
||
|
||
In of_parse_phandle_with_args_map() the inner loop that
|
||
iterates through the map entries calls of_node_put(new)
|
||
to free the reference acquired by the previous iteration
|
||
of the inner loop. This assumes that the value of "new" is
|
||
NULL on the first iteration of the inner loop.
|
||
|
||
Make sure that this is true in all iterations of the outer
|
||
loop by setting "new" to NULL after its value is assigned to "cur".
|
||
|
||
Extend the unittest to detect the double free and add an additional
|
||
test case that actually triggers this path.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-02</ReleaseDate>
|
||
<CVE>CVE-2023-52679</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-02</DATE>
|
||
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1944</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">A race condition was found in the Linux kernel's drm/exynos device driver in exynos_drm_crtc_atomic_disable() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.
|
||
|
||
|
||
</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-02</ReleaseDate>
|
||
<CVE>CVE-2024-22386</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.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-1944</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="16" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
nilfs2: fix potential kernel bug due to lack of writeback flag waiting
|
||
|
||
Destructive writes to a block device on which nilfs2 is mounted can cause
|
||
a kernel bug in the folio/page writeback start routine or writeback end
|
||
routine (__folio_start_writeback in the log below):
|
||
|
||
kernel BUG at mm/page-writeback.c:3070!
|
||
Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
|
||
...
|
||
RIP: 0010:__folio_start_writeback+0xbaa/0x10e0
|
||
Code: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff
|
||
e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 <0f>
|
||
0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00
|
||
...
|
||
Call Trace:
|
||
<TASK>
|
||
nilfs_segctor_do_construct+0x4654/0x69d0 [nilfs2]
|
||
nilfs_segctor_construct+0x181/0x6b0 [nilfs2]
|
||
nilfs_segctor_thread+0x548/0x11c0 [nilfs2]
|
||
kthread+0x2f0/0x390
|
||
ret_from_fork+0x4b/0x80
|
||
ret_from_fork_asm+0x1a/0x30
|
||
</TASK>
|
||
|
||
This is because when the log writer starts a writeback for segment summary
|
||
blocks or a super root block that use the backing device's page cache, it
|
||
does not wait for the ongoing folio/page writeback, resulting in an
|
||
inconsistent writeback state.
|
||
|
||
Fix this issue by waiting for ongoing writebacks when putting
|
||
folios/pages on the backing device into writeback state.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-02</ReleaseDate>
|
||
<CVE>CVE-2024-37078</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-02</DATE>
|
||
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1944</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="17" 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-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-02</DATE>
|
||
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1944</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="18" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
media: i2c: et8ek8: Don't strip remove function when driver is builtin
|
||
|
||
Using __exit for the remove function results in the remove callback
|
||
being discarded with CONFIG_VIDEO_ET8EK8=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/media/i2c/et8ek8/et8ek8: section mismatch in reference: et8ek8_i2c_driver+0x10 (section: .data) -> et8ek8_remove (section: .exit.text)</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-02</ReleaseDate>
|
||
<CVE>CVE-2024-38611</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:N/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-1944</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="19" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
stm class: Fix a double free in stm_register_device()
|
||
|
||
The put_device(&stm->dev) call will trigger stm_device_release() which
|
||
frees "stm" so the vfree(stm) on the next line is a double free.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-02</ReleaseDate>
|
||
<CVE>CVE-2024-38627</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-02</DATE>
|
||
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1944</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="20" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:fbdev: savage: Handle err return when savagefb_check_var failedThe commit 04e5eac8f3ab( fbdev: savage: Error out if pixclock equals zero )checks the value of pixclock to avoid divide-by-zero error. Howeverthe function savagefb_probe doesn t handle the error return ofsavagefb_check_var. When pixclock is 0, it will cause divide-by-zero error.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-02</ReleaseDate>
|
||
<CVE>CVE-2024-39475</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-02</DATE>
|
||
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1944</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="21" 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-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-02</DATE>
|
||
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1944</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="22" 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-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-02</DATE>
|
||
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1944</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="23" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
wifi: mac80211: mesh: Fix leak of mesh_preq_queue objects
|
||
|
||
The hwmp code use objects of type mesh_preq_queue, added to a list in
|
||
ieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpath
|
||
gets deleted, ex mesh interface is removed, the entries in that list will
|
||
never get cleaned. Fix this by flushing all corresponding items of the
|
||
preq_queue in mesh_path_flush_pending().
|
||
|
||
This should take care of KASAN reports like this:
|
||
|
||
unreferenced object 0xffff00000668d800 (size 128):
|
||
comm "kworker/u8:4", pid 67, jiffies 4295419552 (age 1836.444s)
|
||
hex dump (first 32 bytes):
|
||
00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff ..........h.....
|
||
8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00 ....>...........
|
||
backtrace:
|
||
[<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c
|
||
[<00000000049bd418>] kmalloc_trace+0x34/0x80
|
||
[<0000000000d792bb>] mesh_queue_preq+0x44/0x2a8
|
||
[<00000000c99c3696>] mesh_nexthop_resolve+0x198/0x19c
|
||
[<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4
|
||
[<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764
|
||
[<000000005926ee38>] ieee80211_subif_start_xmit+0x9c/0x7a4
|
||
[<000000004c86e916>] dev_hard_start_xmit+0x174/0x440
|
||
[<0000000023495647>] __dev_queue_xmit+0xe24/0x111c
|
||
[<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4
|
||
[<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508
|
||
[<00000000adc3cd94>] process_one_work+0x4b8/0xa1c
|
||
[<00000000b36425d1>] worker_thread+0x9c/0x634
|
||
[<0000000005852dd5>] kthread+0x1bc/0x1c4
|
||
[<000000005fccd770>] ret_from_fork+0x10/0x20
|
||
unreferenced object 0xffff000009051f00 (size 128):
|
||
comm "kworker/u8:4", pid 67, jiffies 4295419553 (age 1836.440s)
|
||
hex dump (first 32 bytes):
|
||
90 d6 92 0d 00 00 ff ff 00 d8 68 06 00 00 ff ff ..........h.....
|
||
36 27 92 e4 02 e0 01 00 00 58 79 06 00 00 ff ff 6'.......Xy.....
|
||
backtrace:
|
||
[<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c
|
||
[<00000000049bd418>] kmalloc_trace+0x34/0x80
|
||
[<0000000000d792bb>] mesh_queue_preq+0x44/0x2a8
|
||
[<00000000c99c3696>] mesh_nexthop_resolve+0x198/0x19c
|
||
[<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4
|
||
[<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764
|
||
[<000000005926ee38>] ieee80211_subif_start_xmit+0x9c/0x7a4
|
||
[<000000004c86e916>] dev_hard_start_xmit+0x174/0x440
|
||
[<0000000023495647>] __dev_queue_xmit+0xe24/0x111c
|
||
[<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4
|
||
[<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508
|
||
[<00000000adc3cd94>] process_one_work+0x4b8/0xa1c
|
||
[<00000000b36425d1>] worker_thread+0x9c/0x634
|
||
[<0000000005852dd5>] kthread+0x1bc/0x1c4
|
||
[<000000005fccd770>] ret_from_fork+0x10/0x20</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-02</ReleaseDate>
|
||
<CVE>CVE-2024-40942</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-02</DATE>
|
||
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1944</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="24" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
ima: Avoid blocking in RCU read-side critical section
|
||
|
||
A panic happens in ima_match_policy:
|
||
|
||
BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
|
||
PGD 42f873067 P4D 0
|
||
Oops: 0000 [#1] SMP NOPTI
|
||
CPU: 5 PID: 1286325 Comm: kubeletmonit.sh
|
||
Kdump: loaded Tainted: P
|
||
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
|
||
BIOS 0.0.0 02/06/2015
|
||
RIP: 0010:ima_match_policy+0x84/0x450
|
||
Code: 49 89 fc 41 89 cf 31 ed 89 44 24 14 eb 1c 44 39
|
||
7b 18 74 26 41 83 ff 05 74 20 48 8b 1b 48 3b 1d
|
||
f2 b9 f4 00 0f 84 9c 01 00 00 <44> 85 73 10 74 ea
|
||
44 8b 6b 14 41 f6 c5 01 75 d4 41 f6 c5 02 74 0f
|
||
RSP: 0018:ff71570009e07a80 EFLAGS: 00010207
|
||
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000200
|
||
RDX: ffffffffad8dc7c0 RSI: 0000000024924925 RDI: ff3e27850dea2000
|
||
RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffffabfce739
|
||
R10: ff3e27810cc42400 R11: 0000000000000000 R12: ff3e2781825ef970
|
||
R13: 00000000ff3e2785 R14: 000000000000000c R15: 0000000000000001
|
||
FS: 00007f5195b51740(0000)
|
||
GS:ff3e278b12d40000(0000) knlGS:0000000000000000
|
||
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
||
CR2: 0000000000000010 CR3: 0000000626d24002 CR4: 0000000000361ee0
|
||
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
||
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
||
Call Trace:
|
||
ima_get_action+0x22/0x30
|
||
process_measurement+0xb0/0x830
|
||
? page_add_file_rmap+0x15/0x170
|
||
? alloc_set_pte+0x269/0x4c0
|
||
? prep_new_page+0x81/0x140
|
||
? simple_xattr_get+0x75/0xa0
|
||
? selinux_file_open+0x9d/0xf0
|
||
ima_file_check+0x64/0x90
|
||
path_openat+0x571/0x1720
|
||
do_filp_open+0x9b/0x110
|
||
? page_counter_try_charge+0x57/0xc0
|
||
? files_cgroup_alloc_fd+0x38/0x60
|
||
? __alloc_fd+0xd4/0x250
|
||
? do_sys_open+0x1bd/0x250
|
||
do_sys_open+0x1bd/0x250
|
||
do_syscall_64+0x5d/0x1d0
|
||
entry_SYSCALL_64_after_hwframe+0x65/0xca
|
||
|
||
Commit c7423dbdbc9e ("ima: Handle -ESTALE returned by
|
||
ima_filter_rule_match()") introduced call to ima_lsm_copy_rule within a
|
||
RCU read-side critical section which contains kmalloc with GFP_KERNEL.
|
||
This implies a possible sleep and violates limitations of RCU read-side
|
||
critical sections on non-PREEMPT systems.
|
||
|
||
Sleeping within RCU read-side critical section might cause
|
||
synchronize_rcu() returning early and break RCU protection, allowing a
|
||
UAF to happen.
|
||
|
||
The root cause of this issue could be described as follows:
|
||
| Thread A | Thread B |
|
||
| |ima_match_policy |
|
||
| | rcu_read_lock |
|
||
|ima_lsm_update_rule | |
|
||
| synchronize_rcu | |
|
||
| | kmalloc(GFP_KERNEL)|
|
||
| | sleep |
|
||
==> synchronize_rcu returns early
|
||
| kfree(entry) | |
|
||
| | entry = entry->next|
|
||
==> UAF happens and entry now becomes NULL (or could be anything).
|
||
| | entry->action |
|
||
==> Accessing entry might cause panic.
|
||
|
||
To fix this issue, we are converting all kmalloc that is called within
|
||
RCU read-side critical section to use GFP_ATOMIC.
|
||
|
||
[PM: fixed missing comment, long lines, !CONFIG_IMA_LSM_RULES case]</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-02</ReleaseDate>
|
||
<CVE>CVE-2024-40947</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-02</DATE>
|
||
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1944</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="25" 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-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-02</DATE>
|
||
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1944</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="26" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
scsi: qedi: Fix crash while reading debugfs attribute
|
||
|
||
The qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directly
|
||
on a __user pointer, which results into the crash.
|
||
|
||
To fix this issue, use a small local stack buffer for sprintf() and then
|
||
call simple_read_from_buffer(), which in turns make the copy_to_user()
|
||
call.
|
||
|
||
BUG: unable to handle page fault for address: 00007f4801111000
|
||
PGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0
|
||
Oops: 0002 [#1] PREEMPT SMP PTI
|
||
Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023
|
||
RIP: 0010:memcpy_orig+0xcd/0x130
|
||
RSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202
|
||
RAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f
|
||
RDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000
|
||
RBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572
|
||
R10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff
|
||
R13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af
|
||
FS: 00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000
|
||
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
||
CR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0
|
||
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
||
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
||
PKRU: 55555554
|
||
Call Trace:
|
||
<TASK>
|
||
? __die_body+0x1a/0x60
|
||
? page_fault_oops+0x183/0x510
|
||
? exc_page_fault+0x69/0x150
|
||
? asm_exc_page_fault+0x22/0x30
|
||
? memcpy_orig+0xcd/0x130
|
||
vsnprintf+0x102/0x4c0
|
||
sprintf+0x51/0x80
|
||
qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324]
|
||
full_proxy_read+0x50/0x80
|
||
vfs_read+0xa5/0x2e0
|
||
? folio_add_new_anon_rmap+0x44/0xa0
|
||
? set_pte_at+0x15/0x30
|
||
? do_pte_missing+0x426/0x7f0
|
||
ksys_read+0xa5/0xe0
|
||
do_syscall_64+0x58/0x80
|
||
? __count_memcg_events+0x46/0x90
|
||
? count_memcg_event_mm+0x3d/0x60
|
||
? handle_mm_fault+0x196/0x2f0
|
||
? do_user_addr_fault+0x267/0x890
|
||
? exc_page_fault+0x69/0x150
|
||
entry_SYSCALL_64_after_hwframe+0x72/0xdc
|
||
RIP: 0033:0x7f4800f20b4d</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-02</ReleaseDate>
|
||
<CVE>CVE-2024-40978</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: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-1944</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="27" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
batman-adv: bypass empty buckets in batadv_purge_orig_ref()
|
||
|
||
Many syzbot reports are pointing to soft lockups in
|
||
batadv_purge_orig_ref() [1]
|
||
|
||
Root cause is unknown, but we can avoid spending too much
|
||
time there and perhaps get more interesting reports.
|
||
|
||
[1]
|
||
|
||
watchdog: BUG: soft lockup - CPU#0 stuck for 27s! [kworker/u4:6:621]
|
||
Modules linked in:
|
||
irq event stamp: 6182794
|
||
hardirqs last enabled at (6182793): [<ffff8000801dae10>] __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386
|
||
hardirqs last disabled at (6182794): [<ffff80008ad66a78>] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]
|
||
hardirqs last disabled at (6182794): [<ffff80008ad66a78>] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551
|
||
softirqs last enabled at (6182792): [<ffff80008aab71c4>] spin_unlock_bh include/linux/spinlock.h:396 [inline]
|
||
softirqs last enabled at (6182792): [<ffff80008aab71c4>] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287
|
||
softirqs last disabled at (6182790): [<ffff80008aab61dc>] spin_lock_bh include/linux/spinlock.h:356 [inline]
|
||
softirqs last disabled at (6182790): [<ffff80008aab61dc>] batadv_purge_orig_ref+0x164/0x1228 net/batman-adv/originator.c:1271
|
||
CPU: 0 PID: 621 Comm: kworker/u4:6 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0
|
||
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
|
||
Workqueue: bat_events batadv_purge_orig
|
||
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
||
pc : should_resched arch/arm64/include/asm/preempt.h:79 [inline]
|
||
pc : __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:388
|
||
lr : __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386
|
||
sp : ffff800099007970
|
||
x29: ffff800099007980 x28: 1fffe00018fce1bd x27: dfff800000000000
|
||
x26: ffff0000d2620008 x25: ffff0000c7e70de8 x24: 0000000000000001
|
||
x23: 1fffe00018e57781 x22: dfff800000000000 x21: ffff80008aab71c4
|
||
x20: ffff0001b40136c0 x19: ffff0000c72bbc08 x18: 1fffe0001a817bb0
|
||
x17: ffff800125414000 x16: ffff80008032116c x15: 0000000000000001
|
||
x14: 1fffe0001ee9d610 x13: 0000000000000000 x12: 0000000000000003
|
||
x11: 0000000000000000 x10: 0000000000ff0100 x9 : 0000000000000000
|
||
x8 : 00000000005e5789 x7 : ffff80008aab61dc x6 : 0000000000000000
|
||
x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000
|
||
x2 : 0000000000000006 x1 : 0000000000000080 x0 : ffff800125414000
|
||
Call trace:
|
||
__daif_local_irq_enable arch/arm64/include/asm/irqflags.h:27 [inline]
|
||
arch_local_irq_enable arch/arm64/include/asm/irqflags.h:49 [inline]
|
||
__local_bh_enable_ip+0x228/0x44c kernel/softirq.c:386
|
||
__raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline]
|
||
_raw_spin_unlock_bh+0x3c/0x4c kernel/locking/spinlock.c:210
|
||
spin_unlock_bh include/linux/spinlock.h:396 [inline]
|
||
batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287
|
||
batadv_purge_orig+0x20/0x70 net/batman-adv/originator.c:1300
|
||
process_one_work+0x694/0x1204 kernel/workqueue.c:2633
|
||
process_scheduled_works kernel/workqueue.c:2706 [inline]
|
||
worker_thread+0x938/0xef4 kernel/workqueue.c:2787
|
||
kthread+0x288/0x310 kernel/kthread.c:388
|
||
ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860
|
||
Sending NMI from CPU 0 to CPUs 1:
|
||
NMI backtrace for cpu 1
|
||
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0
|
||
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
|
||
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
||
pc : arch_local_irq_enable+0x8/0xc arch/arm64/include/asm/irqflags.h:51
|
||
lr : default_idle_call+0xf8/0x128 kernel/sched/idle.c:103
|
||
sp : ffff800093a17d30
|
||
x29: ffff800093a17d30 x28: dfff800000000000 x27: 1ffff00012742fb4
|
||
x26: ffff80008ec9d000 x25: 0000000000000000 x24: 0000000000000002
|
||
x23: 1ffff00011d93a74 x22: ffff80008ec9d3a0 x21: 0000000000000000
|
||
x20: ffff0000c19dbc00 x19: ffff8000802d0fd8 x18: 1fffe00036804396
|
||
x17: ffff80008ec9d000 x16: ffff8000802d089c x15: 0000000000000001
|
||
---truncated---</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-02</ReleaseDate>
|
||
<CVE>CVE-2024-40981</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-02</DATE>
|
||
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1944</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="28" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
drm/radeon: fix UBSAN warning in kv_dpm.c
|
||
|
||
Adds bounds check for sumo_vid_mapping_entry.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-02</ReleaseDate>
|
||
<CVE>CVE-2024-40988</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-02</DATE>
|
||
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1944</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="29" 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-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-02</DATE>
|
||
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1944</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
</cvrfdoc> |