1812 lines
79 KiB
XML
1812 lines
79 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
|
|
<DocumentTitle xml:lang="en">An update for kernel is now available for openEuler-20.03-LTS-SP4</DocumentTitle>
|
|
<DocumentType>Security Advisory</DocumentType>
|
|
<DocumentPublisher Type="Vendor">
|
|
<ContactDetails>openeuler-security@openeuler.org</ContactDetails>
|
|
<IssuingAuthority>openEuler security committee</IssuingAuthority>
|
|
</DocumentPublisher>
|
|
<DocumentTracking>
|
|
<Identification>
|
|
<ID>openEuler-SA-2024-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 &= m;
|
|
...
|
|
WARN_ON may be considered superfluous. Remove it to suppress future
|
|
syzkaller triggers.
|
|
|
|
[1]
|
|
WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 implement drivers/hid/hid-core.c:1451 [inline]
|
|
WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863
|
|
Modules linked in:
|
|
CPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
|
|
RIP: 0010:implement drivers/hid/hid-core.c:1451 [inline]
|
|
RIP: 0010:hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863
|
|
...
|
|
Call Trace:
|
|
<TASK>
|
|
__usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [inline]
|
|
usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid-core.c:636
|
|
hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726
|
|
vfs_ioctl fs/ioctl.c:51 [inline]
|
|
__do_sys_ioctl fs/ioctl.c:904 [inline]
|
|
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
|
...(CVE-2024-39509)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
filelock: Remove locks reliably when fcntl/close race is detected
|
|
|
|
When fcntl_setlk() races with close(), it removes the created lock with
|
|
do_lock_file_wait().
|
|
However, LSMs can allow the first do_lock_file_wait() that created the lock
|
|
while denying the second do_lock_file_wait() that tries to remove the lock.
|
|
Separately, posix_lock_file() could also fail to
|
|
remove a lock due to GFP_KERNEL allocation failure (when splitting a range
|
|
in the middle).
|
|
|
|
After the bug has been triggered, use-after-free reads will occur in
|
|
lock_get_status() when userspace reads /proc/locks. This can likely be used
|
|
to read arbitrary kernel memory, but can't corrupt kernel memory.
|
|
|
|
Fix it by calling locks_remove_posix() instead, which is designed to
|
|
reliably get rid of POSIX locks associated with the given file and
|
|
files_struct and is also used by filp_flush().(CVE-2024-41012)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nilfs2: fix kernel bug on rename operation of broken directory
|
|
|
|
Syzbot reported that in rename directory operation on broken directory on
|
|
nilfs2, __block_write_begin_int() called to prepare block write may fail
|
|
BUG_ON check for access exceeding the folio/page size.
|
|
|
|
This is because nilfs_dotdot(), which gets parent directory reference
|
|
entry ("..") of the directory to be moved or renamed, does not check
|
|
consistency enough, and may return location exceeding folio/page size for
|
|
broken directories.
|
|
|
|
Fix this issue by checking required directory entries ("." and "..") in
|
|
the first chunk of the directory in nilfs_dotdot().(CVE-2024-41034)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor
|
|
|
|
Syzbot has identified a bug in usbcore (see the Closes: tag below)
|
|
caused by our assumption that the reserved bits in an endpoint
|
|
descriptor's bEndpointAddress field will always be 0. As a result of
|
|
the bug, the endpoint_is_duplicate() routine in config.c (and possibly
|
|
other routines as well) may believe that two descriptors are for
|
|
distinct endpoints, even though they have the same direction and
|
|
endpoint number. This can lead to confusion, including the bug
|
|
identified by syzbot (two descriptors with matching endpoint numbers
|
|
and directions, where one was interrupt and the other was bulk).
|
|
|
|
To fix the bug, we will clear the reserved bits in bEndpointAddress
|
|
when we parse the descriptor. (Note that both the USB-2.0 and USB-3.1
|
|
specs say these bits are "Reserved, reset to zero".) This requires us
|
|
to make a copy of the descriptor earlier in usb_parse_endpoint() and
|
|
use the copy instead of the original when checking for duplicates.(CVE-2024-41035)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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 <SF,EE,ME,IR,DR,RI,LE> CR: 2828220f XER: 0000000e
|
|
CFAR: c0000000001fdc80 IRQMASK: 0
|
|
[ ... GPRs omitted ... ]
|
|
NIP [c0000000005d23d4] usercopy_abort+0x78/0xb0
|
|
LR [c0000000005d23d0] usercopy_abort+0x74/0xb0
|
|
Call Trace:
|
|
usercopy_abort+0x74/0xb0 (unreliable)
|
|
__check_heap_object+0xf8/0x120
|
|
check_heap_object+0x218/0x240
|
|
__check_object_size+0x84/0x1a4
|
|
dtl_file_read+0x17c/0x2c4
|
|
full_proxy_read+0x8c/0x110
|
|
vfs_read+0xdc/0x3a0
|
|
ksys_read+0x84/0x144
|
|
system_call_exception+0x124/0x330
|
|
system_call_vectored_common+0x15c/0x2ec
|
|
--- interrupt: 3000 at 0x7fff81f3ab34
|
|
|
|
Commit 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0")
|
|
requires that only whitelisted areas in slab/slub objects can be copied to
|
|
userspace when usercopy hardening is enabled using CONFIG_HARDENED_USERCOPY.
|
|
Dtl contains hypervisor dispatch events which are expected to be read by
|
|
privileged users. Hence mark this safe for user access.
|
|
Specify useroffset=0 and usersize=DISPATCH_LOG_BYTES to whitelist the
|
|
entire object.(CVE-2024-41065)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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:
|
|
<TASK>
|
|
? __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->pdev before using it
|
|
|
|
priv->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->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->dev is dereferenced before assignment but never used,
|
|
for example if there is no error to be printed, the driver won'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 'profile_pc()' function is used for timer-based profiling, which
|
|
isn't really all that relevant any more to begin with, but it also ends
|
|
up making assumptions based on the stack layout that aren't necessarily
|
|
valid.
|
|
|
|
Basically, the code tries to account the time spent in spinlocks to the
|
|
caller rather than the spinlock, and while I support that as a concept,
|
|
it's not worth the code complexity or the KASAN warnings when no serious
|
|
profiling is done using timers anyway these days.
|
|
|
|
And the code really does depend on stack layout that is only true in the
|
|
simplest of cases. We've lost the comment at some point (I think when
|
|
the 32-bit and 64-bit code was unified), but it used to say:
|
|
|
|
Assume the lock function has either no stack frame or a copy
|
|
of eflags from PUSHF.
|
|
|
|
which explains why it just blindly loads a word or two straight off the
|
|
stack pointer and then takes a minimal look at the values to just check
|
|
if they might be eflags or the return pc:
|
|
|
|
Eflags always has bits 22 and up cleared unlike kernel addresses
|
|
|
|
but that basic stack layout assumption assumes that there isn't any lock
|
|
debugging etc going on that would complicate the code and cause a stack
|
|
frame.
|
|
|
|
It causes KASAN unhappiness reported for years by syzkaller [1] and
|
|
others [2].
|
|
|
|
With no real practical reason for this any more, just remove the code.
|
|
|
|
Just for historical interest, here's some background commits relating to
|
|
this code from 2006:
|
|
|
|
0cb91a229364 ("i386: Account spinlocks to the caller during profiling for !FP kernels")
|
|
31679f38d886 ("Simplify profile_pc on x86-64")
|
|
|
|
and a code unification from 2009:
|
|
|
|
ef4512882dbe ("x86: time_32/64.c unify profile_pc")
|
|
|
|
but the basics of this thing actually goes back to before the git tree.(CVE-2024-42096)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Revert "mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again"
|
|
|
|
Patch series "mm: Avoid possible overflows in dirty throttling".
|
|
|
|
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 >= 1<<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 & cheap. Thirdly, if dirty
|
|
thresholds are larger than 1<<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 "nilfs2: fix potential issues related to reserved inodes".
|
|
|
|
This series fixes one use-after-free issue reported by syzbot, caused by
|
|
nilfs2's internal inode being exposed in the namespace on a corrupted
|
|
filesystem, and a couple of flaws that cause problems if the starting
|
|
number of non-reserved inodes written in the on-disk super block is
|
|
intentionally (or corruptly) changed from its default value.
|
|
|
|
|
|
This patch (of 3):
|
|
|
|
In the current implementation of nilfs2, "nilfs->ns_first_ino", which
|
|
gives the first non-reserved inode number, is read from the superblock,
|
|
but its lower limit is not checked.
|
|
|
|
As a result, if a number that overlaps with the inode number range of
|
|
reserved inodes such as the root directory or metadata files is set in the
|
|
super block parameter, the inode number test macros (NILFS_MDT_INODE and
|
|
NILFS_VALID_INODE) will not function properly.
|
|
|
|
In addition, these test macros use left bit-shift calculations using with
|
|
the inode number as the shift count via the BIT macro, but the result of a
|
|
shift calculation that exceeds the bit width of an integer is undefined in
|
|
the C specification, so if "ns_first_ino" is set to a large value other
|
|
than the default value NILFS_USER_INO (=11), the macros may potentially
|
|
malfunction depending on the environment.
|
|
|
|
Fix these issues by checking the lower bound of "nilfs->ns_first_ino" and
|
|
by preventing bit shifts equal to or greater than the NILFS_USER_INO
|
|
constant in the inode number test macros.
|
|
|
|
Also, change the type of "ns_first_ino" from signed integer to unsigned
|
|
integer to avoid the need for type casting in comparisons such as the
|
|
lower bound check introduced this time.(CVE-2024-42105)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
orangefs: fix out-of-bounds fsid access
|
|
|
|
Arnd Bergmann sent a patch to fsdevel, he says:
|
|
|
|
"orangefs_statfs() copies two consecutive fields of the superblock into
|
|
the statfs structure, which triggers a warning from the string fortification
|
|
helpers"
|
|
|
|
Jan Kara suggested an alternate way to do the patch to make it more readable.
|
|
|
|
I ran both ideas through xfstests and both seem fine. This patch
|
|
is based on Jan Kara's suggestion.(CVE-2024-42143)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
bnx2x: Fix multiple UBSAN array-index-out-of-bounds
|
|
|
|
Fix UBSAN warnings that occur when using a system with 32 physical
|
|
cpu cores or more, or when the user defines a number of Ethernet
|
|
queues greater than or equal to FP_SB_MAX_E1x using the num_queues
|
|
module parameter.
|
|
|
|
Currently there is a read/write out of bounds that occurs on the array
|
|
"struct stats_query_entry query" present inside the "bnx2x_fw_stats_req"
|
|
struct in "drivers/net/ethernet/broadcom/bnx2x/bnx2x.h".
|
|
Looking at the definition of the "struct stats_query_entry query" array:
|
|
|
|
struct stats_query_entry query[FP_SB_MAX_E1x+
|
|
BNX2X_FIRST_QUEUE_QUERY_IDX];
|
|
|
|
FP_SB_MAX_E1x is defined as the maximum number of fast path interrupts and
|
|
has a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3
|
|
meaning the array has a total size of 19.
|
|
Since accesses to "struct stats_query_entry query" are offset-ted by
|
|
BNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernet
|
|
queues should not exceed FP_SB_MAX_E1x (16). However one of these queues
|
|
is reserved for FCOE and thus the number of Ethernet queues should be set
|
|
to [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) if
|
|
it is not.
|
|
|
|
This is also described in a comment in the source code in
|
|
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definition
|
|
of FP_SB_MAX_E1x. Below is the part of this explanation that it important
|
|
for this patch
|
|
|
|
/*
|
|
* The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is
|
|
* control by the number of fast-path status blocks supported by the
|
|
* device (HW/FW). Each fast-path status block (FP-SB) aka non-default
|
|
* status block represents an independent interrupts context that can
|
|
* serve a regular L2 networking queue. However special L2 queues such
|
|
* as the FCoE queue do not require a FP-SB and other components like
|
|
* the CNIC may consume FP-SB reducing the number of possible L2 queues
|
|
*
|
|
* If the maximum number of FP-SB available is X then:
|
|
* a. If CNIC is supported it consumes 1 FP-SB thus the max number of
|
|
* regular L2 queues is Y=X-1
|
|
* b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor)
|
|
* c. If the FCoE L2 queue is supported the actual number of L2 queues
|
|
* is Y+1
|
|
* d. The number of irqs (MSIX vectors) is either Y+1 (one extra for
|
|
* slow-path interrupts) or Y+2 if CNIC is supported (one additional
|
|
* FP interrupt context for the CNIC).
|
|
* e. The number of HW context (CID count) is always X or X+1 if FCoE
|
|
* L2 queue is supported. The cid for the FCoE L2 queue is always X.
|
|
*/
|
|
|
|
However this driver also supports NICs that use the E2 controller which can
|
|
handle more queues due to having more FP-SB represented by FP_SB_MAX_E2.
|
|
Looking at the commits when the E2 support was added, it was originally
|
|
using the E1x parameters: commit f2e0899f0f27 ("bnx2x: Add 57712 support").
|
|
Back then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driver
|
|
was later updated to take full advantage of the E2 instead of having it be
|
|
limited to the capabilities of the E1x. But as far as we can tell, the
|
|
array "stats_query_entry query" was still limited to using the FP-SB
|
|
available to the E1x cards as part of an oversignt when the driver was
|
|
updated to take full advantage of the E2, and now with the driver being
|
|
aware of the greater queue size supported by E2 NICs, it causes the UBSAN
|
|
warnings seen in the stack traces below.
|
|
|
|
This patch increases the size of the "stats_query_entry query" array by
|
|
replacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handle
|
|
both types of NICs.
|
|
|
|
Stack traces:
|
|
|
|
UBSAN: array-index-out-of-bounds in
|
|
drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11
|
|
index 20 is out of range for type 'stats_query_entry [19]'
|
|
CPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic
|
|
#202405052133
|
|
Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360
|
|
---truncated---(CVE-2024-42148)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tcp_metrics: validate source addr length
|
|
|
|
I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4
|
|
is at least 4 bytes long, and the policy doesn't have an entry
|
|
for this attribute at all (neither does it for IPv6 but v6 is
|
|
manually validated).(CVE-2024-42154)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
s390/pkey: Wipe 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'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->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 ("USB: serial: use generic method if no
|
|
alternative is provided in usb serial layer"), USB serial core calls the
|
|
generic resume implementation when the driver has not provided one.
|
|
|
|
This can trigger a crash on resume with mos7840 since support for
|
|
multiple read URBs was added back in 2011. Specifically, both port read
|
|
URBs are now submitted on resume for open ports, but the context pointer
|
|
of the second URB is left set to the core rather than mos7840 port
|
|
structure.
|
|
|
|
Fix this by implementing dedicated suspend and resume functions for
|
|
mos7840.
|
|
|
|
Tested with Delock 87414 USB 2.0 to 4x serial adapter.
|
|
|
|
[ johan: analyse crash and rewrite commit message; set busy flag on
|
|
resume; drop bulk-in check; drop unnecessary usb_kill_urb() ](CVE-2024-42244)</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 &= m;
|
|
...
|
|
WARN_ON may be considered superfluous. Remove it to suppress future
|
|
syzkaller triggers.
|
|
|
|
[1]
|
|
WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 implement drivers/hid/hid-core.c:1451 [inline]
|
|
WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863
|
|
Modules linked in:
|
|
CPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
|
|
RIP: 0010:implement drivers/hid/hid-core.c:1451 [inline]
|
|
RIP: 0010:hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863
|
|
...
|
|
Call Trace:
|
|
<TASK>
|
|
__usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [inline]
|
|
usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid-core.c:636
|
|
hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726
|
|
vfs_ioctl fs/ioctl.c:51 [inline]
|
|
__do_sys_ioctl fs/ioctl.c:904 [inline]
|
|
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
|
...</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-39509</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-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'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 ("..") of the directory to be moved or renamed, does not check
|
|
consistency enough, and may return location exceeding folio/page size for
|
|
broken directories.
|
|
|
|
Fix this issue by checking required directory entries ("." and "..") in
|
|
the first chunk of the directory in nilfs_dotdot().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-41034</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-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's bEndpointAddress field will always be 0. As a result of
|
|
the bug, the endpoint_is_duplicate() routine in config.c (and possibly
|
|
other routines as well) may believe that two descriptors are for
|
|
distinct endpoints, even though they have the same direction and
|
|
endpoint number. This can lead to confusion, including the bug
|
|
identified by syzbot (two descriptors with matching endpoint numbers
|
|
and directions, where one was interrupt and the other was bulk).
|
|
|
|
To fix the bug, we will clear the reserved bits in bEndpointAddress
|
|
when we parse the descriptor. (Note that both the USB-2.0 and USB-3.1
|
|
specs say these bits are "Reserved, reset to zero".) This requires us
|
|
to make a copy of the descriptor earlier in usb_parse_endpoint() and
|
|
use the copy instead of the original when checking for duplicates.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-41035</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-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 <SF,EE,ME,IR,DR,RI,LE> CR: 2828220f XER: 0000000e
|
|
CFAR: c0000000001fdc80 IRQMASK: 0
|
|
[ ... GPRs omitted ... ]
|
|
NIP [c0000000005d23d4] usercopy_abort+0x78/0xb0
|
|
LR [c0000000005d23d0] usercopy_abort+0x74/0xb0
|
|
Call Trace:
|
|
usercopy_abort+0x74/0xb0 (unreliable)
|
|
__check_heap_object+0xf8/0x120
|
|
check_heap_object+0x218/0x240
|
|
__check_object_size+0x84/0x1a4
|
|
dtl_file_read+0x17c/0x2c4
|
|
full_proxy_read+0x8c/0x110
|
|
vfs_read+0xdc/0x3a0
|
|
ksys_read+0x84/0x144
|
|
system_call_exception+0x124/0x330
|
|
system_call_vectored_common+0x15c/0x2ec
|
|
--- interrupt: 3000 at 0x7fff81f3ab34
|
|
|
|
Commit 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0")
|
|
requires that only whitelisted areas in slab/slub objects can be copied to
|
|
userspace when usercopy hardening is enabled using CONFIG_HARDENED_USERCOPY.
|
|
Dtl contains hypervisor dispatch events which are expected to be read by
|
|
privileged users. Hence mark this safe for user access.
|
|
Specify useroffset=0 and usersize=DISPATCH_LOG_BYTES to whitelist the
|
|
entire object.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-41065</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-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:
|
|
<TASK>
|
|
? __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->pdev before using it
|
|
|
|
priv->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->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->dev is dereferenced before assignment but never used,
|
|
for example if there is no error to be printed, the driver won'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 'profile_pc()' function is used for timer-based profiling, which
|
|
isn't really all that relevant any more to begin with, but it also ends
|
|
up making assumptions based on the stack layout that aren't necessarily
|
|
valid.
|
|
|
|
Basically, the code tries to account the time spent in spinlocks to the
|
|
caller rather than the spinlock, and while I support that as a concept,
|
|
it's not worth the code complexity or the KASAN warnings when no serious
|
|
profiling is done using timers anyway these days.
|
|
|
|
And the code really does depend on stack layout that is only true in the
|
|
simplest of cases. We've lost the comment at some point (I think when
|
|
the 32-bit and 64-bit code was unified), but it used to say:
|
|
|
|
Assume the lock function has either no stack frame or a copy
|
|
of eflags from PUSHF.
|
|
|
|
which explains why it just blindly loads a word or two straight off the
|
|
stack pointer and then takes a minimal look at the values to just check
|
|
if they might be eflags or the return pc:
|
|
|
|
Eflags always has bits 22 and up cleared unlike kernel addresses
|
|
|
|
but that basic stack layout assumption assumes that there isn't any lock
|
|
debugging etc going on that would complicate the code and cause a stack
|
|
frame.
|
|
|
|
It causes KASAN unhappiness reported for years by syzkaller [1] and
|
|
others [2].
|
|
|
|
With no real practical reason for this any more, just remove the code.
|
|
|
|
Just for historical interest, here's some background commits relating to
|
|
this code from 2006:
|
|
|
|
0cb91a229364 ("i386: Account spinlocks to the caller during profiling for !FP kernels")
|
|
31679f38d886 ("Simplify profile_pc on x86-64")
|
|
|
|
and a code unification from 2009:
|
|
|
|
ef4512882dbe ("x86: time_32/64.c unify profile_pc")
|
|
|
|
but the basics of this thing actually goes back to before the git tree.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-42096</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-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 "mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again"
|
|
|
|
Patch series "mm: Avoid possible overflows in dirty throttling".
|
|
|
|
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 >= 1<<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 & cheap. Thirdly, if dirty
|
|
thresholds are larger than 1<<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 "nilfs2: fix potential issues related to reserved inodes".
|
|
|
|
This series fixes one use-after-free issue reported by syzbot, caused by
|
|
nilfs2's internal inode being exposed in the namespace on a corrupted
|
|
filesystem, and a couple of flaws that cause problems if the starting
|
|
number of non-reserved inodes written in the on-disk super block is
|
|
intentionally (or corruptly) changed from its default value.
|
|
|
|
|
|
This patch (of 3):
|
|
|
|
In the current implementation of nilfs2, "nilfs->ns_first_ino", which
|
|
gives the first non-reserved inode number, is read from the superblock,
|
|
but its lower limit is not checked.
|
|
|
|
As a result, if a number that overlaps with the inode number range of
|
|
reserved inodes such as the root directory or metadata files is set in the
|
|
super block parameter, the inode number test macros (NILFS_MDT_INODE and
|
|
NILFS_VALID_INODE) will not function properly.
|
|
|
|
In addition, these test macros use left bit-shift calculations using with
|
|
the inode number as the shift count via the BIT macro, but the result of a
|
|
shift calculation that exceeds the bit width of an integer is undefined in
|
|
the C specification, so if "ns_first_ino" is set to a large value other
|
|
than the default value NILFS_USER_INO (=11), the macros may potentially
|
|
malfunction depending on the environment.
|
|
|
|
Fix these issues by checking the lower bound of "nilfs->ns_first_ino" and
|
|
by preventing bit shifts equal to or greater than the NILFS_USER_INO
|
|
constant in the inode number test macros.
|
|
|
|
Also, change the type of "ns_first_ino" from signed integer to unsigned
|
|
integer to avoid the need for type casting in comparisons such as the
|
|
lower bound check introduced this time.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-42105</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-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:
|
|
|
|
"orangefs_statfs() copies two consecutive fields of the superblock into
|
|
the statfs structure, which triggers a warning from the string fortification
|
|
helpers"
|
|
|
|
Jan Kara suggested an alternate way to do the patch to make it more readable.
|
|
|
|
I ran both ideas through xfstests and both seem fine. This patch
|
|
is based on Jan Kara's suggestion.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-42143</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-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
|
|
"struct stats_query_entry query" present inside the "bnx2x_fw_stats_req"
|
|
struct in "drivers/net/ethernet/broadcom/bnx2x/bnx2x.h".
|
|
Looking at the definition of the "struct stats_query_entry query" array:
|
|
|
|
struct stats_query_entry query[FP_SB_MAX_E1x+
|
|
BNX2X_FIRST_QUEUE_QUERY_IDX];
|
|
|
|
FP_SB_MAX_E1x is defined as the maximum number of fast path interrupts and
|
|
has a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3
|
|
meaning the array has a total size of 19.
|
|
Since accesses to "struct stats_query_entry query" are offset-ted by
|
|
BNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernet
|
|
queues should not exceed FP_SB_MAX_E1x (16). However one of these queues
|
|
is reserved for FCOE and thus the number of Ethernet queues should be set
|
|
to [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) if
|
|
it is not.
|
|
|
|
This is also described in a comment in the source code in
|
|
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definition
|
|
of FP_SB_MAX_E1x. Below is the part of this explanation that it important
|
|
for this patch
|
|
|
|
/*
|
|
* The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is
|
|
* control by the number of fast-path status blocks supported by the
|
|
* device (HW/FW). Each fast-path status block (FP-SB) aka non-default
|
|
* status block represents an independent interrupts context that can
|
|
* serve a regular L2 networking queue. However special L2 queues such
|
|
* as the FCoE queue do not require a FP-SB and other components like
|
|
* the CNIC may consume FP-SB reducing the number of possible L2 queues
|
|
*
|
|
* If the maximum number of FP-SB available is X then:
|
|
* a. If CNIC is supported it consumes 1 FP-SB thus the max number of
|
|
* regular L2 queues is Y=X-1
|
|
* b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor)
|
|
* c. If the FCoE L2 queue is supported the actual number of L2 queues
|
|
* is Y+1
|
|
* d. The number of irqs (MSIX vectors) is either Y+1 (one extra for
|
|
* slow-path interrupts) or Y+2 if CNIC is supported (one additional
|
|
* FP interrupt context for the CNIC).
|
|
* e. The number of HW context (CID count) is always X or X+1 if FCoE
|
|
* L2 queue is supported. The cid for the FCoE L2 queue is always X.
|
|
*/
|
|
|
|
However this driver also supports NICs that use the E2 controller which can
|
|
handle more queues due to having more FP-SB represented by FP_SB_MAX_E2.
|
|
Looking at the commits when the E2 support was added, it was originally
|
|
using the E1x parameters: commit f2e0899f0f27 ("bnx2x: Add 57712 support").
|
|
Back then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driver
|
|
was later updated to take full advantage of the E2 instead of having it be
|
|
limited to the capabilities of the E1x. But as far as we can tell, the
|
|
array "stats_query_entry query" was still limited to using the FP-SB
|
|
available to the E1x cards as part of an oversignt when the driver was
|
|
updated to take full advantage of the E2, and now with the driver being
|
|
aware of the greater queue size supported by E2 NICs, it causes the UBSAN
|
|
warnings seen in the stack traces below.
|
|
|
|
This patch increases the size of the "stats_query_entry query" array by
|
|
replacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handle
|
|
both types of NICs.
|
|
|
|
Stack traces:
|
|
|
|
UBSAN: array-index-out-of-bounds in
|
|
drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11
|
|
index 20 is out of range for type 'stats_query_entry [19]'
|
|
CPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic
|
|
#202405052133
|
|
Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-42148</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-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'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->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 ("USB: serial: use generic method if no
|
|
alternative is provided in usb serial layer"), USB serial core calls the
|
|
generic resume implementation when the driver has not provided one.
|
|
|
|
This can trigger a crash on resume with mos7840 since support for
|
|
multiple read URBs was added back in 2011. Specifically, both port read
|
|
URBs are now submitted on resume for open ports, but the context pointer
|
|
of the second URB is left set to the core rather than mos7840 port
|
|
structure.
|
|
|
|
Fix this by implementing dedicated suspend and resume functions for
|
|
mos7840.
|
|
|
|
Tested with Delock 87414 USB 2.0 to 4x serial adapter.
|
|
|
|
[ johan: analyse crash and rewrite commit message; set busy flag on
|
|
resume; drop bulk-in check; drop unnecessary usb_kill_urb() ]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-16</ReleaseDate>
|
|
<CVE>CVE-2024-42244</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-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> |