2192 lines
98 KiB
XML
2192 lines
98 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-1393</ID>
|
|
</Identification>
|
|
<Status>Final</Status>
|
|
<Version>1.0</Version>
|
|
<RevisionHistory>
|
|
<Revision>
|
|
<Number>1.0</Number>
|
|
<Date>2024-04-12</Date>
|
|
<Description>Initial</Description>
|
|
</Revision>
|
|
</RevisionHistory>
|
|
<InitialReleaseDate>2024-04-12</InitialReleaseDate>
|
|
<CurrentReleaseDate>2024-04-12</CurrentReleaseDate>
|
|
<Generator>
|
|
<Engine>openEuler SA Tool V1.0</Engine>
|
|
<Date>2024-04-12</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:
|
|
|
|
media: dvbdev: Fix memory leak in dvb_media_device_free()
|
|
|
|
dvb_media_device_free() is leaking memory. Free `dvbdev->adapter->conn`
|
|
before setting it to NULL, as documented in include/media/media-device.h:
|
|
"The media_entity instance itself must be freed explicitly by the driver
|
|
if required."(CVE-2020-36777)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
i2c: sprd: fix reference leak when pm_runtime_get_sync fails
|
|
|
|
The PM reference count is not expected to be incremented on
|
|
return in sprd_i2c_master_xfer() and sprd_i2c_remove().
|
|
|
|
However, pm_runtime_get_sync will increment the PM reference
|
|
count even failed. Forgetting to putting operation will result
|
|
in a reference leak here.
|
|
|
|
Replace it with pm_runtime_resume_and_get to keep usage
|
|
counter balanced.(CVE-2020-36780)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
i2c: cadence: fix reference leak when pm_runtime_get_sync fails
|
|
|
|
The PM reference count is not expected to be incremented on
|
|
return in functions cdns_i2c_master_xfer and cdns_reg_slave.
|
|
|
|
However, pm_runtime_get_sync will increment pm usage counter
|
|
even failed. Forgetting to putting operation will result in a
|
|
reference leak here.
|
|
|
|
Replace it with pm_runtime_resume_and_get to keep usage
|
|
counter balanced.(CVE-2020-36784)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: hso: fix null-ptr-deref during tty device unregistration
|
|
|
|
Multiple ttys try to claim the same the minor number causing a double
|
|
unregistration of the same device. The first unregistration succeeds
|
|
but the next one results in a null-ptr-deref.
|
|
|
|
The get_free_serial_index() function returns an available minor number
|
|
but doesn't assign it immediately. The assignment is done by the caller
|
|
later. But before this assignment, calls to get_free_serial_index()
|
|
would return the same minor number.
|
|
|
|
Fix this by modifying get_free_serial_index to assign the minor number
|
|
immediately after one is found to be and rename it to obtain_minor()
|
|
to better reflect what it does. Similary, rename set_serial_by_index()
|
|
to release_minor() and modify it to free up the minor number of the
|
|
given hso_serial. Every obtain_minor() should have corresponding
|
|
release_minor() call.(CVE-2021-46904)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
NFC: st21nfca: Fix memory leak in device probe and remove
|
|
|
|
'phy->pending_skb' is alloced when device probe, but forgot to free
|
|
in the error handling path and remove path, this cause memory leak
|
|
as follows:
|
|
|
|
unreferenced object 0xffff88800bc06800 (size 512):
|
|
comm "8", pid 11775, jiffies 4295159829 (age 9.032s)
|
|
hex dump (first 32 bytes):
|
|
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
backtrace:
|
|
[<00000000d66c09ce>] __kmalloc_node_track_caller+0x1ed/0x450
|
|
[<00000000c93382b3>] kmalloc_reserve+0x37/0xd0
|
|
[<000000005fea522c>] __alloc_skb+0x124/0x380
|
|
[<0000000019f29f9a>] st21nfca_hci_i2c_probe+0x170/0x8f2
|
|
|
|
Fix it by freeing 'pending_skb' in error and remove.(CVE-2021-46924)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ALSA: hda: intel-sdw-acpi: harden detection of controller
|
|
|
|
The existing code currently sets a pointer to an ACPI handle before
|
|
checking that it's actually a SoundWire controller. This can lead to
|
|
issues where the graph walk continues and eventually fails, but the
|
|
pointer was set already.
|
|
|
|
This patch changes the logic so that the information provided to
|
|
the caller is set when a controller is found.(CVE-2021-46926)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
parisc: Clear stale IIR value on instruction access rights trap
|
|
|
|
When a trap 7 (Instruction access rights) occurs, this means the CPU
|
|
couldn't execute an instruction due to missing execute permissions on
|
|
the memory region. In this case it seems the CPU didn't even fetched
|
|
the instruction from memory and thus did not store it in the cr19 (IIR)
|
|
register before calling the trap handler. So, the trap handler will find
|
|
some random old stale value in cr19.
|
|
|
|
This patch simply overwrites the stale IIR value with a constant magic
|
|
"bad food" value (0xbaadf00d), in the hope people don't start to try to
|
|
understand the various random IIR values in trap 7 dumps.(CVE-2021-46928)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
i2c: validate user data in compat ioctl
|
|
|
|
Wrong user data may cause warning in i2c_transfer(), ex: zero msgs.
|
|
Userspace should not be able to trigger warnings, so this patch adds
|
|
validation checks for user data in compact ioctl to prevent reported
|
|
warnings(CVE-2021-46934)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
binder: fix async_free_space accounting for empty parcels
|
|
|
|
In 4.13, commit 74310e06be4d ("android: binder: Move buffer out of area shared with user space")
|
|
fixed a kernel structure visibility issue. As part of that patch,
|
|
sizeof(void *) was used as the buffer size for 0-length data payloads so
|
|
the driver could detect abusive clients sending 0-length asynchronous
|
|
transactions to a server by enforcing limits on async_free_size.
|
|
|
|
Unfortunately, on the "free" side, the accounting of async_free_space
|
|
did not add the sizeof(void *) back. The result was that up to 8-bytes of
|
|
async_free_space were leaked on every async transaction of 8-bytes or
|
|
less. These small transactions are uncommon, so this accounting issue
|
|
has gone undetected for several years.
|
|
|
|
The fix is to use "buffer_size" (the allocated buffer size) instead of
|
|
"size" (the logical buffer size) when updating the async_free_space
|
|
during the free operation. These are the same except for this
|
|
corner case of asynchronous transactions with payloads < 8 bytes.(CVE-2021-46935)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
NFS: fs_context: validate UDP retrans to prevent shift out-of-bounds
|
|
|
|
Fix shift out-of-bounds in xprt_calc_majortimeo(). This is caused
|
|
by a garbage timeout (retrans) mount option being passed to nfs mount,
|
|
in this case from syzkaller.
|
|
|
|
If the protocol is XPRT_TRANSPORT_UDP, then 'retrans' is a shift
|
|
value for a 64-bit long integer, so 'retrans' cannot be >= 64.
|
|
If it is >= 64, fail the mount and return an error.(CVE-2021-46952)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
hfsplus: prevent corruption in shrinking truncate
|
|
|
|
I believe there are some issues introduced by commit 31651c607151
|
|
("hfsplus: avoid deadlock on file truncation")
|
|
|
|
HFS+ has extent records which always contains 8 extents. In case the
|
|
first extent record in catalog file gets full, new ones are allocated from
|
|
extents overflow file.
|
|
|
|
In case shrinking truncate happens to middle of an extent record which
|
|
locates in extents overflow file, the logic in hfsplus_file_truncate() was
|
|
changed so that call to hfs_brec_remove() is not guarded any more.
|
|
|
|
Right action would be just freeing the extents that exceed the new size
|
|
inside extent record by calling hfsplus_free_extents(), and then check if
|
|
the whole extent record should be removed. However since the guard
|
|
(blk_cnt > start) is now after the call to hfs_brec_remove(), this has
|
|
unfortunate effect that the last matching extent record is removed
|
|
unconditionally.
|
|
|
|
To reproduce this issue, create a file which has at least 10 extents, and
|
|
then perform shrinking truncate into middle of the last extent record, so
|
|
that the number of remaining extents is not under or divisible by 8. This
|
|
causes the last extent record (8 extents) to be removed totally instead of
|
|
truncating into middle of it. Thus this causes corruption, and lost data.
|
|
|
|
Fix for this is simply checking if the new truncated end is below the
|
|
start of this extent record, making it safe to remove the full extent
|
|
record. However call to hfs_brec_remove() can't be moved to it's previous
|
|
place since we're dropping ->tree_lock and it can cause a race condition
|
|
and the cached info being invalidated possibly corrupting the node data.
|
|
|
|
Another issue is related to this one. When entering into the block
|
|
(blk_cnt > start) we are not holding the ->tree_lock. We break out from
|
|
the loop not holding the lock, but hfs_find_exit() does unlock it. Not
|
|
sure if it's possible for someone else to take the lock under our feet,
|
|
but it can cause hard to debug errors and premature unlocking. Even if
|
|
there's no real risk of it, the locking should still always be kept in
|
|
balance. Thus taking the lock now just before the check.(CVE-2021-46989)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
x86/kvm: Teardown PV features on boot CPU as well
|
|
|
|
Various PV features (Async PF, PV EOI, steal time) work through memory
|
|
shared with hypervisor and when we restore from hibernation we must
|
|
properly teardown all these features to make sure hypervisor doesn't
|
|
write to stale locations after we jump to the previously hibernated kernel
|
|
(which can try to place anything there). For secondary CPUs the job is
|
|
already done by kvm_cpu_down_prepare(), register syscore ops to do
|
|
the same for boot CPU.(CVE-2021-47112)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
btrfs: abort in rename_exchange if we fail to insert the second ref
|
|
|
|
Error injection stress uncovered a problem where we'd leave a dangling
|
|
inode ref if we failed during a rename_exchange. This happens because
|
|
we insert the inode ref for one side of the rename, and then for the
|
|
other side. If this second inode ref insert fails we'll leave the first
|
|
one dangling and leave a corrupt file system behind. Fix this by
|
|
aborting if we did the insert for the first inode ref.(CVE-2021-47113)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ocfs2: fix data corruption by fallocate
|
|
|
|
When fallocate punches holes out of inode size, if original isize is in
|
|
the middle of last cluster, then the part from isize to the end of the
|
|
cluster will be zeroed with buffer write, at that time isize is not yet
|
|
updated to match the new size, if writeback is kicked in, it will invoke
|
|
ocfs2_writepage()->block_write_full_page() where the pages out of inode
|
|
size will be dropped. That will cause file corruption. Fix this by
|
|
zero out eof blocks when extending the inode size.
|
|
|
|
Running the following command with qemu-image 4.2.1 can get a corrupted
|
|
coverted image file easily.
|
|
|
|
qemu-img convert -p -t none -T none -f qcow2 $qcow_image \
|
|
-O qcow2 -o compat=1.1 $qcow_image.conv
|
|
|
|
The usage of fallocate in qemu is like this, it first punches holes out
|
|
of inode size, then extend the inode size.
|
|
|
|
fallocate(11, FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE, 2276196352, 65536) = 0
|
|
fallocate(11, 0, 2276196352, 65536) = 0
|
|
|
|
v1: https://www.spinics.net/lists/linux-fsdevel/msg193999.html
|
|
v2: https://lore.kernel.org/linux-fsdevel/20210525093034.GB4112@quack2.suse.cz/T/(CVE-2021-47114)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: caif: fix memory leak in caif_device_notify
|
|
|
|
In case of caif_enroll_dev() fail, allocated
|
|
link_support won't be assigned to the corresponding
|
|
structure. So simply free allocated pointer in case
|
|
of error(CVE-2021-47122)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
apparmor: avoid crash when parsed profile name is empty
|
|
|
|
When processing a packed profile in unpack_profile() described like
|
|
|
|
"profile :ns::samba-dcerpcd /usr/lib*/samba/{,samba/}samba-dcerpcd {...}"
|
|
|
|
a string ":samba-dcerpcd" is unpacked as a fully-qualified name and then
|
|
passed to aa_splitn_fqname().
|
|
|
|
aa_splitn_fqname() treats ":samba-dcerpcd" as only containing a namespace.
|
|
Thus it returns NULL for tmpname, meanwhile tmpns is non-NULL. Later
|
|
aa_alloc_profile() crashes as the new profile name is NULL now.
|
|
|
|
general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI
|
|
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
|
|
CPU: 6 PID: 1657 Comm: apparmor_parser Not tainted 6.7.0-rc2-dirty #16
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014
|
|
RIP: 0010:strlen+0x1e/0xa0
|
|
Call Trace:
|
|
<TASK>
|
|
? strlen+0x1e/0xa0
|
|
aa_policy_init+0x1bb/0x230
|
|
aa_alloc_profile+0xb1/0x480
|
|
unpack_profile+0x3bc/0x4960
|
|
aa_unpack+0x309/0x15e0
|
|
aa_replace_profiles+0x213/0x33c0
|
|
policy_update+0x261/0x370
|
|
profile_replace+0x20e/0x2a0
|
|
vfs_write+0x2af/0xe00
|
|
ksys_write+0x126/0x250
|
|
do_syscall_64+0x46/0xf0
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
</TASK>
|
|
---[ end trace 0000000000000000 ]---
|
|
RIP: 0010:strlen+0x1e/0xa0
|
|
|
|
It seems such behaviour of aa_splitn_fqname() is expected and checked in
|
|
other places where it is called (e.g. aa_remove_profiles). Well, there
|
|
is an explicit comment "a ns name without a following profile is allowed"
|
|
inside.
|
|
|
|
AFAICS, nothing can prevent unpacked "name" to be in form like
|
|
":samba-dcerpcd" - it is passed from userspace.
|
|
|
|
Deny the whole profile set replacement in such case and inform user with
|
|
EPROTO and an explaining message.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org).(CVE-2023-52443)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drivers/amd/pm: fix a use-after-free in kv_parse_power_table
|
|
|
|
When ps allocated by kzalloc equals to NULL, kv_parse_power_table
|
|
frees adev->pm.dpm.ps that allocated before. However, after the control
|
|
flow goes through the following call chains:
|
|
|
|
kv_parse_power_table
|
|
|-> kv_dpm_init
|
|
|-> kv_dpm_sw_init
|
|
|-> kv_dpm_fini
|
|
|
|
The adev->pm.dpm.ps is used in the for loop of kv_dpm_fini after its
|
|
first free in kv_parse_power_table and causes a use-after-free bug.(CVE-2023-52469)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
perf/x86/lbr: Filter vsyscall addresses
|
|
|
|
We found that a panic can occur when a vsyscall is made while LBR sampling
|
|
is active. If the vsyscall is interrupted (NMI) for perf sampling, this
|
|
call sequence can occur (most recent at top):
|
|
|
|
__insn_get_emulate_prefix()
|
|
insn_get_emulate_prefix()
|
|
insn_get_prefixes()
|
|
insn_get_opcode()
|
|
decode_branch_type()
|
|
get_branch_type()
|
|
intel_pmu_lbr_filter()
|
|
intel_pmu_handle_irq()
|
|
perf_event_nmi_handler()
|
|
|
|
Within __insn_get_emulate_prefix() at frame 0, a macro is called:
|
|
|
|
peek_nbyte_next(insn_byte_t, insn, i)
|
|
|
|
Within this macro, this dereference occurs:
|
|
|
|
(insn)->next_byte
|
|
|
|
Inspecting registers at this point, the value of the next_byte field is the
|
|
address of the vsyscall made, for example the location of the vsyscall
|
|
version of gettimeofday() at 0xffffffffff600000. The access to an address
|
|
in the vsyscall region will trigger an oops due to an unhandled page fault.
|
|
|
|
To fix the bug, filtering for vsyscalls can be done when
|
|
determining the branch type. This patch will return
|
|
a "none" branch if a kernel address if found to lie in the
|
|
vsyscall region.(CVE-2023-52476)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: nfc: fix races in nfc_llcp_sock_get() and nfc_llcp_sock_get_sn()
|
|
|
|
Sili Luo reported a race in nfc_llcp_sock_get(), leading to UAF.
|
|
|
|
Getting a reference on the socket found in a lookup while
|
|
holding a lock should happen before releasing the lock.
|
|
|
|
nfc_llcp_sock_get_sn() has a similar problem.
|
|
|
|
Finally nfc_llcp_recv_snl() needs to make sure the socket
|
|
found by nfc_llcp_sock_from_sn() does not disappear.(CVE-2023-52502)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ravb: Fix use-after-free issue in ravb_tx_timeout_work()
|
|
|
|
The ravb_stop() should call cancel_work_sync(). Otherwise,
|
|
ravb_tx_timeout_work() is possible to use the freed priv after
|
|
ravb_remove() was called like below:
|
|
|
|
CPU0 CPU1
|
|
ravb_tx_timeout()
|
|
ravb_remove()
|
|
unregister_netdev()
|
|
free_netdev(ndev)
|
|
// free priv
|
|
ravb_tx_timeout_work()
|
|
// use priv
|
|
|
|
unregister_netdev() will call .ndo_stop() so that ravb_stop() is
|
|
called. And, after phy_stop() is called, netif_carrier_off()
|
|
is also called. So that .ndo_tx_timeout() will not be called
|
|
after phy_stop().(CVE-2023-52509)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
jfs: fix array-index-out-of-bounds in diNewExt
|
|
|
|
[Syz report]
|
|
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_imap.c:2360:2
|
|
index -878706688 is out of range for type 'struct iagctl[128]'
|
|
CPU: 1 PID: 5065 Comm: syz-executor282 Not tainted 6.7.0-rc4-syzkaller-00009-gbee0e7762ad2 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
|
|
ubsan_epilogue lib/ubsan.c:217 [inline]
|
|
__ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348
|
|
diNewExt+0x3cf3/0x4000 fs/jfs/jfs_imap.c:2360
|
|
diAllocExt fs/jfs/jfs_imap.c:1949 [inline]
|
|
diAllocAG+0xbe8/0x1e50 fs/jfs/jfs_imap.c:1666
|
|
diAlloc+0x1d3/0x1760 fs/jfs/jfs_imap.c:1587
|
|
ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56
|
|
jfs_mkdir+0x1c5/0xb90 fs/jfs/namei.c:225
|
|
vfs_mkdir+0x2f1/0x4b0 fs/namei.c:4106
|
|
do_mkdirat+0x264/0x3a0 fs/namei.c:4129
|
|
__do_sys_mkdir fs/namei.c:4149 [inline]
|
|
__se_sys_mkdir fs/namei.c:4147 [inline]
|
|
__x64_sys_mkdir+0x6e/0x80 fs/namei.c:4147
|
|
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
|
|
do_syscall_64+0x45/0x110 arch/x86/entry/common.c:82
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b
|
|
RIP: 0033:0x7fcb7e6a0b57
|
|
Code: ff ff 77 07 31 c0 c3 0f 1f 40 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 b8 53 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
|
|
RSP: 002b:00007ffd83023038 EFLAGS: 00000286 ORIG_RAX: 0000000000000053
|
|
RAX: ffffffffffffffda RBX: 00000000ffffffff RCX: 00007fcb7e6a0b57
|
|
RDX: 00000000000a1020 RSI: 00000000000001ff RDI: 0000000020000140
|
|
RBP: 0000000020000140 R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000286 R12: 00007ffd830230d0
|
|
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
|
|
|
|
[Analysis]
|
|
When the agstart is too large, it can cause agno overflow.
|
|
|
|
[Fix]
|
|
After obtaining agno, if the value is invalid, exit the subsequent process.
|
|
|
|
|
|
Modified the test from agno > MAXAG to agno >= MAXAG based on linux-next
|
|
report by kernel test robot (Dan Carpenter).(CVE-2023-52599)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
jfs: fix uaf in jfs_evict_inode
|
|
|
|
When the execution of diMount(ipimap) fails, the object ipimap that has been
|
|
released may be accessed in diFreeSpecial(). Asynchronous ipimap release occurs
|
|
when rcu_core() calls jfs_free_node().
|
|
|
|
Therefore, when diMount(ipimap) fails, sbi->ipimap should not be initialized as
|
|
ipimap.(CVE-2023-52600)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
jfs: fix array-index-out-of-bounds in dbAdjTree
|
|
|
|
Currently there is a bound check missing in the dbAdjTree while
|
|
accessing the dmt_stree. To add the required check added the bool is_ctl
|
|
which is required to determine the size as suggest in the following
|
|
commit.
|
|
https://lore.kernel.org/linux-kernel-mentees/f9475918-2186-49b8-b801-6f0f9e75f4fa@oracle.com/(CVE-2023-52601)
|
|
|
|
Integer Overflow or Wraparound vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (md, raid, raid5 modules) allows Forced Integer Overflow.(CVE-2024-23307)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: qualcomm: rmnet: fix global oob in rmnet_policy
|
|
|
|
The variable rmnet_link_ops assign a *bigger* maxtype which leads to a
|
|
global out-of-bounds read when parsing the netlink attributes. See bug
|
|
trace below:
|
|
|
|
==================================================================
|
|
BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline]
|
|
BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
|
|
Read of size 1 at addr ffffffff92c438d0 by task syz-executor.6/84207
|
|
|
|
CPU: 0 PID: 84207 Comm: syz-executor.6 Tainted: G N 6.1.0 #3
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106
|
|
print_address_description mm/kasan/report.c:284 [inline]
|
|
print_report+0x172/0x475 mm/kasan/report.c:395
|
|
kasan_report+0xbb/0x1c0 mm/kasan/report.c:495
|
|
validate_nla lib/nlattr.c:386 [inline]
|
|
__nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
|
|
__nla_parse+0x3e/0x50 lib/nlattr.c:697
|
|
nla_parse_nested_deprecated include/net/netlink.h:1248 [inline]
|
|
__rtnl_newlink+0x50a/0x1880 net/core/rtnetlink.c:3485
|
|
rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3594
|
|
rtnetlink_rcv_msg+0x43c/0xd70 net/core/rtnetlink.c:6091
|
|
netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540
|
|
netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
|
|
netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345
|
|
netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921
|
|
sock_sendmsg_nosec net/socket.c:714 [inline]
|
|
sock_sendmsg+0x154/0x190 net/socket.c:734
|
|
____sys_sendmsg+0x6df/0x840 net/socket.c:2482
|
|
___sys_sendmsg+0x110/0x1b0 net/socket.c:2536
|
|
__sys_sendmsg+0xf3/0x1c0 net/socket.c:2565
|
|
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
|
|
do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
|
|
entry_SYSCALL_64_after_hwframe+0x63/0xcd
|
|
RIP: 0033:0x7fdcf2072359
|
|
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
|
|
RSP: 002b:00007fdcf13e3168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
|
|
RAX: ffffffffffffffda RBX: 00007fdcf219ff80 RCX: 00007fdcf2072359
|
|
RDX: 0000000000000000 RSI: 0000000020000200 RDI: 0000000000000003
|
|
RBP: 00007fdcf20bd493 R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
|
|
R13: 00007fffbb8d7bdf R14: 00007fdcf13e3300 R15: 0000000000022000
|
|
</TASK>
|
|
|
|
The buggy address belongs to the variable:
|
|
rmnet_policy+0x30/0xe0
|
|
|
|
The buggy address belongs to the physical page:
|
|
page:0000000065bdeb3c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x155243
|
|
flags: 0x200000000001000(reserved|node=0|zone=2)
|
|
raw: 0200000000001000 ffffea00055490c8 ffffea00055490c8 0000000000000000
|
|
raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
|
|
page dumped because: kasan: bad access detected
|
|
|
|
Memory state around the buggy address:
|
|
ffffffff92c43780: f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9 00 00 00 07
|
|
ffffffff92c43800: f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 06 f9 f9 f9
|
|
>ffffffff92c43880: f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9
|
|
^
|
|
ffffffff92c43900: 00 00 00 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9 f9
|
|
ffffffff92c43980: 00 00 00 07 f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9
|
|
|
|
According to the comment of `nla_parse_nested_deprecated`, the maxtype
|
|
should be len(destination array) - 1. Hence use `IFLA_RMNET_MAX` here.(CVE-2024-26597)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP
|
|
|
|
If the external phy working together with phy-omap-usb2 does not implement
|
|
send_srp(), we may still attempt to call it. This can happen on an idle
|
|
Ethernet gadget triggering a wakeup for example:
|
|
|
|
configfs-gadget.g1 gadget.0: ECM Suspend
|
|
configfs-gadget.g1 gadget.0: Port suspended. Triggering wakeup
|
|
...
|
|
Unable to handle kernel NULL pointer dereference at virtual address
|
|
00000000 when execute
|
|
...
|
|
PC is at 0x0
|
|
LR is at musb_gadget_wakeup+0x1d4/0x254 [musb_hdrc]
|
|
...
|
|
musb_gadget_wakeup [musb_hdrc] from usb_gadget_wakeup+0x1c/0x3c [udc_core]
|
|
usb_gadget_wakeup [udc_core] from eth_start_xmit+0x3b0/0x3d4 [u_ether]
|
|
eth_start_xmit [u_ether] from dev_hard_start_xmit+0x94/0x24c
|
|
dev_hard_start_xmit from sch_direct_xmit+0x104/0x2e4
|
|
sch_direct_xmit from __dev_queue_xmit+0x334/0xd88
|
|
__dev_queue_xmit from arp_solicit+0xf0/0x268
|
|
arp_solicit from neigh_probe+0x54/0x7c
|
|
neigh_probe from __neigh_event_send+0x22c/0x47c
|
|
__neigh_event_send from neigh_resolve_output+0x14c/0x1c0
|
|
neigh_resolve_output from ip_finish_output2+0x1c8/0x628
|
|
ip_finish_output2 from ip_send_skb+0x40/0xd8
|
|
ip_send_skb from udp_send_skb+0x124/0x340
|
|
udp_send_skb from udp_sendmsg+0x780/0x984
|
|
udp_sendmsg from __sys_sendto+0xd8/0x158
|
|
__sys_sendto from ret_fast_syscall+0x0/0x58
|
|
|
|
Let's fix the issue by checking for send_srp() and set_vbus() before
|
|
calling them. For USB peripheral only cases these both could be NULL.(CVE-2024-26600)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
binder: signal epoll threads of self-work
|
|
|
|
In (e)poll mode, threads often depend on I/O events to determine when
|
|
data is ready for consumption. Within binder, a thread may initiate a
|
|
command via BINDER_WRITE_READ without a read buffer and then make use
|
|
of epoll_wait() or similar to consume any responses afterwards.
|
|
|
|
It is then crucial that epoll threads are signaled via wakeup when they
|
|
queue their own work. Otherwise, they risk waiting indefinitely for an
|
|
event leaving their work unhandled. What is worse, subsequent commands
|
|
won't trigger a wakeup either as the thread has pending work.(CVE-2024-26606)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tomoyo: fix UAF write bug in tomoyo_write_control()
|
|
|
|
Since tomoyo_write_control() updates head->write_buf when write()
|
|
of long lines is requested, we need to fetch head->write_buf after
|
|
head->io_sem is held. Otherwise, concurrent write() requests can
|
|
cause use-after-free-write and double-free problems.(CVE-2024-26622)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
llc: call sock_orphan() at release time
|
|
|
|
syzbot reported an interesting trace [1] caused by a stale sk->sk_wq
|
|
pointer in a closed llc socket.
|
|
|
|
In commit ff7b11aa481f ("net: socket: set sock->sk to NULL after
|
|
calling proto_ops::release()") Eric Biggers hinted that some protocols
|
|
are missing a sock_orphan(), we need to perform a full audit.
|
|
|
|
In net-next, I plan to clear sock->sk from sock_orphan() and
|
|
amend Eric patch to add a warning.
|
|
|
|
[1]
|
|
BUG: KASAN: slab-use-after-free in list_empty include/linux/list.h:373 [inline]
|
|
BUG: KASAN: slab-use-after-free in waitqueue_active include/linux/wait.h:127 [inline]
|
|
BUG: KASAN: slab-use-after-free in sock_def_write_space_wfree net/core/sock.c:3384 [inline]
|
|
BUG: KASAN: slab-use-after-free in sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468
|
|
Read of size 8 at addr ffff88802f4fc880 by task ksoftirqd/1/27
|
|
|
|
CPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0
|
|
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106
|
|
print_address_description mm/kasan/report.c:377 [inline]
|
|
print_report+0xc4/0x620 mm/kasan/report.c:488
|
|
kasan_report+0xda/0x110 mm/kasan/report.c:601
|
|
list_empty include/linux/list.h:373 [inline]
|
|
waitqueue_active include/linux/wait.h:127 [inline]
|
|
sock_def_write_space_wfree net/core/sock.c:3384 [inline]
|
|
sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468
|
|
skb_release_head_state+0xa3/0x2b0 net/core/skbuff.c:1080
|
|
skb_release_all net/core/skbuff.c:1092 [inline]
|
|
napi_consume_skb+0x119/0x2b0 net/core/skbuff.c:1404
|
|
e1000_unmap_and_free_tx_resource+0x144/0x200 drivers/net/ethernet/intel/e1000/e1000_main.c:1970
|
|
e1000_clean_tx_irq drivers/net/ethernet/intel/e1000/e1000_main.c:3860 [inline]
|
|
e1000_clean+0x4a1/0x26e0 drivers/net/ethernet/intel/e1000/e1000_main.c:3801
|
|
__napi_poll.constprop.0+0xb4/0x540 net/core/dev.c:6576
|
|
napi_poll net/core/dev.c:6645 [inline]
|
|
net_rx_action+0x956/0xe90 net/core/dev.c:6778
|
|
__do_softirq+0x21a/0x8de kernel/softirq.c:553
|
|
run_ksoftirqd kernel/softirq.c:921 [inline]
|
|
run_ksoftirqd+0x31/0x60 kernel/softirq.c:913
|
|
smpboot_thread_fn+0x660/0xa10 kernel/smpboot.c:164
|
|
kthread+0x2c6/0x3a0 kernel/kthread.c:388
|
|
ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
|
|
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242
|
|
</TASK>
|
|
|
|
Allocated by task 5167:
|
|
kasan_save_stack+0x33/0x50 mm/kasan/common.c:47
|
|
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
|
|
unpoison_slab_object mm/kasan/common.c:314 [inline]
|
|
__kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:340
|
|
kasan_slab_alloc include/linux/kasan.h:201 [inline]
|
|
slab_post_alloc_hook mm/slub.c:3813 [inline]
|
|
slab_alloc_node mm/slub.c:3860 [inline]
|
|
kmem_cache_alloc_lru+0x142/0x6f0 mm/slub.c:3879
|
|
alloc_inode_sb include/linux/fs.h:3019 [inline]
|
|
sock_alloc_inode+0x25/0x1c0 net/socket.c:308
|
|
alloc_inode+0x5d/0x220 fs/inode.c:260
|
|
new_inode_pseudo+0x16/0x80 fs/inode.c:1005
|
|
sock_alloc+0x40/0x270 net/socket.c:634
|
|
__sock_create+0xbc/0x800 net/socket.c:1535
|
|
sock_create net/socket.c:1622 [inline]
|
|
__sys_socket_create net/socket.c:1659 [inline]
|
|
__sys_socket+0x14c/0x260 net/socket.c:1706
|
|
__do_sys_socket net/socket.c:1720 [inline]
|
|
__se_sys_socket net/socket.c:1718 [inline]
|
|
__x64_sys_socket+0x72/0xb0 net/socket.c:1718
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b
|
|
|
|
Freed by task 0:
|
|
kasan_save_stack+0x33/0x50 mm/kasan/common.c:47
|
|
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
|
|
kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640
|
|
poison_slab_object mm/kasan/common.c:241 [inline]
|
|
__kasan_slab_free+0x121/0x1b0 mm/kasan/common.c:257
|
|
kasan_slab_free include/linux/kasan.h:184 [inline]
|
|
slab_free_hook mm/slub.c:2121 [inlin
|
|
---truncated---(CVE-2024-26625)</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/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1393</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2020-36777</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2020-36780</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2020-36784</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-46904</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-46924</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-46926</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-46928</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-46934</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-46935</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-46952</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-46989</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47112</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47113</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47114</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47122</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52443</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52469</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52476</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52502</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52509</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52599</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52600</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52601</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-23307</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26597</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26600</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26606</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26622</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26625</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2020-36777</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2020-36780</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2020-36784</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-46904</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-46924</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-46926</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-46928</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-46934</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-46935</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-46952</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-46989</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47112</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47113</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47114</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47122</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52443</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52469</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52476</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52502</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52509</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52599</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52600</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52601</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-23307</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26597</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26600</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26606</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26622</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26625</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="perf-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-4.19.90-2404.1.0.0272.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-4.19.90-2404.1.0.0272.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-devel-4.19.90-2404.1.0.0272.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debuginfo-4.19.90-2404.1.0.0272.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-debuginfo-4.19.90-2404.1.0.0272.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-4.19.90-2404.1.0.0272.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-debuginfo-4.19.90-2404.1.0.0272.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-debuginfo-4.19.90-2404.1.0.0272.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-4.19.90-2404.1.0.0272.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-source-4.19.90-2404.1.0.0272.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-debuginfo-4.19.90-2404.1.0.0272.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debugsource-4.19.90-2404.1.0.0272.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2404.1.0.0272.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-debuginfo-4.19.90-2404.1.0.0272.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-devel-4.19.90-2404.1.0.0272.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-4.19.90-2404.1.0.0272.oe2003sp4.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2404.1.0.0272.oe2003sp4.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="kernel-tools-devel-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-devel-4.19.90-2404.1.0.0272.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-debuginfo-4.19.90-2404.1.0.0272.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-debuginfo-4.19.90-2404.1.0.0272.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-4.19.90-2404.1.0.0272.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-source-4.19.90-2404.1.0.0272.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debuginfo-4.19.90-2404.1.0.0272.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-debuginfo-4.19.90-2404.1.0.0272.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-4.19.90-2404.1.0.0272.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-4.19.90-2404.1.0.0272.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-debuginfo-4.19.90-2404.1.0.0272.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-debuginfo-4.19.90-2404.1.0.0272.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2404.1.0.0272.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-4.19.90-2404.1.0.0272.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-4.19.90-2404.1.0.0272.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debugsource-4.19.90-2404.1.0.0272.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-4.19.90-2404.1.0.0272" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-devel-4.19.90-2404.1.0.0272.oe2003sp4.x86_64.rpm</FullProductName>
|
|
</Branch>
|
|
</ProductTree>
|
|
<Vulnerability Ordinal="1" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:media: dvbdev: Fix memory leak in dvb_media_device_free()dvb_media_device_free() is leaking memory. Free `dvbdev->adapter->conn`before setting it to NULL, as documented in include/media/media-device.h: The media_entity instance itself must be freed explicitly by the driverif required.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-12</ReleaseDate>
|
|
<CVE>CVE-2020-36777</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:L/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-04-12</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1393</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="2" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
i2c: sprd: fix reference leak when pm_runtime_get_sync fails
|
|
|
|
The PM reference count is not expected to be incremented on
|
|
return in sprd_i2c_master_xfer() and sprd_i2c_remove().
|
|
|
|
However, pm_runtime_get_sync will increment the PM reference
|
|
count even failed. Forgetting to putting operation will result
|
|
in a reference leak here.
|
|
|
|
Replace it with pm_runtime_resume_and_get to keep usage
|
|
counter balanced.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-12</ReleaseDate>
|
|
<CVE>CVE-2020-36780</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-04-12</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1393</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="3" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
i2c: cadence: fix reference leak when pm_runtime_get_sync fails
|
|
|
|
The PM reference count is not expected to be incremented on
|
|
return in functions cdns_i2c_master_xfer and cdns_reg_slave.
|
|
|
|
However, pm_runtime_get_sync will increment pm usage counter
|
|
even failed. Forgetting to putting operation will result in a
|
|
reference leak here.
|
|
|
|
Replace it with pm_runtime_resume_and_get to keep usage
|
|
counter balanced.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-12</ReleaseDate>
|
|
<CVE>CVE-2020-36784</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:L/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-04-12</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1393</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="4" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: hso: fix null-ptr-deref during tty device unregistration
|
|
|
|
Multiple ttys try to claim the same the minor number causing a double
|
|
unregistration of the same device. The first unregistration succeeds
|
|
but the next one results in a null-ptr-deref.
|
|
|
|
The get_free_serial_index() function returns an available minor number
|
|
but doesn't assign it immediately. The assignment is done by the caller
|
|
later. But before this assignment, calls to get_free_serial_index()
|
|
would return the same minor number.
|
|
|
|
Fix this by modifying get_free_serial_index to assign the minor number
|
|
immediately after one is found to be and rename it to obtain_minor()
|
|
to better reflect what it does. Similary, rename set_serial_by_index()
|
|
to release_minor() and modify it to free up the minor number of the
|
|
given hso_serial. Every obtain_minor() should have corresponding
|
|
release_minor() call.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-12</ReleaseDate>
|
|
<CVE>CVE-2021-46904</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-04-12</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1393</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="5" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:NFC: st21nfca: Fix memory leak in device probe and remove phy->pending_skb is alloced when device probe, but forgot to freein the error handling path and remove path, this cause memory leakas follows:unreferenced object 0xffff88800bc06800 (size 512): comm 8 , pid 11775, jiffies 4295159829 (age 9.032s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000d66c09ce>] __kmalloc_node_track_caller+0x1ed/0x450 [<00000000c93382b3>] kmalloc_reserve+0x37/0xd0 [<000000005fea522c>] __alloc_skb+0x124/0x380 [<0000000019f29f9a>] st21nfca_hci_i2c_probe+0x170/0x8f2Fix it by freeing pending_skb in error and remove.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-12</ReleaseDate>
|
|
<CVE>CVE-2021-46924</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.3</BaseScore>
|
|
<Vector>AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-04-12</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1393</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="6" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ALSA: hda: intel-sdw-acpi: harden detection of controller
|
|
|
|
The existing code currently sets a pointer to an ACPI handle before
|
|
checking that it's actually a SoundWire controller. This can lead to
|
|
issues where the graph walk continues and eventually fails, but the
|
|
pointer was set already.
|
|
|
|
This patch changes the logic so that the information provided to
|
|
the caller is set when a controller is found.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-12</ReleaseDate>
|
|
<CVE>CVE-2021-46926</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>2.3</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/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-04-12</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1393</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="7" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:parisc: Clear stale IIR value on instruction access rights trapWhen a trap 7 (Instruction access rights) occurs, this means the CPUcouldn t execute an instruction due to missing execute permissions onthe memory region. In this case it seems the CPU didn t even fetchedthe instruction from memory and thus did not store it in the cr19 (IIR)register before calling the trap handler. So, the trap handler will findsome random old stale value in cr19.This patch simply overwrites the stale IIR value with a constant magic bad food value (0xbaadf00d), in the hope people don t start to try tounderstand the various random IIR values in trap 7 dumps.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-12</ReleaseDate>
|
|
<CVE>CVE-2021-46928</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-04-12</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1393</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="8" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:i2c: validate user data in compat ioctlWrong user data may cause warning in i2c_transfer(), ex: zero msgs.Userspace should not be able to trigger warnings, so this patch addsvalidation checks for user data in compact ioctl to prevent reportedwarnings</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-12</ReleaseDate>
|
|
<CVE>CVE-2021-46934</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:L/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-04-12</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1393</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="9" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:binder: fix async_free_space accounting for empty parcelsIn 4.13, commit 74310e06be4d ( android: binder: Move buffer out of area shared with user space )fixed a kernel structure visibility issue. As part of that patch,sizeof(void *) was used as the buffer size for 0-length data payloads sothe driver could detect abusive clients sending 0-length asynchronoustransactions to a server by enforcing limits on async_free_size.Unfortunately, on the free side, the accounting of async_free_spacedid not add the sizeof(void *) back. The result was that up to 8-bytes ofasync_free_space were leaked on every async transaction of 8-bytes orless. These small transactions are uncommon, so this accounting issuehas gone undetected for several years.The fix is to use buffer_size (the allocated buffer size) instead of size (the logical buffer size) when updating the async_free_spaceduring the free operation. These are the same except for thiscorner case of asynchronous transactions with payloads < 8 bytes.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-12</ReleaseDate>
|
|
<CVE>CVE-2021-46935</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:H/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-04-12</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1393</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="10" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:NFS: fs_context: validate UDP retrans to prevent shift out-of-boundsFix shift out-of-bounds in xprt_calc_majortimeo(). This is causedby a garbage timeout (retrans) mount option being passed to nfs mount,in this case from syzkaller.If the protocol is XPRT_TRANSPORT_UDP, then retrans is a shiftvalue for a 64-bit long integer, so retrans cannot be >= 64.If it is >= 64, fail the mount and return an error.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-12</ReleaseDate>
|
|
<CVE>CVE-2021-46952</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.1</BaseScore>
|
|
<Vector>AV:L/AC:L/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-04-12</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1393</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="11" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
hfsplus: prevent corruption in shrinking truncate
|
|
|
|
I believe there are some issues introduced by commit 31651c607151
|
|
("hfsplus: avoid deadlock on file truncation")
|
|
|
|
HFS+ has extent records which always contains 8 extents. In case the
|
|
first extent record in catalog file gets full, new ones are allocated from
|
|
extents overflow file.
|
|
|
|
In case shrinking truncate happens to middle of an extent record which
|
|
locates in extents overflow file, the logic in hfsplus_file_truncate() was
|
|
changed so that call to hfs_brec_remove() is not guarded any more.
|
|
|
|
Right action would be just freeing the extents that exceed the new size
|
|
inside extent record by calling hfsplus_free_extents(), and then check if
|
|
the whole extent record should be removed. However since the guard
|
|
(blk_cnt > start) is now after the call to hfs_brec_remove(), this has
|
|
unfortunate effect that the last matching extent record is removed
|
|
unconditionally.
|
|
|
|
To reproduce this issue, create a file which has at least 10 extents, and
|
|
then perform shrinking truncate into middle of the last extent record, so
|
|
that the number of remaining extents is not under or divisible by 8. This
|
|
causes the last extent record (8 extents) to be removed totally instead of
|
|
truncating into middle of it. Thus this causes corruption, and lost data.
|
|
|
|
Fix for this is simply checking if the new truncated end is below the
|
|
start of this extent record, making it safe to remove the full extent
|
|
record. However call to hfs_brec_remove() can't be moved to it's previous
|
|
place since we're dropping ->tree_lock and it can cause a race condition
|
|
and the cached info being invalidated possibly corrupting the node data.
|
|
|
|
Another issue is related to this one. When entering into the block
|
|
(blk_cnt > start) we are not holding the ->tree_lock. We break out from
|
|
the loop not holding the lock, but hfs_find_exit() does unlock it. Not
|
|
sure if it's possible for someone else to take the lock under our feet,
|
|
but it can cause hard to debug errors and premature unlocking. Even if
|
|
there's no real risk of it, the locking should still always be kept in
|
|
balance. Thus taking the lock now just before the check.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-12</ReleaseDate>
|
|
<CVE>CVE-2021-46989</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-04-12</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1393</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="12" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
x86/kvm: Teardown PV features on boot CPU as well
|
|
|
|
Various PV features (Async PF, PV EOI, steal time) work through memory
|
|
shared with hypervisor and when we restore from hibernation we must
|
|
properly teardown all these features to make sure hypervisor doesn't
|
|
write to stale locations after we jump to the previously hibernated kernel
|
|
(which can try to place anything there). For secondary CPUs the job is
|
|
already done by kvm_cpu_down_prepare(), register syscore ops to do
|
|
the same for boot CPU.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-12</ReleaseDate>
|
|
<CVE>CVE-2021-47112</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-04-12</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1393</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="13" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
btrfs: abort in rename_exchange if we fail to insert the second ref
|
|
|
|
Error injection stress uncovered a problem where we'd leave a dangling
|
|
inode ref if we failed during a rename_exchange. This happens because
|
|
we insert the inode ref for one side of the rename, and then for the
|
|
other side. If this second inode ref insert fails we'll leave the first
|
|
one dangling and leave a corrupt file system behind. Fix this by
|
|
aborting if we did the insert for the first inode ref.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-12</ReleaseDate>
|
|
<CVE>CVE-2021-47113</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-04-12</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1393</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="14" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ocfs2: fix data corruption by fallocate
|
|
|
|
When fallocate punches holes out of inode size, if original isize is in
|
|
the middle of last cluster, then the part from isize to the end of the
|
|
cluster will be zeroed with buffer write, at that time isize is not yet
|
|
updated to match the new size, if writeback is kicked in, it will invoke
|
|
ocfs2_writepage()->block_write_full_page() where the pages out of inode
|
|
size will be dropped. That will cause file corruption. Fix this by
|
|
zero out eof blocks when extending the inode size.
|
|
|
|
Running the following command with qemu-image 4.2.1 can get a corrupted
|
|
coverted image file easily.
|
|
|
|
qemu-img convert -p -t none -T none -f qcow2 $qcow_image \
|
|
-O qcow2 -o compat=1.1 $qcow_image.conv
|
|
|
|
The usage of fallocate in qemu is like this, it first punches holes out
|
|
of inode size, then extend the inode size.
|
|
|
|
fallocate(11, FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE, 2276196352, 65536) = 0
|
|
fallocate(11, 0, 2276196352, 65536) = 0
|
|
|
|
v1: https://www.spinics.net/lists/linux-fsdevel/msg193999.html
|
|
v2: https://lore.kernel.org/linux-fsdevel/20210525093034.GB4112@quack2.suse.cz/T/</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-12</ReleaseDate>
|
|
<CVE>CVE-2021-47114</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-04-12</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1393</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="15" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: caif: fix memory leak in caif_device_notify
|
|
|
|
In case of caif_enroll_dev() fail, allocated
|
|
link_support won't be assigned to the corresponding
|
|
structure. So simply free allocated pointer in case
|
|
of error</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-12</ReleaseDate>
|
|
<CVE>CVE-2021-47122</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:H/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-04-12</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1393</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="16" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:apparmor: avoid crash when parsed profile name is emptyWhen processing a packed profile in unpack_profile() described like profile :ns::samba-dcerpcd /usr/lib*/samba/{,samba/}samba-dcerpcd {...} a string :samba-dcerpcd is unpacked as a fully-qualified name and thenpassed to aa_splitn_fqname().aa_splitn_fqname() treats :samba-dcerpcd as only containing a namespace.Thus it returns NULL for tmpname, meanwhile tmpns is non-NULL. Lateraa_alloc_profile() crashes as the new profile name is NULL now.general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 6 PID: 1657 Comm: apparmor_parser Not tainted 6.7.0-rc2-dirty #16Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014RIP: 0010:strlen+0x1e/0xa0Call Trace: <TASK> ? strlen+0x1e/0xa0 aa_policy_init+0x1bb/0x230 aa_alloc_profile+0xb1/0x480 unpack_profile+0x3bc/0x4960 aa_unpack+0x309/0x15e0 aa_replace_profiles+0x213/0x33c0 policy_update+0x261/0x370 profile_replace+0x20e/0x2a0 vfs_write+0x2af/0xe00 ksys_write+0x126/0x250 do_syscall_64+0x46/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 </TASK>---[ end trace 0000000000000000 ]---RIP: 0010:strlen+0x1e/0xa0It seems such behaviour of aa_splitn_fqname() is expected and checked inother places where it is called (e.g. aa_remove_profiles). Well, thereis an explicit comment a ns name without a following profile is allowed inside.AFAICS, nothing can prevent unpacked name to be in form like :samba-dcerpcd - it is passed from userspace.Deny the whole profile set replacement in such case and inform user withEPROTO and an explaining message.Found by Linux Verification Center (linuxtesting.org).</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-12</ReleaseDate>
|
|
<CVE>CVE-2023-52443</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-04-12</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1393</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="17" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drivers/amd/pm: fix a use-after-free in kv_parse_power_table
|
|
|
|
When ps allocated by kzalloc equals to NULL, kv_parse_power_table
|
|
frees adev->pm.dpm.ps that allocated before. However, after the control
|
|
flow goes through the following call chains:
|
|
|
|
kv_parse_power_table
|
|
|-> kv_dpm_init
|
|
|-> kv_dpm_sw_init
|
|
|-> kv_dpm_fini
|
|
|
|
The adev->pm.dpm.ps is used in the for loop of kv_dpm_fini after its
|
|
first free in kv_parse_power_table and causes a use-after-free bug.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-12</ReleaseDate>
|
|
<CVE>CVE-2023-52469</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-04-12</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1393</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="18" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
perf/x86/lbr: Filter vsyscall addresses
|
|
|
|
We found that a panic can occur when a vsyscall is made while LBR sampling
|
|
is active. If the vsyscall is interrupted (NMI) for perf sampling, this
|
|
call sequence can occur (most recent at top):
|
|
|
|
__insn_get_emulate_prefix()
|
|
insn_get_emulate_prefix()
|
|
insn_get_prefixes()
|
|
insn_get_opcode()
|
|
decode_branch_type()
|
|
get_branch_type()
|
|
intel_pmu_lbr_filter()
|
|
intel_pmu_handle_irq()
|
|
perf_event_nmi_handler()
|
|
|
|
Within __insn_get_emulate_prefix() at frame 0, a macro is called:
|
|
|
|
peek_nbyte_next(insn_byte_t, insn, i)
|
|
|
|
Within this macro, this dereference occurs:
|
|
|
|
(insn)->next_byte
|
|
|
|
Inspecting registers at this point, the value of the next_byte field is the
|
|
address of the vsyscall made, for example the location of the vsyscall
|
|
version of gettimeofday() at 0xffffffffff600000. The access to an address
|
|
in the vsyscall region will trigger an oops due to an unhandled page fault.
|
|
|
|
To fix the bug, filtering for vsyscalls can be done when
|
|
determining the branch type. This patch will return
|
|
a "none" branch if a kernel address if found to lie in the
|
|
vsyscall region.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-12</ReleaseDate>
|
|
<CVE>CVE-2023-52476</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.7</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-04-12</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1393</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="19" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: nfc: fix races in nfc_llcp_sock_get() and nfc_llcp_sock_get_sn()
|
|
|
|
Sili Luo reported a race in nfc_llcp_sock_get(), leading to UAF.
|
|
|
|
Getting a reference on the socket found in a lookup while
|
|
holding a lock should happen before releasing the lock.
|
|
|
|
nfc_llcp_sock_get_sn() has a similar problem.
|
|
|
|
Finally nfc_llcp_recv_snl() needs to make sure the socket
|
|
found by nfc_llcp_sock_from_sn() does not disappear.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-12</ReleaseDate>
|
|
<CVE>CVE-2023-52502</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.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-04-12</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1393</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="20" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ravb: Fix use-after-free issue in ravb_tx_timeout_work()
|
|
|
|
The ravb_stop() should call cancel_work_sync(). Otherwise,
|
|
ravb_tx_timeout_work() is possible to use the freed priv after
|
|
ravb_remove() was called like below:
|
|
|
|
CPU0 CPU1
|
|
ravb_tx_timeout()
|
|
ravb_remove()
|
|
unregister_netdev()
|
|
free_netdev(ndev)
|
|
// free priv
|
|
ravb_tx_timeout_work()
|
|
// use priv
|
|
|
|
unregister_netdev() will call .ndo_stop() so that ravb_stop() is
|
|
called. And, after phy_stop() is called, netif_carrier_off()
|
|
is also called. So that .ndo_tx_timeout() will not be called
|
|
after phy_stop().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-12</ReleaseDate>
|
|
<CVE>CVE-2023-52509</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-04-12</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1393</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="21" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
jfs: fix array-index-out-of-bounds in diNewExt
|
|
|
|
[Syz report]
|
|
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_imap.c:2360:2
|
|
index -878706688 is out of range for type 'struct iagctl[128]'
|
|
CPU: 1 PID: 5065 Comm: syz-executor282 Not tainted 6.7.0-rc4-syzkaller-00009-gbee0e7762ad2 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
|
|
ubsan_epilogue lib/ubsan.c:217 [inline]
|
|
__ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348
|
|
diNewExt+0x3cf3/0x4000 fs/jfs/jfs_imap.c:2360
|
|
diAllocExt fs/jfs/jfs_imap.c:1949 [inline]
|
|
diAllocAG+0xbe8/0x1e50 fs/jfs/jfs_imap.c:1666
|
|
diAlloc+0x1d3/0x1760 fs/jfs/jfs_imap.c:1587
|
|
ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56
|
|
jfs_mkdir+0x1c5/0xb90 fs/jfs/namei.c:225
|
|
vfs_mkdir+0x2f1/0x4b0 fs/namei.c:4106
|
|
do_mkdirat+0x264/0x3a0 fs/namei.c:4129
|
|
__do_sys_mkdir fs/namei.c:4149 [inline]
|
|
__se_sys_mkdir fs/namei.c:4147 [inline]
|
|
__x64_sys_mkdir+0x6e/0x80 fs/namei.c:4147
|
|
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
|
|
do_syscall_64+0x45/0x110 arch/x86/entry/common.c:82
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b
|
|
RIP: 0033:0x7fcb7e6a0b57
|
|
Code: ff ff 77 07 31 c0 c3 0f 1f 40 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 b8 53 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
|
|
RSP: 002b:00007ffd83023038 EFLAGS: 00000286 ORIG_RAX: 0000000000000053
|
|
RAX: ffffffffffffffda RBX: 00000000ffffffff RCX: 00007fcb7e6a0b57
|
|
RDX: 00000000000a1020 RSI: 00000000000001ff RDI: 0000000020000140
|
|
RBP: 0000000020000140 R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000286 R12: 00007ffd830230d0
|
|
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
|
|
|
|
[Analysis]
|
|
When the agstart is too large, it can cause agno overflow.
|
|
|
|
[Fix]
|
|
After obtaining agno, if the value is invalid, exit the subsequent process.
|
|
|
|
|
|
Modified the test from agno > MAXAG to agno >= MAXAG based on linux-next
|
|
report by kernel test robot (Dan Carpenter).</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-12</ReleaseDate>
|
|
<CVE>CVE-2023-52599</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.1</BaseScore>
|
|
<Vector>AV:L/AC:L/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-04-12</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1393</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="22" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
jfs: fix uaf in jfs_evict_inode
|
|
|
|
When the execution of diMount(ipimap) fails, the object ipimap that has been
|
|
released may be accessed in diFreeSpecial(). Asynchronous ipimap release occurs
|
|
when rcu_core() calls jfs_free_node().
|
|
|
|
Therefore, when diMount(ipimap) fails, sbi->ipimap should not be initialized as
|
|
ipimap.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-12</ReleaseDate>
|
|
<CVE>CVE-2023-52600</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-04-12</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1393</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="23" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="23" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
jfs: fix array-index-out-of-bounds in dbAdjTree
|
|
|
|
Currently there is a bound check missing in the dbAdjTree while
|
|
accessing the dmt_stree. To add the required check added the bool is_ctl
|
|
which is required to determine the size as suggest in the following
|
|
commit.
|
|
https://lore.kernel.org/linux-kernel-mentees/f9475918-2186-49b8-b801-6f0f9e75f4fa@oracle.com/</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-12</ReleaseDate>
|
|
<CVE>CVE-2023-52601</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.1</BaseScore>
|
|
<Vector>AV:L/AC:L/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-04-12</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1393</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="24" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="24" xml:lang="en">Integer Overflow or Wraparound vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (md, raid, raid5 modules) allows Forced Integer Overflow.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-12</ReleaseDate>
|
|
<CVE>CVE-2024-23307</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-04-12</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1393</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="25" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="25" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: qualcomm: rmnet: fix global oob in rmnet_policy
|
|
|
|
The variable rmnet_link_ops assign a *bigger* maxtype which leads to a
|
|
global out-of-bounds read when parsing the netlink attributes. See bug
|
|
trace below:
|
|
|
|
==================================================================
|
|
BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline]
|
|
BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
|
|
Read of size 1 at addr ffffffff92c438d0 by task syz-executor.6/84207
|
|
|
|
CPU: 0 PID: 84207 Comm: syz-executor.6 Tainted: G N 6.1.0 #3
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106
|
|
print_address_description mm/kasan/report.c:284 [inline]
|
|
print_report+0x172/0x475 mm/kasan/report.c:395
|
|
kasan_report+0xbb/0x1c0 mm/kasan/report.c:495
|
|
validate_nla lib/nlattr.c:386 [inline]
|
|
__nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
|
|
__nla_parse+0x3e/0x50 lib/nlattr.c:697
|
|
nla_parse_nested_deprecated include/net/netlink.h:1248 [inline]
|
|
__rtnl_newlink+0x50a/0x1880 net/core/rtnetlink.c:3485
|
|
rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3594
|
|
rtnetlink_rcv_msg+0x43c/0xd70 net/core/rtnetlink.c:6091
|
|
netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540
|
|
netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
|
|
netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345
|
|
netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921
|
|
sock_sendmsg_nosec net/socket.c:714 [inline]
|
|
sock_sendmsg+0x154/0x190 net/socket.c:734
|
|
____sys_sendmsg+0x6df/0x840 net/socket.c:2482
|
|
___sys_sendmsg+0x110/0x1b0 net/socket.c:2536
|
|
__sys_sendmsg+0xf3/0x1c0 net/socket.c:2565
|
|
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
|
|
do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
|
|
entry_SYSCALL_64_after_hwframe+0x63/0xcd
|
|
RIP: 0033:0x7fdcf2072359
|
|
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
|
|
RSP: 002b:00007fdcf13e3168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
|
|
RAX: ffffffffffffffda RBX: 00007fdcf219ff80 RCX: 00007fdcf2072359
|
|
RDX: 0000000000000000 RSI: 0000000020000200 RDI: 0000000000000003
|
|
RBP: 00007fdcf20bd493 R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
|
|
R13: 00007fffbb8d7bdf R14: 00007fdcf13e3300 R15: 0000000000022000
|
|
</TASK>
|
|
|
|
The buggy address belongs to the variable:
|
|
rmnet_policy+0x30/0xe0
|
|
|
|
The buggy address belongs to the physical page:
|
|
page:0000000065bdeb3c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x155243
|
|
flags: 0x200000000001000(reserved|node=0|zone=2)
|
|
raw: 0200000000001000 ffffea00055490c8 ffffea00055490c8 0000000000000000
|
|
raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
|
|
page dumped because: kasan: bad access detected
|
|
|
|
Memory state around the buggy address:
|
|
ffffffff92c43780: f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9 00 00 00 07
|
|
ffffffff92c43800: f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 06 f9 f9 f9
|
|
>ffffffff92c43880: f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9
|
|
^
|
|
ffffffff92c43900: 00 00 00 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9 f9
|
|
ffffffff92c43980: 00 00 00 07 f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9
|
|
|
|
According to the comment of `nla_parse_nested_deprecated`, the maxtype
|
|
should be len(destination array) - 1. Hence use `IFLA_RMNET_MAX` here.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-12</ReleaseDate>
|
|
<CVE>CVE-2024-26597</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:L/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-04-12</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1393</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="26" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="26" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP
|
|
|
|
If the external phy working together with phy-omap-usb2 does not implement
|
|
send_srp(), we may still attempt to call it. This can happen on an idle
|
|
Ethernet gadget triggering a wakeup for example:
|
|
|
|
configfs-gadget.g1 gadget.0: ECM Suspend
|
|
configfs-gadget.g1 gadget.0: Port suspended. Triggering wakeup
|
|
...
|
|
Unable to handle kernel NULL pointer dereference at virtual address
|
|
00000000 when execute
|
|
...
|
|
PC is at 0x0
|
|
LR is at musb_gadget_wakeup+0x1d4/0x254 [musb_hdrc]
|
|
...
|
|
musb_gadget_wakeup [musb_hdrc] from usb_gadget_wakeup+0x1c/0x3c [udc_core]
|
|
usb_gadget_wakeup [udc_core] from eth_start_xmit+0x3b0/0x3d4 [u_ether]
|
|
eth_start_xmit [u_ether] from dev_hard_start_xmit+0x94/0x24c
|
|
dev_hard_start_xmit from sch_direct_xmit+0x104/0x2e4
|
|
sch_direct_xmit from __dev_queue_xmit+0x334/0xd88
|
|
__dev_queue_xmit from arp_solicit+0xf0/0x268
|
|
arp_solicit from neigh_probe+0x54/0x7c
|
|
neigh_probe from __neigh_event_send+0x22c/0x47c
|
|
__neigh_event_send from neigh_resolve_output+0x14c/0x1c0
|
|
neigh_resolve_output from ip_finish_output2+0x1c8/0x628
|
|
ip_finish_output2 from ip_send_skb+0x40/0xd8
|
|
ip_send_skb from udp_send_skb+0x124/0x340
|
|
udp_send_skb from udp_sendmsg+0x780/0x984
|
|
udp_sendmsg from __sys_sendto+0xd8/0x158
|
|
__sys_sendto from ret_fast_syscall+0x0/0x58
|
|
|
|
Let's fix the issue by checking for send_srp() and set_vbus() before
|
|
calling them. For USB peripheral only cases these both could be NULL.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-12</ReleaseDate>
|
|
<CVE>CVE-2024-26600</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-04-12</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1393</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="27" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="27" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
binder: signal epoll threads of self-work
|
|
|
|
In (e)poll mode, threads often depend on I/O events to determine when
|
|
data is ready for consumption. Within binder, a thread may initiate a
|
|
command via BINDER_WRITE_READ without a read buffer and then make use
|
|
of epoll_wait() or similar to consume any responses afterwards.
|
|
|
|
It is then crucial that epoll threads are signaled via wakeup when they
|
|
queue their own work. Otherwise, they risk waiting indefinitely for an
|
|
event leaving their work unhandled. What is worse, subsequent commands
|
|
won't trigger a wakeup either as the thread has pending work.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-12</ReleaseDate>
|
|
<CVE>CVE-2024-26606</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-04-12</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1393</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="28" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="28" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tomoyo: fix UAF write bug in tomoyo_write_control()
|
|
|
|
Since tomoyo_write_control() updates head->write_buf when write()
|
|
of long lines is requested, we need to fetch head->write_buf after
|
|
head->io_sem is held. Otherwise, concurrent write() requests can
|
|
cause use-after-free-write and double-free problems.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-12</ReleaseDate>
|
|
<CVE>CVE-2024-26622</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-04-12</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1393</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="29" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="29" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
llc: call sock_orphan() at release time
|
|
|
|
syzbot reported an interesting trace [1] caused by a stale sk->sk_wq
|
|
pointer in a closed llc socket.
|
|
|
|
In commit ff7b11aa481f ("net: socket: set sock->sk to NULL after
|
|
calling proto_ops::release()") Eric Biggers hinted that some protocols
|
|
are missing a sock_orphan(), we need to perform a full audit.
|
|
|
|
In net-next, I plan to clear sock->sk from sock_orphan() and
|
|
amend Eric patch to add a warning.
|
|
|
|
[1]
|
|
BUG: KASAN: slab-use-after-free in list_empty include/linux/list.h:373 [inline]
|
|
BUG: KASAN: slab-use-after-free in waitqueue_active include/linux/wait.h:127 [inline]
|
|
BUG: KASAN: slab-use-after-free in sock_def_write_space_wfree net/core/sock.c:3384 [inline]
|
|
BUG: KASAN: slab-use-after-free in sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468
|
|
Read of size 8 at addr ffff88802f4fc880 by task ksoftirqd/1/27
|
|
|
|
CPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0
|
|
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106
|
|
print_address_description mm/kasan/report.c:377 [inline]
|
|
print_report+0xc4/0x620 mm/kasan/report.c:488
|
|
kasan_report+0xda/0x110 mm/kasan/report.c:601
|
|
list_empty include/linux/list.h:373 [inline]
|
|
waitqueue_active include/linux/wait.h:127 [inline]
|
|
sock_def_write_space_wfree net/core/sock.c:3384 [inline]
|
|
sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468
|
|
skb_release_head_state+0xa3/0x2b0 net/core/skbuff.c:1080
|
|
skb_release_all net/core/skbuff.c:1092 [inline]
|
|
napi_consume_skb+0x119/0x2b0 net/core/skbuff.c:1404
|
|
e1000_unmap_and_free_tx_resource+0x144/0x200 drivers/net/ethernet/intel/e1000/e1000_main.c:1970
|
|
e1000_clean_tx_irq drivers/net/ethernet/intel/e1000/e1000_main.c:3860 [inline]
|
|
e1000_clean+0x4a1/0x26e0 drivers/net/ethernet/intel/e1000/e1000_main.c:3801
|
|
__napi_poll.constprop.0+0xb4/0x540 net/core/dev.c:6576
|
|
napi_poll net/core/dev.c:6645 [inline]
|
|
net_rx_action+0x956/0xe90 net/core/dev.c:6778
|
|
__do_softirq+0x21a/0x8de kernel/softirq.c:553
|
|
run_ksoftirqd kernel/softirq.c:921 [inline]
|
|
run_ksoftirqd+0x31/0x60 kernel/softirq.c:913
|
|
smpboot_thread_fn+0x660/0xa10 kernel/smpboot.c:164
|
|
kthread+0x2c6/0x3a0 kernel/kthread.c:388
|
|
ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
|
|
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242
|
|
</TASK>
|
|
|
|
Allocated by task 5167:
|
|
kasan_save_stack+0x33/0x50 mm/kasan/common.c:47
|
|
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
|
|
unpoison_slab_object mm/kasan/common.c:314 [inline]
|
|
__kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:340
|
|
kasan_slab_alloc include/linux/kasan.h:201 [inline]
|
|
slab_post_alloc_hook mm/slub.c:3813 [inline]
|
|
slab_alloc_node mm/slub.c:3860 [inline]
|
|
kmem_cache_alloc_lru+0x142/0x6f0 mm/slub.c:3879
|
|
alloc_inode_sb include/linux/fs.h:3019 [inline]
|
|
sock_alloc_inode+0x25/0x1c0 net/socket.c:308
|
|
alloc_inode+0x5d/0x220 fs/inode.c:260
|
|
new_inode_pseudo+0x16/0x80 fs/inode.c:1005
|
|
sock_alloc+0x40/0x270 net/socket.c:634
|
|
__sock_create+0xbc/0x800 net/socket.c:1535
|
|
sock_create net/socket.c:1622 [inline]
|
|
__sys_socket_create net/socket.c:1659 [inline]
|
|
__sys_socket+0x14c/0x260 net/socket.c:1706
|
|
__do_sys_socket net/socket.c:1720 [inline]
|
|
__se_sys_socket net/socket.c:1718 [inline]
|
|
__x64_sys_socket+0x72/0xb0 net/socket.c:1718
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x63/0x6b
|
|
|
|
Freed by task 0:
|
|
kasan_save_stack+0x33/0x50 mm/kasan/common.c:47
|
|
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
|
|
kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640
|
|
poison_slab_object mm/kasan/common.c:241 [inline]
|
|
__kasan_slab_free+0x121/0x1b0 mm/kasan/common.c:257
|
|
kasan_slab_free include/linux/kasan.h:184 [inline]
|
|
slab_free_hook mm/slub.c:2121 [inlin
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-12</ReleaseDate>
|
|
<CVE>CVE-2024-26625</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-04-12</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1393</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |