<?xml version="1.0" encoding="UTF-8"?>
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
	<DocumentTitle xml:lang="en">An update for kernel is now available for openEuler-20.03-LTS-SP4</DocumentTitle>
	<DocumentType>Security Advisory</DocumentType>
	<DocumentPublisher Type="Vendor">
		<ContactDetails>openeuler-security@openeuler.org</ContactDetails>
		<IssuingAuthority>openEuler security committee</IssuingAuthority>
	</DocumentPublisher>
	<DocumentTracking>
		<Identification>
			<ID>openEuler-SA-2024-1996</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-20.03-LTS-SP4</Note>
		<Note Title="Description" Type="General" Ordinal="3" xml:lang="en">The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

ethernet: Fix error handling in xemaclite_of_probe

This node pointer is returned by of_parse_phandle() with refcount
incremented in this function. Calling of_node_put() to avoid the
refcount leak. As the remove function do.(CVE-2022-48860)

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:

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:

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:

hfsplus: fix uninit-value in copy_name

[syzbot reported]
BUG: KMSAN: uninit-value in sized_strscpy+0xc4/0x160
 sized_strscpy+0xc4/0x160
 copy_name+0x2af/0x320 fs/hfsplus/xattr.c:411
 hfsplus_listxattr+0x11e9/0x1a50 fs/hfsplus/xattr.c:750
 vfs_listxattr fs/xattr.c:493 [inline]
 listxattr+0x1f3/0x6b0 fs/xattr.c:840
 path_listxattr fs/xattr.c:864 [inline]
 __do_sys_listxattr fs/xattr.c:876 [inline]
 __se_sys_listxattr fs/xattr.c:873 [inline]
 __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873
 x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Uninit was created at:
 slab_post_alloc_hook mm/slub.c:3877 [inline]
 slab_alloc_node mm/slub.c:3918 [inline]
 kmalloc_trace+0x57b/0xbe0 mm/slub.c:4065
 kmalloc include/linux/slab.h:628 [inline]
 hfsplus_listxattr+0x4cc/0x1a50 fs/hfsplus/xattr.c:699
 vfs_listxattr fs/xattr.c:493 [inline]
 listxattr+0x1f3/0x6b0 fs/xattr.c:840
 path_listxattr fs/xattr.c:864 [inline]
 __do_sys_listxattr fs/xattr.c:876 [inline]
 __se_sys_listxattr fs/xattr.c:873 [inline]
 __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873
 x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
[Fix]
When allocating memory to strbuf, initialize memory to 0.(CVE-2024-41059)

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:

ata: libata-core: Fix double free on error

If e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jump
to the err_out label, which will call devres_release_group().
devres_release_group() will trigger a call to ata_host_release().
ata_host_release() calls kfree(host), so executing the kfree(host) in
ata_host_alloc() will lead to a double free:

kernel BUG at mm/slub.c:553!
Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
RIP: 0010:kfree+0x2cf/0x2f0
Code: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da
RSP: 0018:ffffc90000f377f0 EFLAGS: 00010246
RAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320
RDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0
RBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000
R10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780
R13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006
FS:  00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 ? __die_body.cold+0x19/0x27
 ? die+0x2e/0x50
 ? do_trap+0xca/0x110
 ? do_error_trap+0x6a/0x90
 ? kfree+0x2cf/0x2f0
 ? exc_invalid_op+0x50/0x70
 ? kfree+0x2cf/0x2f0
 ? asm_exc_invalid_op+0x1a/0x20
 ? ata_host_alloc+0xf5/0x120 [libata]
 ? ata_host_alloc+0xf5/0x120 [libata]
 ? kfree+0x2cf/0x2f0
 ata_host_alloc+0xf5/0x120 [libata]
 ata_host_alloc_pinfo+0x14/0xa0 [libata]
 ahci_init_one+0x6c9/0xd20 [ahci]

Ensure that we will not call kfree(host) twice, by performing the kfree()
only if the devres_open_group() call failed.(CVE-2024-41087)

In the Linux kernel, the following vulnerability has been resolved:

ftruncate: pass a signed offset

The old ftruncate() syscall, using the 32-bit off_t misses a sign
extension when called in compat mode on 64-bit architectures.  As a
result, passing a negative length accidentally succeeds in truncating
to file size between 2GiB and 4GiB.

Changing the type of the compat syscall to the signed compat_off_t
changes the behavior so it instead returns -EINVAL.

The native entry point, the truncate() syscall and the corresponding
loff_t based variants are all correct already and do not suffer
from this mistake.(CVE-2024-42084)

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:

ASoC: fsl-asoc-card: set priv-&gt;pdev before using it

priv-&gt;pdev pointer was set after being used in
fsl_asoc_card_audmux_init().
Move this assignment at the start of the probe function, so
sub-functions can correctly use pdev through priv.

fsl_asoc_card_audmux_init() dereferences priv-&gt;pdev to get access to the
dev struct, used with dev_err macros.
As priv is zero-initialised, there would be a NULL pointer dereference.
Note that if priv-&gt;dev is dereferenced before assignment but never used,
for example if there is no error to be printed, the driver won&apos;t crash
probably due to compiler optimisations.(CVE-2024-42089)

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:

Revert &quot;mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again&quot;

Patch series &quot;mm: Avoid possible overflows in dirty throttling&quot;.

Dirty throttling logic assumes dirty limits in page units fit into
32-bits.  This patch series makes sure this is true (see patch 2/2 for
more details).


This patch (of 2):

This reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78.

The commit is broken in several ways.  Firstly, the removed (u64) cast
from the multiplication will introduce a multiplication overflow on 32-bit
archs if wb_thresh * bg_thresh &gt;= 1&lt;&lt;32 (which is actually common - the
default settings with 4GB of RAM will trigger this).  Secondly, the
div64_u64() is unnecessarily expensive on 32-bit archs.  We have
div64_ul() in case we want to be safe &amp; cheap.  Thirdly, if dirty
thresholds are larger than 1&lt;&lt;32 pages, then dirty balancing is going to
blow up in many other spectacular ways anyway so trying to fix one
possible overflow is just moot.(CVE-2024-42102)

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:

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 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:

f2fs: check validation of fault attrs in f2fs_build_fault_attr()

- It missed to check validation of fault attrs in parse_options(),
let&apos;s fix to add check condition in f2fs_build_fault_attr().
- Use f2fs_build_fault_attr() in __sbi_store() to clean up code.(CVE-2024-42160)

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:

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)</Note>
		<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-20.03-LTS-SP4.

openEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.</Note>
		<Note Title="Severity" Type="General" Ordinal="5" xml:lang="en">High</Note>
		<Note Title="Affected Component" Type="General" Ordinal="6" xml:lang="en">kernel</Note>
	</DocumentNotes>
	<DocumentReferences>
		<Reference Type="Self">
			<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1996</URL>
		</Reference>
		<Reference Type="openEuler CVE">
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48860</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-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-41046</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41059</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-41087</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42084</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-42089</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-42102</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-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-42157</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42160</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-42244</URL>
		</Reference>
		<Reference Type="Other">
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48860</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39509</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-41046</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41059</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41065</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41087</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42084</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42087</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42089</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42096</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42102</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42105</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-42157</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42160</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42223</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42244</URL>
		</Reference>
	</DocumentReferences>
	<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
		<Branch Type="Product Name" Name="openEuler">
			<FullProductName ProductID="openEuler-20.03-LTS-SP4" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">openEuler-20.03-LTS-SP4</FullProductName>
		</Branch>
		<Branch Type="Package Arch" Name="aarch64">
			<FullProductName ProductID="bpftool-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-4.19.90-2408.3.0.0290.oe2003sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="bpftool-debuginfo-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-debuginfo-4.19.90-2408.3.0.0290.oe2003sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2408.3.0.0290.oe2003sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-debuginfo-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debuginfo-4.19.90-2408.3.0.0290.oe2003sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-debugsource-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debugsource-4.19.90-2408.3.0.0290.oe2003sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-devel-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-devel-4.19.90-2408.3.0.0290.oe2003sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-source-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-source-4.19.90-2408.3.0.0290.oe2003sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-4.19.90-2408.3.0.0290.oe2003sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-debuginfo-4.19.90-2408.3.0.0290.oe2003sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-devel-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-devel-4.19.90-2408.3.0.0290.oe2003sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="perf-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-4.19.90-2408.3.0.0290.oe2003sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="perf-debuginfo-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-debuginfo-4.19.90-2408.3.0.0290.oe2003sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="python2-perf-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-4.19.90-2408.3.0.0290.oe2003sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-debuginfo-4.19.90-2408.3.0.0290.oe2003sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="python3-perf-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-4.19.90-2408.3.0.0290.oe2003sp4.aarch64.rpm</FullProductName>
			<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-debuginfo-4.19.90-2408.3.0.0290.oe2003sp4.aarch64.rpm</FullProductName>
		</Branch>
		<Branch Type="Package Arch" Name="x86_64">
			<FullProductName ProductID="bpftool-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-4.19.90-2408.3.0.0290.oe2003sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="bpftool-debuginfo-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-debuginfo-4.19.90-2408.3.0.0290.oe2003sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2408.3.0.0290.oe2003sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-debuginfo-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debuginfo-4.19.90-2408.3.0.0290.oe2003sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-debugsource-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debugsource-4.19.90-2408.3.0.0290.oe2003sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-devel-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-devel-4.19.90-2408.3.0.0290.oe2003sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-source-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-source-4.19.90-2408.3.0.0290.oe2003sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-4.19.90-2408.3.0.0290.oe2003sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-debuginfo-4.19.90-2408.3.0.0290.oe2003sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-devel-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-devel-4.19.90-2408.3.0.0290.oe2003sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="perf-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-4.19.90-2408.3.0.0290.oe2003sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="perf-debuginfo-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-debuginfo-4.19.90-2408.3.0.0290.oe2003sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="python2-perf-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-4.19.90-2408.3.0.0290.oe2003sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-debuginfo-4.19.90-2408.3.0.0290.oe2003sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="python3-perf-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-4.19.90-2408.3.0.0290.oe2003sp4.x86_64.rpm</FullProductName>
			<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-debuginfo-4.19.90-2408.3.0.0290.oe2003sp4.x86_64.rpm</FullProductName>
		</Branch>
		<Branch Type="Package Arch" Name="src">
			<FullProductName ProductID="kernel-4.19.90-2408.3.0.0290" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2408.3.0.0290.oe2003sp4.src.rpm</FullProductName>
		</Branch>
	</ProductTree>
	<Vulnerability Ordinal="1" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:ethernet: Fix error handling in xemaclite_of_probeThis node pointer is returned by of_parse_phandle() with refcountincremented in this function. Calling of_node_put() to avoid therefcount leak. As the remove function do.</Note>
		</Notes>
		<ReleaseDate>2024-08-16</ReleaseDate>
		<CVE>CVE-2022-48860</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-20.03-LTS-SP4</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-08-16</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1996</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:

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-20.03-LTS-SP4</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-08-16</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1996</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
	<Vulnerability Ordinal="3" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

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-20.03-LTS-SP4</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>6.3</BaseScore>
				<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-08-16</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1996</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:

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-20.03-LTS-SP4</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-08-16</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1996</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:

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-20.03-LTS-SP4</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-08-16</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1996</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:

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-20.03-LTS-SP4</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>6.7</BaseScore>
				<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-08-16</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1996</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:

hfsplus: fix uninit-value in copy_name

[syzbot reported]
BUG: KMSAN: uninit-value in sized_strscpy+0xc4/0x160
 sized_strscpy+0xc4/0x160
 copy_name+0x2af/0x320 fs/hfsplus/xattr.c:411
 hfsplus_listxattr+0x11e9/0x1a50 fs/hfsplus/xattr.c:750
 vfs_listxattr fs/xattr.c:493 [inline]
 listxattr+0x1f3/0x6b0 fs/xattr.c:840
 path_listxattr fs/xattr.c:864 [inline]
 __do_sys_listxattr fs/xattr.c:876 [inline]
 __se_sys_listxattr fs/xattr.c:873 [inline]
 __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873
 x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Uninit was created at:
 slab_post_alloc_hook mm/slub.c:3877 [inline]
 slab_alloc_node mm/slub.c:3918 [inline]
 kmalloc_trace+0x57b/0xbe0 mm/slub.c:4065
 kmalloc include/linux/slab.h:628 [inline]
 hfsplus_listxattr+0x4cc/0x1a50 fs/hfsplus/xattr.c:699
 vfs_listxattr fs/xattr.c:493 [inline]
 listxattr+0x1f3/0x6b0 fs/xattr.c:840
 path_listxattr fs/xattr.c:864 [inline]
 __do_sys_listxattr fs/xattr.c:876 [inline]
 __se_sys_listxattr fs/xattr.c:873 [inline]
 __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873
 x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
[Fix]
When allocating memory to strbuf, initialize memory to 0.</Note>
		</Notes>
		<ReleaseDate>2024-08-16</ReleaseDate>
		<CVE>CVE-2024-41059</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-20.03-LTS-SP4</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>High</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>7.8</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-08-16</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1996</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:

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-20.03-LTS-SP4</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>4.4</BaseScore>
				<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-08-16</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1996</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:

ata: libata-core: Fix double free on error

If e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jump
to the err_out label, which will call devres_release_group().
devres_release_group() will trigger a call to ata_host_release().
ata_host_release() calls kfree(host), so executing the kfree(host) in
ata_host_alloc() will lead to a double free:

kernel BUG at mm/slub.c:553!
Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
RIP: 0010:kfree+0x2cf/0x2f0
Code: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da
RSP: 0018:ffffc90000f377f0 EFLAGS: 00010246
RAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320
RDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0
RBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000
R10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780
R13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006
FS:  00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 ? __die_body.cold+0x19/0x27
 ? die+0x2e/0x50
 ? do_trap+0xca/0x110
 ? do_error_trap+0x6a/0x90
 ? kfree+0x2cf/0x2f0
 ? exc_invalid_op+0x50/0x70
 ? kfree+0x2cf/0x2f0
 ? asm_exc_invalid_op+0x1a/0x20
 ? ata_host_alloc+0xf5/0x120 [libata]
 ? ata_host_alloc+0xf5/0x120 [libata]
 ? kfree+0x2cf/0x2f0
 ata_host_alloc+0xf5/0x120 [libata]
 ata_host_alloc_pinfo+0x14/0xa0 [libata]
 ahci_init_one+0x6c9/0xd20 [ahci]

Ensure that we will not call kfree(host) twice, by performing the kfree()
only if the devres_open_group() call failed.</Note>
		</Notes>
		<ReleaseDate>2024-08-16</ReleaseDate>
		<CVE>CVE-2024-41087</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-20.03-LTS-SP4</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>High</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>7.8</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-08-16</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1996</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:

ftruncate: pass a signed offset

The old ftruncate() syscall, using the 32-bit off_t misses a sign
extension when called in compat mode on 64-bit architectures.  As a
result, passing a negative length accidentally succeeds in truncating
to file size between 2GiB and 4GiB.

Changing the type of the compat syscall to the signed compat_off_t
changes the behavior so it instead returns -EINVAL.

The native entry point, the truncate() syscall and the corresponding
loff_t based variants are all correct already and do not suffer
from this mistake.</Note>
		</Notes>
		<ReleaseDate>2024-08-16</ReleaseDate>
		<CVE>CVE-2024-42084</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-20.03-LTS-SP4</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-08-16</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1996</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:

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-20.03-LTS-SP4</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Low</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>3.3</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-08-16</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1996</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:

ASoC: fsl-asoc-card: set priv-&gt;pdev before using it

priv-&gt;pdev pointer was set after being used in
fsl_asoc_card_audmux_init().
Move this assignment at the start of the probe function, so
sub-functions can correctly use pdev through priv.

fsl_asoc_card_audmux_init() dereferences priv-&gt;pdev to get access to the
dev struct, used with dev_err macros.
As priv is zero-initialised, there would be a NULL pointer dereference.
Note that if priv-&gt;dev is dereferenced before assignment but never used,
for example if there is no error to be printed, the driver won&apos;t crash
probably due to compiler optimisations.</Note>
		</Notes>
		<ReleaseDate>2024-08-16</ReleaseDate>
		<CVE>CVE-2024-42089</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-20.03-LTS-SP4</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-08-16</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1996</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:

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-20.03-LTS-SP4</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-08-16</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1996</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:

Revert &quot;mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again&quot;

Patch series &quot;mm: Avoid possible overflows in dirty throttling&quot;.

Dirty throttling logic assumes dirty limits in page units fit into
32-bits.  This patch series makes sure this is true (see patch 2/2 for
more details).


This patch (of 2):

This reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78.

The commit is broken in several ways.  Firstly, the removed (u64) cast
from the multiplication will introduce a multiplication overflow on 32-bit
archs if wb_thresh * bg_thresh &gt;= 1&lt;&lt;32 (which is actually common - the
default settings with 4GB of RAM will trigger this).  Secondly, the
div64_u64() is unnecessarily expensive on 32-bit archs.  We have
div64_ul() in case we want to be safe &amp; cheap.  Thirdly, if dirty
thresholds are larger than 1&lt;&lt;32 pages, then dirty balancing is going to
blow up in many other spectacular ways anyway so trying to fix one
possible overflow is just moot.</Note>
		</Notes>
		<ReleaseDate>2024-08-16</ReleaseDate>
		<CVE>CVE-2024-42102</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-20.03-LTS-SP4</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-08-16</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1996</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:

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-20.03-LTS-SP4</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>6.1</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-08-16</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1996</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:

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-20.03-LTS-SP4</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-08-16</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1996</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:

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-20.03-LTS-SP4</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-08-16</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1996</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: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-20.03-LTS-SP4</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-08-16</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1996</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:

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-20.03-LTS-SP4</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>4.1</BaseScore>
				<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-08-16</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1996</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:

f2fs: check validation of fault attrs in f2fs_build_fault_attr()

- It missed to check validation of fault attrs in parse_options(),
let&apos;s fix to add check condition in f2fs_build_fault_attr().
- Use f2fs_build_fault_attr() in __sbi_store() to clean up code.</Note>
		</Notes>
		<ReleaseDate>2024-08-16</ReleaseDate>
		<CVE>CVE-2024-42160</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-20.03-LTS-SP4</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>High</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>7.8</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-08-16</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1996</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: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-20.03-LTS-SP4</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-08-16</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1996</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:

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-20.03-LTS-SP4</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-08-16</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1996</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
</cvrfdoc>