<?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 &quot;Task X blocked for more than N
seconds&quot;, 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
&quot;echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs&quot; 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&apos;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&apos;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&apos;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 &amp;= 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:
 &lt;TASK&gt;
 __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 &quot;kworker/u8:4&quot;, 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  ....&gt;...........
  backtrace:
    [&lt;000000007302a0b6&gt;] __kmem_cache_alloc_node+0x1e0/0x35c
    [&lt;00000000049bd418&gt;] kmalloc_trace+0x34/0x80
    [&lt;0000000000d792bb&gt;] mesh_queue_preq+0x44/0x2a8
    [&lt;00000000c99c3696&gt;] mesh_nexthop_resolve+0x198/0x19c
    [&lt;00000000926bf598&gt;] ieee80211_xmit+0x1d0/0x1f4
    [&lt;00000000fc8c2284&gt;] __ieee80211_subif_start_xmit+0x30c/0x764
    [&lt;000000005926ee38&gt;] ieee80211_subif_start_xmit+0x9c/0x7a4
    [&lt;000000004c86e916&gt;] dev_hard_start_xmit+0x174/0x440
    [&lt;0000000023495647&gt;] __dev_queue_xmit+0xe24/0x111c
    [&lt;00000000cfe9ca78&gt;] batadv_send_skb_packet+0x180/0x1e4
    [&lt;000000007bacc5d5&gt;] batadv_v_elp_periodic_work+0x2f4/0x508
    [&lt;00000000adc3cd94&gt;] process_one_work+0x4b8/0xa1c
    [&lt;00000000b36425d1&gt;] worker_thread+0x9c/0x634
    [&lt;0000000005852dd5&gt;] kthread+0x1bc/0x1c4
    [&lt;000000005fccd770&gt;] ret_from_fork+0x10/0x20
unreferenced object 0xffff000009051f00 (size 128):
  comm &quot;kworker/u8:4&quot;, 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&apos;.......Xy.....
  backtrace:
    [&lt;000000007302a0b6&gt;] __kmem_cache_alloc_node+0x1e0/0x35c
    [&lt;00000000049bd418&gt;] kmalloc_trace+0x34/0x80
    [&lt;0000000000d792bb&gt;] mesh_queue_preq+0x44/0x2a8
    [&lt;00000000c99c3696&gt;] mesh_nexthop_resolve+0x198/0x19c
    [&lt;00000000926bf598&gt;] ieee80211_xmit+0x1d0/0x1f4
    [&lt;00000000fc8c2284&gt;] __ieee80211_subif_start_xmit+0x30c/0x764
    [&lt;000000005926ee38&gt;] ieee80211_subif_start_xmit+0x9c/0x7a4
    [&lt;000000004c86e916&gt;] dev_hard_start_xmit+0x174/0x440
    [&lt;0000000023495647&gt;] __dev_queue_xmit+0xe24/0x111c
    [&lt;00000000cfe9ca78&gt;] batadv_send_skb_packet+0x180/0x1e4
    [&lt;000000007bacc5d5&gt;] batadv_v_elp_periodic_work+0x2f4/0x508
    [&lt;00000000adc3cd94&gt;] process_one_work+0x4b8/0xa1c
    [&lt;00000000b36425d1&gt;] worker_thread+0x9c/0x634
    [&lt;0000000005852dd5&gt;] kthread+0x1bc/0x1c4
    [&lt;000000005fccd770&gt;] 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&apos;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&apos;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 (&quot;..&quot;) 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 (&quot;.&quot; and &quot;..&quot;) 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&apos;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 &quot;Reserved, reset to zero&quot;.)  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-&gt;level &gt;= NFT_JUMP_STACK_SIZE).

It also follows maps via -&gt;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&apos;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&apos;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-&gt;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 &lt;SF,EE,ME,IR,DR,RI,LE&gt;  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 (&quot;usercopy: Restrict non-usercopy caches to size 0&quot;)
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 &apos;out&apos; label without
ever dropping the reference on the quota root, resulting in a leak of the
root since fs_info-&gt;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 &apos;out&apos; label.
This is a problem that exists since qgroups were first added in 2012 by
commit bed92eae26cc (&quot;Btrfs: qgroup implementation and prototypes&quot;), 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:

&lt;6&gt; [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence
...
&lt;6&gt; [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled
&lt;6&gt; [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled
&lt;3&gt; [414.070354] Unable to pin Y-tiled fence; err:-4
&lt;3&gt; [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&amp;fence-&gt;active))
...
&lt;4&gt;[  609.603992] ------------[ cut here ]------------
&lt;2&gt;[  609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301!
&lt;4&gt;[  609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
&lt;4&gt;[  609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G     U  W          6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1
&lt;4&gt;[  609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023
&lt;4&gt;[  609.604010] Workqueue: i915 __i915_gem_free_work [i915]
&lt;4&gt;[  609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915]
...
&lt;4&gt;[  609.604271] Call Trace:
&lt;4&gt;[  609.604273]  &lt;TASK&gt;
...
&lt;4&gt;[  609.604716]  __i915_vma_evict+0x2e9/0x550 [i915]
&lt;4&gt;[  609.604852]  __i915_vma_unbind+0x7c/0x160 [i915]
&lt;4&gt;[  609.604977]  force_unbind+0x24/0xa0 [i915]
&lt;4&gt;[  609.605098]  i915_vma_destroy+0x2f/0xa0 [i915]
&lt;4&gt;[  609.605210]  __i915_gem_object_pages_fini+0x51/0x2f0 [i915]
&lt;4&gt;[  609.605330]  __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915]
&lt;4&gt;[  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 (&quot;drm/i915/gt: Only wait for GPU activity
before unbinding a GGTT fence&quot;), i915_vma_revoke_fence() was waiting for
idleness of vma-&gt;active via fence_update().   That commit introduced
vma-&gt;fence-&gt;active in order for the fence_update() to be able to wait
selectively on that one instead of vma-&gt;active since only idleness of
fence registers was needed.  But then, another commit 0d86ee35097a
(&quot;drm/i915/gt: Make fence revocation unequivocal&quot;) 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(&amp;fence-&gt;active)) in front.
No justification was provided on why we might then expect idleness of
vma-&gt;fence-&gt;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-&gt;fence-&gt;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 &apos;profile_pc()&apos; function is used for timer-based profiling, which
isn&apos;t really all that relevant any more to begin with, but it also ends
up making assumptions based on the stack layout that aren&apos;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&apos;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&apos;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&apos;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&apos;s some background commits relating to
this code from 2006:

  0cb91a229364 (&quot;i386: Account spinlocks to the caller during profiling for !FP kernels&quot;)
  31679f38d886 (&quot;Simplify profile_pc on x86-64&quot;)

and a code unification from 2009:

  ef4512882dbe (&quot;x86: time_32/64.c unify profile_pc&quot;)

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 &quot;nilfs2: fix potential issues related to reserved inodes&quot;.

This series fixes one use-after-free issue reported by syzbot, caused by
nilfs2&apos;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, &quot;nilfs-&gt;ns_first_ino&quot;, 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 &quot;ns_first_ino&quot; 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 &quot;nilfs-&gt;ns_first_ino&quot; 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 &quot;ns_first_ino&quot; 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 (&quot;pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM&quot;)

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): [&lt;ffff80008ae8778c&gt;] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline]
 hardirqs last  enabled at (131134): [&lt;ffff80008ae8778c&gt;] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95
 hardirqs last disabled at (131135): [&lt;ffff80008ae85378&gt;] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]
 hardirqs last disabled at (131135): [&lt;ffff80008ae85378&gt;] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551
 softirqs last  enabled at (125892): [&lt;ffff80008907e82c&gt;] neigh_hh_init net/core/neighbour.c:1538 [inline]
 softirqs last  enabled at (125892): [&lt;ffff80008907e82c&gt;] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553
 softirqs last disabled at (125896): [&lt;ffff80008904166c&gt;] 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&apos;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 &quot;percpu_alloc=page&quot; 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&apos;s remove() is done.
led_classdev_unregister() calls module&apos;s led_set_brightness() to turn off
the LEDs and that callback uses mutex which was destroyed already
in module&apos;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:

&quot;orangefs_statfs() copies two consecutive fields of the superblock into
the statfs structure, which triggers a warning from the string fortification
helpers&quot;

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&apos;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
&quot;struct stats_query_entry query&quot; present inside the &quot;bnx2x_fw_stats_req&quot;
struct in &quot;drivers/net/ethernet/broadcom/bnx2x/bnx2x.h&quot;.
Looking at the definition of the &quot;struct stats_query_entry query&quot; 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 &quot;struct stats_query_entry query&quot; 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 (&quot;bnx2x: Add 57712 support&quot;).
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 &quot;stats_query_entry query&quot; 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 &quot;stats_query_entry query&quot; 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 &apos;stats_query_entry [19]&apos;
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&apos;t see anything checking that TCP_METRICS_ATTR_SADDR_IPV4
is at least 4 bytes long, and the policy doesn&apos;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-&gt;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 (&quot;USB: serial: use generic method if no
alternative is provided in usb serial layer&quot;), 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 (&quot;bpf: Make BPF_PROG_RUN_ARRAY return -err
instead of allow boolean&quot;), 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 &quot;Task X blocked for more than N
seconds&quot;, 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
&quot;echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs&quot; 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&apos;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&apos;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&apos;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 &amp;= 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:
 &lt;TASK&gt;
 __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 &quot;kworker/u8:4&quot;, 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  ....&gt;...........
  backtrace:
    [&lt;000000007302a0b6&gt;] __kmem_cache_alloc_node+0x1e0/0x35c
    [&lt;00000000049bd418&gt;] kmalloc_trace+0x34/0x80
    [&lt;0000000000d792bb&gt;] mesh_queue_preq+0x44/0x2a8
    [&lt;00000000c99c3696&gt;] mesh_nexthop_resolve+0x198/0x19c
    [&lt;00000000926bf598&gt;] ieee80211_xmit+0x1d0/0x1f4
    [&lt;00000000fc8c2284&gt;] __ieee80211_subif_start_xmit+0x30c/0x764
    [&lt;000000005926ee38&gt;] ieee80211_subif_start_xmit+0x9c/0x7a4
    [&lt;000000004c86e916&gt;] dev_hard_start_xmit+0x174/0x440
    [&lt;0000000023495647&gt;] __dev_queue_xmit+0xe24/0x111c
    [&lt;00000000cfe9ca78&gt;] batadv_send_skb_packet+0x180/0x1e4
    [&lt;000000007bacc5d5&gt;] batadv_v_elp_periodic_work+0x2f4/0x508
    [&lt;00000000adc3cd94&gt;] process_one_work+0x4b8/0xa1c
    [&lt;00000000b36425d1&gt;] worker_thread+0x9c/0x634
    [&lt;0000000005852dd5&gt;] kthread+0x1bc/0x1c4
    [&lt;000000005fccd770&gt;] ret_from_fork+0x10/0x20
unreferenced object 0xffff000009051f00 (size 128):
  comm &quot;kworker/u8:4&quot;, 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&apos;.......Xy.....
  backtrace:
    [&lt;000000007302a0b6&gt;] __kmem_cache_alloc_node+0x1e0/0x35c
    [&lt;00000000049bd418&gt;] kmalloc_trace+0x34/0x80
    [&lt;0000000000d792bb&gt;] mesh_queue_preq+0x44/0x2a8
    [&lt;00000000c99c3696&gt;] mesh_nexthop_resolve+0x198/0x19c
    [&lt;00000000926bf598&gt;] ieee80211_xmit+0x1d0/0x1f4
    [&lt;00000000fc8c2284&gt;] __ieee80211_subif_start_xmit+0x30c/0x764
    [&lt;000000005926ee38&gt;] ieee80211_subif_start_xmit+0x9c/0x7a4
    [&lt;000000004c86e916&gt;] dev_hard_start_xmit+0x174/0x440
    [&lt;0000000023495647&gt;] __dev_queue_xmit+0xe24/0x111c
    [&lt;00000000cfe9ca78&gt;] batadv_send_skb_packet+0x180/0x1e4
    [&lt;000000007bacc5d5&gt;] batadv_v_elp_periodic_work+0x2f4/0x508
    [&lt;00000000adc3cd94&gt;] process_one_work+0x4b8/0xa1c
    [&lt;00000000b36425d1&gt;] worker_thread+0x9c/0x634
    [&lt;0000000005852dd5&gt;] kthread+0x1bc/0x1c4
    [&lt;000000005fccd770&gt;] 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&apos;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&apos;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 (&quot;..&quot;) 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 (&quot;.&quot; and &quot;..&quot;) 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&apos;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 &quot;Reserved, reset to zero&quot;.)  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-&gt;level &gt;= NFT_JUMP_STACK_SIZE).

It also follows maps via -&gt;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&apos;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&apos;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-&gt;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 &lt;SF,EE,ME,IR,DR,RI,LE&gt;  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 (&quot;usercopy: Restrict non-usercopy caches to size 0&quot;)
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 &apos;out&apos; label without
ever dropping the reference on the quota root, resulting in a leak of the
root since fs_info-&gt;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 &apos;out&apos; label.
This is a problem that exists since qgroups were first added in 2012 by
commit bed92eae26cc (&quot;Btrfs: qgroup implementation and prototypes&quot;), 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:

&lt;6&gt; [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence
...
&lt;6&gt; [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled
&lt;6&gt; [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled
&lt;3&gt; [414.070354] Unable to pin Y-tiled fence; err:-4
&lt;3&gt; [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&amp;fence-&gt;active))
...
&lt;4&gt;[  609.603992] ------------[ cut here ]------------
&lt;2&gt;[  609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301!
&lt;4&gt;[  609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
&lt;4&gt;[  609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G     U  W          6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1
&lt;4&gt;[  609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023
&lt;4&gt;[  609.604010] Workqueue: i915 __i915_gem_free_work [i915]
&lt;4&gt;[  609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915]
...
&lt;4&gt;[  609.604271] Call Trace:
&lt;4&gt;[  609.604273]  &lt;TASK&gt;
...
&lt;4&gt;[  609.604716]  __i915_vma_evict+0x2e9/0x550 [i915]
&lt;4&gt;[  609.604852]  __i915_vma_unbind+0x7c/0x160 [i915]
&lt;4&gt;[  609.604977]  force_unbind+0x24/0xa0 [i915]
&lt;4&gt;[  609.605098]  i915_vma_destroy+0x2f/0xa0 [i915]
&lt;4&gt;[  609.605210]  __i915_gem_object_pages_fini+0x51/0x2f0 [i915]
&lt;4&gt;[  609.605330]  __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915]
&lt;4&gt;[  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 (&quot;drm/i915/gt: Only wait for GPU activity
before unbinding a GGTT fence&quot;), i915_vma_revoke_fence() was waiting for
idleness of vma-&gt;active via fence_update().   That commit introduced
vma-&gt;fence-&gt;active in order for the fence_update() to be able to wait
selectively on that one instead of vma-&gt;active since only idleness of
fence registers was needed.  But then, another commit 0d86ee35097a
(&quot;drm/i915/gt: Make fence revocation unequivocal&quot;) 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(&amp;fence-&gt;active)) in front.
No justification was provided on why we might then expect idleness of
vma-&gt;fence-&gt;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-&gt;fence-&gt;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 &apos;profile_pc()&apos; function is used for timer-based profiling, which
isn&apos;t really all that relevant any more to begin with, but it also ends
up making assumptions based on the stack layout that aren&apos;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&apos;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&apos;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&apos;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&apos;s some background commits relating to
this code from 2006:

  0cb91a229364 (&quot;i386: Account spinlocks to the caller during profiling for !FP kernels&quot;)
  31679f38d886 (&quot;Simplify profile_pc on x86-64&quot;)

and a code unification from 2009:

  ef4512882dbe (&quot;x86: time_32/64.c unify profile_pc&quot;)

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 &quot;nilfs2: fix potential issues related to reserved inodes&quot;.

This series fixes one use-after-free issue reported by syzbot, caused by
nilfs2&apos;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, &quot;nilfs-&gt;ns_first_ino&quot;, 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 &quot;ns_first_ino&quot; 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 &quot;nilfs-&gt;ns_first_ino&quot; 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 &quot;ns_first_ino&quot; 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 (&quot;pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM&quot;)

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): [&lt;ffff80008ae8778c&gt;] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline]
 hardirqs last  enabled at (131134): [&lt;ffff80008ae8778c&gt;] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95
 hardirqs last disabled at (131135): [&lt;ffff80008ae85378&gt;] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]
 hardirqs last disabled at (131135): [&lt;ffff80008ae85378&gt;] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551
 softirqs last  enabled at (125892): [&lt;ffff80008907e82c&gt;] neigh_hh_init net/core/neighbour.c:1538 [inline]
 softirqs last  enabled at (125892): [&lt;ffff80008907e82c&gt;] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553
 softirqs last disabled at (125896): [&lt;ffff80008904166c&gt;] 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&apos;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 &quot;percpu_alloc=page&quot; 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&apos;s remove() is done.
led_classdev_unregister() calls module&apos;s led_set_brightness() to turn off
the LEDs and that callback uses mutex which was destroyed already
in module&apos;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:

&quot;orangefs_statfs() copies two consecutive fields of the superblock into
the statfs structure, which triggers a warning from the string fortification
helpers&quot;

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&apos;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
&quot;struct stats_query_entry query&quot; present inside the &quot;bnx2x_fw_stats_req&quot;
struct in &quot;drivers/net/ethernet/broadcom/bnx2x/bnx2x.h&quot;.
Looking at the definition of the &quot;struct stats_query_entry query&quot; 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 &quot;struct stats_query_entry query&quot; 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 (&quot;bnx2x: Add 57712 support&quot;).
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 &quot;stats_query_entry query&quot; 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 &quot;stats_query_entry query&quot; 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 &apos;stats_query_entry [19]&apos;
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-&gt;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 (&quot;USB: serial: use generic method if no
alternative is provided in usb serial layer&quot;), 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 (&quot;bpf: Make BPF_PROG_RUN_ARRAY return -err
instead of allow boolean&quot;), 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>