2697 lines
120 KiB
XML
2697 lines
120 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
|
|
<DocumentTitle xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-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-1994</ID>
|
|
</Identification>
|
|
<Status>Final</Status>
|
|
<Version>1.0</Version>
|
|
<RevisionHistory>
|
|
<Revision>
|
|
<Number>1.0</Number>
|
|
<Date>2024-08-16</Date>
|
|
<Description>Initial</Description>
|
|
</Revision>
|
|
</RevisionHistory>
|
|
<InitialReleaseDate>2024-08-16</InitialReleaseDate>
|
|
<CurrentReleaseDate>2024-08-16</CurrentReleaseDate>
|
|
<Generator>
|
|
<Engine>openEuler SA Tool V1.0</Engine>
|
|
<Date>2024-08-16</Date>
|
|
</Generator>
|
|
</DocumentTracking>
|
|
<DocumentNotes>
|
|
<Note Title="Synopsis" Type="General" Ordinal="1" xml:lang="en">kernel security update</Note>
|
|
<Note Title="Summary" Type="General" Ordinal="2" xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-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: core: Make do_proc_control() and do_proc_bulk() killable
|
|
|
|
The USBDEVFS_CONTROL and USBDEVFS_BULK ioctls invoke
|
|
usb_start_wait_urb(), which contains an uninterruptible wait with a
|
|
user-specified timeout value. If timeout value is very large and the
|
|
device being accessed does not respond in a reasonable amount of time,
|
|
the kernel will complain about "Task X blocked for more than N
|
|
seconds", as found in testing by syzbot:
|
|
|
|
INFO: task syz-executor.0:8700 blocked for more than 143 seconds.
|
|
Not tainted 5.14.0-rc7-syzkaller #0
|
|
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
|
|
task:syz-executor.0 state:D stack:23192 pid: 8700 ppid: 8455 flags:0x00004004
|
|
Call Trace:
|
|
context_switch kernel/sched/core.c:4681 [inline]
|
|
__schedule+0xc07/0x11f0 kernel/sched/core.c:5938
|
|
schedule+0x14b/0x210 kernel/sched/core.c:6017
|
|
schedule_timeout+0x98/0x2f0 kernel/time/timer.c:1857
|
|
do_wait_for_common+0x2da/0x480 kernel/sched/completion.c:85
|
|
__wait_for_common kernel/sched/completion.c:106 [inline]
|
|
wait_for_common kernel/sched/completion.c:117 [inline]
|
|
wait_for_completion_timeout+0x46/0x60 kernel/sched/completion.c:157
|
|
usb_start_wait_urb+0x167/0x550 drivers/usb/core/message.c:63
|
|
do_proc_bulk+0x978/0x1080 drivers/usb/core/devio.c:1236
|
|
proc_bulk drivers/usb/core/devio.c:1273 [inline]
|
|
usbdev_do_ioctl drivers/usb/core/devio.c:2547 [inline]
|
|
usbdev_ioctl+0x3441/0x6b10 drivers/usb/core/devio.c:2713
|
|
...
|
|
|
|
To fix this problem, this patch replaces usbfs's calls to
|
|
usb_control_msg() and usb_bulk_msg() with special-purpose code that
|
|
does essentially the same thing (as recommended in the comment for
|
|
usb_start_wait_urb()), except that it always uses a killable wait and
|
|
it uses GFP_KERNEL rather than GFP_NOIO.(CVE-2021-47582)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: mediatek: vcodec: Only free buffer VA that is not NULL
|
|
|
|
In the MediaTek vcodec driver, while mtk_vcodec_mem_free() is mostly
|
|
called only when the buffer to free exists, there are some instances
|
|
that didn't do the check and triggered warnings in practice.
|
|
|
|
We believe those checks were forgotten unintentionally. Add the checks
|
|
back to fix the warnings.(CVE-2023-52888)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
HID: core: remove unnecessary WARN_ON() in implement()
|
|
|
|
Syzkaller hit a warning [1] in a call to implement() when trying
|
|
to write a value into a field of smaller size in an output report.
|
|
|
|
Since implement() already has a warn message printed out with the
|
|
help of hid_warn() and value in question gets trimmed with:
|
|
...
|
|
value &= m;
|
|
...
|
|
WARN_ON may be considered superfluous. Remove it to suppress future
|
|
syzkaller triggers.
|
|
|
|
[1]
|
|
WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 implement drivers/hid/hid-core.c:1451 [inline]
|
|
WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863
|
|
Modules linked in:
|
|
CPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
|
|
RIP: 0010:implement drivers/hid/hid-core.c:1451 [inline]
|
|
RIP: 0010:hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863
|
|
...
|
|
Call Trace:
|
|
<TASK>
|
|
__usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [inline]
|
|
usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid-core.c:636
|
|
hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726
|
|
vfs_ioctl fs/ioctl.c:51 [inline]
|
|
__do_sys_ioctl fs/ioctl.c:904 [inline]
|
|
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
|
...(CVE-2024-39509)
|
|
|
|
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:
|
|
|
|
dmaengine: idxd: Fix possible Use-After-Free in irq_process_work_list
|
|
|
|
Use list_for_each_entry_safe() to allow iterating through the list and
|
|
deleting the entry in the iteration process. The descriptor is freed via
|
|
idxd_desc_complete() and there's a slight chance may cause issue for
|
|
the list iterator when the descriptor is reused by another thread
|
|
without it being deleted from the list.(CVE-2024-40956)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
RDMA/mlx5: Add check for srq max_sge attribute
|
|
|
|
max_sge attribute is passed by the user, and is inserted and used
|
|
unchecked, so verify that the value doesn't exceed maximum allowed value
|
|
before using it.(CVE-2024-40990)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
filelock: Remove locks reliably when fcntl/close race is detected
|
|
|
|
When fcntl_setlk() races with close(), it removes the created lock with
|
|
do_lock_file_wait().
|
|
However, LSMs can allow the first do_lock_file_wait() that created the lock
|
|
while denying the second do_lock_file_wait() that tries to remove the lock.
|
|
Separately, posix_lock_file() could also fail to
|
|
remove a lock due to GFP_KERNEL allocation failure (when splitting a range
|
|
in the middle).
|
|
|
|
After the bug has been triggered, use-after-free reads will occur in
|
|
lock_get_status() when userspace reads /proc/locks. This can likely be used
|
|
to read arbitrary kernel memory, but can't corrupt kernel memory.
|
|
|
|
Fix it by calling locks_remove_posix() instead, which is designed to
|
|
reliably get rid of POSIX locks associated with the given file and
|
|
files_struct and is also used by filp_flush().(CVE-2024-41012)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nilfs2: fix kernel bug on rename operation of broken directory
|
|
|
|
Syzbot reported that in rename directory operation on broken directory on
|
|
nilfs2, __block_write_begin_int() called to prepare block write may fail
|
|
BUG_ON check for access exceeding the folio/page size.
|
|
|
|
This is because nilfs_dotdot(), which gets parent directory reference
|
|
entry ("..") of the directory to be moved or renamed, does not check
|
|
consistency enough, and may return location exceeding folio/page size for
|
|
broken directories.
|
|
|
|
Fix this issue by checking required directory entries ("." and "..") in
|
|
the first chunk of the directory in nilfs_dotdot().(CVE-2024-41034)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor
|
|
|
|
Syzbot has identified a bug in usbcore (see the Closes: tag below)
|
|
caused by our assumption that the reserved bits in an endpoint
|
|
descriptor's bEndpointAddress field will always be 0. As a result of
|
|
the bug, the endpoint_is_duplicate() routine in config.c (and possibly
|
|
other routines as well) may believe that two descriptors are for
|
|
distinct endpoints, even though they have the same direction and
|
|
endpoint number. This can lead to confusion, including the bug
|
|
identified by syzbot (two descriptors with matching endpoint numbers
|
|
and directions, where one was interrupt and the other was bulk).
|
|
|
|
To fix the bug, we will clear the reserved bits in bEndpointAddress
|
|
when we parse the descriptor. (Note that both the USB-2.0 and USB-3.1
|
|
specs say these bits are "Reserved, reset to zero".) This requires us
|
|
to make a copy of the descriptor earlier in usb_parse_endpoint() and
|
|
use the copy instead of the original when checking for duplicates.(CVE-2024-41035)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nf_tables: prefer nft_chain_validate
|
|
|
|
nft_chain_validate already performs loop detection because a cycle will
|
|
result in a call stack overflow (ctx->level >= NFT_JUMP_STACK_SIZE).
|
|
|
|
It also follows maps via ->validate callback in nft_lookup, so there
|
|
appears no reason to iterate the maps again.
|
|
|
|
nf_tables_check_loops() and all its helper functions can be removed.
|
|
This improves ruleset load time significantly, from 23s down to 12s.
|
|
|
|
This also fixes a crash bug. Old loop detection code can result in
|
|
unbounded recursion:
|
|
|
|
BUG: TASK stack guard page was hit at ....
|
|
Oops: stack guard page: 0000 [#1] PREEMPT SMP KASAN
|
|
CPU: 4 PID: 1539 Comm: nft Not tainted 6.10.0-rc5+ #1
|
|
[..]
|
|
|
|
with a suitable ruleset during validation of register stores.
|
|
|
|
I can't see any actual reason to attempt to check for this from
|
|
nft_validate_register_store(), at this point the transaction is still in
|
|
progress, so we don't have a full picture of the rule graph.
|
|
|
|
For nf-next it might make sense to either remove it or make this depend
|
|
on table->validate_state in case we could catch an error earlier
|
|
(for improved error reporting to userspace).(CVE-2024-41042)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: ethernet: lantiq_etop: fix double free in detach
|
|
|
|
The number of the currently released descriptor is never incremented
|
|
which results in the same skb being released multiple times.(CVE-2024-41046)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
powerpc/pseries: Whitelist dtl slub object for copying to userspace
|
|
|
|
Reading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-*
|
|
results in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as
|
|
shown below.
|
|
|
|
kernel BUG at mm/usercopy.c:102!
|
|
Oops: Exception in kernel mode, sig: 5 [#1]
|
|
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
|
|
Modules linked in: xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc
|
|
scsi_transport_fc ibmveth pseries_wdt dm_multipath dm_mirror dm_region_hash dm_log dm_mod fuse
|
|
CPU: 27 PID: 1815 Comm: python3 Not tainted 6.10.0-rc3 #85
|
|
Hardware name: IBM,9040-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_042) hv:phyp pSeries
|
|
NIP: c0000000005d23d4 LR: c0000000005d23d0 CTR: 00000000006ee6f8
|
|
REGS: c000000120c078c0 TRAP: 0700 Not tainted (6.10.0-rc3)
|
|
MSR: 8000000000029033 <SF,EE,ME,IR,DR,RI,LE> CR: 2828220f XER: 0000000e
|
|
CFAR: c0000000001fdc80 IRQMASK: 0
|
|
[ ... GPRs omitted ... ]
|
|
NIP [c0000000005d23d4] usercopy_abort+0x78/0xb0
|
|
LR [c0000000005d23d0] usercopy_abort+0x74/0xb0
|
|
Call Trace:
|
|
usercopy_abort+0x74/0xb0 (unreliable)
|
|
__check_heap_object+0xf8/0x120
|
|
check_heap_object+0x218/0x240
|
|
__check_object_size+0x84/0x1a4
|
|
dtl_file_read+0x17c/0x2c4
|
|
full_proxy_read+0x8c/0x110
|
|
vfs_read+0xdc/0x3a0
|
|
ksys_read+0x84/0x144
|
|
system_call_exception+0x124/0x330
|
|
system_call_vectored_common+0x15c/0x2ec
|
|
--- interrupt: 3000 at 0x7fff81f3ab34
|
|
|
|
Commit 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0")
|
|
requires that only whitelisted areas in slab/slub objects can be copied to
|
|
userspace when usercopy hardening is enabled using CONFIG_HARDENED_USERCOPY.
|
|
Dtl contains hypervisor dispatch events which are expected to be read by
|
|
privileged users. Hence mark this safe for user access.
|
|
Specify useroffset=0 and usersize=DISPATCH_LOG_BYTES to whitelist the
|
|
entire object.(CVE-2024-41065)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
btrfs: qgroup: fix quota root leak after quota disable failure
|
|
|
|
If during the quota disable we fail when cleaning the quota tree or when
|
|
deleting the root from the root tree, we jump to the 'out' label without
|
|
ever dropping the reference on the quota root, resulting in a leak of the
|
|
root since fs_info->quota_root is no longer pointing to the root (we have
|
|
set it to NULL just before those steps).
|
|
|
|
Fix this by always doing a btrfs_put_root() call under the 'out' label.
|
|
This is a problem that exists since qgroups were first added in 2012 by
|
|
commit bed92eae26cc ("Btrfs: qgroup implementation and prototypes"), but
|
|
back then we missed a kfree on the quota root and free_extent_buffer()
|
|
calls on its root and commit root nodes, since back then roots were not
|
|
yet reference counted.(CVE-2024-41078)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/i915/gt: Fix potential UAF by revoke of fence registers
|
|
|
|
CI has been sporadically reporting the following issue triggered by
|
|
igt@i915_selftest@live@hangcheck on ADL-P and similar machines:
|
|
|
|
<6> [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence
|
|
...
|
|
<6> [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled
|
|
<6> [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled
|
|
<3> [414.070354] Unable to pin Y-tiled fence; err:-4
|
|
<3> [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&fence->active))
|
|
...
|
|
<4>[ 609.603992] ------------[ cut here ]------------
|
|
<2>[ 609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301!
|
|
<4>[ 609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
|
|
<4>[ 609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G U W 6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1
|
|
<4>[ 609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023
|
|
<4>[ 609.604010] Workqueue: i915 __i915_gem_free_work [i915]
|
|
<4>[ 609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915]
|
|
...
|
|
<4>[ 609.604271] Call Trace:
|
|
<4>[ 609.604273] <TASK>
|
|
...
|
|
<4>[ 609.604716] __i915_vma_evict+0x2e9/0x550 [i915]
|
|
<4>[ 609.604852] __i915_vma_unbind+0x7c/0x160 [i915]
|
|
<4>[ 609.604977] force_unbind+0x24/0xa0 [i915]
|
|
<4>[ 609.605098] i915_vma_destroy+0x2f/0xa0 [i915]
|
|
<4>[ 609.605210] __i915_gem_object_pages_fini+0x51/0x2f0 [i915]
|
|
<4>[ 609.605330] __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915]
|
|
<4>[ 609.605440] process_scheduled_works+0x351/0x690
|
|
...
|
|
|
|
In the past, there were similar failures reported by CI from other IGT
|
|
tests, observed on other platforms.
|
|
|
|
Before commit 63baf4f3d587 ("drm/i915/gt: Only wait for GPU activity
|
|
before unbinding a GGTT fence"), i915_vma_revoke_fence() was waiting for
|
|
idleness of vma->active via fence_update(). That commit introduced
|
|
vma->fence->active in order for the fence_update() to be able to wait
|
|
selectively on that one instead of vma->active since only idleness of
|
|
fence registers was needed. But then, another commit 0d86ee35097a
|
|
("drm/i915/gt: Make fence revocation unequivocal") replaced the call to
|
|
fence_update() in i915_vma_revoke_fence() with only fence_write(), and
|
|
also added that GEM_BUG_ON(!i915_active_is_idle(&fence->active)) in front.
|
|
No justification was provided on why we might then expect idleness of
|
|
vma->fence->active without first waiting on it.
|
|
|
|
The issue can be potentially caused by a race among revocation of fence
|
|
registers on one side and sequential execution of signal callbacks invoked
|
|
on completion of a request that was using them on the other, still
|
|
processed in parallel to revocation of those fence registers. Fix it by
|
|
waiting for idleness of vma->fence->active in i915_vma_revoke_fence().
|
|
|
|
(cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1)(CVE-2024-41092)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep
|
|
|
|
The ilitek-ili9881c controls the reset GPIO using the non-sleeping
|
|
gpiod_set_value() function. This complains loudly when the GPIO
|
|
controller needs to sleep. As the caller can sleep, use
|
|
gpiod_set_value_cansleep() to fix the issue.(CVE-2024-42087)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
serial: 8250_omap: Implementation of Errata i2310
|
|
|
|
As per Errata i2310[0], Erroneous timeout can be triggered,
|
|
if this Erroneous interrupt is not cleared then it may leads
|
|
to storm of interrupts, therefore apply Errata i2310 solution.
|
|
|
|
[0] https://www.ti.com/lit/pdf/sprz536 page 23(CVE-2024-42095)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
x86: stop playing stack games in profile_pc()
|
|
|
|
The 'profile_pc()' function is used for timer-based profiling, which
|
|
isn't really all that relevant any more to begin with, but it also ends
|
|
up making assumptions based on the stack layout that aren't necessarily
|
|
valid.
|
|
|
|
Basically, the code tries to account the time spent in spinlocks to the
|
|
caller rather than the spinlock, and while I support that as a concept,
|
|
it's not worth the code complexity or the KASAN warnings when no serious
|
|
profiling is done using timers anyway these days.
|
|
|
|
And the code really does depend on stack layout that is only true in the
|
|
simplest of cases. We've lost the comment at some point (I think when
|
|
the 32-bit and 64-bit code was unified), but it used to say:
|
|
|
|
Assume the lock function has either no stack frame or a copy
|
|
of eflags from PUSHF.
|
|
|
|
which explains why it just blindly loads a word or two straight off the
|
|
stack pointer and then takes a minimal look at the values to just check
|
|
if they might be eflags or the return pc:
|
|
|
|
Eflags always has bits 22 and up cleared unlike kernel addresses
|
|
|
|
but that basic stack layout assumption assumes that there isn't any lock
|
|
debugging etc going on that would complicate the code and cause a stack
|
|
frame.
|
|
|
|
It causes KASAN unhappiness reported for years by syzkaller [1] and
|
|
others [2].
|
|
|
|
With no real practical reason for this any more, just remove the code.
|
|
|
|
Just for historical interest, here's some background commits relating to
|
|
this code from 2006:
|
|
|
|
0cb91a229364 ("i386: Account spinlocks to the caller during profiling for !FP kernels")
|
|
31679f38d886 ("Simplify profile_pc on x86-64")
|
|
|
|
and a code unification from 2009:
|
|
|
|
ef4512882dbe ("x86: time_32/64.c unify profile_pc")
|
|
|
|
but the basics of this thing actually goes back to before the git tree.(CVE-2024-42096)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
crypto: ecdh - explicitly zeroize private_key
|
|
|
|
private_key is overwritten with the key parameter passed in by the
|
|
caller (if present), or alternatively a newly generated private key.
|
|
However, it is possible that the caller provides a key (or the newly
|
|
generated key) which is shorter than the previous key. In that
|
|
scenario, some key material from the previous key would not be
|
|
overwritten. The easiest solution is to explicitly zeroize the entire
|
|
private_key array first.
|
|
|
|
Note that this patch slightly changes the behavior of this function:
|
|
previously, if the ecc_gen_privkey failed, the old private_key would
|
|
remain. Now, the private_key is always zeroized. This behavior is
|
|
consistent with the case where params.key is set and ecc_is_key_valid
|
|
fails.(CVE-2024-42098)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nilfs2: fix inode number range checks
|
|
|
|
Patch series "nilfs2: fix potential issues related to reserved inodes".
|
|
|
|
This series fixes one use-after-free issue reported by syzbot, caused by
|
|
nilfs2's internal inode being exposed in the namespace on a corrupted
|
|
filesystem, and a couple of flaws that cause problems if the starting
|
|
number of non-reserved inodes written in the on-disk super block is
|
|
intentionally (or corruptly) changed from its default value.
|
|
|
|
|
|
This patch (of 3):
|
|
|
|
In the current implementation of nilfs2, "nilfs->ns_first_ino", which
|
|
gives the first non-reserved inode number, is read from the superblock,
|
|
but its lower limit is not checked.
|
|
|
|
As a result, if a number that overlaps with the inode number range of
|
|
reserved inodes such as the root directory or metadata files is set in the
|
|
super block parameter, the inode number test macros (NILFS_MDT_INODE and
|
|
NILFS_VALID_INODE) will not function properly.
|
|
|
|
In addition, these test macros use left bit-shift calculations using with
|
|
the inode number as the shift count via the BIT macro, but the result of a
|
|
shift calculation that exceeds the bit width of an integer is undefined in
|
|
the C specification, so if "ns_first_ino" is set to a large value other
|
|
than the default value NILFS_USER_INO (=11), the macros may potentially
|
|
malfunction depending on the environment.
|
|
|
|
Fix these issues by checking the lower bound of "nilfs->ns_first_ino" and
|
|
by preventing bit shifts equal to or greater than the NILFS_USER_INO
|
|
constant in the inode number test macros.
|
|
|
|
Also, change the type of "ns_first_ino" from signed integer to unsigned
|
|
integer to avoid the need for type casting in comparisons such as the
|
|
lower bound check introduced this time.(CVE-2024-42105)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM values
|
|
|
|
syzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUM
|
|
to 2^31.
|
|
|
|
We had a similar issue in sch_fq, fixed with commit
|
|
d9e15a273306 ("pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM")
|
|
|
|
watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24]
|
|
Modules linked in:
|
|
irq event stamp: 131135
|
|
hardirqs last enabled at (131134): [<ffff80008ae8778c>] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline]
|
|
hardirqs last enabled at (131134): [<ffff80008ae8778c>] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95
|
|
hardirqs last disabled at (131135): [<ffff80008ae85378>] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]
|
|
hardirqs last disabled at (131135): [<ffff80008ae85378>] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551
|
|
softirqs last enabled at (125892): [<ffff80008907e82c>] neigh_hh_init net/core/neighbour.c:1538 [inline]
|
|
softirqs last enabled at (125892): [<ffff80008907e82c>] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553
|
|
softirqs last disabled at (125896): [<ffff80008904166c>] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19
|
|
CPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
|
|
Workqueue: mld mld_ifc_work
|
|
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
|
pc : __list_del include/linux/list.h:195 [inline]
|
|
pc : __list_del_entry include/linux/list.h:218 [inline]
|
|
pc : list_move_tail include/linux/list.h:310 [inline]
|
|
pc : fq_tin_dequeue include/net/fq_impl.h:112 [inline]
|
|
pc : ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854
|
|
lr : __list_del_entry include/linux/list.h:218 [inline]
|
|
lr : list_move_tail include/linux/list.h:310 [inline]
|
|
lr : fq_tin_dequeue include/net/fq_impl.h:112 [inline]
|
|
lr : ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854
|
|
sp : ffff800093d36700
|
|
x29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000
|
|
x26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0
|
|
x23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0
|
|
x20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0
|
|
x17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8
|
|
x14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffff
|
|
x11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000
|
|
x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
|
|
x5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fc
|
|
x2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470
|
|
Call trace:
|
|
__list_del include/linux/list.h:195 [inline]
|
|
__list_del_entry include/linux/list.h:218 [inline]
|
|
list_move_tail include/linux/list.h:310 [inline]
|
|
fq_tin_dequeue include/net/fq_impl.h:112 [inline]
|
|
ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854
|
|
wake_tx_push_queue net/mac80211/util.c:294 [inline]
|
|
ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315
|
|
drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [inline]
|
|
schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [inline]
|
|
ieee80211_queue_skb+0x18e8/0x2244 net/mac80211/tx.c:1664
|
|
ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966
|
|
ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062
|
|
__ieee80211_subif_start_xmit+0xab8/0x122c net/mac80211/tx.c:4338
|
|
ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532
|
|
__netdev_start_xmit include/linux/netdevice.h:4903 [inline]
|
|
netdev_start_xmit include/linux/netdevice.h:4917 [inline]
|
|
xmit_one net/core/dev.c:3531 [inline]
|
|
dev_hard_start_xmit+0x27c/0x938 net/core/dev.c:3547
|
|
__dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341
|
|
dev_queue_xmit include/linux/netdevice.h:3091 [inline]
|
|
neigh_resolve_output+0x558/0x658 net/core/neighbour.c:1563
|
|
neigh_output include/net/neighbour.h:542 [inline]
|
|
ip6_fini
|
|
---truncated---(CVE-2024-42114)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
powerpc: Avoid nmi_enter/nmi_exit in real mode interrupt.
|
|
|
|
nmi_enter()/nmi_exit() touches per cpu variables which can lead to kernel
|
|
crash when invoked during real mode interrupt handling (e.g. early HMI/MCE
|
|
interrupt handler) if percpu allocation comes from vmalloc area.
|
|
|
|
Early HMI/MCE handlers are called through DEFINE_INTERRUPT_HANDLER_NMI()
|
|
wrapper which invokes nmi_enter/nmi_exit calls. We don't see any issue when
|
|
percpu allocation is from the embedded first chunk. However with
|
|
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK enabled there are chances where percpu
|
|
allocation can come from the vmalloc area.
|
|
|
|
With kernel command line "percpu_alloc=page" we can force percpu allocation
|
|
to come from vmalloc area and can see kernel crash in machine_check_early:
|
|
|
|
[ 1.215714] NIP [c000000000e49eb4] rcu_nmi_enter+0x24/0x110
|
|
[ 1.215717] LR [c0000000000461a0] machine_check_early+0xf0/0x2c0
|
|
[ 1.215719] --- interrupt: 200
|
|
[ 1.215720] [c000000fffd73180] [0000000000000000] 0x0 (unreliable)
|
|
[ 1.215722] [c000000fffd731b0] [0000000000000000] 0x0
|
|
[ 1.215724] [c000000fffd73210] [c000000000008364] machine_check_early_common+0x134/0x1f8
|
|
|
|
Fix this by avoiding use of nmi_enter()/nmi_exit() in real mode if percpu
|
|
first chunk is not embedded.(CVE-2024-42126)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
leds: an30259a: Use devm_mutex_init() for mutex initialization
|
|
|
|
In this driver LEDs are registered using devm_led_classdev_register()
|
|
so they are automatically unregistered after module's remove() is done.
|
|
led_classdev_unregister() calls module's led_set_brightness() to turn off
|
|
the LEDs and that callback uses mutex which was destroyed already
|
|
in module's remove() so use devm API instead.(CVE-2024-42128)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
orangefs: fix out-of-bounds fsid access
|
|
|
|
Arnd Bergmann sent a patch to fsdevel, he says:
|
|
|
|
"orangefs_statfs() copies two consecutive fields of the superblock into
|
|
the statfs structure, which triggers a warning from the string fortification
|
|
helpers"
|
|
|
|
Jan Kara suggested an alternate way to do the patch to make it more readable.
|
|
|
|
I ran both ideas through xfstests and both seem fine. This patch
|
|
is based on Jan Kara's suggestion.(CVE-2024-42143)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
bnx2x: Fix multiple UBSAN array-index-out-of-bounds
|
|
|
|
Fix UBSAN warnings that occur when using a system with 32 physical
|
|
cpu cores or more, or when the user defines a number of Ethernet
|
|
queues greater than or equal to FP_SB_MAX_E1x using the num_queues
|
|
module parameter.
|
|
|
|
Currently there is a read/write out of bounds that occurs on the array
|
|
"struct stats_query_entry query" present inside the "bnx2x_fw_stats_req"
|
|
struct in "drivers/net/ethernet/broadcom/bnx2x/bnx2x.h".
|
|
Looking at the definition of the "struct stats_query_entry query" array:
|
|
|
|
struct stats_query_entry query[FP_SB_MAX_E1x+
|
|
BNX2X_FIRST_QUEUE_QUERY_IDX];
|
|
|
|
FP_SB_MAX_E1x is defined as the maximum number of fast path interrupts and
|
|
has a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3
|
|
meaning the array has a total size of 19.
|
|
Since accesses to "struct stats_query_entry query" are offset-ted by
|
|
BNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernet
|
|
queues should not exceed FP_SB_MAX_E1x (16). However one of these queues
|
|
is reserved for FCOE and thus the number of Ethernet queues should be set
|
|
to [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) if
|
|
it is not.
|
|
|
|
This is also described in a comment in the source code in
|
|
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definition
|
|
of FP_SB_MAX_E1x. Below is the part of this explanation that it important
|
|
for this patch
|
|
|
|
/*
|
|
* The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is
|
|
* control by the number of fast-path status blocks supported by the
|
|
* device (HW/FW). Each fast-path status block (FP-SB) aka non-default
|
|
* status block represents an independent interrupts context that can
|
|
* serve a regular L2 networking queue. However special L2 queues such
|
|
* as the FCoE queue do not require a FP-SB and other components like
|
|
* the CNIC may consume FP-SB reducing the number of possible L2 queues
|
|
*
|
|
* If the maximum number of FP-SB available is X then:
|
|
* a. If CNIC is supported it consumes 1 FP-SB thus the max number of
|
|
* regular L2 queues is Y=X-1
|
|
* b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor)
|
|
* c. If the FCoE L2 queue is supported the actual number of L2 queues
|
|
* is Y+1
|
|
* d. The number of irqs (MSIX vectors) is either Y+1 (one extra for
|
|
* slow-path interrupts) or Y+2 if CNIC is supported (one additional
|
|
* FP interrupt context for the CNIC).
|
|
* e. The number of HW context (CID count) is always X or X+1 if FCoE
|
|
* L2 queue is supported. The cid for the FCoE L2 queue is always X.
|
|
*/
|
|
|
|
However this driver also supports NICs that use the E2 controller which can
|
|
handle more queues due to having more FP-SB represented by FP_SB_MAX_E2.
|
|
Looking at the commits when the E2 support was added, it was originally
|
|
using the E1x parameters: commit f2e0899f0f27 ("bnx2x: Add 57712 support").
|
|
Back then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driver
|
|
was later updated to take full advantage of the E2 instead of having it be
|
|
limited to the capabilities of the E1x. But as far as we can tell, the
|
|
array "stats_query_entry query" was still limited to using the FP-SB
|
|
available to the E1x cards as part of an oversignt when the driver was
|
|
updated to take full advantage of the E2, and now with the driver being
|
|
aware of the greater queue size supported by E2 NICs, it causes the UBSAN
|
|
warnings seen in the stack traces below.
|
|
|
|
This patch increases the size of the "stats_query_entry query" array by
|
|
replacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handle
|
|
both types of NICs.
|
|
|
|
Stack traces:
|
|
|
|
UBSAN: array-index-out-of-bounds in
|
|
drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11
|
|
index 20 is out of range for type 'stats_query_entry [19]'
|
|
CPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic
|
|
#202405052133
|
|
Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360
|
|
---truncated---(CVE-2024-42148)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tcp_metrics: validate source addr length
|
|
|
|
I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4
|
|
is at least 4 bytes long, and the policy doesn't have an entry
|
|
for this attribute at all (neither does it for IPv6 but v6 is
|
|
manually validated).(CVE-2024-42154)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
s390/pkey: Wipe copies of clear-key structures on failure
|
|
|
|
Wipe all sensitive data from stack for all IOCTLs, which convert a
|
|
clear-key into a protected- or secure-key.(CVE-2024-42156)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
s390/pkey: Wipe sensitive data on failure
|
|
|
|
Wipe sensitive data from stack also if the copy_to_user() fails.(CVE-2024-42157)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
s390/pkey: Use kfree_sensitive() to fix Coccinelle warnings
|
|
|
|
Replace memzero_explicit() and kfree() with kfree_sensitive() to fix
|
|
warnings reported by Coccinelle:
|
|
|
|
WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1506)
|
|
WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1643)
|
|
WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1770)(CVE-2024-42158)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: dvb-frontends: tda10048: Fix integer overflow
|
|
|
|
state->xtal_hz can be up to 16M, so it can overflow a 32 bit integer
|
|
when multiplied by pll_mfactor.
|
|
|
|
Create a new 64 bit variable to hold the calculations.(CVE-2024-42223)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: mt76: replace skb_put with skb_put_zero
|
|
|
|
Avoid potentially reusing uninitialized data(CVE-2024-42225)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
crypto: aead,cipher - zeroize key buffer after use
|
|
|
|
I.G 9.7.B for FIPS 140-3 specifies that variables temporarily holding
|
|
cryptographic information should be zeroized once they are no longer
|
|
needed. Accomplish this by using kfree_sensitive for buffers that
|
|
previously held the private key.(CVE-2024-42229)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
USB: serial: mos7840: fix crash on resume
|
|
|
|
Since commit c49cfa917025 ("USB: serial: use generic method if no
|
|
alternative is provided in usb serial layer"), USB serial core calls the
|
|
generic resume implementation when the driver has not provided one.
|
|
|
|
This can trigger a crash on resume with mos7840 since support for
|
|
multiple read URBs was added back in 2011. Specifically, both port read
|
|
URBs are now submitted on resume for open ports, but the context pointer
|
|
of the second URB is left set to the core rather than mos7840 port
|
|
structure.
|
|
|
|
Fix this by implementing dedicated suspend and resume functions for
|
|
mos7840.
|
|
|
|
Tested with Delock 87414 USB 2.0 to 4x serial adapter.
|
|
|
|
[ johan: analyse crash and rewrite commit message; set busy flag on
|
|
resume; drop bulk-in check; drop unnecessary usb_kill_urb() ](CVE-2024-42244)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket
|
|
|
|
When using a BPF program on kernel_connect(), the call can return -EPERM. This
|
|
causes xs_tcp_setup_socket() to loop forever, filling up the syslog and causing
|
|
the kernel to potentially freeze up.
|
|
|
|
Neil suggested:
|
|
|
|
This will propagate -EPERM up into other layers which might not be ready
|
|
to handle it. It might be safer to map EPERM to an error we would be more
|
|
likely to expect from the network system - such as ECONNREFUSED or ENETDOWN.
|
|
|
|
ECONNREFUSED as error seems reasonable. For programs setting a different error
|
|
can be out of reach (see handling in 4fbac77d2d09) in particular on kernels
|
|
which do not have f10d05966196 ("bpf: Make BPF_PROG_RUN_ARRAY return -err
|
|
instead of allow boolean"), thus given that it is better to simply remap for
|
|
consistent behavior. UDP does handle EPERM in xs_udp_send_request().(CVE-2024-42246)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wireguard: allowedips: avoid unaligned 64-bit memory accesses
|
|
|
|
On the parisc platform, the kernel issues kernel warnings because
|
|
swap_endian() tries to load a 128-bit IPv6 address from an unaligned
|
|
memory location:
|
|
|
|
Kernel: unaligned access to 0x55f4688c in wg_allowedips_insert_v6+0x2c/0x80 [wireguard] (iir 0xf3010df)
|
|
Kernel: unaligned access to 0x55f46884 in wg_allowedips_insert_v6+0x38/0x80 [wireguard] (iir 0xf2010dc)
|
|
|
|
Avoid such unaligned memory accesses by instead using the
|
|
get_unaligned_be64() helper macro.
|
|
|
|
[Jason: replace src[8] in original patch with src+8](CVE-2024-42247)</Note>
|
|
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP4.
|
|
|
|
openEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.</Note>
|
|
<Note Title="Severity" Type="General" Ordinal="5" xml:lang="en">High</Note>
|
|
<Note Title="Affected Component" Type="General" Ordinal="6" xml:lang="en">kernel</Note>
|
|
</DocumentNotes>
|
|
<DocumentReferences>
|
|
<Reference Type="Self">
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2021-47582</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-52888</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39509</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-40956</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40990</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41012</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41034</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41035</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41042</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41046</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41065</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41078</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41092</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42087</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42095</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42096</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42098</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42105</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42114</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42126</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42128</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42143</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42148</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42154</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42156</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42157</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42158</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42223</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42225</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42229</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42244</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42246</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42247</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47582</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52888</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39509</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40942</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40956</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40990</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41012</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41034</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41035</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41042</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41046</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41065</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41078</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41092</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42087</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42095</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42096</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42098</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42105</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42114</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42126</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42128</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42143</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42148</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42154</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42156</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42157</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42158</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42223</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42225</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42229</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42244</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42246</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42247</URL>
|
|
</Reference>
|
|
</DocumentReferences>
|
|
<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
|
|
<Branch Type="Product Name" Name="openEuler">
|
|
<FullProductName ProductID="openEuler-22.03-LTS-SP4" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">openEuler-22.03-LTS-SP4</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="bpftool-5.10.0-223.0.0.122" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">bpftool-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-5.10.0-223.0.0.122" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">bpftool-debuginfo-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-5.10.0-223.0.0.122" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-223.0.0.122" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-debuginfo-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-223.0.0.122" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-debugsource-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-223.0.0.122" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-devel-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-223.0.0.122" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-headers-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-223.0.0.122" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-source-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-223.0.0.122" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-tools-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-223.0.0.122" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-tools-debuginfo-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-223.0.0.122" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-tools-devel-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-223.0.0.122" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">perf-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-223.0.0.122" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">perf-debuginfo-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-223.0.0.122" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">python3-perf-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-223.0.0.122" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">python3-perf-debuginfo-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="bpftool-5.10.0-223.0.0.122" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">bpftool-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-5.10.0-223.0.0.122" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">bpftool-debuginfo-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-5.10.0-223.0.0.122" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-223.0.0.122" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-debuginfo-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-223.0.0.122" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-debugsource-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-223.0.0.122" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-devel-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-223.0.0.122" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-headers-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-223.0.0.122" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-source-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-223.0.0.122" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-tools-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-223.0.0.122" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-tools-debuginfo-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-223.0.0.122" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-tools-devel-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-223.0.0.122" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">perf-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-223.0.0.122" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">perf-debuginfo-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-223.0.0.122" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">python3-perf-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-223.0.0.122" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">python3-perf-debuginfo-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-5.10.0-223.0.0.122" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP4">kernel-5.10.0-223.0.0.122.oe2203sp4.src.rpm</FullProductName>
|
|
</Branch>
|
|
</ProductTree>
|
|
<Vulnerability Ordinal="1" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
USB: core: Make do_proc_control() and do_proc_bulk() killable
|
|
|
|
The USBDEVFS_CONTROL and USBDEVFS_BULK ioctls invoke
|
|
usb_start_wait_urb(), which contains an uninterruptible wait with a
|
|
user-specified timeout value. If timeout value is very large and the
|
|
device being accessed does not respond in a reasonable amount of time,
|
|
the kernel will complain about "Task X blocked for more than N
|
|
seconds", as found in testing by syzbot:
|
|
|
|
INFO: task syz-executor.0:8700 blocked for more than 143 seconds.
|
|
Not tainted 5.14.0-rc7-syzkaller #0
|
|
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
|
|
task:syz-executor.0 state:D stack:23192 pid: 8700 ppid: 8455 flags:0x00004004
|
|
Call Trace:
|
|
context_switch kernel/sched/core.c:4681 [inline]
|
|
__schedule+0xc07/0x11f0 kernel/sched/core.c:5938
|
|
schedule+0x14b/0x210 kernel/sched/core.c:6017
|
|
schedule_timeout+0x98/0x2f0 kernel/time/timer.c:1857
|
|
do_wait_for_common+0x2da/0x480 kernel/sched/completion.c:85
|
|
__wait_for_common kernel/sched/completion.c:106 [inline]
|
|
wait_for_common kernel/sched/completion.c:117 [inline]
|
|
wait_for_completion_timeout+0x46/0x60 kernel/sched/completion.c:157
|
|
usb_start_wait_urb+0x167/0x550 drivers/usb/core/message.c:63
|
|
do_proc_bulk+0x978/0x1080 drivers/usb/core/devio.c:1236
|
|
proc_bulk drivers/usb/core/devio.c:1273 [inline]
|
|
usbdev_do_ioctl drivers/usb/core/devio.c:2547 [inline]
|
|
usbdev_ioctl+0x3441/0x6b10 drivers/usb/core/devio.c:2713
|
|
...
|
|
|
|
To fix this problem, this patch replaces usbfs's calls to
|
|
usb_control_msg() and usb_bulk_msg() with special-purpose code that
|
|
does essentially the same thing (as recommended in the comment for
|
|
usb_start_wait_urb()), except that it always uses a killable wait and
|
|
it uses GFP_KERNEL rather than GFP_NOIO.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2021-47582</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="2" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: mediatek: vcodec: Only free buffer VA that is not NULL
|
|
|
|
In the MediaTek vcodec driver, while mtk_vcodec_mem_free() is mostly
|
|
called only when the buffer to free exists, there are some instances
|
|
that didn't do the check and triggered warnings in practice.
|
|
|
|
We believe those checks were forgotten unintentionally. Add the checks
|
|
back to fix the warnings.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2023-52888</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="3" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
HID: core: remove unnecessary WARN_ON() in implement()
|
|
|
|
Syzkaller hit a warning [1] in a call to implement() when trying
|
|
to write a value into a field of smaller size in an output report.
|
|
|
|
Since implement() already has a warn message printed out with the
|
|
help of hid_warn() and value in question gets trimmed with:
|
|
...
|
|
value &= m;
|
|
...
|
|
WARN_ON may be considered superfluous. Remove it to suppress future
|
|
syzkaller triggers.
|
|
|
|
[1]
|
|
WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 implement drivers/hid/hid-core.c:1451 [inline]
|
|
WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863
|
|
Modules linked in:
|
|
CPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
|
|
RIP: 0010:implement drivers/hid/hid-core.c:1451 [inline]
|
|
RIP: 0010:hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863
|
|
...
|
|
Call Trace:
|
|
<TASK>
|
|
__usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [inline]
|
|
usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid-core.c:636
|
|
hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726
|
|
vfs_ioctl fs/ioctl.c:51 [inline]
|
|
__do_sys_ioctl fs/ioctl.c:904 [inline]
|
|
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
|
...</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-39509</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="4" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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-16</ReleaseDate>
|
|
<CVE>CVE-2024-40942</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="5" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
dmaengine: idxd: Fix possible Use-After-Free in irq_process_work_list
|
|
|
|
Use list_for_each_entry_safe() to allow iterating through the list and
|
|
deleting the entry in the iteration process. The descriptor is freed via
|
|
idxd_desc_complete() and there's a slight chance may cause issue for
|
|
the list iterator when the descriptor is reused by another thread
|
|
without it being deleted from the list.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-40956</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="6" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
RDMA/mlx5: Add check for srq max_sge attribute
|
|
|
|
max_sge attribute is passed by the user, and is inserted and used
|
|
unchecked, so verify that the value doesn't exceed maximum allowed value
|
|
before using it.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-40990</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="7" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
filelock: Remove locks reliably when fcntl/close race is detected
|
|
|
|
When fcntl_setlk() races with close(), it removes the created lock with
|
|
do_lock_file_wait().
|
|
However, LSMs can allow the first do_lock_file_wait() that created the lock
|
|
while denying the second do_lock_file_wait() that tries to remove the lock.
|
|
Separately, posix_lock_file() could also fail to
|
|
remove a lock due to GFP_KERNEL allocation failure (when splitting a range
|
|
in the middle).
|
|
|
|
After the bug has been triggered, use-after-free reads will occur in
|
|
lock_get_status() when userspace reads /proc/locks. This can likely be used
|
|
to read arbitrary kernel memory, but can't corrupt kernel memory.
|
|
|
|
Fix it by calling locks_remove_posix() instead, which is designed to
|
|
reliably get rid of POSIX locks associated with the given file and
|
|
files_struct and is also used by filp_flush().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-41012</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.3</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="8" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nilfs2: fix kernel bug on rename operation of broken directory
|
|
|
|
Syzbot reported that in rename directory operation on broken directory on
|
|
nilfs2, __block_write_begin_int() called to prepare block write may fail
|
|
BUG_ON check for access exceeding the folio/page size.
|
|
|
|
This is because nilfs_dotdot(), which gets parent directory reference
|
|
entry ("..") of the directory to be moved or renamed, does not check
|
|
consistency enough, and may return location exceeding folio/page size for
|
|
broken directories.
|
|
|
|
Fix this issue by checking required directory entries ("." and "..") in
|
|
the first chunk of the directory in nilfs_dotdot().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-41034</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="9" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor
|
|
|
|
Syzbot has identified a bug in usbcore (see the Closes: tag below)
|
|
caused by our assumption that the reserved bits in an endpoint
|
|
descriptor's bEndpointAddress field will always be 0. As a result of
|
|
the bug, the endpoint_is_duplicate() routine in config.c (and possibly
|
|
other routines as well) may believe that two descriptors are for
|
|
distinct endpoints, even though they have the same direction and
|
|
endpoint number. This can lead to confusion, including the bug
|
|
identified by syzbot (two descriptors with matching endpoint numbers
|
|
and directions, where one was interrupt and the other was bulk).
|
|
|
|
To fix the bug, we will clear the reserved bits in bEndpointAddress
|
|
when we parse the descriptor. (Note that both the USB-2.0 and USB-3.1
|
|
specs say these bits are "Reserved, reset to zero".) This requires us
|
|
to make a copy of the descriptor earlier in usb_parse_endpoint() and
|
|
use the copy instead of the original when checking for duplicates.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-41035</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="10" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nf_tables: prefer nft_chain_validate
|
|
|
|
nft_chain_validate already performs loop detection because a cycle will
|
|
result in a call stack overflow (ctx->level >= NFT_JUMP_STACK_SIZE).
|
|
|
|
It also follows maps via ->validate callback in nft_lookup, so there
|
|
appears no reason to iterate the maps again.
|
|
|
|
nf_tables_check_loops() and all its helper functions can be removed.
|
|
This improves ruleset load time significantly, from 23s down to 12s.
|
|
|
|
This also fixes a crash bug. Old loop detection code can result in
|
|
unbounded recursion:
|
|
|
|
BUG: TASK stack guard page was hit at ....
|
|
Oops: stack guard page: 0000 [#1] PREEMPT SMP KASAN
|
|
CPU: 4 PID: 1539 Comm: nft Not tainted 6.10.0-rc5+ #1
|
|
[..]
|
|
|
|
with a suitable ruleset during validation of register stores.
|
|
|
|
I can't see any actual reason to attempt to check for this from
|
|
nft_validate_register_store(), at this point the transaction is still in
|
|
progress, so we don't have a full picture of the rule graph.
|
|
|
|
For nf-next it might make sense to either remove it or make this depend
|
|
on table->validate_state in case we could catch an error earlier
|
|
(for improved error reporting to userspace).</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-41042</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="11" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: ethernet: lantiq_etop: fix double free in detach
|
|
|
|
The number of the currently released descriptor is never incremented
|
|
which results in the same skb being released multiple times.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-41046</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.7</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="12" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
powerpc/pseries: Whitelist dtl slub object for copying to userspace
|
|
|
|
Reading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-*
|
|
results in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as
|
|
shown below.
|
|
|
|
kernel BUG at mm/usercopy.c:102!
|
|
Oops: Exception in kernel mode, sig: 5 [#1]
|
|
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
|
|
Modules linked in: xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc
|
|
scsi_transport_fc ibmveth pseries_wdt dm_multipath dm_mirror dm_region_hash dm_log dm_mod fuse
|
|
CPU: 27 PID: 1815 Comm: python3 Not tainted 6.10.0-rc3 #85
|
|
Hardware name: IBM,9040-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_042) hv:phyp pSeries
|
|
NIP: c0000000005d23d4 LR: c0000000005d23d0 CTR: 00000000006ee6f8
|
|
REGS: c000000120c078c0 TRAP: 0700 Not tainted (6.10.0-rc3)
|
|
MSR: 8000000000029033 <SF,EE,ME,IR,DR,RI,LE> CR: 2828220f XER: 0000000e
|
|
CFAR: c0000000001fdc80 IRQMASK: 0
|
|
[ ... GPRs omitted ... ]
|
|
NIP [c0000000005d23d4] usercopy_abort+0x78/0xb0
|
|
LR [c0000000005d23d0] usercopy_abort+0x74/0xb0
|
|
Call Trace:
|
|
usercopy_abort+0x74/0xb0 (unreliable)
|
|
__check_heap_object+0xf8/0x120
|
|
check_heap_object+0x218/0x240
|
|
__check_object_size+0x84/0x1a4
|
|
dtl_file_read+0x17c/0x2c4
|
|
full_proxy_read+0x8c/0x110
|
|
vfs_read+0xdc/0x3a0
|
|
ksys_read+0x84/0x144
|
|
system_call_exception+0x124/0x330
|
|
system_call_vectored_common+0x15c/0x2ec
|
|
--- interrupt: 3000 at 0x7fff81f3ab34
|
|
|
|
Commit 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0")
|
|
requires that only whitelisted areas in slab/slub objects can be copied to
|
|
userspace when usercopy hardening is enabled using CONFIG_HARDENED_USERCOPY.
|
|
Dtl contains hypervisor dispatch events which are expected to be read by
|
|
privileged users. Hence mark this safe for user access.
|
|
Specify useroffset=0 and usersize=DISPATCH_LOG_BYTES to whitelist the
|
|
entire object.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-41065</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="13" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
btrfs: qgroup: fix quota root leak after quota disable failure
|
|
|
|
If during the quota disable we fail when cleaning the quota tree or when
|
|
deleting the root from the root tree, we jump to the 'out' label without
|
|
ever dropping the reference on the quota root, resulting in a leak of the
|
|
root since fs_info->quota_root is no longer pointing to the root (we have
|
|
set it to NULL just before those steps).
|
|
|
|
Fix this by always doing a btrfs_put_root() call under the 'out' label.
|
|
This is a problem that exists since qgroups were first added in 2012 by
|
|
commit bed92eae26cc ("Btrfs: qgroup implementation and prototypes"), but
|
|
back then we missed a kfree on the quota root and free_extent_buffer()
|
|
calls on its root and commit root nodes, since back then roots were not
|
|
yet reference counted.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-41078</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="14" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/i915/gt: Fix potential UAF by revoke of fence registers
|
|
|
|
CI has been sporadically reporting the following issue triggered by
|
|
igt@i915_selftest@live@hangcheck on ADL-P and similar machines:
|
|
|
|
<6> [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence
|
|
...
|
|
<6> [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled
|
|
<6> [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled
|
|
<3> [414.070354] Unable to pin Y-tiled fence; err:-4
|
|
<3> [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&fence->active))
|
|
...
|
|
<4>[ 609.603992] ------------[ cut here ]------------
|
|
<2>[ 609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301!
|
|
<4>[ 609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
|
|
<4>[ 609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G U W 6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1
|
|
<4>[ 609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023
|
|
<4>[ 609.604010] Workqueue: i915 __i915_gem_free_work [i915]
|
|
<4>[ 609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915]
|
|
...
|
|
<4>[ 609.604271] Call Trace:
|
|
<4>[ 609.604273] <TASK>
|
|
...
|
|
<4>[ 609.604716] __i915_vma_evict+0x2e9/0x550 [i915]
|
|
<4>[ 609.604852] __i915_vma_unbind+0x7c/0x160 [i915]
|
|
<4>[ 609.604977] force_unbind+0x24/0xa0 [i915]
|
|
<4>[ 609.605098] i915_vma_destroy+0x2f/0xa0 [i915]
|
|
<4>[ 609.605210] __i915_gem_object_pages_fini+0x51/0x2f0 [i915]
|
|
<4>[ 609.605330] __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915]
|
|
<4>[ 609.605440] process_scheduled_works+0x351/0x690
|
|
...
|
|
|
|
In the past, there were similar failures reported by CI from other IGT
|
|
tests, observed on other platforms.
|
|
|
|
Before commit 63baf4f3d587 ("drm/i915/gt: Only wait for GPU activity
|
|
before unbinding a GGTT fence"), i915_vma_revoke_fence() was waiting for
|
|
idleness of vma->active via fence_update(). That commit introduced
|
|
vma->fence->active in order for the fence_update() to be able to wait
|
|
selectively on that one instead of vma->active since only idleness of
|
|
fence registers was needed. But then, another commit 0d86ee35097a
|
|
("drm/i915/gt: Make fence revocation unequivocal") replaced the call to
|
|
fence_update() in i915_vma_revoke_fence() with only fence_write(), and
|
|
also added that GEM_BUG_ON(!i915_active_is_idle(&fence->active)) in front.
|
|
No justification was provided on why we might then expect idleness of
|
|
vma->fence->active without first waiting on it.
|
|
|
|
The issue can be potentially caused by a race among revocation of fence
|
|
registers on one side and sequential execution of signal callbacks invoked
|
|
on completion of a request that was using them on the other, still
|
|
processed in parallel to revocation of those fence registers. Fix it by
|
|
waiting for idleness of vma->fence->active in i915_vma_revoke_fence().
|
|
|
|
(cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1)</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-41092</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="15" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep
|
|
|
|
The ilitek-ili9881c controls the reset GPIO using the non-sleeping
|
|
gpiod_set_value() function. This complains loudly when the GPIO
|
|
controller needs to sleep. As the caller can sleep, use
|
|
gpiod_set_value_cansleep() to fix the issue.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-42087</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="16" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
serial: 8250_omap: Implementation of Errata i2310
|
|
|
|
As per Errata i2310[0], Erroneous timeout can be triggered,
|
|
if this Erroneous interrupt is not cleared then it may leads
|
|
to storm of interrupts, therefore apply Errata i2310 solution.
|
|
|
|
[0] https://www.ti.com/lit/pdf/sprz536 page 23</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-42095</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="17" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
x86: stop playing stack games in profile_pc()
|
|
|
|
The 'profile_pc()' function is used for timer-based profiling, which
|
|
isn't really all that relevant any more to begin with, but it also ends
|
|
up making assumptions based on the stack layout that aren't necessarily
|
|
valid.
|
|
|
|
Basically, the code tries to account the time spent in spinlocks to the
|
|
caller rather than the spinlock, and while I support that as a concept,
|
|
it's not worth the code complexity or the KASAN warnings when no serious
|
|
profiling is done using timers anyway these days.
|
|
|
|
And the code really does depend on stack layout that is only true in the
|
|
simplest of cases. We've lost the comment at some point (I think when
|
|
the 32-bit and 64-bit code was unified), but it used to say:
|
|
|
|
Assume the lock function has either no stack frame or a copy
|
|
of eflags from PUSHF.
|
|
|
|
which explains why it just blindly loads a word or two straight off the
|
|
stack pointer and then takes a minimal look at the values to just check
|
|
if they might be eflags or the return pc:
|
|
|
|
Eflags always has bits 22 and up cleared unlike kernel addresses
|
|
|
|
but that basic stack layout assumption assumes that there isn't any lock
|
|
debugging etc going on that would complicate the code and cause a stack
|
|
frame.
|
|
|
|
It causes KASAN unhappiness reported for years by syzkaller [1] and
|
|
others [2].
|
|
|
|
With no real practical reason for this any more, just remove the code.
|
|
|
|
Just for historical interest, here's some background commits relating to
|
|
this code from 2006:
|
|
|
|
0cb91a229364 ("i386: Account spinlocks to the caller during profiling for !FP kernels")
|
|
31679f38d886 ("Simplify profile_pc on x86-64")
|
|
|
|
and a code unification from 2009:
|
|
|
|
ef4512882dbe ("x86: time_32/64.c unify profile_pc")
|
|
|
|
but the basics of this thing actually goes back to before the git tree.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-42096</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="18" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
crypto: ecdh - explicitly zeroize private_key
|
|
|
|
private_key is overwritten with the key parameter passed in by the
|
|
caller (if present), or alternatively a newly generated private key.
|
|
However, it is possible that the caller provides a key (or the newly
|
|
generated key) which is shorter than the previous key. In that
|
|
scenario, some key material from the previous key would not be
|
|
overwritten. The easiest solution is to explicitly zeroize the entire
|
|
private_key array first.
|
|
|
|
Note that this patch slightly changes the behavior of this function:
|
|
previously, if the ecc_gen_privkey failed, the old private_key would
|
|
remain. Now, the private_key is always zeroized. This behavior is
|
|
consistent with the case where params.key is set and ecc_is_key_valid
|
|
fails.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-42098</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="19" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nilfs2: fix inode number range checks
|
|
|
|
Patch series "nilfs2: fix potential issues related to reserved inodes".
|
|
|
|
This series fixes one use-after-free issue reported by syzbot, caused by
|
|
nilfs2's internal inode being exposed in the namespace on a corrupted
|
|
filesystem, and a couple of flaws that cause problems if the starting
|
|
number of non-reserved inodes written in the on-disk super block is
|
|
intentionally (or corruptly) changed from its default value.
|
|
|
|
|
|
This patch (of 3):
|
|
|
|
In the current implementation of nilfs2, "nilfs->ns_first_ino", which
|
|
gives the first non-reserved inode number, is read from the superblock,
|
|
but its lower limit is not checked.
|
|
|
|
As a result, if a number that overlaps with the inode number range of
|
|
reserved inodes such as the root directory or metadata files is set in the
|
|
super block parameter, the inode number test macros (NILFS_MDT_INODE and
|
|
NILFS_VALID_INODE) will not function properly.
|
|
|
|
In addition, these test macros use left bit-shift calculations using with
|
|
the inode number as the shift count via the BIT macro, but the result of a
|
|
shift calculation that exceeds the bit width of an integer is undefined in
|
|
the C specification, so if "ns_first_ino" is set to a large value other
|
|
than the default value NILFS_USER_INO (=11), the macros may potentially
|
|
malfunction depending on the environment.
|
|
|
|
Fix these issues by checking the lower bound of "nilfs->ns_first_ino" and
|
|
by preventing bit shifts equal to or greater than the NILFS_USER_INO
|
|
constant in the inode number test macros.
|
|
|
|
Also, change the type of "ns_first_ino" from signed integer to unsigned
|
|
integer to avoid the need for type casting in comparisons such as the
|
|
lower bound check introduced this time.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-42105</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="20" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM values
|
|
|
|
syzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUM
|
|
to 2^31.
|
|
|
|
We had a similar issue in sch_fq, fixed with commit
|
|
d9e15a273306 ("pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM")
|
|
|
|
watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24]
|
|
Modules linked in:
|
|
irq event stamp: 131135
|
|
hardirqs last enabled at (131134): [<ffff80008ae8778c>] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline]
|
|
hardirqs last enabled at (131134): [<ffff80008ae8778c>] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95
|
|
hardirqs last disabled at (131135): [<ffff80008ae85378>] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]
|
|
hardirqs last disabled at (131135): [<ffff80008ae85378>] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551
|
|
softirqs last enabled at (125892): [<ffff80008907e82c>] neigh_hh_init net/core/neighbour.c:1538 [inline]
|
|
softirqs last enabled at (125892): [<ffff80008907e82c>] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553
|
|
softirqs last disabled at (125896): [<ffff80008904166c>] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19
|
|
CPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
|
|
Workqueue: mld mld_ifc_work
|
|
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
|
pc : __list_del include/linux/list.h:195 [inline]
|
|
pc : __list_del_entry include/linux/list.h:218 [inline]
|
|
pc : list_move_tail include/linux/list.h:310 [inline]
|
|
pc : fq_tin_dequeue include/net/fq_impl.h:112 [inline]
|
|
pc : ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854
|
|
lr : __list_del_entry include/linux/list.h:218 [inline]
|
|
lr : list_move_tail include/linux/list.h:310 [inline]
|
|
lr : fq_tin_dequeue include/net/fq_impl.h:112 [inline]
|
|
lr : ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854
|
|
sp : ffff800093d36700
|
|
x29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000
|
|
x26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0
|
|
x23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0
|
|
x20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0
|
|
x17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8
|
|
x14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffff
|
|
x11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000
|
|
x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
|
|
x5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fc
|
|
x2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470
|
|
Call trace:
|
|
__list_del include/linux/list.h:195 [inline]
|
|
__list_del_entry include/linux/list.h:218 [inline]
|
|
list_move_tail include/linux/list.h:310 [inline]
|
|
fq_tin_dequeue include/net/fq_impl.h:112 [inline]
|
|
ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854
|
|
wake_tx_push_queue net/mac80211/util.c:294 [inline]
|
|
ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315
|
|
drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [inline]
|
|
schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [inline]
|
|
ieee80211_queue_skb+0x18e8/0x2244 net/mac80211/tx.c:1664
|
|
ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966
|
|
ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062
|
|
__ieee80211_subif_start_xmit+0xab8/0x122c net/mac80211/tx.c:4338
|
|
ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532
|
|
__netdev_start_xmit include/linux/netdevice.h:4903 [inline]
|
|
netdev_start_xmit include/linux/netdevice.h:4917 [inline]
|
|
xmit_one net/core/dev.c:3531 [inline]
|
|
dev_hard_start_xmit+0x27c/0x938 net/core/dev.c:3547
|
|
__dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341
|
|
dev_queue_xmit include/linux/netdevice.h:3091 [inline]
|
|
neigh_resolve_output+0x558/0x658 net/core/neighbour.c:1563
|
|
neigh_output include/net/neighbour.h:542 [inline]
|
|
ip6_fini
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-42114</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="21" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
powerpc: Avoid nmi_enter/nmi_exit in real mode interrupt.
|
|
|
|
nmi_enter()/nmi_exit() touches per cpu variables which can lead to kernel
|
|
crash when invoked during real mode interrupt handling (e.g. early HMI/MCE
|
|
interrupt handler) if percpu allocation comes from vmalloc area.
|
|
|
|
Early HMI/MCE handlers are called through DEFINE_INTERRUPT_HANDLER_NMI()
|
|
wrapper which invokes nmi_enter/nmi_exit calls. We don't see any issue when
|
|
percpu allocation is from the embedded first chunk. However with
|
|
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK enabled there are chances where percpu
|
|
allocation can come from the vmalloc area.
|
|
|
|
With kernel command line "percpu_alloc=page" we can force percpu allocation
|
|
to come from vmalloc area and can see kernel crash in machine_check_early:
|
|
|
|
[ 1.215714] NIP [c000000000e49eb4] rcu_nmi_enter+0x24/0x110
|
|
[ 1.215717] LR [c0000000000461a0] machine_check_early+0xf0/0x2c0
|
|
[ 1.215719] --- interrupt: 200
|
|
[ 1.215720] [c000000fffd73180] [0000000000000000] 0x0 (unreliable)
|
|
[ 1.215722] [c000000fffd731b0] [0000000000000000] 0x0
|
|
[ 1.215724] [c000000fffd73210] [c000000000008364] machine_check_early_common+0x134/0x1f8
|
|
|
|
Fix this by avoiding use of nmi_enter()/nmi_exit() in real mode if percpu
|
|
first chunk is not embedded.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-42126</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="22" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
leds: an30259a: Use devm_mutex_init() for mutex initialization
|
|
|
|
In this driver LEDs are registered using devm_led_classdev_register()
|
|
so they are automatically unregistered after module's remove() is done.
|
|
led_classdev_unregister() calls module's led_set_brightness() to turn off
|
|
the LEDs and that callback uses mutex which was destroyed already
|
|
in module's remove() so use devm API instead.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-42128</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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:L/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="23" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
orangefs: fix out-of-bounds fsid access
|
|
|
|
Arnd Bergmann sent a patch to fsdevel, he says:
|
|
|
|
"orangefs_statfs() copies two consecutive fields of the superblock into
|
|
the statfs structure, which triggers a warning from the string fortification
|
|
helpers"
|
|
|
|
Jan Kara suggested an alternate way to do the patch to make it more readable.
|
|
|
|
I ran both ideas through xfstests and both seem fine. This patch
|
|
is based on Jan Kara's suggestion.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-42143</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="24" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
bnx2x: Fix multiple UBSAN array-index-out-of-bounds
|
|
|
|
Fix UBSAN warnings that occur when using a system with 32 physical
|
|
cpu cores or more, or when the user defines a number of Ethernet
|
|
queues greater than or equal to FP_SB_MAX_E1x using the num_queues
|
|
module parameter.
|
|
|
|
Currently there is a read/write out of bounds that occurs on the array
|
|
"struct stats_query_entry query" present inside the "bnx2x_fw_stats_req"
|
|
struct in "drivers/net/ethernet/broadcom/bnx2x/bnx2x.h".
|
|
Looking at the definition of the "struct stats_query_entry query" array:
|
|
|
|
struct stats_query_entry query[FP_SB_MAX_E1x+
|
|
BNX2X_FIRST_QUEUE_QUERY_IDX];
|
|
|
|
FP_SB_MAX_E1x is defined as the maximum number of fast path interrupts and
|
|
has a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3
|
|
meaning the array has a total size of 19.
|
|
Since accesses to "struct stats_query_entry query" are offset-ted by
|
|
BNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernet
|
|
queues should not exceed FP_SB_MAX_E1x (16). However one of these queues
|
|
is reserved for FCOE and thus the number of Ethernet queues should be set
|
|
to [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) if
|
|
it is not.
|
|
|
|
This is also described in a comment in the source code in
|
|
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definition
|
|
of FP_SB_MAX_E1x. Below is the part of this explanation that it important
|
|
for this patch
|
|
|
|
/*
|
|
* The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is
|
|
* control by the number of fast-path status blocks supported by the
|
|
* device (HW/FW). Each fast-path status block (FP-SB) aka non-default
|
|
* status block represents an independent interrupts context that can
|
|
* serve a regular L2 networking queue. However special L2 queues such
|
|
* as the FCoE queue do not require a FP-SB and other components like
|
|
* the CNIC may consume FP-SB reducing the number of possible L2 queues
|
|
*
|
|
* If the maximum number of FP-SB available is X then:
|
|
* a. If CNIC is supported it consumes 1 FP-SB thus the max number of
|
|
* regular L2 queues is Y=X-1
|
|
* b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor)
|
|
* c. If the FCoE L2 queue is supported the actual number of L2 queues
|
|
* is Y+1
|
|
* d. The number of irqs (MSIX vectors) is either Y+1 (one extra for
|
|
* slow-path interrupts) or Y+2 if CNIC is supported (one additional
|
|
* FP interrupt context for the CNIC).
|
|
* e. The number of HW context (CID count) is always X or X+1 if FCoE
|
|
* L2 queue is supported. The cid for the FCoE L2 queue is always X.
|
|
*/
|
|
|
|
However this driver also supports NICs that use the E2 controller which can
|
|
handle more queues due to having more FP-SB represented by FP_SB_MAX_E2.
|
|
Looking at the commits when the E2 support was added, it was originally
|
|
using the E1x parameters: commit f2e0899f0f27 ("bnx2x: Add 57712 support").
|
|
Back then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driver
|
|
was later updated to take full advantage of the E2 instead of having it be
|
|
limited to the capabilities of the E1x. But as far as we can tell, the
|
|
array "stats_query_entry query" was still limited to using the FP-SB
|
|
available to the E1x cards as part of an oversignt when the driver was
|
|
updated to take full advantage of the E2, and now with the driver being
|
|
aware of the greater queue size supported by E2 NICs, it causes the UBSAN
|
|
warnings seen in the stack traces below.
|
|
|
|
This patch increases the size of the "stats_query_entry query" array by
|
|
replacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handle
|
|
both types of NICs.
|
|
|
|
Stack traces:
|
|
|
|
UBSAN: array-index-out-of-bounds in
|
|
drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11
|
|
index 20 is out of range for type 'stats_query_entry [19]'
|
|
CPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic
|
|
#202405052133
|
|
Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-42148</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="25" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:tcp_metrics: validate source addr lengthI don t see anything checking that TCP_METRICS_ATTR_SADDR_IPV4is at least 4 bytes long, and the policy doesn t have an entryfor this attribute at all (neither does it for IPv6 but v6 ismanually validated).</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-42154</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="26" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
s390/pkey: Wipe copies of clear-key structures on failure
|
|
|
|
Wipe all sensitive data from stack for all IOCTLs, which convert a
|
|
clear-key into a protected- or secure-key.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-42156</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.1</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="27" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
s390/pkey: Wipe sensitive data on failure
|
|
|
|
Wipe sensitive data from stack also if the copy_to_user() fails.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-42157</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.1</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="28" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:s390/pkey: Use kfree_sensitive() to fix Coccinelle warningsReplace memzero_explicit() and kfree() with kfree_sensitive() to fixwarnings reported by Coccinelle:WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1506)WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1643)WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1770)</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-42158</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.1</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="29" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:media: dvb-frontends: tda10048: Fix integer overflowstate->xtal_hz can be up to 16M, so it can overflow a 32 bit integerwhen multiplied by pll_mfactor.Create a new 64 bit variable to hold the calculations.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-42223</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="30" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: mt76: replace skb_put with skb_put_zero
|
|
|
|
Avoid potentially reusing uninitialized data</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-42225</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.5</BaseScore>
|
|
<Vector>AV:A/AC:H/PR:N/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-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="31" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
crypto: aead,cipher - zeroize key buffer after use
|
|
|
|
I.G 9.7.B for FIPS 140-3 specifies that variables temporarily holding
|
|
cryptographic information should be zeroized once they are no longer
|
|
needed. Accomplish this by using kfree_sensitive for buffers that
|
|
previously held the private key.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-42229</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.1</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="32" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
USB: serial: mos7840: fix crash on resume
|
|
|
|
Since commit c49cfa917025 ("USB: serial: use generic method if no
|
|
alternative is provided in usb serial layer"), USB serial core calls the
|
|
generic resume implementation when the driver has not provided one.
|
|
|
|
This can trigger a crash on resume with mos7840 since support for
|
|
multiple read URBs was added back in 2011. Specifically, both port read
|
|
URBs are now submitted on resume for open ports, but the context pointer
|
|
of the second URB is left set to the core rather than mos7840 port
|
|
structure.
|
|
|
|
Fix this by implementing dedicated suspend and resume functions for
|
|
mos7840.
|
|
|
|
Tested with Delock 87414 USB 2.0 to 4x serial adapter.
|
|
|
|
[ johan: analyse crash and rewrite commit message; set busy flag on
|
|
resume; drop bulk-in check; drop unnecessary usb_kill_urb() ]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-42244</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="33" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket
|
|
|
|
When using a BPF program on kernel_connect(), the call can return -EPERM. This
|
|
causes xs_tcp_setup_socket() to loop forever, filling up the syslog and causing
|
|
the kernel to potentially freeze up.
|
|
|
|
Neil suggested:
|
|
|
|
This will propagate -EPERM up into other layers which might not be ready
|
|
to handle it. It might be safer to map EPERM to an error we would be more
|
|
likely to expect from the network system - such as ECONNREFUSED or ENETDOWN.
|
|
|
|
ECONNREFUSED as error seems reasonable. For programs setting a different error
|
|
can be out of reach (see handling in 4fbac77d2d09) in particular on kernels
|
|
which do not have f10d05966196 ("bpf: Make BPF_PROG_RUN_ARRAY return -err
|
|
instead of allow boolean"), thus given that it is better to simply remap for
|
|
consistent behavior. UDP does handle EPERM in xs_udp_send_request().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-42246</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="34" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:wireguard: allowedips: avoid unaligned 64-bit memory accessesOn the parisc platform, the kernel issues kernel warnings becauseswap_endian() tries to load a 128-bit IPv6 address from an unalignedmemory location: Kernel: unaligned access to 0x55f4688c in wg_allowedips_insert_v6+0x2c/0x80 [wireguard] (iir 0xf3010df) Kernel: unaligned access to 0x55f46884 in wg_allowedips_insert_v6+0x38/0x80 [wireguard] (iir 0xf2010dc)Avoid such unaligned memory accesses by instead using theget_unaligned_be64() helper macro.[Jason: replace src[8] in original patch with src+8]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-42247</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.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-16</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1994</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |