2683 lines
119 KiB
XML
2683 lines
119 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-SP3</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-1995</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-SP3</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)
|
||
|
||
A race condition was found in the Linux kernel's drm/exynos device driver in exynos_drm_crtc_atomic_disable() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.
|
||
|
||
|
||
(CVE-2024-22386)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
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:
|
||
|
||
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-SP3.
|
||
|
||
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-1995</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-22386</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-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-22386</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-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-SP3" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">openEuler-22.03-LTS-SP3</FullProductName>
|
||
</Branch>
|
||
<Branch Type="Package Arch" Name="aarch64">
|
||
<FullProductName ProductID="kernel-5.10.0-223.0.0.126" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-debuginfo-5.10.0-223.0.0.126" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debuginfo-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-debugsource-5.10.0-223.0.0.126" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debugsource-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-devel-5.10.0-223.0.0.126" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-devel-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-headers-5.10.0-223.0.0.126" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-headers-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-source-5.10.0-223.0.0.126" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-source-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-tools-5.10.0-223.0.0.126" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-223.0.0.126" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-debuginfo-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-tools-devel-5.10.0-223.0.0.126" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-devel-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="perf-5.10.0-223.0.0.126" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="perf-debuginfo-5.10.0-223.0.0.126" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-debuginfo-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="python3-perf-5.10.0-223.0.0.126" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-223.0.0.126" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-debuginfo-5.10.0-223.0.0.126.oe2203sp3.aarch64.rpm</FullProductName>
|
||
</Branch>
|
||
<Branch Type="Package Arch" Name="src">
|
||
<FullProductName ProductID="kernel-5.10.0-223.0.0.126" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-223.0.0.126.oe2203sp3.src.rpm</FullProductName>
|
||
</Branch>
|
||
<Branch Type="Package Arch" Name="x86_64">
|
||
<FullProductName ProductID="kernel-5.10.0-223.0.0.126" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-debuginfo-5.10.0-223.0.0.126" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debuginfo-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-debugsource-5.10.0-223.0.0.126" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debugsource-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-devel-5.10.0-223.0.0.126" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-devel-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-headers-5.10.0-223.0.0.126" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-headers-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-source-5.10.0-223.0.0.126" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-source-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-tools-5.10.0-223.0.0.126" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-223.0.0.126" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-debuginfo-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-tools-devel-5.10.0-223.0.0.126" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-devel-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="perf-5.10.0-223.0.0.126" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="perf-debuginfo-5.10.0-223.0.0.126" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-debuginfo-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="python3-perf-5.10.0-223.0.0.126" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-223.0.0.126" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-debuginfo-5.10.0-223.0.0.126.oe2203sp3.x86_64.rpm</FullProductName>
|
||
</Branch>
|
||
</ProductTree>
|
||
<Vulnerability Ordinal="1" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
||
<Notes>
|
||
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
USB: 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-SP3</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-1995</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-SP3</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-1995</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">A race condition was found in the Linux kernel's drm/exynos device driver in exynos_drm_crtc_atomic_disable() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.
|
||
|
||
|
||
</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-08-16</ReleaseDate>
|
||
<CVE>CVE-2024-22386</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>4.7</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-08-16</DATE>
|
||
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1995</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:
|
||
|
||
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-SP3</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-1995</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:
|
||
|
||
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-SP3</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-1995</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-SP3</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-1995</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-SP3</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-1995</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-SP3</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-1995</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-SP3</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-1995</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-SP3</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-1995</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-SP3</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-1995</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-SP3</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-1995</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-SP3</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-1995</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-SP3</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-1995</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-SP3</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-1995</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-SP3</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-1995</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-SP3</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-1995</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-SP3</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-1995</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-SP3</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-1995</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-SP3</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-1995</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-SP3</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-1995</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-SP3</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-1995</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-SP3</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-1995</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-SP3</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-1995</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-SP3</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-1995</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-SP3</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-1995</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-SP3</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-1995</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-SP3</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-1995</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-SP3</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-1995</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-SP3</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-1995</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-SP3</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-1995</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-SP3</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-1995</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-SP3</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-1995</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-SP3</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-1995</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
</cvrfdoc> |