5849 lines
247 KiB
XML
5849 lines
247 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-1692</ID>
|
|
</Identification>
|
|
<Status>Final</Status>
|
|
<Version>1.0</Version>
|
|
<RevisionHistory>
|
|
<Revision>
|
|
<Number>1.0</Number>
|
|
<Date>2024-06-07</Date>
|
|
<Description>Initial</Description>
|
|
</Revision>
|
|
</RevisionHistory>
|
|
<InitialReleaseDate>2024-06-07</InitialReleaseDate>
|
|
<CurrentReleaseDate>2024-06-07</CurrentReleaseDate>
|
|
<Generator>
|
|
<Engine>openEuler SA Tool V1.0</Engine>
|
|
<Date>2024-06-07</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:
|
|
|
|
net: usb: fix possible use-after-free in smsc75xx_bind
|
|
|
|
The commit 46a8b29c6306 ("net: usb: fix memory leak in smsc75xx_bind")
|
|
fails to clean up the work scheduled in smsc75xx_reset->
|
|
smsc75xx_set_multicast, which leads to use-after-free if the work is
|
|
scheduled to start after the deallocation. In addition, this patch
|
|
also removes a dangling pointer - dev->data[0].
|
|
|
|
This patch calls cancel_work_sync to cancel the scheduled work and set
|
|
the dangling pointer to NULL.(CVE-2021-47239)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
RDMA: Verify port when creating flow rule
|
|
|
|
Validate port value provided by the user and with that remove no longer
|
|
needed validation by the driver. The missing check in the mlx5_ib driver
|
|
could cause to the below oops.
|
|
|
|
Call trace:
|
|
_create_flow_rule+0x2d4/0xf28 [mlx5_ib]
|
|
mlx5_ib_create_flow+0x2d0/0x5b0 [mlx5_ib]
|
|
ib_uverbs_ex_create_flow+0x4cc/0x624 [ib_uverbs]
|
|
ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xd4/0x150 [ib_uverbs]
|
|
ib_uverbs_cmd_verbs.isra.7+0xb28/0xc50 [ib_uverbs]
|
|
ib_uverbs_ioctl+0x158/0x1d0 [ib_uverbs]
|
|
do_vfs_ioctl+0xd0/0xaf0
|
|
ksys_ioctl+0x84/0xb4
|
|
__arm64_sys_ioctl+0x28/0xc4
|
|
el0_svc_common.constprop.3+0xa4/0x254
|
|
el0_svc_handler+0x84/0xa0
|
|
el0_svc+0x10/0x26c
|
|
Code: b9401260 f9615681 51000400 8b001c20 (f9403c1a)(CVE-2021-47265)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
bcache: avoid oversized read request in cache missing code path
|
|
|
|
In the cache missing code path of cached device, if a proper location
|
|
from the internal B+ tree is matched for a cache miss range, function
|
|
cached_dev_cache_miss() will be called in cache_lookup_fn() in the
|
|
following code block,
|
|
[code block 1]
|
|
526 unsigned int sectors = KEY_INODE(k) == s->iop.inode
|
|
527 ? min_t(uint64_t, INT_MAX,
|
|
528 KEY_START(k) - bio->bi_iter.bi_sector)
|
|
529 : INT_MAX;
|
|
530 int ret = s->d->cache_miss(b, s, bio, sectors);
|
|
|
|
Here s->d->cache_miss() is the call backfunction pointer initialized as
|
|
cached_dev_cache_miss(), the last parameter 'sectors' is an important
|
|
hint to calculate the size of read request to backing device of the
|
|
missing cache data.
|
|
|
|
Current calculation in above code block may generate oversized value of
|
|
'sectors', which consequently may trigger 2 different potential kernel
|
|
panics by BUG() or BUG_ON() as listed below,
|
|
|
|
1) BUG_ON() inside bch_btree_insert_key(),
|
|
[code block 2]
|
|
886 BUG_ON(b->ops->is_extents && !KEY_SIZE(k));
|
|
2) BUG() inside biovec_slab(),
|
|
[code block 3]
|
|
51 default:
|
|
52 BUG();
|
|
53 return NULL;
|
|
|
|
All the above panics are original from cached_dev_cache_miss() by the
|
|
oversized parameter 'sectors'.
|
|
|
|
Inside cached_dev_cache_miss(), parameter 'sectors' is used to calculate
|
|
the size of data read from backing device for the cache missing. This
|
|
size is stored in s->insert_bio_sectors by the following lines of code,
|
|
[code block 4]
|
|
909 s->insert_bio_sectors = min(sectors, bio_sectors(bio) + reada);
|
|
|
|
Then the actual key inserting to the internal B+ tree is generated and
|
|
stored in s->iop.replace_key by the following lines of code,
|
|
[code block 5]
|
|
911 s->iop.replace_key = KEY(s->iop.inode,
|
|
912 bio->bi_iter.bi_sector + s->insert_bio_sectors,
|
|
913 s->insert_bio_sectors);
|
|
The oversized parameter 'sectors' may trigger panic 1) by BUG_ON() from
|
|
the above code block.
|
|
|
|
And the bio sending to backing device for the missing data is allocated
|
|
with hint from s->insert_bio_sectors by the following lines of code,
|
|
[code block 6]
|
|
926 cache_bio = bio_alloc_bioset(GFP_NOWAIT,
|
|
927 DIV_ROUND_UP(s->insert_bio_sectors, PAGE_SECTORS),
|
|
928 &dc->disk.bio_split);
|
|
The oversized parameter 'sectors' may trigger panic 2) by BUG() from the
|
|
agove code block.
|
|
|
|
Now let me explain how the panics happen with the oversized 'sectors'.
|
|
In code block 5, replace_key is generated by macro KEY(). From the
|
|
definition of macro KEY(),
|
|
[code block 7]
|
|
71 #define KEY(inode, offset, size) \
|
|
72 ((struct bkey) { \
|
|
73 .high = (1ULL << 63) | ((__u64) (size) << 20) | (inode), \
|
|
74 .low = (offset) \
|
|
75 })
|
|
|
|
Here 'size' is 16bits width embedded in 64bits member 'high' of struct
|
|
bkey. But in code block 1, if "KEY_START(k) - bio->bi_iter.bi_sector" is
|
|
very probably to be larger than (1<<16) - 1, which makes the bkey size
|
|
calculation in code block 5 is overflowed. In one bug report the value
|
|
of parameter 'sectors' is 131072 (= 1 << 17), the overflowed 'sectors'
|
|
results the overflowed s->insert_bio_sectors in code block 4, then makes
|
|
size field of s->iop.replace_key to be 0 in code block 5. Then the 0-
|
|
sized s->iop.replace_key is inserted into the internal B+ tree as cache
|
|
missing check key (a special key to detect and avoid a racing between
|
|
normal write request and cache missing read request) as,
|
|
[code block 8]
|
|
915 ret = bch_btree_insert_check_key(b, &s->op, &s->iop.replace_key);
|
|
|
|
Then the 0-sized s->iop.replace_key as 3rd parameter triggers the bkey
|
|
size check BUG_ON() in code block 2, and causes the kernel panic 1).
|
|
|
|
Another ke
|
|
---truncated---(CVE-2021-47275)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
kvm: avoid speculation-based attacks from out-of-range memslot accesses
|
|
|
|
KVM's mechanism for accessing guest memory translates a guest physical
|
|
address (gpa) to a host virtual address using the right-shifted gpa
|
|
(also known as gfn) and a struct kvm_memory_slot. The translation is
|
|
performed in __gfn_to_hva_memslot using the following formula:
|
|
|
|
hva = slot->userspace_addr + (gfn - slot->base_gfn) * PAGE_SIZE
|
|
|
|
It is expected that gfn falls within the boundaries of the guest's
|
|
physical memory. However, a guest can access invalid physical addresses
|
|
in such a way that the gfn is invalid.
|
|
|
|
__gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which first
|
|
retrieves a memslot through __gfn_to_memslot. While __gfn_to_memslot
|
|
does check that the gfn falls within the boundaries of the guest's
|
|
physical memory or not, a CPU can speculate the result of the check and
|
|
continue execution speculatively using an illegal gfn. The speculation
|
|
can result in calculating an out-of-bounds hva. If the resulting host
|
|
virtual address is used to load another guest physical address, this
|
|
is effectively a Spectre gadget consisting of two consecutive reads,
|
|
the second of which is data dependent on the first.
|
|
|
|
Right now it's not clear if there are any cases in which this is
|
|
exploitable. One interesting case was reported by the original author
|
|
of this patch, and involves visiting guest page tables on x86. Right
|
|
now these are not vulnerable because the hva read goes through get_user(),
|
|
which contains an LFENCE speculation barrier. However, there are
|
|
patches in progress for x86 uaccess.h to mask kernel addresses instead of
|
|
using LFENCE; once these land, a guest could use speculation to read
|
|
from the VMM's ring 3 address space. Other architectures such as ARM
|
|
already use the address masking method, and would be susceptible to
|
|
this same kind of data-dependent access gadgets. Therefore, this patch
|
|
proactively protects from these attacks by masking out-of-bounds gfns
|
|
in __gfn_to_hva_memslot, which blocks speculation of invalid hvas.
|
|
|
|
Sean Christopherson noted that this patch does not cover
|
|
kvm_read_guest_offset_cached. This however is limited to a few bytes
|
|
past the end of the cache, and therefore it is unlikely to be useful in
|
|
the context of building a chain of data dependent accesses.(CVE-2021-47277)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: fix uninit-value in caif_seqpkt_sendmsg
|
|
|
|
When nr_segs equal to zero in iovec_from_user, the object
|
|
msg->msg_iter.iov is uninit stack memory in caif_seqpkt_sendmsg
|
|
which is defined in ___sys_sendmsg. So we cann't just judge
|
|
msg->msg_iter.iov->base directlly. We can use nr_segs to judge
|
|
msg in caif_seqpkt_sendmsg whether has data buffers.
|
|
|
|
=====================================================
|
|
BUG: KMSAN: uninit-value in caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542
|
|
Call Trace:
|
|
__dump_stack lib/dump_stack.c:77 [inline]
|
|
dump_stack+0x1c9/0x220 lib/dump_stack.c:118
|
|
kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118
|
|
__msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215
|
|
caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542
|
|
sock_sendmsg_nosec net/socket.c:652 [inline]
|
|
sock_sendmsg net/socket.c:672 [inline]
|
|
____sys_sendmsg+0x12b6/0x1350 net/socket.c:2343
|
|
___sys_sendmsg net/socket.c:2397 [inline]
|
|
__sys_sendmmsg+0x808/0xc90 net/socket.c:2480
|
|
__compat_sys_sendmmsg net/compat.c:656 [inline](CVE-2021-47297)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
memory: fsl_ifc: fix leak of private memory on probe failure
|
|
|
|
On probe error the driver should free the memory allocated for private
|
|
structure. Fix this by using resource-managed allocation.(CVE-2021-47314)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
watchdog: sc520_wdt: Fix possible use-after-free in wdt_turnoff()
|
|
|
|
This module's remove path calls del_timer(). However, that function
|
|
does not wait until the timer handler finishes. This means that the
|
|
timer handler may still be running after the driver's remove function
|
|
has finished, which would result in a use-after-free.
|
|
|
|
Fix by calling del_timer_sync(), which makes sure the timer handler
|
|
has finished, and unable to re-schedule itself.(CVE-2021-47323)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tty: serial: 8250: serial_cs: Fix a memory leak in error handling path
|
|
|
|
In the probe function, if the final 'serial_config()' fails, 'info' is
|
|
leaking.
|
|
|
|
Add a resource handling path to free this memory.(CVE-2021-47330)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
powerpc/mm: Fix lockup on kernel exec fault
|
|
|
|
The powerpc kernel is not prepared to handle exec faults from kernel.
|
|
Especially, the function is_exec_fault() will return 'false' when an
|
|
exec fault is taken by kernel, because the check is based on reading
|
|
current->thread.regs->trap which contains the trap from user.
|
|
|
|
For instance, when provoking a LKDTM EXEC_USERSPACE test,
|
|
current->thread.regs->trap is set to SYSCALL trap (0xc00), and
|
|
the fault taken by the kernel is not seen as an exec fault by
|
|
set_access_flags_filter().
|
|
|
|
Commit d7df2443cd5f ("powerpc/mm: Fix spurious segfaults on radix
|
|
with autonuma") made it clear and handled it properly. But later on
|
|
commit d3ca587404b3 ("powerpc/mm: Fix reporting of kernel execute
|
|
faults") removed that handling, introducing test based on error_code.
|
|
And here is the problem, because on the 603 all upper bits of SRR1
|
|
get cleared when the TLB instruction miss handler bails out to ISI.
|
|
|
|
Until commit cbd7e6ca0210 ("powerpc/fault: Avoid heavy
|
|
search_exception_tables() verification"), an exec fault from kernel
|
|
at a userspace address was indirectly caught by the lack of entry for
|
|
that address in the exception tables. But after that commit the
|
|
kernel mainly relies on KUAP or on core mm handling to catch wrong
|
|
user accesses. Here the access is not wrong, so mm handles it.
|
|
It is a minor fault because PAGE_EXEC is not set,
|
|
set_access_flags_filter() should set PAGE_EXEC and voila.
|
|
But as is_exec_fault() returns false as explained in the beginning,
|
|
set_access_flags_filter() bails out without setting PAGE_EXEC flag,
|
|
which leads to a forever minor exec fault.
|
|
|
|
As the kernel is not prepared to handle such exec faults, the thing to
|
|
do is to fire in bad_kernel_fault() for any exec fault taken by the
|
|
kernel, as it was prior to commit d3ca587404b3.(CVE-2021-47350)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
udf: Fix NULL pointer dereference in udf_symlink function
|
|
|
|
In function udf_symlink, epos.bh is assigned with the value returned
|
|
by udf_tgetblk. The function udf_tgetblk is defined in udf/misc.c
|
|
and returns the value of sb_getblk function that could be NULL.
|
|
Then, epos.bh is used without any check, causing a possible
|
|
NULL pointer dereference when sb_getblk fails.
|
|
|
|
This fix adds a check to validate the value of epos.bh.(CVE-2021-47353)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
atm: nicstar: Fix possible use-after-free in nicstar_cleanup()
|
|
|
|
This module's remove path calls del_timer(). However, that function
|
|
does not wait until the timer handler finishes. This means that the
|
|
timer handler may still be running after the driver's remove function
|
|
has finished, which would result in a use-after-free.
|
|
|
|
Fix by calling del_timer_sync(), which makes sure the timer handler
|
|
has finished, and unable to re-schedule itself.(CVE-2021-47355)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mISDN: fix possible use-after-free in HFC_cleanup()
|
|
|
|
This module's remove path calls del_timer(). However, that function
|
|
does not wait until the timer handler finishes. This means that the
|
|
timer handler may still be running after the driver's remove function
|
|
has finished, which would result in a use-after-free.
|
|
|
|
Fix by calling del_timer_sync(), which makes sure the timer handler
|
|
has finished, and unable to re-schedule itself.(CVE-2021-47356)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
atm: iphase: fix possible use-after-free in ia_module_exit()
|
|
|
|
This module's remove path calls del_timer(). However, that function
|
|
does not wait until the timer handler finishes. This means that the
|
|
timer handler may still be running after the driver's remove function
|
|
has finished, which would result in a use-after-free.
|
|
|
|
Fix by calling del_timer_sync(), which makes sure the timer handler
|
|
has finished, and unable to re-schedule itself.(CVE-2021-47357)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mcb: fix error handling in mcb_alloc_bus()
|
|
|
|
There are two bugs:
|
|
1) If ida_simple_get() fails then this code calls put_device(carrier)
|
|
but we haven't yet called get_device(carrier) and probably that
|
|
leads to a use after free.
|
|
2) After device_initialize() then we need to use put_device() to
|
|
release the bus. This will free the internal resources tied to the
|
|
device and call mcb_free_bus() which will free the rest.(CVE-2021-47361)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amd/pm: Update intermediate power state for SI
|
|
|
|
Update the current state as boot state during dpm initialization.
|
|
During the subsequent initialization, set_power_state gets called to
|
|
transition to the final power state. set_power_state refers to values
|
|
from the current state and without current state populated, it could
|
|
result in NULL pointer dereference.
|
|
|
|
For ex: on platforms where PCI speed change is supported through ACPI
|
|
ATCS method, the link speed of current state needs to be queried before
|
|
deciding on changing to final power state's link speed. The logic to query
|
|
ATCS-support was broken on certain platforms. The issue became visible
|
|
when broken ATCS-support logic got fixed with commit
|
|
f9b7f3703ff9 ("drm/amdgpu/acpi: make ATPX/ATCS structures global (v2)").
|
|
|
|
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1698(CVE-2021-47362)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mac80211: fix use-after-free in CCMP/GCMP RX
|
|
|
|
When PN checking is done in mac80211, for fragmentation we need
|
|
to copy the PN to the RX struct so we can later use it to do a
|
|
comparison, since commit bf30ca922a0c ("mac80211: check defrag
|
|
PN against current frame").
|
|
|
|
Unfortunately, in that commit I used the 'hdr' variable without
|
|
it being necessarily valid, so use-after-free could occur if it
|
|
was necessary to reallocate (parts of) the frame.
|
|
|
|
Fix this by reloading the variable after the code that results
|
|
in the reallocations, if any.
|
|
|
|
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=214401.(CVE-2021-47388)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mac80211: limit injected vht mcs/nss in ieee80211_parse_tx_radiotap
|
|
|
|
Limit max values for vht mcs and nss in ieee80211_parse_tx_radiotap
|
|
routine in order to fix the following warning reported by syzbot:
|
|
|
|
WARNING: CPU: 0 PID: 10717 at include/net/mac80211.h:989 ieee80211_rate_set_vht include/net/mac80211.h:989 [inline]
|
|
WARNING: CPU: 0 PID: 10717 at include/net/mac80211.h:989 ieee80211_parse_tx_radiotap+0x101e/0x12d0 net/mac80211/tx.c:2244
|
|
Modules linked in:
|
|
CPU: 0 PID: 10717 Comm: syz-executor.5 Not tainted 5.14.0-syzkaller #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
|
|
RIP: 0010:ieee80211_rate_set_vht include/net/mac80211.h:989 [inline]
|
|
RIP: 0010:ieee80211_parse_tx_radiotap+0x101e/0x12d0 net/mac80211/tx.c:2244
|
|
RSP: 0018:ffffc9000186f3e8 EFLAGS: 00010216
|
|
RAX: 0000000000000618 RBX: ffff88804ef76500 RCX: ffffc900143a5000
|
|
RDX: 0000000000040000 RSI: ffffffff888f478e RDI: 0000000000000003
|
|
RBP: 00000000ffffffff R08: 0000000000000000 R09: 0000000000000100
|
|
R10: ffffffff888f46f9 R11: 0000000000000000 R12: 00000000fffffff8
|
|
R13: ffff88804ef7653c R14: 0000000000000001 R15: 0000000000000004
|
|
FS: 00007fbf5718f700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000001b2de23000 CR3: 000000006a671000 CR4: 00000000001506f0
|
|
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
|
|
Call Trace:
|
|
ieee80211_monitor_select_queue+0xa6/0x250 net/mac80211/iface.c:740
|
|
netdev_core_pick_tx+0x169/0x2e0 net/core/dev.c:4089
|
|
__dev_queue_xmit+0x6f9/0x3710 net/core/dev.c:4165
|
|
__bpf_tx_skb net/core/filter.c:2114 [inline]
|
|
__bpf_redirect_no_mac net/core/filter.c:2139 [inline]
|
|
__bpf_redirect+0x5ba/0xd20 net/core/filter.c:2162
|
|
____bpf_clone_redirect net/core/filter.c:2429 [inline]
|
|
bpf_clone_redirect+0x2ae/0x420 net/core/filter.c:2401
|
|
bpf_prog_eeb6f53a69e5c6a2+0x59/0x234
|
|
bpf_dispatcher_nop_func include/linux/bpf.h:717 [inline]
|
|
__bpf_prog_run include/linux/filter.h:624 [inline]
|
|
bpf_prog_run include/linux/filter.h:631 [inline]
|
|
bpf_test_run+0x381/0xa30 net/bpf/test_run.c:119
|
|
bpf_prog_test_run_skb+0xb84/0x1ee0 net/bpf/test_run.c:663
|
|
bpf_prog_test_run kernel/bpf/syscall.c:3307 [inline]
|
|
__sys_bpf+0x2137/0x5df0 kernel/bpf/syscall.c:4605
|
|
__do_sys_bpf kernel/bpf/syscall.c:4691 [inline]
|
|
__se_sys_bpf kernel/bpf/syscall.c:4689 [inline]
|
|
__x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:4689
|
|
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
|
|
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
|
|
entry_SYSCALL_64_after_hwframe+0x44/0xae
|
|
RIP: 0033:0x4665f9(CVE-2021-47395)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
sctp: break out if skb_header_pointer returns NULL in sctp_rcv_ootb
|
|
|
|
We should always check if skb_header_pointer's return is NULL before
|
|
using it, otherwise it may cause null-ptr-deref, as syzbot reported:
|
|
|
|
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
|
|
RIP: 0010:sctp_rcv_ootb net/sctp/input.c:705 [inline]
|
|
RIP: 0010:sctp_rcv+0x1d84/0x3220 net/sctp/input.c:196
|
|
Call Trace:
|
|
<IRQ>
|
|
sctp6_rcv+0x38/0x60 net/sctp/ipv6.c:1109
|
|
ip6_protocol_deliver_rcu+0x2e9/0x1ca0 net/ipv6/ip6_input.c:422
|
|
ip6_input_finish+0x62/0x170 net/ipv6/ip6_input.c:463
|
|
NF_HOOK include/linux/netfilter.h:307 [inline]
|
|
NF_HOOK include/linux/netfilter.h:301 [inline]
|
|
ip6_input+0x9c/0xd0 net/ipv6/ip6_input.c:472
|
|
dst_input include/net/dst.h:460 [inline]
|
|
ip6_rcv_finish net/ipv6/ip6_input.c:76 [inline]
|
|
NF_HOOK include/linux/netfilter.h:307 [inline]
|
|
NF_HOOK include/linux/netfilter.h:301 [inline]
|
|
ipv6_rcv+0x28c/0x3c0 net/ipv6/ip6_input.c:297(CVE-2021-47397)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ipack: ipoctal: fix stack information leak
|
|
|
|
The tty driver name is used also after registering the driver and must
|
|
specifically not be allocated on the stack to avoid leaking information
|
|
to user space (or triggering an oops).
|
|
|
|
Drivers should not try to encode topology information in the tty device
|
|
name but this one snuck in through staging without anyone noticing and
|
|
another driver has since copied this malpractice.
|
|
|
|
Fixing the ABI is a separate issue, but this at least plugs the security
|
|
hole.(CVE-2021-47401)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
HID: betop: fix slab-out-of-bounds Write in betop_probe
|
|
|
|
Syzbot reported slab-out-of-bounds Write bug in hid-betopff driver.
|
|
The problem is the driver assumes the device must have an input report but
|
|
some malicious devices violate this assumption.
|
|
|
|
So this patch checks hid_device's input is non empty before it's been used.(CVE-2021-47404)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
HID: usbhid: free raw_report buffers in usbhid_stop
|
|
|
|
Free the unsent raw_report buffers when the device is removed.
|
|
|
|
Fixes a memory leak reported by syzbot at:
|
|
https://syzkaller.appspot.com/bug?id=7b4fa7cb1a7c2d3342a2a8a6c53371c8c418ab47(CVE-2021-47405)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: conntrack: serialize hash resizes and cleanups
|
|
|
|
Syzbot was able to trigger the following warning [1]
|
|
|
|
No repro found by syzbot yet but I was able to trigger similar issue
|
|
by having 2 scripts running in parallel, changing conntrack hash sizes,
|
|
and:
|
|
|
|
for j in `seq 1 1000` ; do unshare -n /bin/true >/dev/null ; done
|
|
|
|
It would take more than 5 minutes for net_namespace structures
|
|
to be cleaned up.
|
|
|
|
This is because nf_ct_iterate_cleanup() has to restart everytime
|
|
a resize happened.
|
|
|
|
By adding a mutex, we can serialize hash resizes and cleanups
|
|
and also make get_next_corpse() faster by skipping over empty
|
|
buckets.
|
|
|
|
Even without resizes in the picture, this patch considerably
|
|
speeds up network namespace dismantles.
|
|
|
|
[1]
|
|
INFO: task syz-executor.0:8312 can't die for more than 144 seconds.
|
|
task:syz-executor.0 state:R running task stack:25672 pid: 8312 ppid: 6573 flags:0x00004006
|
|
Call Trace:
|
|
context_switch kernel/sched/core.c:4955 [inline]
|
|
__schedule+0x940/0x26f0 kernel/sched/core.c:6236
|
|
preempt_schedule_common+0x45/0xc0 kernel/sched/core.c:6408
|
|
preempt_schedule_thunk+0x16/0x18 arch/x86/entry/thunk_64.S:35
|
|
__local_bh_enable_ip+0x109/0x120 kernel/softirq.c:390
|
|
local_bh_enable include/linux/bottom_half.h:32 [inline]
|
|
get_next_corpse net/netfilter/nf_conntrack_core.c:2252 [inline]
|
|
nf_ct_iterate_cleanup+0x15a/0x450 net/netfilter/nf_conntrack_core.c:2275
|
|
nf_conntrack_cleanup_net_list+0x14c/0x4f0 net/netfilter/nf_conntrack_core.c:2469
|
|
ops_exit_list+0x10d/0x160 net/core/net_namespace.c:171
|
|
setup_net+0x639/0xa30 net/core/net_namespace.c:349
|
|
copy_net_ns+0x319/0x760 net/core/net_namespace.c:470
|
|
create_new_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110
|
|
unshare_nsproxy_namespaces+0xc1/0x1f0 kernel/nsproxy.c:226
|
|
ksys_unshare+0x445/0x920 kernel/fork.c:3128
|
|
__do_sys_unshare kernel/fork.c:3202 [inline]
|
|
__se_sys_unshare kernel/fork.c:3200 [inline]
|
|
__x64_sys_unshare+0x2d/0x40 kernel/fork.c:3200
|
|
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
|
|
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
|
|
entry_SYSCALL_64_after_hwframe+0x44/0xae
|
|
RIP: 0033:0x7f63da68e739
|
|
RSP: 002b:00007f63d7c05188 EFLAGS: 00000246 ORIG_RAX: 0000000000000110
|
|
RAX: ffffffffffffffda RBX: 00007f63da792f80 RCX: 00007f63da68e739
|
|
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000040000000
|
|
RBP: 00007f63da6e8cc4 R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f63da792f80
|
|
R13: 00007fff50b75d3f R14: 00007f63d7c05300 R15: 0000000000022000
|
|
|
|
Showing all locks held in the system:
|
|
1 lock held by khungtaskd/27:
|
|
#0: ffffffff8b980020 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x53/0x260 kernel/locking/lockdep.c:6446
|
|
2 locks held by kworker/u4:2/153:
|
|
#0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
|
|
#0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: arch_atomic_long_set include/linux/atomic/atomic-long.h:41 [inline]
|
|
#0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: atomic_long_set include/linux/atomic/atomic-instrumented.h:1198 [inline]
|
|
#0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: set_work_data kernel/workqueue.c:634 [inline]
|
|
#0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: set_work_pool_and_clear_pending kernel/workqueue.c:661 [inline]
|
|
#0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x896/0x1690 kernel/workqueue.c:2268
|
|
#1: ffffc9000140fdb0 ((kfence_timer).work){+.+.}-{0:0}, at: process_one_work+0x8ca/0x1690 kernel/workqueue.c:2272
|
|
1 lock held by systemd-udevd/2970:
|
|
1 lock held by in:imklog/6258:
|
|
#0: ffff88807f970ff0 (&f->f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0xe9/0x100 fs/file.c:990
|
|
3 locks held by kworker/1:6/8158:
|
|
1 lock held by syz-executor.0/8312:
|
|
2 locks held by kworker/u4:13/9320:
|
|
1 lock held by
|
|
---truncated---(CVE-2021-47408)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/nouveau/debugfs: fix file release memory leak
|
|
|
|
When using single_open() for opening, single_release() should be
|
|
called, otherwise the 'op' allocated in single_open() will be leaked.(CVE-2021-47423)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: iscsi: Fix iscsi_task use after free
|
|
|
|
Commit d39df158518c ("scsi: iscsi: Have abort handler get ref to conn")
|
|
added iscsi_get_conn()/iscsi_put_conn() calls during abort handling but
|
|
then also changed the handling of the case where we detect an already
|
|
completed task where we now end up doing a goto to the common put/cleanup
|
|
code. This results in a iscsi_task use after free, because the common
|
|
cleanup code will do a put on the iscsi_task.
|
|
|
|
This reverts the goto and moves the iscsi_get_conn() to after we've checked
|
|
if the iscsi_task is valid.(CVE-2021-47427)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/mlx5e: Fix memory leak in mlx5_core_destroy_cq() error path
|
|
|
|
Prior to this patch in case mlx5_core_destroy_cq() failed it returns
|
|
without completing all destroy operations and that leads to memory leak.
|
|
Instead, complete the destroy flow before return error.
|
|
|
|
Also move mlx5_debug_cq_remove() to the beginning of mlx5_core_destroy_cq()
|
|
to be symmetrical with mlx5_core_create_cq().
|
|
|
|
kmemleak complains on:
|
|
|
|
unreferenced object 0xc000000038625100 (size 64):
|
|
comm "ethtool", pid 28301, jiffies 4298062946 (age 785.380s)
|
|
hex dump (first 32 bytes):
|
|
60 01 48 94 00 00 00 c0 b8 05 34 c3 00 00 00 c0 `.H.......4.....
|
|
02 00 00 00 00 00 00 00 00 db 7d c1 00 00 00 c0 ..........}.....
|
|
backtrace:
|
|
[<000000009e8643cb>] add_res_tree+0xd0/0x270 [mlx5_core]
|
|
[<00000000e7cb8e6c>] mlx5_debug_cq_add+0x5c/0xc0 [mlx5_core]
|
|
[<000000002a12918f>] mlx5_core_create_cq+0x1d0/0x2d0 [mlx5_core]
|
|
[<00000000cef0a696>] mlx5e_create_cq+0x210/0x3f0 [mlx5_core]
|
|
[<000000009c642c26>] mlx5e_open_cq+0xb4/0x130 [mlx5_core]
|
|
[<0000000058dfa578>] mlx5e_ptp_open+0x7f4/0xe10 [mlx5_core]
|
|
[<0000000081839561>] mlx5e_open_channels+0x9cc/0x13e0 [mlx5_core]
|
|
[<0000000009cf05d4>] mlx5e_switch_priv_channels+0xa4/0x230
|
|
[mlx5_core]
|
|
[<0000000042bbedd8>] mlx5e_safe_switch_params+0x14c/0x300
|
|
[mlx5_core]
|
|
[<0000000004bc9db8>] set_pflag_tx_port_ts+0x9c/0x160 [mlx5_core]
|
|
[<00000000a0553443>] mlx5e_set_priv_flags+0xd0/0x1b0 [mlx5_core]
|
|
[<00000000a8f3d84b>] ethnl_set_privflags+0x234/0x2d0
|
|
[<00000000fd27f27c>] genl_family_rcv_msg_doit+0x108/0x1d0
|
|
[<00000000f495e2bb>] genl_family_rcv_msg+0xe4/0x1f0
|
|
[<00000000646c5c2c>] genl_rcv_msg+0x78/0x120
|
|
[<00000000d53e384e>] netlink_rcv_skb+0x74/0x1a0(CVE-2021-47438)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
NFC: digital: fix possible memory leak in digital_in_send_sdd_req()
|
|
|
|
'skb' is allocated in digital_in_send_sdd_req(), but not free when
|
|
digital_in_send_cmd() failed, which will cause memory leak. Fix it
|
|
by freeing 'skb' if digital_in_send_cmd() return failed.(CVE-2021-47442)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
NFC: digital: fix possible memory leak in digital_tg_listen_mdaa()
|
|
|
|
'params' is allocated in digital_tg_listen_mdaa(), but not free when
|
|
digital_send_cmd() failed, which will cause memory leak. Fix it by
|
|
freeing 'params' if digital_send_cmd() return failed.(CVE-2021-47443)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/msm: Fix null pointer dereference on pointer edp
|
|
|
|
The initialization of pointer dev dereferences pointer edp before
|
|
edp is null checked, so there is a potential null pointer deference
|
|
issue. Fix this by only dereferencing edp after edp has been null
|
|
checked.
|
|
|
|
Addresses-Coverity: ("Dereference before null check")(CVE-2021-47445)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ocfs2: mount fails with buffer overflow in strlen
|
|
|
|
Starting with kernel 5.11 built with CONFIG_FORTIFY_SOURCE mouting an
|
|
ocfs2 filesystem with either o2cb or pcmk cluster stack fails with the
|
|
trace below. Problem seems to be that strings for cluster stack and
|
|
cluster name are not guaranteed to be null terminated in the disk
|
|
representation, while strlcpy assumes that the source string is always
|
|
null terminated. This causes a read outside of the source string
|
|
triggering the buffer overflow detection.
|
|
|
|
detected buffer overflow in strlen
|
|
------------[ cut here ]------------
|
|
kernel BUG at lib/string.c:1149!
|
|
invalid opcode: 0000 [#1] SMP PTI
|
|
CPU: 1 PID: 910 Comm: mount.ocfs2 Not tainted 5.14.0-1-amd64 #1
|
|
Debian 5.14.6-2
|
|
RIP: 0010:fortify_panic+0xf/0x11
|
|
...
|
|
Call Trace:
|
|
ocfs2_initialize_super.isra.0.cold+0xc/0x18 [ocfs2]
|
|
ocfs2_fill_super+0x359/0x19b0 [ocfs2]
|
|
mount_bdev+0x185/0x1b0
|
|
legacy_get_tree+0x27/0x40
|
|
vfs_get_tree+0x25/0xb0
|
|
path_mount+0x454/0xa20
|
|
__x64_sys_mount+0x103/0x140
|
|
do_syscall_64+0x3b/0xc0
|
|
entry_SYSCALL_64_after_hwframe+0x44/0xae(CVE-2021-47458)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
can: j1939: j1939_netdev_start(): fix UAF for rx_kref of j1939_priv
|
|
|
|
It will trigger UAF for rx_kref of j1939_priv as following.
|
|
|
|
cpu0 cpu1
|
|
j1939_sk_bind(socket0, ndev0, ...)
|
|
j1939_netdev_start
|
|
j1939_sk_bind(socket1, ndev0, ...)
|
|
j1939_netdev_start
|
|
j1939_priv_set
|
|
j1939_priv_get_by_ndev_locked
|
|
j1939_jsk_add
|
|
.....
|
|
j1939_netdev_stop
|
|
kref_put_lock(&priv->rx_kref, ...)
|
|
kref_get(&priv->rx_kref, ...)
|
|
REFCOUNT_WARN("addition on 0;...")
|
|
|
|
====================================================
|
|
refcount_t: addition on 0; use-after-free.
|
|
WARNING: CPU: 1 PID: 20874 at lib/refcount.c:25 refcount_warn_saturate+0x169/0x1e0
|
|
RIP: 0010:refcount_warn_saturate+0x169/0x1e0
|
|
Call Trace:
|
|
j1939_netdev_start+0x68b/0x920
|
|
j1939_sk_bind+0x426/0xeb0
|
|
? security_socket_bind+0x83/0xb0
|
|
|
|
The rx_kref's kref_get() and kref_put() should use j1939_netdev_lock to
|
|
protect.(CVE-2021-47459)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
comedi: vmk80xx: fix transfer-buffer overflows
|
|
|
|
The driver uses endpoint-sized USB transfer buffers but up until
|
|
recently had no sanity checks on the sizes.
|
|
|
|
Commit e1f13c879a7c ("staging: comedi: check validity of wMaxPacketSize
|
|
of usb endpoints found") inadvertently fixed NULL-pointer dereferences
|
|
when accessing the transfer buffers in case a malicious device has a
|
|
zero wMaxPacketSize.
|
|
|
|
Make sure to allocate buffers large enough to handle also the other
|
|
accesses that are done without a size check (e.g. byte 18 in
|
|
vmk80xx_cnt_insn_read() for the VMK8061_MODEL) to avoid writing beyond
|
|
the buffers, for example, when doing descriptor fuzzing.
|
|
|
|
The original driver was for a low-speed device with 8-byte buffers.
|
|
Support was later added for a device that uses bulk transfers and is
|
|
presumably a full-speed device with a maximum 64-byte wMaxPacketSize.(CVE-2021-47475)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
comedi: dt9812: fix DMA buffers on stack
|
|
|
|
USB transfer buffers are typically mapped for DMA and must not be
|
|
allocated on the stack or transfers will fail.
|
|
|
|
Allocate proper transfer buffers in the various command helpers and
|
|
return an error on short transfers instead of acting on random stack
|
|
data.
|
|
|
|
Note that this also fixes a stack info leak on systems where DMA is not
|
|
used as 32 bytes are always sent to the device regardless of how short
|
|
the command is.(CVE-2021-47477)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
usbnet: sanity check for maxpacket
|
|
|
|
maxpacket of 0 makes no sense and oopses as we need to divide
|
|
by it. Give up.
|
|
|
|
V2: fixed typo in log and stylistic issues(CVE-2021-47495)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
perf hist: Fix memory leak of a perf_hpp_fmt
|
|
|
|
perf_hpp__column_unregister() removes an entry from a list but doesn't
|
|
free the memory causing a memory leak spotted by leak sanitizer.
|
|
|
|
Add the free while at the same time reducing the scope of the function
|
|
to static.(CVE-2021-47545)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port()
|
|
|
|
The if statement:
|
|
if (port >= DSAF_GE_NUM)
|
|
return;
|
|
|
|
limits the value of port less than DSAF_GE_NUM (i.e., 8).
|
|
However, if the value of port is 6 or 7, an array overflow could occur:
|
|
port_rst_off = dsaf_dev->mac_cb[port]->port_rst_off;
|
|
|
|
because the length of dsaf_dev->mac_cb is DSAF_MAX_PORT_NUM (i.e., 6).
|
|
|
|
To fix this possible array overflow, we first check port and if it is
|
|
greater than or equal to DSAF_MAX_PORT_NUM, the function returns.(CVE-2021-47548)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
sata_fsl: fix UAF in sata_fsl_port_stop when rmmod sata_fsl
|
|
|
|
When the `rmmod sata_fsl.ko` command is executed in the PPC64 GNU/Linux,
|
|
a bug is reported:
|
|
==================================================================
|
|
BUG: Unable to handle kernel data access on read at 0x80000800805b502c
|
|
Oops: Kernel access of bad area, sig: 11 [#1]
|
|
NIP [c0000000000388a4] .ioread32+0x4/0x20
|
|
LR [80000000000c6034] .sata_fsl_port_stop+0x44/0xe0 [sata_fsl]
|
|
Call Trace:
|
|
.free_irq+0x1c/0x4e0 (unreliable)
|
|
.ata_host_stop+0x74/0xd0 [libata]
|
|
.release_nodes+0x330/0x3f0
|
|
.device_release_driver_internal+0x178/0x2c0
|
|
.driver_detach+0x64/0xd0
|
|
.bus_remove_driver+0x70/0xf0
|
|
.driver_unregister+0x38/0x80
|
|
.platform_driver_unregister+0x14/0x30
|
|
.fsl_sata_driver_exit+0x18/0xa20 [sata_fsl]
|
|
.__se_sys_delete_module+0x1ec/0x2d0
|
|
.system_call_exception+0xfc/0x1f0
|
|
system_call_common+0xf8/0x200
|
|
==================================================================
|
|
|
|
The triggering of the BUG is shown in the following stack:
|
|
|
|
driver_detach
|
|
device_release_driver_internal
|
|
__device_release_driver
|
|
drv->remove(dev) --> platform_drv_remove/platform_remove
|
|
drv->remove(dev) --> sata_fsl_remove
|
|
iounmap(host_priv->hcr_base); <---- unmap
|
|
kfree(host_priv); <---- free
|
|
devres_release_all
|
|
release_nodes
|
|
dr->node.release(dev, dr->data) --> ata_host_stop
|
|
ap->ops->port_stop(ap) --> sata_fsl_port_stop
|
|
ioread32(hcr_base + HCONTROL) <---- UAF
|
|
host->ops->host_stop(host)
|
|
|
|
The iounmap(host_priv->hcr_base) and kfree(host_priv) functions should
|
|
not be executed in drv->remove. These functions should be executed in
|
|
host_stop after port_stop. Therefore, we move these functions to the
|
|
new function sata_fsl_host_stop and bind the new function to host_stop.(CVE-2021-47549)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/smc: Fix NULL pointer dereferencing in smc_vlan_by_tcpsk()
|
|
|
|
Coverity reports a possible NULL dereferencing problem:
|
|
|
|
in smc_vlan_by_tcpsk():
|
|
6. returned_null: netdev_lower_get_next returns NULL (checked 29 out of 30 times).
|
|
7. var_assigned: Assigning: ndev = NULL return value from netdev_lower_get_next.
|
|
1623 ndev = (struct net_device *)netdev_lower_get_next(ndev, &lower);
|
|
CID 1468509 (#1 of 1): Dereference null return value (NULL_RETURNS)
|
|
8. dereference: Dereferencing a pointer that might be NULL ndev when calling is_vlan_dev.
|
|
1624 if (is_vlan_dev(ndev)) {
|
|
|
|
Remove the manual implementation and use netdev_walk_all_lower_dev() to
|
|
iterate over the lower devices. While on it remove an obsolete function
|
|
parameter comment.(CVE-2021-47559)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
pinctrl: single: fix potential NULL dereference
|
|
|
|
Added checking of pointer "function" in pcs_set_mux().
|
|
pinmux_generic_get_function() can return NULL and the pointer
|
|
"function" was dereferenced without checking against NULL.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2022-48708)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
crypto: s390/aes - Fix buffer overread in CTR mode
|
|
|
|
When processing the last block, the s390 ctr code will always read
|
|
a whole block, even if there isn't a whole block of data left. Fix
|
|
this by using the actual length left and copy it into a buffer first
|
|
for processing.(CVE-2023-52669)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ACPI: video: check for error while searching for backlight device parent
|
|
|
|
If acpi_get_parent() called in acpi_video_dev_register_backlight()
|
|
fails, for example, because acpi_ut_acquire_mutex() fails inside
|
|
acpi_get_parent), this can lead to incorrect (uninitialized)
|
|
acpi_parent handle being passed to acpi_get_pci_dev() for detecting
|
|
the parent pci device.
|
|
|
|
Check acpi_get_parent() result and set parent device only in case of success.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52693)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
sysv: don't call sb_bread() with pointers_lock held
|
|
|
|
syzbot is reporting sleep in atomic context in SysV filesystem [1], for
|
|
sb_bread() is called with rw_spinlock held.
|
|
|
|
A "write_lock(&pointers_lock) => read_lock(&pointers_lock) deadlock" bug
|
|
and a "sb_bread() with write_lock(&pointers_lock)" bug were introduced by
|
|
"Replace BKL for chain locking with sysvfs-private rwlock" in Linux 2.5.12.
|
|
|
|
Then, "[PATCH] err1-40: sysvfs locking fix" in Linux 2.6.8 fixed the
|
|
former bug by moving pointers_lock lock to the callers, but instead
|
|
introduced a "sb_bread() with read_lock(&pointers_lock)" bug (which made
|
|
this problem easier to hit).
|
|
|
|
Al Viro suggested that why not to do like get_branch()/get_block()/
|
|
find_shared() in Minix filesystem does. And doing like that is almost a
|
|
revert of "[PATCH] err1-40: sysvfs locking fix" except that get_branch()
|
|
from with find_shared() is called without write_lock(&pointers_lock).(CVE-2023-52699)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/usb: kalmia: Don't pass act_len in usb_bulk_msg error path
|
|
|
|
syzbot reported that act_len in kalmia_send_init_packet() is
|
|
uninitialized when passing it to the first usb_bulk_msg error path. Jiri
|
|
Pirko noted that it's pointless to pass it in the error path, and that
|
|
the value that would be printed in the second error path would be the
|
|
value of act_len from the first call to usb_bulk_msg.[1]
|
|
|
|
With this in mind, let's just not pass act_len to the usb_bulk_msg error
|
|
paths.
|
|
|
|
1: https://lore.kernel.org/lkml/Y9pY61y1nwTuzMOa@nanopsycho/(CVE-2023-52703)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
arm64: Restrict CPU_BIG_ENDIAN to GNU as or LLVM IAS 15.x or newer
|
|
|
|
Prior to LLVM 15.0.0, LLVM's integrated assembler would incorrectly
|
|
byte-swap NOP when compiling for big-endian, and the resulting series of
|
|
bytes happened to match the encoding of FNMADD S21, S30, S0, S0.
|
|
|
|
This went unnoticed until commit:
|
|
|
|
34f66c4c4d5518c1 ("arm64: Use a positive cpucap for FP/SIMD")
|
|
|
|
Prior to that commit, the kernel would always enable the use of FPSIMD
|
|
early in boot when __cpu_setup() initialized CPACR_EL1, and so usage of
|
|
FNMADD within the kernel was not detected, but could result in the
|
|
corruption of user or kernel FPSIMD state.
|
|
|
|
After that commit, the instructions happen to trap during boot prior to
|
|
FPSIMD being detected and enabled, e.g.
|
|
|
|
| Unhandled 64-bit el1h sync exception on CPU0, ESR 0x000000001fe00000 -- ASIMD
|
|
| CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1
|
|
| Hardware name: linux,dummy-virt (DT)
|
|
| pstate: 400000c9 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
|
| pc : __pi_strcmp+0x1c/0x150
|
|
| lr : populate_properties+0xe4/0x254
|
|
| sp : ffffd014173d3ad0
|
|
| x29: ffffd014173d3af0 x28: fffffbfffddffcb8 x27: 0000000000000000
|
|
| x26: 0000000000000058 x25: fffffbfffddfe054 x24: 0000000000000008
|
|
| x23: fffffbfffddfe000 x22: fffffbfffddfe000 x21: fffffbfffddfe044
|
|
| x20: ffffd014173d3b70 x19: 0000000000000001 x18: 0000000000000005
|
|
| x17: 0000000000000010 x16: 0000000000000000 x15: 00000000413e7000
|
|
| x14: 0000000000000000 x13: 0000000000001bcc x12: 0000000000000000
|
|
| x11: 00000000d00dfeed x10: ffffd414193f2cd0 x9 : 0000000000000000
|
|
| x8 : 0101010101010101 x7 : ffffffffffffffc0 x6 : 0000000000000000
|
|
| x5 : 0000000000000000 x4 : 0101010101010101 x3 : 000000000000002a
|
|
| x2 : 0000000000000001 x1 : ffffd014171f2988 x0 : fffffbfffddffcb8
|
|
| Kernel panic - not syncing: Unhandled exception
|
|
| CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1
|
|
| Hardware name: linux,dummy-virt (DT)
|
|
| Call trace:
|
|
| dump_backtrace+0xec/0x108
|
|
| show_stack+0x18/0x2c
|
|
| dump_stack_lvl+0x50/0x68
|
|
| dump_stack+0x18/0x24
|
|
| panic+0x13c/0x340
|
|
| el1t_64_irq_handler+0x0/0x1c
|
|
| el1_abort+0x0/0x5c
|
|
| el1h_64_sync+0x64/0x68
|
|
| __pi_strcmp+0x1c/0x150
|
|
| unflatten_dt_nodes+0x1e8/0x2d8
|
|
| __unflatten_device_tree+0x5c/0x15c
|
|
| unflatten_device_tree+0x38/0x50
|
|
| setup_arch+0x164/0x1e0
|
|
| start_kernel+0x64/0x38c
|
|
| __primary_switched+0xbc/0xc4
|
|
|
|
Restrict CONFIG_CPU_BIG_ENDIAN to a known good assembler, which is
|
|
either GNU as or LLVM's IAS 15.0.0 and newer, which contains the linked
|
|
commit.(CVE-2023-52750)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
smb: client: fix use-after-free bug in cifs_debug_data_proc_show()
|
|
|
|
Skip SMB sessions that are being teared down
|
|
(e.g. @ses->ses_status == SES_EXITING) in cifs_debug_data_proc_show()
|
|
to avoid use-after-free in @ses.
|
|
|
|
This fixes the following GPF when reading from /proc/fs/cifs/DebugData
|
|
while mounting and umounting
|
|
|
|
[ 816.251274] general protection fault, probably for non-canonical
|
|
address 0x6b6b6b6b6b6b6d81: 0000 [#1] PREEMPT SMP NOPTI
|
|
...
|
|
[ 816.260138] Call Trace:
|
|
[ 816.260329] <TASK>
|
|
[ 816.260499] ? die_addr+0x36/0x90
|
|
[ 816.260762] ? exc_general_protection+0x1b3/0x410
|
|
[ 816.261126] ? asm_exc_general_protection+0x26/0x30
|
|
[ 816.261502] ? cifs_debug_tcon+0xbd/0x240 [cifs]
|
|
[ 816.261878] ? cifs_debug_tcon+0xab/0x240 [cifs]
|
|
[ 816.262249] cifs_debug_data_proc_show+0x516/0xdb0 [cifs]
|
|
[ 816.262689] ? seq_read_iter+0x379/0x470
|
|
[ 816.262995] seq_read_iter+0x118/0x470
|
|
[ 816.263291] proc_reg_read_iter+0x53/0x90
|
|
[ 816.263596] ? srso_alias_return_thunk+0x5/0x7f
|
|
[ 816.263945] vfs_read+0x201/0x350
|
|
[ 816.264211] ksys_read+0x75/0x100
|
|
[ 816.264472] do_syscall_64+0x3f/0x90
|
|
[ 816.264750] entry_SYSCALL_64_after_hwframe+0x6e/0xd8
|
|
[ 816.265135] RIP: 0033:0x7fd5e669d381(CVE-2023-52752)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
gfs2: ignore negated quota changes
|
|
|
|
When lots of quota changes are made, there may be cases in which an
|
|
inode's quota information is increased and then decreased, such as when
|
|
blocks are added to a file, then deleted from it. If the timing is
|
|
right, function do_qc can add pending quota changes to a transaction,
|
|
then later, another call to do_qc can negate those changes, resulting
|
|
in a net gain of 0. The quota_change information is recorded in the qc
|
|
buffer (and qd element of the inode as well). The buffer is added to the
|
|
transaction by the first call to do_qc, but a subsequent call changes
|
|
the value from non-zero back to zero. At that point it's too late to
|
|
remove the buffer_head from the transaction. Later, when the quota sync
|
|
code is called, the zero-change qd element is discovered and flagged as
|
|
an assert warning. If the fs is mounted with errors=panic, the kernel
|
|
will panic.
|
|
|
|
This is usually seen when files are truncated and the quota changes are
|
|
negated by punch_hole/truncate which uses gfs2_quota_hold and
|
|
gfs2_quota_unhold rather than block allocations that use gfs2_quota_lock
|
|
and gfs2_quota_unlock which automatically do quota sync.
|
|
|
|
This patch solves the problem by adding a check to qd_check_sync such
|
|
that net-zero quota changes already added to the transaction are no
|
|
longer deemed necessary to be synced, and skipped.
|
|
|
|
In this case references are taken for the qd and the slot from do_qc
|
|
so those need to be put. The normal sequence of events for a normal
|
|
non-zero quota change is as follows:
|
|
|
|
gfs2_quota_change
|
|
do_qc
|
|
qd_hold
|
|
slot_hold
|
|
|
|
Later, when the changes are to be synced:
|
|
|
|
gfs2_quota_sync
|
|
qd_fish
|
|
qd_check_sync
|
|
gets qd ref via lockref_get_not_dead
|
|
do_sync
|
|
do_qc(QC_SYNC)
|
|
qd_put
|
|
lockref_put_or_lock
|
|
qd_unlock
|
|
qd_put
|
|
lockref_put_or_lock
|
|
|
|
In the net-zero change case, we add a check to qd_check_sync so it puts
|
|
the qd and slot references acquired in gfs2_quota_change and skip the
|
|
unneeded sync.(CVE-2023-52759)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tty: vcc: Add check for kstrdup() in vcc_probe()
|
|
|
|
Add check for the return value of kstrdup() and return the error, if it
|
|
fails in order to avoid NULL pointer dereference.(CVE-2023-52789)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ipvlan: add ipvlan_route_v6_outbound() helper
|
|
|
|
Inspired by syzbot reports using a stack of multiple ipvlan devices.
|
|
|
|
Reduce stack size needed in ipvlan_process_v6_outbound() by moving
|
|
the flowi6 struct used for the route lookup in an non inlined
|
|
helper. ipvlan_route_v6_outbound() needs 120 bytes on the stack,
|
|
immediately reclaimed.
|
|
|
|
Also make sure ipvlan_process_v4_outbound() is not inlined.
|
|
|
|
We might also have to lower MAX_NEST_DEV, because only syzbot uses
|
|
setups with more than four stacked devices.
|
|
|
|
BUG: TASK stack guard page was hit at ffffc9000e803ff8 (stack is ffffc9000e804000..ffffc9000e808000)
|
|
stack guard page: 0000 [#1] SMP KASAN
|
|
CPU: 0 PID: 13442 Comm: syz-executor.4 Not tainted 6.1.52-syzkaller #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023
|
|
RIP: 0010:kasan_check_range+0x4/0x2a0 mm/kasan/generic.c:188
|
|
Code: 48 01 c6 48 89 c7 e8 db 4e c1 03 31 c0 5d c3 cc 0f 0b eb 02 0f 0b b8 ea ff ff ff 5d c3 cc 00 00 cc cc 00 00 cc cc 55 48 89 e5 <41> 57 41 56 41 55 41 54 53 b0 01 48 85 f6 0f 84 a4 01 00 00 48 89
|
|
RSP: 0018:ffffc9000e804000 EFLAGS: 00010246
|
|
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817e5bf2
|
|
RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff887c6568
|
|
RBP: ffffc9000e804000 R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff92001d0080c
|
|
R13: dffffc0000000000 R14: ffffffff87e6b100 R15: 0000000000000000
|
|
FS: 00007fd0c55826c0(0000) GS:ffff8881f6800000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: ffffc9000e803ff8 CR3: 0000000170ef7000 CR4: 00000000003506f0
|
|
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
Call Trace:
|
|
<#DF>
|
|
</#DF>
|
|
<TASK>
|
|
[<ffffffff81f281d1>] __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31
|
|
[<ffffffff817e5bf2>] instrument_atomic_read include/linux/instrumented.h:72 [inline]
|
|
[<ffffffff817e5bf2>] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]
|
|
[<ffffffff817e5bf2>] cpumask_test_cpu include/linux/cpumask.h:506 [inline]
|
|
[<ffffffff817e5bf2>] cpu_online include/linux/cpumask.h:1092 [inline]
|
|
[<ffffffff817e5bf2>] trace_lock_acquire include/trace/events/lock.h:24 [inline]
|
|
[<ffffffff817e5bf2>] lock_acquire+0xe2/0x590 kernel/locking/lockdep.c:5632
|
|
[<ffffffff8563221e>] rcu_lock_acquire+0x2e/0x40 include/linux/rcupdate.h:306
|
|
[<ffffffff8561464d>] rcu_read_lock include/linux/rcupdate.h:747 [inline]
|
|
[<ffffffff8561464d>] ip6_pol_route+0x15d/0x1440 net/ipv6/route.c:2221
|
|
[<ffffffff85618120>] ip6_pol_route_output+0x50/0x80 net/ipv6/route.c:2606
|
|
[<ffffffff856f65b5>] pol_lookup_func include/net/ip6_fib.h:584 [inline]
|
|
[<ffffffff856f65b5>] fib6_rule_lookup+0x265/0x620 net/ipv6/fib6_rules.c:116
|
|
[<ffffffff85618009>] ip6_route_output_flags_noref+0x2d9/0x3a0 net/ipv6/route.c:2638
|
|
[<ffffffff8561821a>] ip6_route_output_flags+0xca/0x340 net/ipv6/route.c:2651
|
|
[<ffffffff838bd5a3>] ip6_route_output include/net/ip6_route.h:100 [inline]
|
|
[<ffffffff838bd5a3>] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:473 [inline]
|
|
[<ffffffff838bd5a3>] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline]
|
|
[<ffffffff838bd5a3>] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]
|
|
[<ffffffff838bd5a3>] ipvlan_queue_xmit+0xc33/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677
|
|
[<ffffffff838c2909>] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229
|
|
[<ffffffff84d03900>] netdev_start_xmit include/linux/netdevice.h:4966 [inline]
|
|
[<ffffffff84d03900>] xmit_one net/core/dev.c:3644 [inline]
|
|
[<ffffffff84d03900>] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660
|
|
[<ffffffff84d080e2>] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324
|
|
[<ffffffff855ce4cd>] dev_queue_xmit include/linux/netdevice.h:3067 [inline]
|
|
[<ffffffff855ce4cd>] neigh_hh_output include/net/neighbour.h:529 [inline]
|
|
[<f
|
|
---truncated---(CVE-2023-52796)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
jfs: fix array-index-out-of-bounds in dbFindLeaf
|
|
|
|
Currently while searching for dmtree_t for sufficient free blocks there
|
|
is an array out of bounds while getting element in tp->dm_stree. To add
|
|
the required check for out of bound we first need to determine the type
|
|
of dmtree. Thus added an extra parameter to dbFindLeaf so that the type
|
|
of tree can be determined and the required check can be applied.(CVE-2023-52799)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
iio: adc: stm32-adc: harden against NULL pointer deref in stm32_adc_probe()
|
|
|
|
of_match_device() may fail and returns a NULL pointer.
|
|
|
|
In practice there is no known reasonable way to trigger this, but
|
|
in case one is added in future, harden the code by adding the check(CVE-2023-52802)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fs/jfs: Add validity check for db_maxag and db_agpref
|
|
|
|
Both db_maxag and db_agpref are used as the index of the
|
|
db_agfree array, but there is currently no validity check for
|
|
db_maxag and db_agpref, which can lead to errors.
|
|
|
|
The following is related bug reported by Syzbot:
|
|
|
|
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:639:20
|
|
index 7936 is out of range for type 'atomic_t[128]'
|
|
|
|
Add checking that the values of db_maxag and db_agpref are valid
|
|
indexes for the db_agfree array.(CVE-2023-52804)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
jfs: fix array-index-out-of-bounds in diAlloc
|
|
|
|
Currently there is not check against the agno of the iag while
|
|
allocating new inodes to avoid fragmentation problem. Added the check
|
|
which is required.(CVE-2023-52805)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup()
|
|
|
|
fc_lport_ptp_setup() did not check the return value of fc_rport_create()
|
|
which can return NULL and would cause a NULL pointer dereference. Address
|
|
this issue by checking return value of fc_rport_create() and log error
|
|
message on fc_rport_create() failed.(CVE-2023-52809)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amd: Fix UBSAN array-index-out-of-bounds for Polaris and Tonga
|
|
|
|
For pptable structs that use flexible array sizes, use flexible arrays.(CVE-2023-52819)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
cpu/hotplug: Don't offline the last non-isolated CPU
|
|
|
|
If a system has isolated CPUs via the "isolcpus=" command line parameter,
|
|
then an attempt to offline the last housekeeping CPU will result in a
|
|
WARN_ON() when rebuilding the scheduler domains and a subsequent panic due
|
|
to and unhandled empty CPU mas in partition_sched_domains_locked().
|
|
|
|
cpuset_hotplug_workfn()
|
|
rebuild_sched_domains_locked()
|
|
ndoms = generate_sched_domains(&doms, &attr);
|
|
cpumask_and(doms[0], top_cpuset.effective_cpus, housekeeping_cpumask(HK_FLAG_DOMAIN));
|
|
|
|
Thus results in an empty CPU mask which triggers the warning and then the
|
|
subsequent crash:
|
|
|
|
WARNING: CPU: 4 PID: 80 at kernel/sched/topology.c:2366 build_sched_domains+0x120c/0x1408
|
|
Call trace:
|
|
build_sched_domains+0x120c/0x1408
|
|
partition_sched_domains_locked+0x234/0x880
|
|
rebuild_sched_domains_locked+0x37c/0x798
|
|
rebuild_sched_domains+0x30/0x58
|
|
cpuset_hotplug_workfn+0x2a8/0x930
|
|
|
|
Unable to handle kernel paging request at virtual address fffe80027ab37080
|
|
partition_sched_domains_locked+0x318/0x880
|
|
rebuild_sched_domains_locked+0x37c/0x798
|
|
|
|
Aside of the resulting crash, it does not make any sense to offline the last
|
|
last housekeeping CPU.
|
|
|
|
Prevent this by masking out the non-housekeeping CPUs when selecting a
|
|
target CPU for initiating the CPU unplug operation via the work queue.(CVE-2023-52831)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: mac80211: don't return unset power in ieee80211_get_tx_power()
|
|
|
|
We can get a UBSAN warning if ieee80211_get_tx_power() returns the
|
|
INT_MIN value mac80211 internally uses for "unset power level".
|
|
|
|
UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5
|
|
-2147483648 * 100 cannot be represented in type 'int'
|
|
CPU: 0 PID: 20433 Comm: insmod Tainted: G WC OE
|
|
Call Trace:
|
|
dump_stack+0x74/0x92
|
|
ubsan_epilogue+0x9/0x50
|
|
handle_overflow+0x8d/0xd0
|
|
__ubsan_handle_mul_overflow+0xe/0x10
|
|
nl80211_send_iface+0x688/0x6b0 [cfg80211]
|
|
[...]
|
|
cfg80211_register_wdev+0x78/0xb0 [cfg80211]
|
|
cfg80211_netdev_notifier_call+0x200/0x620 [cfg80211]
|
|
[...]
|
|
ieee80211_if_add+0x60e/0x8f0 [mac80211]
|
|
ieee80211_register_hw+0xda5/0x1170 [mac80211]
|
|
|
|
In this case, simply return an error instead, to indicate
|
|
that no data is available.(CVE-2023-52832)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tipc: Change nla_policy for bearer-related names to NLA_NUL_STRING
|
|
|
|
syzbot reported the following uninit-value access issue [1]:
|
|
|
|
=====================================================
|
|
BUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline]
|
|
BUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756
|
|
strlen lib/string.c:418 [inline]
|
|
strstr+0xb8/0x2f0 lib/string.c:756
|
|
tipc_nl_node_reset_link_stats+0x3ea/0xb50 net/tipc/node.c:2595
|
|
genl_family_rcv_msg_doit net/netlink/genetlink.c:971 [inline]
|
|
genl_family_rcv_msg net/netlink/genetlink.c:1051 [inline]
|
|
genl_rcv_msg+0x11ec/0x1290 net/netlink/genetlink.c:1066
|
|
netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2545
|
|
genl_rcv+0x40/0x60 net/netlink/genetlink.c:1075
|
|
netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline]
|
|
netlink_unicast+0xf47/0x1250 net/netlink/af_netlink.c:1368
|
|
netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
sock_sendmsg net/socket.c:753 [inline]
|
|
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541
|
|
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595
|
|
__sys_sendmsg net/socket.c:2624 [inline]
|
|
__do_sys_sendmsg net/socket.c:2633 [inline]
|
|
__se_sys_sendmsg net/socket.c:2631 [inline]
|
|
__x64_sys_sendmsg+0x307/0x490 net/socket.c:2631
|
|
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
|
|
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
|
|
entry_SYSCALL_64_after_hwframe+0x63/0xcd
|
|
|
|
Uninit was created at:
|
|
slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767
|
|
slab_alloc_node mm/slub.c:3478 [inline]
|
|
kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523
|
|
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559
|
|
__alloc_skb+0x318/0x740 net/core/skbuff.c:650
|
|
alloc_skb include/linux/skbuff.h:1286 [inline]
|
|
netlink_alloc_large_skb net/netlink/af_netlink.c:1214 [inline]
|
|
netlink_sendmsg+0xb34/0x13d0 net/netlink/af_netlink.c:1885
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
sock_sendmsg net/socket.c:753 [inline]
|
|
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541
|
|
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595
|
|
__sys_sendmsg net/socket.c:2624 [inline]
|
|
__do_sys_sendmsg net/socket.c:2633 [inline]
|
|
__se_sys_sendmsg net/socket.c:2631 [inline]
|
|
__x64_sys_sendmsg+0x307/0x490 net/socket.c:2631
|
|
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
|
|
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
|
|
entry_SYSCALL_64_after_hwframe+0x63/0xcd
|
|
|
|
TIPC bearer-related names including link names must be null-terminated
|
|
strings. If a link name which is not null-terminated is passed through
|
|
netlink, strstr() and similar functions can cause buffer overrun. This
|
|
causes the above issue.
|
|
|
|
This patch changes the nla_policy for bearer-related names from NLA_STRING
|
|
to NLA_NUL_STRING. This resolves the issue by ensuring that only
|
|
null-terminated strings are accepted as bearer-related names.
|
|
|
|
syzbot reported similar uninit-value issue related to bearer names [2]. The
|
|
root cause of this issue is that a non-null-terminated bearer name was
|
|
passed. This patch also resolved this issue.(CVE-2023-52845)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
can: dev: can_put_echo_skb(): don't crash kernel if can_priv::echo_skb is accessed out of bounds
|
|
|
|
If the "struct can_priv::echoo_skb" is accessed out of bounds, this
|
|
would cause a kernel crash. Instead, issue a meaningful warning
|
|
message and return with an error.(CVE-2023-52878)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
USB: core: Fix deadlock in usb_deauthorize_interface()
|
|
|
|
Among the attribute file callback routines in
|
|
drivers/usb/core/sysfs.c, the interface_authorized_store() function is
|
|
the only one which acquires a device lock on an ancestor device: It
|
|
calls usb_deauthorize_interface(), which locks the interface's parent
|
|
USB device.
|
|
|
|
The will lead to deadlock if another process already owns that lock
|
|
and tries to remove the interface, whether through a configuration
|
|
change or because the device has been disconnected. As part of the
|
|
removal procedure, device_del() waits for all ongoing sysfs attribute
|
|
callbacks to complete. But usb_deauthorize_interface() can't complete
|
|
until the device lock has been released, and the lock won't be
|
|
released until the removal has finished.
|
|
|
|
The mechanism provided by sysfs to prevent this kind of deadlock is
|
|
to use the sysfs_break_active_protection() function, which tells sysfs
|
|
not to wait for the attribute callback.
|
|
|
|
Reported-and-tested by: Yue Sun <samsun1006219@gmail.com>
|
|
Reported by: xingwei lee <xrivendell7@gmail.com>(CVE-2024-26934)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get()
|
|
|
|
nft_unregister_expr() can concurrent with __nft_expr_type_get(),
|
|
and there is not any protection when iterate over nf_tables_expressions
|
|
list in __nft_expr_type_get(). Therefore, there is potential data-race
|
|
of nf_tables_expressions list entry.
|
|
|
|
Use list_for_each_entry_rcu() to iterate over nf_tables_expressions
|
|
list in __nft_expr_type_get(), and use rcu_read_lock() in the caller
|
|
nft_expr_type_get() to protect the entire type query process.(CVE-2024-27020)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout
|
|
|
|
There is a race condition between l2cap_chan_timeout() and
|
|
l2cap_chan_del(). When we use l2cap_chan_del() to delete the
|
|
channel, the chan->conn will be set to null. But the conn could
|
|
be dereferenced again in the mutex_lock() of l2cap_chan_timeout().
|
|
As a result the null pointer dereference bug will happen. The
|
|
KASAN report triggered by POC is shown below:
|
|
|
|
[ 472.074580] ==================================================================
|
|
[ 472.075284] BUG: KASAN: null-ptr-deref in mutex_lock+0x68/0xc0
|
|
[ 472.075308] Write of size 8 at addr 0000000000000158 by task kworker/0:0/7
|
|
[ 472.075308]
|
|
[ 472.075308] CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.9.0-rc5-00356-g78c0094a146b #36
|
|
[ 472.075308] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4
|
|
[ 472.075308] Workqueue: events l2cap_chan_timeout
|
|
[ 472.075308] Call Trace:
|
|
[ 472.075308] <TASK>
|
|
[ 472.075308] dump_stack_lvl+0x137/0x1a0
|
|
[ 472.075308] print_report+0x101/0x250
|
|
[ 472.075308] ? __virt_addr_valid+0x77/0x160
|
|
[ 472.075308] ? mutex_lock+0x68/0xc0
|
|
[ 472.075308] kasan_report+0x139/0x170
|
|
[ 472.075308] ? mutex_lock+0x68/0xc0
|
|
[ 472.075308] kasan_check_range+0x2c3/0x2e0
|
|
[ 472.075308] mutex_lock+0x68/0xc0
|
|
[ 472.075308] l2cap_chan_timeout+0x181/0x300
|
|
[ 472.075308] process_one_work+0x5d2/0xe00
|
|
[ 472.075308] worker_thread+0xe1d/0x1660
|
|
[ 472.075308] ? pr_cont_work+0x5e0/0x5e0
|
|
[ 472.075308] kthread+0x2b7/0x350
|
|
[ 472.075308] ? pr_cont_work+0x5e0/0x5e0
|
|
[ 472.075308] ? kthread_blkcg+0xd0/0xd0
|
|
[ 472.075308] ret_from_fork+0x4d/0x80
|
|
[ 472.075308] ? kthread_blkcg+0xd0/0xd0
|
|
[ 472.075308] ret_from_fork_asm+0x11/0x20
|
|
[ 472.075308] </TASK>
|
|
[ 472.075308] ==================================================================
|
|
[ 472.094860] Disabling lock debugging due to kernel taint
|
|
[ 472.096136] BUG: kernel NULL pointer dereference, address: 0000000000000158
|
|
[ 472.096136] #PF: supervisor write access in kernel mode
|
|
[ 472.096136] #PF: error_code(0x0002) - not-present page
|
|
[ 472.096136] PGD 0 P4D 0
|
|
[ 472.096136] Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI
|
|
[ 472.096136] CPU: 0 PID: 7 Comm: kworker/0:0 Tainted: G B 6.9.0-rc5-00356-g78c0094a146b #36
|
|
[ 472.096136] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4
|
|
[ 472.096136] Workqueue: events l2cap_chan_timeout
|
|
[ 472.096136] RIP: 0010:mutex_lock+0x88/0xc0
|
|
[ 472.096136] Code: be 08 00 00 00 e8 f8 23 1f fd 4c 89 f7 be 08 00 00 00 e8 eb 23 1f fd 42 80 3c 23 00 74 08 48 88
|
|
[ 472.096136] RSP: 0018:ffff88800744fc78 EFLAGS: 00000246
|
|
[ 472.096136] RAX: 0000000000000000 RBX: 1ffff11000e89f8f RCX: ffffffff8457c865
|
|
[ 472.096136] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff88800744fc78
|
|
[ 472.096136] RBP: 0000000000000158 R08: ffff88800744fc7f R09: 1ffff11000e89f8f
|
|
[ 472.096136] R10: dffffc0000000000 R11: ffffed1000e89f90 R12: dffffc0000000000
|
|
[ 472.096136] R13: 0000000000000158 R14: ffff88800744fc78 R15: ffff888007405a00
|
|
[ 472.096136] FS: 0000000000000000(0000) GS:ffff88806d200000(0000) knlGS:0000000000000000
|
|
[ 472.096136] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 472.096136] CR2: 0000000000000158 CR3: 000000000da32000 CR4: 00000000000006f0
|
|
[ 472.096136] Call Trace:
|
|
[ 472.096136] <TASK>
|
|
[ 472.096136] ? __die_body+0x8d/0xe0
|
|
[ 472.096136] ? page_fault_oops+0x6b8/0x9a0
|
|
[ 472.096136] ? kernelmode_fixup_or_oops+0x20c/0x2a0
|
|
[ 472.096136] ? do_user_addr_fault+0x1027/0x1340
|
|
[ 472.096136] ? _printk+0x7a/0xa0
|
|
[ 472.096136] ? mutex_lock+0x68/0xc0
|
|
[ 472.096136] ? add_taint+0x42/0xd0
|
|
[ 472.096136] ? exc_page_fault+0x6a/0x1b0
|
|
[ 472.096136] ? asm_exc_page_fault+0x26/0x30
|
|
[ 472.096136] ? mutex_lock+0x75/0xc0
|
|
[ 472.096136] ? mutex_lock+0x88/0xc0
|
|
[ 472.096136] ? mutex_lock+0x75/0xc0
|
|
[ 472.096136] l2cap_chan_timeo
|
|
---truncated---(CVE-2024-27399)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
firewire: nosy: ensure user_length is taken into account when fetching packet contents
|
|
|
|
Ensure that packet_buffer_get respects the user_length provided. If
|
|
the length of the head packet exceeds the user_length, packet_buffer_get
|
|
will now return 0 to signify to the user that no data were read
|
|
and a larger buffer size is required. Helps prevent user space overflows.(CVE-2024-27401)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: mac80211: check/clear fast rx for non-4addr sta VLAN changes
|
|
|
|
When moving a station out of a VLAN and deleting the VLAN afterwards, the
|
|
fast_rx entry still holds a pointer to the VLAN's netdev, which can cause
|
|
use-after-free bugs. Fix this by immediately calling ieee80211_check_fast_rx
|
|
after the VLAN change.(CVE-2024-35789)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
md/dm-raid: don't call md_reap_sync_thread() directly
|
|
|
|
Currently md_reap_sync_thread() is called from raid_message() directly
|
|
without holding 'reconfig_mutex', this is definitely unsafe because
|
|
md_reap_sync_thread() can change many fields that is protected by
|
|
'reconfig_mutex'.
|
|
|
|
However, hold 'reconfig_mutex' here is still problematic because this
|
|
will cause deadlock, for example, commit 130443d60b1b ("md: refactor
|
|
idle/frozen_sync_thread() to fix deadlock").
|
|
|
|
Fix this problem by using stop_sync_thread() to unregister sync_thread,
|
|
like md/raid did.(CVE-2024-35808)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
usb: udc: remove warning when queue disabled ep
|
|
|
|
It is possible trigger below warning message from mass storage function,
|
|
|
|
WARNING: CPU: 6 PID: 3839 at drivers/usb/gadget/udc/core.c:294 usb_ep_queue+0x7c/0x104
|
|
pc : usb_ep_queue+0x7c/0x104
|
|
lr : fsg_main_thread+0x494/0x1b3c
|
|
|
|
Root cause is mass storage function try to queue request from main thread,
|
|
but other thread may already disable ep when function disable.
|
|
|
|
As there is no function failure in the driver, in order to avoid effort
|
|
to fix warning, change WARN_ON_ONCE() in usb_ep_queue() to pr_debug().(CVE-2024-35822)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
vt: fix unicode buffer corruption when deleting characters
|
|
|
|
This is the same issue that was fixed for the VGA text buffer in commit
|
|
39cdb68c64d8 ("vt: fix memory overlapping when deleting chars in the
|
|
buffer"). The cure is also the same i.e. replace memcpy() with memmove()
|
|
due to the overlaping buffers.(CVE-2024-35823)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
x86/mm/pat: fix VM_PAT handling in COW mappings
|
|
|
|
PAT handling won't do the right thing in COW mappings: the first PTE (or,
|
|
in fact, all PTEs) can be replaced during write faults to point at anon
|
|
folios. Reliably recovering the correct PFN and cachemode using
|
|
follow_phys() from PTEs will not work in COW mappings.
|
|
|
|
Using follow_phys(), we might just get the address+protection of the anon
|
|
folio (which is very wrong), or fail on swap/nonswap entries, failing
|
|
follow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and
|
|
track_pfn_copy(), not properly calling free_pfn_range().
|
|
|
|
In free_pfn_range(), we either wouldn't call memtype_free() or would call
|
|
it with the wrong range, possibly leaking memory.
|
|
|
|
To fix that, let's update follow_phys() to refuse returning anon folios,
|
|
and fallback to using the stored PFN inside vma->vm_pgoff for COW mappings
|
|
if we run into that.
|
|
|
|
We will now properly handle untrack_pfn() with COW mappings, where we
|
|
don't need the cachemode. We'll have to fail fork()->track_pfn_copy() if
|
|
the first page was replaced by an anon folio, though: we'd have to store
|
|
the cachemode in the VMA to make this work, likely growing the VMA size.
|
|
|
|
For now, lets keep it simple and let track_pfn_copy() just fail in that
|
|
case: it would have failed in the past with swap/nonswap entries already,
|
|
and it would have done the wrong thing with anon folios.
|
|
|
|
Simple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn():
|
|
|
|
<--- C reproducer --->
|
|
#include <stdio.h>
|
|
#include <sys/mman.h>
|
|
#include <unistd.h>
|
|
#include <liburing.h>
|
|
|
|
int main(void)
|
|
{
|
|
struct io_uring_params p = {};
|
|
int ring_fd;
|
|
size_t size;
|
|
char *map;
|
|
|
|
ring_fd = io_uring_setup(1, &p);
|
|
if (ring_fd < 0) {
|
|
perror("io_uring_setup");
|
|
return 1;
|
|
}
|
|
size = p.sq_off.array + p.sq_entries * sizeof(unsigned);
|
|
|
|
/* Map the submission queue ring MAP_PRIVATE */
|
|
map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE,
|
|
ring_fd, IORING_OFF_SQ_RING);
|
|
if (map == MAP_FAILED) {
|
|
perror("mmap");
|
|
return 1;
|
|
}
|
|
|
|
/* We have at least one page. Let's COW it. */
|
|
*map = 0;
|
|
pause();
|
|
return 0;
|
|
}
|
|
<--- C reproducer --->
|
|
|
|
On a system with 16 GiB RAM and swap configured:
|
|
# ./iouring &
|
|
# memhog 16G
|
|
# killall iouring
|
|
[ 301.552930] ------------[ cut here ]------------
|
|
[ 301.553285] WARNING: CPU: 7 PID: 1402 at arch/x86/mm/pat/memtype.c:1060 untrack_pfn+0xf4/0x100
|
|
[ 301.553989] Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_g
|
|
[ 301.558232] CPU: 7 PID: 1402 Comm: iouring Not tainted 6.7.5-100.fc38.x86_64 #1
|
|
[ 301.558772] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebu4
|
|
[ 301.559569] RIP: 0010:untrack_pfn+0xf4/0x100
|
|
[ 301.559893] Code: 75 c4 eb cf 48 8b 43 10 8b a8 e8 00 00 00 3b 6b 28 74 b8 48 8b 7b 30 e8 ea 1a f7 000
|
|
[ 301.561189] RSP: 0018:ffffba2c0377fab8 EFLAGS: 00010282
|
|
[ 301.561590] RAX: 00000000ffffffea RBX: ffff9208c8ce9cc0 RCX: 000000010455e047
|
|
[ 301.562105] RDX: 07fffffff0eb1e0a RSI: 0000000000000000 RDI: ffff9208c391d200
|
|
[ 301.562628] RBP: 0000000000000000 R08: ffffba2c0377fab8 R09: 0000000000000000
|
|
[ 301.563145] R10: ffff9208d2292d50 R11: 0000000000000002 R12: 00007fea890e0000
|
|
[ 301.563669] R13: 0000000000000000 R14: ffffba2c0377fc08 R15: 0000000000000000
|
|
[ 301.564186] FS: 0000000000000000(0000) GS:ffff920c2fbc0000(0000) knlGS:0000000000000000
|
|
[ 301.564773] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 301.565197] CR2: 00007fea88ee8a20 CR3: 00000001033a8000 CR4: 0000000000750ef0
|
|
[ 301.565725] PKRU: 55555554
|
|
[ 301.565944] Call Trace:
|
|
[ 301.566148] <TASK>
|
|
[ 301.566325] ? untrack_pfn+0xf4/0x100
|
|
[ 301.566618] ? __warn+0x81/0x130
|
|
[ 301.566876] ? untrack_pfn+0xf4/0x100
|
|
[ 3
|
|
---truncated---(CVE-2024-35877)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
selinux: avoid dereference of garbage after mount failure
|
|
|
|
In case kern_mount() fails and returns an error pointer return in the
|
|
error branch instead of continuing and dereferencing the error pointer.
|
|
|
|
While on it drop the never read static variable selinuxfs_mount.(CVE-2024-35904)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
block: prevent division by zero in blk_rq_stat_sum()
|
|
|
|
The expression dst->nr_samples + src->nr_samples may
|
|
have zero value on overflow. It is necessary to add
|
|
a check to avoid division by zero.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-35925)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/mlx5: Properly link new fs rules into the tree
|
|
|
|
Previously, add_rule_fg would only add newly created rules from the
|
|
handle into the tree when they had a refcount of 1. On the other hand,
|
|
create_flow_handle tries hard to find and reference already existing
|
|
identical rules instead of creating new ones.
|
|
|
|
These two behaviors can result in a situation where create_flow_handle
|
|
1) creates a new rule and references it, then
|
|
2) in a subsequent step during the same handle creation references it
|
|
again,
|
|
resulting in a rule with a refcount of 2 that is not linked into the
|
|
tree, will have a NULL parent and root and will result in a crash when
|
|
the flow group is deleted because del_sw_hw_rule, invoked on rule
|
|
deletion, assumes node->parent is != NULL.
|
|
|
|
This happened in the wild, due to another bug related to incorrect
|
|
handling of duplicate pkt_reformat ids, which lead to the code in
|
|
create_flow_handle incorrectly referencing a just-added rule in the same
|
|
flow handle, resulting in the problem described above. Full details are
|
|
at [1].
|
|
|
|
This patch changes add_rule_fg to add new rules without parents into
|
|
the tree, properly initializing them and avoiding the crash. This makes
|
|
it more consistent with how rules are added to an FTE in
|
|
create_flow_handle.(CVE-2024-35960)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Bluetooth: Fix memory leak in hci_req_sync_complete()
|
|
|
|
In 'hci_req_sync_complete()', always free the previous sync
|
|
request state before assigning reference to a new one.(CVE-2024-35978)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ACPI: CPPC: Use access_width over bit_width for system memory accesses
|
|
|
|
To align with ACPI 6.3+, since bit_width can be any 8-bit value, it
|
|
cannot be depended on to be always on a clean 8b boundary. This was
|
|
uncovered on the Cobalt 100 platform.
|
|
|
|
SError Interrupt on CPU26, code 0xbe000011 -- SError
|
|
CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1
|
|
Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION
|
|
pstate: 62400009 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--)
|
|
pc : cppc_get_perf_caps+0xec/0x410
|
|
lr : cppc_get_perf_caps+0xe8/0x410
|
|
sp : ffff8000155ab730
|
|
x29: ffff8000155ab730 x28: ffff0080139d0038 x27: ffff0080139d0078
|
|
x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff
|
|
x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000
|
|
x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff
|
|
x17: 0000000000000000 x16: ffffdc7e111bad04 x15: ffff00802b251008
|
|
x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006
|
|
x11: ffffdc7e128f4420 x10: 0000000000000000 x9 : ffffdc7e111badec
|
|
x8 : ffff00802b251980 x7 : 0000000000000000 x6 : ffff0080139d0028
|
|
x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff
|
|
x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000
|
|
Kernel panic - not syncing: Asynchronous SError Interrupt
|
|
CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted
|
|
5.15.2.1-13 #1
|
|
Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION
|
|
Call trace:
|
|
dump_backtrace+0x0/0x1e0
|
|
show_stack+0x24/0x30
|
|
dump_stack_lvl+0x8c/0xb8
|
|
dump_stack+0x18/0x34
|
|
panic+0x16c/0x384
|
|
add_taint+0x0/0xc0
|
|
arm64_serror_panic+0x7c/0x90
|
|
arm64_is_fatal_ras_serror+0x34/0xa4
|
|
do_serror+0x50/0x6c
|
|
el1h_64_error_handler+0x40/0x74
|
|
el1h_64_error+0x7c/0x80
|
|
cppc_get_perf_caps+0xec/0x410
|
|
cppc_cpufreq_cpu_init+0x74/0x400 [cppc_cpufreq]
|
|
cpufreq_online+0x2dc/0xa30
|
|
cpufreq_add_dev+0xc0/0xd4
|
|
subsys_interface_register+0x134/0x14c
|
|
cpufreq_register_driver+0x1b0/0x354
|
|
cppc_cpufreq_init+0x1a8/0x1000 [cppc_cpufreq]
|
|
do_one_initcall+0x50/0x250
|
|
do_init_module+0x60/0x27c
|
|
load_module+0x2300/0x2570
|
|
__do_sys_finit_module+0xa8/0x114
|
|
__arm64_sys_finit_module+0x2c/0x3c
|
|
invoke_syscall+0x78/0x100
|
|
el0_svc_common.constprop.0+0x180/0x1a0
|
|
do_el0_svc+0x84/0xa0
|
|
el0_svc+0x2c/0xc0
|
|
el0t_64_sync_handler+0xa4/0x12c
|
|
el0t_64_sync+0x1a4/0x1a8
|
|
|
|
Instead, use access_width to determine the size and use the offset and
|
|
width to shift and mask the bits to read/write out. Make sure to add a
|
|
check for system memory since pcc redefines the access_width to
|
|
subspace id.
|
|
|
|
If access_width is not set, then fall back to using bit_width.
|
|
|
|
[ rjw: Subject and changelog edits, comment adjustments ](CVE-2024-35995)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
i40e: Do not use WQ_MEM_RECLAIM flag for workqueue
|
|
|
|
Issue reported by customer during SRIOV testing, call trace:
|
|
When both i40e and the i40iw driver are loaded, a warning
|
|
in check_flush_dependency is being triggered. This seems
|
|
to be because of the i40e driver workqueue is allocated with
|
|
the WQ_MEM_RECLAIM flag, and the i40iw one is not.
|
|
|
|
Similar error was encountered on ice too and it was fixed by
|
|
removing the flag. Do the same for i40e too.
|
|
|
|
[Feb 9 09:08] ------------[ cut here ]------------
|
|
[ +0.000004] workqueue: WQ_MEM_RECLAIM i40e:i40e_service_task [i40e] is
|
|
flushing !WQ_MEM_RECLAIM infiniband:0x0
|
|
[ +0.000060] WARNING: CPU: 0 PID: 937 at kernel/workqueue.c:2966
|
|
check_flush_dependency+0x10b/0x120
|
|
[ +0.000007] Modules linked in: snd_seq_dummy snd_hrtimer snd_seq
|
|
snd_timer snd_seq_device snd soundcore nls_utf8 cifs cifs_arc4
|
|
nls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 dns_resolver netfs qrtr
|
|
rfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common irdma
|
|
intel_uncore_frequency intel_uncore_frequency_common ice ipmi_ssif
|
|
isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal
|
|
intel_powerclamp gnss coretemp ib_uverbs rapl intel_cstate ib_core
|
|
iTCO_wdt iTCO_vendor_support acpi_ipmi mei_me ipmi_si intel_uncore
|
|
ioatdma i2c_i801 joydev pcspkr mei ipmi_devintf lpc_ich
|
|
intel_pch_thermal i2c_smbus ipmi_msghandler acpi_power_meter acpi_pad
|
|
xfs libcrc32c ast sd_mod drm_shmem_helper t10_pi drm_kms_helper sg ixgbe
|
|
drm i40e ahci crct10dif_pclmul libahci crc32_pclmul igb crc32c_intel
|
|
libata ghash_clmulni_intel i2c_algo_bit mdio dca wmi dm_mirror
|
|
dm_region_hash dm_log dm_mod fuse
|
|
[ +0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: loaded Not
|
|
tainted 6.8.0-rc2-Feb-net_dev-Qiueue-00279-gbd43c5687e05 #1
|
|
[ +0.000003] Hardware name: Intel Corporation S2600BPB/S2600BPB, BIOS
|
|
SE5C620.86B.02.01.0013.121520200651 12/15/2020
|
|
[ +0.000001] Workqueue: i40e i40e_service_task [i40e]
|
|
[ +0.000024] RIP: 0010:check_flush_dependency+0x10b/0x120
|
|
[ +0.000003] Code: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 48
|
|
81 c6 b0 00 00 00 48 c7 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fd
|
|
ff <0f> 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff ff 90
|
|
[ +0.000002] RSP: 0018:ffffbd294976bcf8 EFLAGS: 00010282
|
|
[ +0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX:
|
|
0000000000000027
|
|
[ +0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI:
|
|
ffff94d47f620bc0
|
|
[ +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09:
|
|
00000000ffff7fff
|
|
[ +0.000001] R10: ffffbd294976bb98 R11: ffffffffa0be65e8 R12:
|
|
ffff94c5451ea180
|
|
[ +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15:
|
|
ffff94c5f1330ab0
|
|
[ +0.000001] FS: 0000000000000000(0000) GS:ffff94d47f600000(0000)
|
|
knlGS:0000000000000000
|
|
[ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ +0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4:
|
|
00000000007706f0
|
|
[ +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
|
|
0000000000000000
|
|
[ +0.000001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
|
|
0000000000000400
|
|
[ +0.000001] PKRU: 55555554
|
|
[ +0.000001] Call Trace:
|
|
[ +0.000001] <TASK>
|
|
[ +0.000002] ? __warn+0x80/0x130
|
|
[ +0.000003] ? check_flush_dependency+0x10b/0x120
|
|
[ +0.000002] ? report_bug+0x195/0x1a0
|
|
[ +0.000005] ? handle_bug+0x3c/0x70
|
|
[ +0.000003] ? exc_invalid_op+0x14/0x70
|
|
[ +0.000002] ? asm_exc_invalid_op+0x16/0x20
|
|
[ +0.000006] ? check_flush_dependency+0x10b/0x120
|
|
[ +0.000002] ? check_flush_dependency+0x10b/0x120
|
|
[ +0.000002] __flush_workqueue+0x126/0x3f0
|
|
[ +0.000015] ib_cache_cleanup_one+0x1c/0xe0 [ib_core]
|
|
[ +0.000056] __ib_unregister_device+0x6a/0xb0 [ib_core]
|
|
[ +0.000023] ib_unregister_device_and_put+0x34/0x50 [ib_core]
|
|
[ +0.000020] i40iw_close+0x4b/0x90 [irdma]
|
|
[ +0.000022] i40e_notify_client_of_netdev_close+0x54/0xc0 [i40e]
|
|
[ +0.000035] i40e_service_task+0x126/0x190 [i40e]
|
|
[ +0.000024] process_one_work+0x174/0x340
|
|
[ +0.000003] worker_th
|
|
---truncated---(CVE-2024-36004)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ppdev: Add an error check in register_device
|
|
|
|
In register_device, the return value of ida_simple_get is unchecked,
|
|
in witch ida_simple_get will use an invalid index value.
|
|
|
|
To address this issue, index should be checked after ida_simple_get. When
|
|
the index value is abnormal, a warning message should be printed, the port
|
|
should be dropped, and the value should be recorded.(CVE-2024-36015)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
pinctrl: core: delete incorrect free in pinctrl_enable()
|
|
|
|
The "pctldev" struct is allocated in devm_pinctrl_register_and_init().
|
|
It's a devm_ managed pointer that is freed by devm_pinctrl_dev_release(),
|
|
so freeing it in pinctrl_enable() will lead to a double free.
|
|
|
|
The devm_pinctrl_dev_release() function frees the pindescs and destroys
|
|
the mutex as well.(CVE-2024-36940)</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-1692</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47239</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47265</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47275</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47277</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47297</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47314</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47323</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47330</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47350</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47353</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47355</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47356</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47357</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47361</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47362</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47388</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47395</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47397</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47401</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47404</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47405</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47408</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47423</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47427</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47438</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47442</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47443</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47445</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47458</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47459</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47475</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47477</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47495</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47545</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47548</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47549</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47559</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2022-48708</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52669</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52693</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52699</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52703</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52750</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52752</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52759</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52789</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52796</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52799</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52802</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52804</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52805</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52809</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52819</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52831</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52832</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52845</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52878</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26934</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27020</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27399</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27401</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35789</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35808</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35822</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35823</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35877</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35904</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35925</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35960</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35978</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35995</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36004</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36015</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36940</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47239</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47265</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47275</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47277</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47297</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47314</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47323</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47330</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47350</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47353</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47355</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47356</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47357</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47361</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47362</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47388</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47395</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47397</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47401</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47404</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47405</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47408</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47423</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47427</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47438</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47442</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47443</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47445</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47458</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47459</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47475</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47477</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47495</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47545</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47548</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47549</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47559</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48708</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52669</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52693</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52699</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52703</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52750</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52752</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52759</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52789</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52796</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52799</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52802</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52804</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52805</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52809</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52819</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52831</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52832</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52845</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52878</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26934</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27020</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27399</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27401</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35789</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35808</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35822</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35823</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35877</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35904</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35925</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35960</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35978</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35995</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36004</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36015</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36940</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="python2-perf-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-4.19.90-2406.1.0.0279.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-debuginfo-4.19.90-2406.1.0.0279.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-debuginfo-4.19.90-2406.1.0.0279.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-4.19.90-2406.1.0.0279.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-devel-4.19.90-2406.1.0.0279.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-4.19.90-2406.1.0.0279.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-source-4.19.90-2406.1.0.0279.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-4.19.90-2406.1.0.0279.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debugsource-4.19.90-2406.1.0.0279.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-debuginfo-4.19.90-2406.1.0.0279.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-devel-4.19.90-2406.1.0.0279.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-debuginfo-4.19.90-2406.1.0.0279.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2406.1.0.0279.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-4.19.90-2406.1.0.0279.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debuginfo-4.19.90-2406.1.0.0279.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-debuginfo-4.19.90-2406.1.0.0279.oe2003sp4.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2406.1.0.0279.oe2003sp4.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="python2-perf-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-4.19.90-2406.1.0.0279.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-debuginfo-4.19.90-2406.1.0.0279.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2406.1.0.0279.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-debuginfo-4.19.90-2406.1.0.0279.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-debuginfo-4.19.90-2406.1.0.0279.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-debuginfo-4.19.90-2406.1.0.0279.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-4.19.90-2406.1.0.0279.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-devel-4.19.90-2406.1.0.0279.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-debuginfo-4.19.90-2406.1.0.0279.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-4.19.90-2406.1.0.0279.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-4.19.90-2406.1.0.0279.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-devel-4.19.90-2406.1.0.0279.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-4.19.90-2406.1.0.0279.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-source-4.19.90-2406.1.0.0279.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debugsource-4.19.90-2406.1.0.0279.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-4.19.90-2406.1.0.0279" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debuginfo-4.19.90-2406.1.0.0279.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:
|
|
|
|
net: usb: fix possible use-after-free in smsc75xx_bind
|
|
|
|
The commit 46a8b29c6306 ("net: usb: fix memory leak in smsc75xx_bind")
|
|
fails to clean up the work scheduled in smsc75xx_reset->
|
|
smsc75xx_set_multicast, which leads to use-after-free if the work is
|
|
scheduled to start after the deallocation. In addition, this patch
|
|
also removes a dangling pointer - dev->data[0].
|
|
|
|
This patch calls cancel_work_sync to cancel the scheduled work and set
|
|
the dangling pointer to NULL.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47239</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</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:
|
|
|
|
RDMA: Verify port when creating flow rule
|
|
|
|
Validate port value provided by the user and with that remove no longer
|
|
needed validation by the driver. The missing check in the mlx5_ib driver
|
|
could cause to the below oops.
|
|
|
|
Call trace:
|
|
_create_flow_rule+0x2d4/0xf28 [mlx5_ib]
|
|
mlx5_ib_create_flow+0x2d0/0x5b0 [mlx5_ib]
|
|
ib_uverbs_ex_create_flow+0x4cc/0x624 [ib_uverbs]
|
|
ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xd4/0x150 [ib_uverbs]
|
|
ib_uverbs_cmd_verbs.isra.7+0xb28/0xc50 [ib_uverbs]
|
|
ib_uverbs_ioctl+0x158/0x1d0 [ib_uverbs]
|
|
do_vfs_ioctl+0xd0/0xaf0
|
|
ksys_ioctl+0x84/0xb4
|
|
__arm64_sys_ioctl+0x28/0xc4
|
|
el0_svc_common.constprop.3+0xa4/0x254
|
|
el0_svc_handler+0x84/0xa0
|
|
el0_svc+0x10/0x26c
|
|
Code: b9401260 f9615681 51000400 8b001c20 (f9403c1a)</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47265</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</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:
|
|
|
|
bcache: avoid oversized read request in cache missing code path
|
|
|
|
In the cache missing code path of cached device, if a proper location
|
|
from the internal B+ tree is matched for a cache miss range, function
|
|
cached_dev_cache_miss() will be called in cache_lookup_fn() in the
|
|
following code block,
|
|
[code block 1]
|
|
526 unsigned int sectors = KEY_INODE(k) == s->iop.inode
|
|
527 ? min_t(uint64_t, INT_MAX,
|
|
528 KEY_START(k) - bio->bi_iter.bi_sector)
|
|
529 : INT_MAX;
|
|
530 int ret = s->d->cache_miss(b, s, bio, sectors);
|
|
|
|
Here s->d->cache_miss() is the call backfunction pointer initialized as
|
|
cached_dev_cache_miss(), the last parameter 'sectors' is an important
|
|
hint to calculate the size of read request to backing device of the
|
|
missing cache data.
|
|
|
|
Current calculation in above code block may generate oversized value of
|
|
'sectors', which consequently may trigger 2 different potential kernel
|
|
panics by BUG() or BUG_ON() as listed below,
|
|
|
|
1) BUG_ON() inside bch_btree_insert_key(),
|
|
[code block 2]
|
|
886 BUG_ON(b->ops->is_extents && !KEY_SIZE(k));
|
|
2) BUG() inside biovec_slab(),
|
|
[code block 3]
|
|
51 default:
|
|
52 BUG();
|
|
53 return NULL;
|
|
|
|
All the above panics are original from cached_dev_cache_miss() by the
|
|
oversized parameter 'sectors'.
|
|
|
|
Inside cached_dev_cache_miss(), parameter 'sectors' is used to calculate
|
|
the size of data read from backing device for the cache missing. This
|
|
size is stored in s->insert_bio_sectors by the following lines of code,
|
|
[code block 4]
|
|
909 s->insert_bio_sectors = min(sectors, bio_sectors(bio) + reada);
|
|
|
|
Then the actual key inserting to the internal B+ tree is generated and
|
|
stored in s->iop.replace_key by the following lines of code,
|
|
[code block 5]
|
|
911 s->iop.replace_key = KEY(s->iop.inode,
|
|
912 bio->bi_iter.bi_sector + s->insert_bio_sectors,
|
|
913 s->insert_bio_sectors);
|
|
The oversized parameter 'sectors' may trigger panic 1) by BUG_ON() from
|
|
the above code block.
|
|
|
|
And the bio sending to backing device for the missing data is allocated
|
|
with hint from s->insert_bio_sectors by the following lines of code,
|
|
[code block 6]
|
|
926 cache_bio = bio_alloc_bioset(GFP_NOWAIT,
|
|
927 DIV_ROUND_UP(s->insert_bio_sectors, PAGE_SECTORS),
|
|
928 &dc->disk.bio_split);
|
|
The oversized parameter 'sectors' may trigger panic 2) by BUG() from the
|
|
agove code block.
|
|
|
|
Now let me explain how the panics happen with the oversized 'sectors'.
|
|
In code block 5, replace_key is generated by macro KEY(). From the
|
|
definition of macro KEY(),
|
|
[code block 7]
|
|
71 #define KEY(inode, offset, size) \
|
|
72 ((struct bkey) { \
|
|
73 .high = (1ULL << 63) | ((__u64) (size) << 20) | (inode), \
|
|
74 .low = (offset) \
|
|
75 })
|
|
|
|
Here 'size' is 16bits width embedded in 64bits member 'high' of struct
|
|
bkey. But in code block 1, if "KEY_START(k) - bio->bi_iter.bi_sector" is
|
|
very probably to be larger than (1<<16) - 1, which makes the bkey size
|
|
calculation in code block 5 is overflowed. In one bug report the value
|
|
of parameter 'sectors' is 131072 (= 1 << 17), the overflowed 'sectors'
|
|
results the overflowed s->insert_bio_sectors in code block 4, then makes
|
|
size field of s->iop.replace_key to be 0 in code block 5. Then the 0-
|
|
sized s->iop.replace_key is inserted into the internal B+ tree as cache
|
|
missing check key (a special key to detect and avoid a racing between
|
|
normal write request and cache missing read request) as,
|
|
[code block 8]
|
|
915 ret = bch_btree_insert_check_key(b, &s->op, &s->iop.replace_key);
|
|
|
|
Then the 0-sized s->iop.replace_key as 3rd parameter triggers the bkey
|
|
size check BUG_ON() in code block 2, and causes the kernel panic 1).
|
|
|
|
Another ke
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47275</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</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:
|
|
|
|
kvm: avoid speculation-based attacks from out-of-range memslot accesses
|
|
|
|
KVM's mechanism for accessing guest memory translates a guest physical
|
|
address (gpa) to a host virtual address using the right-shifted gpa
|
|
(also known as gfn) and a struct kvm_memory_slot. The translation is
|
|
performed in __gfn_to_hva_memslot using the following formula:
|
|
|
|
hva = slot->userspace_addr + (gfn - slot->base_gfn) * PAGE_SIZE
|
|
|
|
It is expected that gfn falls within the boundaries of the guest's
|
|
physical memory. However, a guest can access invalid physical addresses
|
|
in such a way that the gfn is invalid.
|
|
|
|
__gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which first
|
|
retrieves a memslot through __gfn_to_memslot. While __gfn_to_memslot
|
|
does check that the gfn falls within the boundaries of the guest's
|
|
physical memory or not, a CPU can speculate the result of the check and
|
|
continue execution speculatively using an illegal gfn. The speculation
|
|
can result in calculating an out-of-bounds hva. If the resulting host
|
|
virtual address is used to load another guest physical address, this
|
|
is effectively a Spectre gadget consisting of two consecutive reads,
|
|
the second of which is data dependent on the first.
|
|
|
|
Right now it's not clear if there are any cases in which this is
|
|
exploitable. One interesting case was reported by the original author
|
|
of this patch, and involves visiting guest page tables on x86. Right
|
|
now these are not vulnerable because the hva read goes through get_user(),
|
|
which contains an LFENCE speculation barrier. However, there are
|
|
patches in progress for x86 uaccess.h to mask kernel addresses instead of
|
|
using LFENCE; once these land, a guest could use speculation to read
|
|
from the VMM's ring 3 address space. Other architectures such as ARM
|
|
already use the address masking method, and would be susceptible to
|
|
this same kind of data-dependent access gadgets. Therefore, this patch
|
|
proactively protects from these attacks by masking out-of-bounds gfns
|
|
in __gfn_to_hva_memslot, which blocks speculation of invalid hvas.
|
|
|
|
Sean Christopherson noted that this patch does not cover
|
|
kvm_read_guest_offset_cached. This however is limited to a few bytes
|
|
past the end of the cache, and therefore it is unlikely to be useful in
|
|
the context of building a chain of data dependent accesses.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47277</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</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:
|
|
|
|
net: fix uninit-value in caif_seqpkt_sendmsg
|
|
|
|
When nr_segs equal to zero in iovec_from_user, the object
|
|
msg->msg_iter.iov is uninit stack memory in caif_seqpkt_sendmsg
|
|
which is defined in ___sys_sendmsg. So we cann't just judge
|
|
msg->msg_iter.iov->base directlly. We can use nr_segs to judge
|
|
msg in caif_seqpkt_sendmsg whether has data buffers.
|
|
|
|
=====================================================
|
|
BUG: KMSAN: uninit-value in caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542
|
|
Call Trace:
|
|
__dump_stack lib/dump_stack.c:77 [inline]
|
|
dump_stack+0x1c9/0x220 lib/dump_stack.c:118
|
|
kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118
|
|
__msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215
|
|
caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542
|
|
sock_sendmsg_nosec net/socket.c:652 [inline]
|
|
sock_sendmsg net/socket.c:672 [inline]
|
|
____sys_sendmsg+0x12b6/0x1350 net/socket.c:2343
|
|
___sys_sendmsg net/socket.c:2397 [inline]
|
|
__sys_sendmmsg+0x808/0xc90 net/socket.c:2480
|
|
__compat_sys_sendmmsg net/compat.c:656 [inline]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47297</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>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</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:
|
|
|
|
memory: fsl_ifc: fix leak of private memory on probe failure
|
|
|
|
On probe error the driver should free the memory allocated for private
|
|
structure. Fix this by using resource-managed allocation.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47314</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</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:
|
|
|
|
watchdog: sc520_wdt: Fix possible use-after-free in wdt_turnoff()
|
|
|
|
This module's remove path calls del_timer(). However, that function
|
|
does not wait until the timer handler finishes. This means that the
|
|
timer handler may still be running after the driver's remove function
|
|
has finished, which would result in a use-after-free.
|
|
|
|
Fix by calling del_timer_sync(), which makes sure the timer handler
|
|
has finished, and unable to re-schedule itself.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47323</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</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:
|
|
|
|
tty: serial: 8250: serial_cs: Fix a memory leak in error handling path
|
|
|
|
In the probe function, if the final 'serial_config()' fails, 'info' is
|
|
leaking.
|
|
|
|
Add a resource handling path to free this memory.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47330</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</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:
|
|
|
|
powerpc/mm: Fix lockup on kernel exec fault
|
|
|
|
The powerpc kernel is not prepared to handle exec faults from kernel.
|
|
Especially, the function is_exec_fault() will return 'false' when an
|
|
exec fault is taken by kernel, because the check is based on reading
|
|
current->thread.regs->trap which contains the trap from user.
|
|
|
|
For instance, when provoking a LKDTM EXEC_USERSPACE test,
|
|
current->thread.regs->trap is set to SYSCALL trap (0xc00), and
|
|
the fault taken by the kernel is not seen as an exec fault by
|
|
set_access_flags_filter().
|
|
|
|
Commit d7df2443cd5f ("powerpc/mm: Fix spurious segfaults on radix
|
|
with autonuma") made it clear and handled it properly. But later on
|
|
commit d3ca587404b3 ("powerpc/mm: Fix reporting of kernel execute
|
|
faults") removed that handling, introducing test based on error_code.
|
|
And here is the problem, because on the 603 all upper bits of SRR1
|
|
get cleared when the TLB instruction miss handler bails out to ISI.
|
|
|
|
Until commit cbd7e6ca0210 ("powerpc/fault: Avoid heavy
|
|
search_exception_tables() verification"), an exec fault from kernel
|
|
at a userspace address was indirectly caught by the lack of entry for
|
|
that address in the exception tables. But after that commit the
|
|
kernel mainly relies on KUAP or on core mm handling to catch wrong
|
|
user accesses. Here the access is not wrong, so mm handles it.
|
|
It is a minor fault because PAGE_EXEC is not set,
|
|
set_access_flags_filter() should set PAGE_EXEC and voila.
|
|
But as is_exec_fault() returns false as explained in the beginning,
|
|
set_access_flags_filter() bails out without setting PAGE_EXEC flag,
|
|
which leads to a forever minor exec fault.
|
|
|
|
As the kernel is not prepared to handle such exec faults, the thing to
|
|
do is to fire in bad_kernel_fault() for any exec fault taken by the
|
|
kernel, as it was prior to commit d3ca587404b3.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47350</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</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:
|
|
|
|
udf: Fix NULL pointer dereference in udf_symlink function
|
|
|
|
In function udf_symlink, epos.bh is assigned with the value returned
|
|
by udf_tgetblk. The function udf_tgetblk is defined in udf/misc.c
|
|
and returns the value of sb_getblk function that could be NULL.
|
|
Then, epos.bh is used without any check, causing a possible
|
|
NULL pointer dereference when sb_getblk fails.
|
|
|
|
This fix adds a check to validate the value of epos.bh.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47353</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</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:
|
|
|
|
atm: nicstar: Fix possible use-after-free in nicstar_cleanup()
|
|
|
|
This module's remove path calls del_timer(). However, that function
|
|
does not wait until the timer handler finishes. This means that the
|
|
timer handler may still be running after the driver's remove function
|
|
has finished, which would result in a use-after-free.
|
|
|
|
Fix by calling del_timer_sync(), which makes sure the timer handler
|
|
has finished, and unable to re-schedule itself.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47355</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>0.0</BaseScore>
|
|
<Vector></Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</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:
|
|
|
|
mISDN: fix possible use-after-free in HFC_cleanup()
|
|
|
|
This module's remove path calls del_timer(). However, that function
|
|
does not wait until the timer handler finishes. This means that the
|
|
timer handler may still be running after the driver's remove function
|
|
has finished, which would result in a use-after-free.
|
|
|
|
Fix by calling del_timer_sync(), which makes sure the timer handler
|
|
has finished, and unable to re-schedule itself.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47356</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</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:
|
|
|
|
atm: iphase: fix possible use-after-free in ia_module_exit()
|
|
|
|
This module's remove path calls del_timer(). However, that function
|
|
does not wait until the timer handler finishes. This means that the
|
|
timer handler may still be running after the driver's remove function
|
|
has finished, which would result in a use-after-free.
|
|
|
|
Fix by calling del_timer_sync(), which makes sure the timer handler
|
|
has finished, and unable to re-schedule itself.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47357</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</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:
|
|
|
|
mcb: fix error handling in mcb_alloc_bus()
|
|
|
|
There are two bugs:
|
|
1) If ida_simple_get() fails then this code calls put_device(carrier)
|
|
but we haven't yet called get_device(carrier) and probably that
|
|
leads to a use after free.
|
|
2) After device_initialize() then we need to use put_device() to
|
|
release the bus. This will free the internal resources tied to the
|
|
device and call mcb_free_bus() which will free the rest.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47361</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</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:
|
|
|
|
drm/amd/pm: Update intermediate power state for SI
|
|
|
|
Update the current state as boot state during dpm initialization.
|
|
During the subsequent initialization, set_power_state gets called to
|
|
transition to the final power state. set_power_state refers to values
|
|
from the current state and without current state populated, it could
|
|
result in NULL pointer dereference.
|
|
|
|
For ex: on platforms where PCI speed change is supported through ACPI
|
|
ATCS method, the link speed of current state needs to be queried before
|
|
deciding on changing to final power state's link speed. The logic to query
|
|
ATCS-support was broken on certain platforms. The issue became visible
|
|
when broken ATCS-support logic got fixed with commit
|
|
f9b7f3703ff9 ("drm/amdgpu/acpi: make ATPX/ATCS structures global (v2)").
|
|
|
|
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1698</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47362</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</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:
|
|
|
|
mac80211: fix use-after-free in CCMP/GCMP RX
|
|
|
|
When PN checking is done in mac80211, for fragmentation we need
|
|
to copy the PN to the RX struct so we can later use it to do a
|
|
comparison, since commit bf30ca922a0c ("mac80211: check defrag
|
|
PN against current frame").
|
|
|
|
Unfortunately, in that commit I used the 'hdr' variable without
|
|
it being necessarily valid, so use-after-free could occur if it
|
|
was necessary to reallocate (parts of) the frame.
|
|
|
|
Fix this by reloading the variable after the code that results
|
|
in the reallocations, if any.
|
|
|
|
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=214401.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47388</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</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:
|
|
|
|
mac80211: limit injected vht mcs/nss in ieee80211_parse_tx_radiotap
|
|
|
|
Limit max values for vht mcs and nss in ieee80211_parse_tx_radiotap
|
|
routine in order to fix the following warning reported by syzbot:
|
|
|
|
WARNING: CPU: 0 PID: 10717 at include/net/mac80211.h:989 ieee80211_rate_set_vht include/net/mac80211.h:989 [inline]
|
|
WARNING: CPU: 0 PID: 10717 at include/net/mac80211.h:989 ieee80211_parse_tx_radiotap+0x101e/0x12d0 net/mac80211/tx.c:2244
|
|
Modules linked in:
|
|
CPU: 0 PID: 10717 Comm: syz-executor.5 Not tainted 5.14.0-syzkaller #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
|
|
RIP: 0010:ieee80211_rate_set_vht include/net/mac80211.h:989 [inline]
|
|
RIP: 0010:ieee80211_parse_tx_radiotap+0x101e/0x12d0 net/mac80211/tx.c:2244
|
|
RSP: 0018:ffffc9000186f3e8 EFLAGS: 00010216
|
|
RAX: 0000000000000618 RBX: ffff88804ef76500 RCX: ffffc900143a5000
|
|
RDX: 0000000000040000 RSI: ffffffff888f478e RDI: 0000000000000003
|
|
RBP: 00000000ffffffff R08: 0000000000000000 R09: 0000000000000100
|
|
R10: ffffffff888f46f9 R11: 0000000000000000 R12: 00000000fffffff8
|
|
R13: ffff88804ef7653c R14: 0000000000000001 R15: 0000000000000004
|
|
FS: 00007fbf5718f700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000001b2de23000 CR3: 000000006a671000 CR4: 00000000001506f0
|
|
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
|
|
Call Trace:
|
|
ieee80211_monitor_select_queue+0xa6/0x250 net/mac80211/iface.c:740
|
|
netdev_core_pick_tx+0x169/0x2e0 net/core/dev.c:4089
|
|
__dev_queue_xmit+0x6f9/0x3710 net/core/dev.c:4165
|
|
__bpf_tx_skb net/core/filter.c:2114 [inline]
|
|
__bpf_redirect_no_mac net/core/filter.c:2139 [inline]
|
|
__bpf_redirect+0x5ba/0xd20 net/core/filter.c:2162
|
|
____bpf_clone_redirect net/core/filter.c:2429 [inline]
|
|
bpf_clone_redirect+0x2ae/0x420 net/core/filter.c:2401
|
|
bpf_prog_eeb6f53a69e5c6a2+0x59/0x234
|
|
bpf_dispatcher_nop_func include/linux/bpf.h:717 [inline]
|
|
__bpf_prog_run include/linux/filter.h:624 [inline]
|
|
bpf_prog_run include/linux/filter.h:631 [inline]
|
|
bpf_test_run+0x381/0xa30 net/bpf/test_run.c:119
|
|
bpf_prog_test_run_skb+0xb84/0x1ee0 net/bpf/test_run.c:663
|
|
bpf_prog_test_run kernel/bpf/syscall.c:3307 [inline]
|
|
__sys_bpf+0x2137/0x5df0 kernel/bpf/syscall.c:4605
|
|
__do_sys_bpf kernel/bpf/syscall.c:4691 [inline]
|
|
__se_sys_bpf kernel/bpf/syscall.c:4689 [inline]
|
|
__x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:4689
|
|
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
|
|
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
|
|
entry_SYSCALL_64_after_hwframe+0x44/0xae
|
|
RIP: 0033:0x4665f9</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47395</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</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:
|
|
|
|
sctp: break out if skb_header_pointer returns NULL in sctp_rcv_ootb
|
|
|
|
We should always check if skb_header_pointer's return is NULL before
|
|
using it, otherwise it may cause null-ptr-deref, as syzbot reported:
|
|
|
|
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
|
|
RIP: 0010:sctp_rcv_ootb net/sctp/input.c:705 [inline]
|
|
RIP: 0010:sctp_rcv+0x1d84/0x3220 net/sctp/input.c:196
|
|
Call Trace:
|
|
<IRQ>
|
|
sctp6_rcv+0x38/0x60 net/sctp/ipv6.c:1109
|
|
ip6_protocol_deliver_rcu+0x2e9/0x1ca0 net/ipv6/ip6_input.c:422
|
|
ip6_input_finish+0x62/0x170 net/ipv6/ip6_input.c:463
|
|
NF_HOOK include/linux/netfilter.h:307 [inline]
|
|
NF_HOOK include/linux/netfilter.h:301 [inline]
|
|
ip6_input+0x9c/0xd0 net/ipv6/ip6_input.c:472
|
|
dst_input include/net/dst.h:460 [inline]
|
|
ip6_rcv_finish net/ipv6/ip6_input.c:76 [inline]
|
|
NF_HOOK include/linux/netfilter.h:307 [inline]
|
|
NF_HOOK include/linux/netfilter.h:301 [inline]
|
|
ipv6_rcv+0x28c/0x3c0 net/ipv6/ip6_input.c:297</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47397</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</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:
|
|
|
|
ipack: ipoctal: fix stack information leak
|
|
|
|
The tty driver name is used also after registering the driver and must
|
|
specifically not be allocated on the stack to avoid leaking information
|
|
to user space (or triggering an oops).
|
|
|
|
Drivers should not try to encode topology information in the tty device
|
|
name but this one snuck in through staging without anyone noticing and
|
|
another driver has since copied this malpractice.
|
|
|
|
Fixing the ABI is a separate issue, but this at least plugs the security
|
|
hole.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47401</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>0.0</BaseScore>
|
|
<Vector></Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</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:
|
|
|
|
HID: betop: fix slab-out-of-bounds Write in betop_probe
|
|
|
|
Syzbot reported slab-out-of-bounds Write bug in hid-betopff driver.
|
|
The problem is the driver assumes the device must have an input report but
|
|
some malicious devices violate this assumption.
|
|
|
|
So this patch checks hid_device's input is non empty before it's been used.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47404</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</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:
|
|
|
|
HID: usbhid: free raw_report buffers in usbhid_stop
|
|
|
|
Free the unsent raw_report buffers when the device is removed.
|
|
|
|
Fixes a memory leak reported by syzbot at:
|
|
https://syzkaller.appspot.com/bug?id=7b4fa7cb1a7c2d3342a2a8a6c53371c8c418ab47</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47405</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</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:
|
|
|
|
netfilter: conntrack: serialize hash resizes and cleanups
|
|
|
|
Syzbot was able to trigger the following warning [1]
|
|
|
|
No repro found by syzbot yet but I was able to trigger similar issue
|
|
by having 2 scripts running in parallel, changing conntrack hash sizes,
|
|
and:
|
|
|
|
for j in `seq 1 1000` ; do unshare -n /bin/true >/dev/null ; done
|
|
|
|
It would take more than 5 minutes for net_namespace structures
|
|
to be cleaned up.
|
|
|
|
This is because nf_ct_iterate_cleanup() has to restart everytime
|
|
a resize happened.
|
|
|
|
By adding a mutex, we can serialize hash resizes and cleanups
|
|
and also make get_next_corpse() faster by skipping over empty
|
|
buckets.
|
|
|
|
Even without resizes in the picture, this patch considerably
|
|
speeds up network namespace dismantles.
|
|
|
|
[1]
|
|
INFO: task syz-executor.0:8312 can't die for more than 144 seconds.
|
|
task:syz-executor.0 state:R running task stack:25672 pid: 8312 ppid: 6573 flags:0x00004006
|
|
Call Trace:
|
|
context_switch kernel/sched/core.c:4955 [inline]
|
|
__schedule+0x940/0x26f0 kernel/sched/core.c:6236
|
|
preempt_schedule_common+0x45/0xc0 kernel/sched/core.c:6408
|
|
preempt_schedule_thunk+0x16/0x18 arch/x86/entry/thunk_64.S:35
|
|
__local_bh_enable_ip+0x109/0x120 kernel/softirq.c:390
|
|
local_bh_enable include/linux/bottom_half.h:32 [inline]
|
|
get_next_corpse net/netfilter/nf_conntrack_core.c:2252 [inline]
|
|
nf_ct_iterate_cleanup+0x15a/0x450 net/netfilter/nf_conntrack_core.c:2275
|
|
nf_conntrack_cleanup_net_list+0x14c/0x4f0 net/netfilter/nf_conntrack_core.c:2469
|
|
ops_exit_list+0x10d/0x160 net/core/net_namespace.c:171
|
|
setup_net+0x639/0xa30 net/core/net_namespace.c:349
|
|
copy_net_ns+0x319/0x760 net/core/net_namespace.c:470
|
|
create_new_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110
|
|
unshare_nsproxy_namespaces+0xc1/0x1f0 kernel/nsproxy.c:226
|
|
ksys_unshare+0x445/0x920 kernel/fork.c:3128
|
|
__do_sys_unshare kernel/fork.c:3202 [inline]
|
|
__se_sys_unshare kernel/fork.c:3200 [inline]
|
|
__x64_sys_unshare+0x2d/0x40 kernel/fork.c:3200
|
|
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
|
|
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
|
|
entry_SYSCALL_64_after_hwframe+0x44/0xae
|
|
RIP: 0033:0x7f63da68e739
|
|
RSP: 002b:00007f63d7c05188 EFLAGS: 00000246 ORIG_RAX: 0000000000000110
|
|
RAX: ffffffffffffffda RBX: 00007f63da792f80 RCX: 00007f63da68e739
|
|
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000040000000
|
|
RBP: 00007f63da6e8cc4 R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f63da792f80
|
|
R13: 00007fff50b75d3f R14: 00007f63d7c05300 R15: 0000000000022000
|
|
|
|
Showing all locks held in the system:
|
|
1 lock held by khungtaskd/27:
|
|
#0: ffffffff8b980020 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x53/0x260 kernel/locking/lockdep.c:6446
|
|
2 locks held by kworker/u4:2/153:
|
|
#0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
|
|
#0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: arch_atomic_long_set include/linux/atomic/atomic-long.h:41 [inline]
|
|
#0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: atomic_long_set include/linux/atomic/atomic-instrumented.h:1198 [inline]
|
|
#0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: set_work_data kernel/workqueue.c:634 [inline]
|
|
#0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: set_work_pool_and_clear_pending kernel/workqueue.c:661 [inline]
|
|
#0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x896/0x1690 kernel/workqueue.c:2268
|
|
#1: ffffc9000140fdb0 ((kfence_timer).work){+.+.}-{0:0}, at: process_one_work+0x8ca/0x1690 kernel/workqueue.c:2272
|
|
1 lock held by systemd-udevd/2970:
|
|
1 lock held by in:imklog/6258:
|
|
#0: ffff88807f970ff0 (&f->f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0xe9/0x100 fs/file.c:990
|
|
3 locks held by kworker/1:6/8158:
|
|
1 lock held by syz-executor.0/8312:
|
|
2 locks held by kworker/u4:13/9320:
|
|
1 lock held by
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47408</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</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:
|
|
|
|
drm/nouveau/debugfs: fix file release memory leak
|
|
|
|
When using single_open() for opening, single_release() should be
|
|
called, otherwise the 'op' allocated in single_open() will be leaked.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47423</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>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</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">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: iscsi: Fix iscsi_task use after free
|
|
|
|
Commit d39df158518c ("scsi: iscsi: Have abort handler get ref to conn")
|
|
added iscsi_get_conn()/iscsi_put_conn() calls during abort handling but
|
|
then also changed the handling of the case where we detect an already
|
|
completed task where we now end up doing a goto to the common put/cleanup
|
|
code. This results in a iscsi_task use after free, because the common
|
|
cleanup code will do a put on the iscsi_task.
|
|
|
|
This reverts the goto and moves the iscsi_get_conn() to after we've checked
|
|
if the iscsi_task is valid.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47427</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</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/mlx5e: Fix memory leak in mlx5_core_destroy_cq() error path
|
|
|
|
Prior to this patch in case mlx5_core_destroy_cq() failed it returns
|
|
without completing all destroy operations and that leads to memory leak.
|
|
Instead, complete the destroy flow before return error.
|
|
|
|
Also move mlx5_debug_cq_remove() to the beginning of mlx5_core_destroy_cq()
|
|
to be symmetrical with mlx5_core_create_cq().
|
|
|
|
kmemleak complains on:
|
|
|
|
unreferenced object 0xc000000038625100 (size 64):
|
|
comm "ethtool", pid 28301, jiffies 4298062946 (age 785.380s)
|
|
hex dump (first 32 bytes):
|
|
60 01 48 94 00 00 00 c0 b8 05 34 c3 00 00 00 c0 `.H.......4.....
|
|
02 00 00 00 00 00 00 00 00 db 7d c1 00 00 00 c0 ..........}.....
|
|
backtrace:
|
|
[<000000009e8643cb>] add_res_tree+0xd0/0x270 [mlx5_core]
|
|
[<00000000e7cb8e6c>] mlx5_debug_cq_add+0x5c/0xc0 [mlx5_core]
|
|
[<000000002a12918f>] mlx5_core_create_cq+0x1d0/0x2d0 [mlx5_core]
|
|
[<00000000cef0a696>] mlx5e_create_cq+0x210/0x3f0 [mlx5_core]
|
|
[<000000009c642c26>] mlx5e_open_cq+0xb4/0x130 [mlx5_core]
|
|
[<0000000058dfa578>] mlx5e_ptp_open+0x7f4/0xe10 [mlx5_core]
|
|
[<0000000081839561>] mlx5e_open_channels+0x9cc/0x13e0 [mlx5_core]
|
|
[<0000000009cf05d4>] mlx5e_switch_priv_channels+0xa4/0x230
|
|
[mlx5_core]
|
|
[<0000000042bbedd8>] mlx5e_safe_switch_params+0x14c/0x300
|
|
[mlx5_core]
|
|
[<0000000004bc9db8>] set_pflag_tx_port_ts+0x9c/0x160 [mlx5_core]
|
|
[<00000000a0553443>] mlx5e_set_priv_flags+0xd0/0x1b0 [mlx5_core]
|
|
[<00000000a8f3d84b>] ethnl_set_privflags+0x234/0x2d0
|
|
[<00000000fd27f27c>] genl_family_rcv_msg_doit+0x108/0x1d0
|
|
[<00000000f495e2bb>] genl_family_rcv_msg+0xe4/0x1f0
|
|
[<00000000646c5c2c>] genl_rcv_msg+0x78/0x120
|
|
[<00000000d53e384e>] netlink_rcv_skb+0x74/0x1a0</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47438</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</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:
|
|
|
|
NFC: digital: fix possible memory leak in digital_in_send_sdd_req()
|
|
|
|
'skb' is allocated in digital_in_send_sdd_req(), but not free when
|
|
digital_in_send_cmd() failed, which will cause memory leak. Fix it
|
|
by freeing 'skb' if digital_in_send_cmd() return failed.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47442</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</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:
|
|
|
|
NFC: digital: fix possible memory leak in digital_tg_listen_mdaa()
|
|
|
|
'params' is allocated in digital_tg_listen_mdaa(), but not free when
|
|
digital_send_cmd() failed, which will cause memory leak. Fix it by
|
|
freeing 'params' if digital_send_cmd() return failed.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47443</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</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:
|
|
|
|
drm/msm: Fix null pointer dereference on pointer edp
|
|
|
|
The initialization of pointer dev dereferences pointer edp before
|
|
edp is null checked, so there is a potential null pointer deference
|
|
issue. Fix this by only dereferencing edp after edp has been null
|
|
checked.
|
|
|
|
Addresses-Coverity: ("Dereference before null check")</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47445</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>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</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:
|
|
|
|
ocfs2: mount fails with buffer overflow in strlen
|
|
|
|
Starting with kernel 5.11 built with CONFIG_FORTIFY_SOURCE mouting an
|
|
ocfs2 filesystem with either o2cb or pcmk cluster stack fails with the
|
|
trace below. Problem seems to be that strings for cluster stack and
|
|
cluster name are not guaranteed to be null terminated in the disk
|
|
representation, while strlcpy assumes that the source string is always
|
|
null terminated. This causes a read outside of the source string
|
|
triggering the buffer overflow detection.
|
|
|
|
detected buffer overflow in strlen
|
|
------------[ cut here ]------------
|
|
kernel BUG at lib/string.c:1149!
|
|
invalid opcode: 0000 [#1] SMP PTI
|
|
CPU: 1 PID: 910 Comm: mount.ocfs2 Not tainted 5.14.0-1-amd64 #1
|
|
Debian 5.14.6-2
|
|
RIP: 0010:fortify_panic+0xf/0x11
|
|
...
|
|
Call Trace:
|
|
ocfs2_initialize_super.isra.0.cold+0xc/0x18 [ocfs2]
|
|
ocfs2_fill_super+0x359/0x19b0 [ocfs2]
|
|
mount_bdev+0x185/0x1b0
|
|
legacy_get_tree+0x27/0x40
|
|
vfs_get_tree+0x25/0xb0
|
|
path_mount+0x454/0xa20
|
|
__x64_sys_mount+0x103/0x140
|
|
do_syscall_64+0x3b/0xc0
|
|
entry_SYSCALL_64_after_hwframe+0x44/0xae</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47458</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>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="30" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="30" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
can: j1939: j1939_netdev_start(): fix UAF for rx_kref of j1939_priv
|
|
|
|
It will trigger UAF for rx_kref of j1939_priv as following.
|
|
|
|
cpu0 cpu1
|
|
j1939_sk_bind(socket0, ndev0, ...)
|
|
j1939_netdev_start
|
|
j1939_sk_bind(socket1, ndev0, ...)
|
|
j1939_netdev_start
|
|
j1939_priv_set
|
|
j1939_priv_get_by_ndev_locked
|
|
j1939_jsk_add
|
|
.....
|
|
j1939_netdev_stop
|
|
kref_put_lock(&priv->rx_kref, ...)
|
|
kref_get(&priv->rx_kref, ...)
|
|
REFCOUNT_WARN("addition on 0;...")
|
|
|
|
====================================================
|
|
refcount_t: addition on 0; use-after-free.
|
|
WARNING: CPU: 1 PID: 20874 at lib/refcount.c:25 refcount_warn_saturate+0x169/0x1e0
|
|
RIP: 0010:refcount_warn_saturate+0x169/0x1e0
|
|
Call Trace:
|
|
j1939_netdev_start+0x68b/0x920
|
|
j1939_sk_bind+0x426/0xeb0
|
|
? security_socket_bind+0x83/0xb0
|
|
|
|
The rx_kref's kref_get() and kref_put() should use j1939_netdev_lock to
|
|
protect.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47459</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>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="31" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="31" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
comedi: vmk80xx: fix transfer-buffer overflows
|
|
|
|
The driver uses endpoint-sized USB transfer buffers but up until
|
|
recently had no sanity checks on the sizes.
|
|
|
|
Commit e1f13c879a7c ("staging: comedi: check validity of wMaxPacketSize
|
|
of usb endpoints found") inadvertently fixed NULL-pointer dereferences
|
|
when accessing the transfer buffers in case a malicious device has a
|
|
zero wMaxPacketSize.
|
|
|
|
Make sure to allocate buffers large enough to handle also the other
|
|
accesses that are done without a size check (e.g. byte 18 in
|
|
vmk80xx_cnt_insn_read() for the VMK8061_MODEL) to avoid writing beyond
|
|
the buffers, for example, when doing descriptor fuzzing.
|
|
|
|
The original driver was for a low-speed device with 8-byte buffers.
|
|
Support was later added for a device that uses bulk transfers and is
|
|
presumably a full-speed device with a maximum 64-byte wMaxPacketSize.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47475</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="32" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="32" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
comedi: dt9812: fix DMA buffers on stack
|
|
|
|
USB transfer buffers are typically mapped for DMA and must not be
|
|
allocated on the stack or transfers will fail.
|
|
|
|
Allocate proper transfer buffers in the various command helpers and
|
|
return an error on short transfers instead of acting on random stack
|
|
data.
|
|
|
|
Note that this also fixes a stack info leak on systems where DMA is not
|
|
used as 32 bytes are always sent to the device regardless of how short
|
|
the command is.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47477</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>0.0</BaseScore>
|
|
<Vector></Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="33" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="33" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
usbnet: sanity check for maxpacket
|
|
|
|
maxpacket of 0 makes no sense and oopses as we need to divide
|
|
by it. Give up.
|
|
|
|
V2: fixed typo in log and stylistic issues</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47495</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="34" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="34" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
perf hist: Fix memory leak of a perf_hpp_fmt
|
|
|
|
perf_hpp__column_unregister() removes an entry from a list but doesn't
|
|
free the memory causing a memory leak spotted by leak sanitizer.
|
|
|
|
Add the free while at the same time reducing the scope of the function
|
|
to static.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47545</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>0.0</BaseScore>
|
|
<Vector></Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="35" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="35" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port()
|
|
|
|
The if statement:
|
|
if (port >= DSAF_GE_NUM)
|
|
return;
|
|
|
|
limits the value of port less than DSAF_GE_NUM (i.e., 8).
|
|
However, if the value of port is 6 or 7, an array overflow could occur:
|
|
port_rst_off = dsaf_dev->mac_cb[port]->port_rst_off;
|
|
|
|
because the length of dsaf_dev->mac_cb is DSAF_MAX_PORT_NUM (i.e., 6).
|
|
|
|
To fix this possible array overflow, we first check port and if it is
|
|
greater than or equal to DSAF_MAX_PORT_NUM, the function returns.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47548</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="36" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="36" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
sata_fsl: fix UAF in sata_fsl_port_stop when rmmod sata_fsl
|
|
|
|
When the `rmmod sata_fsl.ko` command is executed in the PPC64 GNU/Linux,
|
|
a bug is reported:
|
|
==================================================================
|
|
BUG: Unable to handle kernel data access on read at 0x80000800805b502c
|
|
Oops: Kernel access of bad area, sig: 11 [#1]
|
|
NIP [c0000000000388a4] .ioread32+0x4/0x20
|
|
LR [80000000000c6034] .sata_fsl_port_stop+0x44/0xe0 [sata_fsl]
|
|
Call Trace:
|
|
.free_irq+0x1c/0x4e0 (unreliable)
|
|
.ata_host_stop+0x74/0xd0 [libata]
|
|
.release_nodes+0x330/0x3f0
|
|
.device_release_driver_internal+0x178/0x2c0
|
|
.driver_detach+0x64/0xd0
|
|
.bus_remove_driver+0x70/0xf0
|
|
.driver_unregister+0x38/0x80
|
|
.platform_driver_unregister+0x14/0x30
|
|
.fsl_sata_driver_exit+0x18/0xa20 [sata_fsl]
|
|
.__se_sys_delete_module+0x1ec/0x2d0
|
|
.system_call_exception+0xfc/0x1f0
|
|
system_call_common+0xf8/0x200
|
|
==================================================================
|
|
|
|
The triggering of the BUG is shown in the following stack:
|
|
|
|
driver_detach
|
|
device_release_driver_internal
|
|
__device_release_driver
|
|
drv->remove(dev) --> platform_drv_remove/platform_remove
|
|
drv->remove(dev) --> sata_fsl_remove
|
|
iounmap(host_priv->hcr_base); <---- unmap
|
|
kfree(host_priv); <---- free
|
|
devres_release_all
|
|
release_nodes
|
|
dr->node.release(dev, dr->data) --> ata_host_stop
|
|
ap->ops->port_stop(ap) --> sata_fsl_port_stop
|
|
ioread32(hcr_base + HCONTROL) <---- UAF
|
|
host->ops->host_stop(host)
|
|
|
|
The iounmap(host_priv->hcr_base) and kfree(host_priv) functions should
|
|
not be executed in drv->remove. These functions should be executed in
|
|
host_stop after port_stop. Therefore, we move these functions to the
|
|
new function sata_fsl_host_stop and bind the new function to host_stop.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47549</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>0.0</BaseScore>
|
|
<Vector></Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="37" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="37" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/smc: Fix NULL pointer dereferencing in smc_vlan_by_tcpsk()
|
|
|
|
Coverity reports a possible NULL dereferencing problem:
|
|
|
|
in smc_vlan_by_tcpsk():
|
|
6. returned_null: netdev_lower_get_next returns NULL (checked 29 out of 30 times).
|
|
7. var_assigned: Assigning: ndev = NULL return value from netdev_lower_get_next.
|
|
1623 ndev = (struct net_device *)netdev_lower_get_next(ndev, &lower);
|
|
CID 1468509 (#1 of 1): Dereference null return value (NULL_RETURNS)
|
|
8. dereference: Dereferencing a pointer that might be NULL ndev when calling is_vlan_dev.
|
|
1624 if (is_vlan_dev(ndev)) {
|
|
|
|
Remove the manual implementation and use netdev_walk_all_lower_dev() to
|
|
iterate over the lower devices. While on it remove an obsolete function
|
|
parameter comment.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47559</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="38" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="38" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
pinctrl: single: fix potential NULL dereference
|
|
|
|
Added checking of pointer "function" in pcs_set_mux().
|
|
pinmux_generic_get_function() can return NULL and the pointer
|
|
"function" was dereferenced without checking against NULL.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2022-48708</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>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="39" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="39" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
crypto: s390/aes - Fix buffer overread in CTR mode
|
|
|
|
When processing the last block, the s390 ctr code will always read
|
|
a whole block, even if there isn't a whole block of data left. Fix
|
|
this by using the actual length left and copy it into a buffer first
|
|
for processing.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52669</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="40" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="40" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ACPI: video: check for error while searching for backlight device parent
|
|
|
|
If acpi_get_parent() called in acpi_video_dev_register_backlight()
|
|
fails, for example, because acpi_ut_acquire_mutex() fails inside
|
|
acpi_get_parent), this can lead to incorrect (uninitialized)
|
|
acpi_parent handle being passed to acpi_get_pci_dev() for detecting
|
|
the parent pci device.
|
|
|
|
Check acpi_get_parent() result and set parent device only in case of success.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52693</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="41" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="41" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
sysv: don't call sb_bread() with pointers_lock held
|
|
|
|
syzbot is reporting sleep in atomic context in SysV filesystem [1], for
|
|
sb_bread() is called with rw_spinlock held.
|
|
|
|
A "write_lock(&pointers_lock) => read_lock(&pointers_lock) deadlock" bug
|
|
and a "sb_bread() with write_lock(&pointers_lock)" bug were introduced by
|
|
"Replace BKL for chain locking with sysvfs-private rwlock" in Linux 2.5.12.
|
|
|
|
Then, "[PATCH] err1-40: sysvfs locking fix" in Linux 2.6.8 fixed the
|
|
former bug by moving pointers_lock lock to the callers, but instead
|
|
introduced a "sb_bread() with read_lock(&pointers_lock)" bug (which made
|
|
this problem easier to hit).
|
|
|
|
Al Viro suggested that why not to do like get_branch()/get_block()/
|
|
find_shared() in Minix filesystem does. And doing like that is almost a
|
|
revert of "[PATCH] err1-40: sysvfs locking fix" except that get_branch()
|
|
from with find_shared() is called without write_lock(&pointers_lock).</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52699</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="42" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="42" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/usb: kalmia: Don't pass act_len in usb_bulk_msg error path
|
|
|
|
syzbot reported that act_len in kalmia_send_init_packet() is
|
|
uninitialized when passing it to the first usb_bulk_msg error path. Jiri
|
|
Pirko noted that it's pointless to pass it in the error path, and that
|
|
the value that would be printed in the second error path would be the
|
|
value of act_len from the first call to usb_bulk_msg.[1]
|
|
|
|
With this in mind, let's just not pass act_len to the usb_bulk_msg error
|
|
paths.
|
|
|
|
1: https://lore.kernel.org/lkml/Y9pY61y1nwTuzMOa@nanopsycho/</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52703</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="43" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="43" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
arm64: Restrict CPU_BIG_ENDIAN to GNU as or LLVM IAS 15.x or newer
|
|
|
|
Prior to LLVM 15.0.0, LLVM's integrated assembler would incorrectly
|
|
byte-swap NOP when compiling for big-endian, and the resulting series of
|
|
bytes happened to match the encoding of FNMADD S21, S30, S0, S0.
|
|
|
|
This went unnoticed until commit:
|
|
|
|
34f66c4c4d5518c1 ("arm64: Use a positive cpucap for FP/SIMD")
|
|
|
|
Prior to that commit, the kernel would always enable the use of FPSIMD
|
|
early in boot when __cpu_setup() initialized CPACR_EL1, and so usage of
|
|
FNMADD within the kernel was not detected, but could result in the
|
|
corruption of user or kernel FPSIMD state.
|
|
|
|
After that commit, the instructions happen to trap during boot prior to
|
|
FPSIMD being detected and enabled, e.g.
|
|
|
|
| Unhandled 64-bit el1h sync exception on CPU0, ESR 0x000000001fe00000 -- ASIMD
|
|
| CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1
|
|
| Hardware name: linux,dummy-virt (DT)
|
|
| pstate: 400000c9 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
|
| pc : __pi_strcmp+0x1c/0x150
|
|
| lr : populate_properties+0xe4/0x254
|
|
| sp : ffffd014173d3ad0
|
|
| x29: ffffd014173d3af0 x28: fffffbfffddffcb8 x27: 0000000000000000
|
|
| x26: 0000000000000058 x25: fffffbfffddfe054 x24: 0000000000000008
|
|
| x23: fffffbfffddfe000 x22: fffffbfffddfe000 x21: fffffbfffddfe044
|
|
| x20: ffffd014173d3b70 x19: 0000000000000001 x18: 0000000000000005
|
|
| x17: 0000000000000010 x16: 0000000000000000 x15: 00000000413e7000
|
|
| x14: 0000000000000000 x13: 0000000000001bcc x12: 0000000000000000
|
|
| x11: 00000000d00dfeed x10: ffffd414193f2cd0 x9 : 0000000000000000
|
|
| x8 : 0101010101010101 x7 : ffffffffffffffc0 x6 : 0000000000000000
|
|
| x5 : 0000000000000000 x4 : 0101010101010101 x3 : 000000000000002a
|
|
| x2 : 0000000000000001 x1 : ffffd014171f2988 x0 : fffffbfffddffcb8
|
|
| Kernel panic - not syncing: Unhandled exception
|
|
| CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1
|
|
| Hardware name: linux,dummy-virt (DT)
|
|
| Call trace:
|
|
| dump_backtrace+0xec/0x108
|
|
| show_stack+0x18/0x2c
|
|
| dump_stack_lvl+0x50/0x68
|
|
| dump_stack+0x18/0x24
|
|
| panic+0x13c/0x340
|
|
| el1t_64_irq_handler+0x0/0x1c
|
|
| el1_abort+0x0/0x5c
|
|
| el1h_64_sync+0x64/0x68
|
|
| __pi_strcmp+0x1c/0x150
|
|
| unflatten_dt_nodes+0x1e8/0x2d8
|
|
| __unflatten_device_tree+0x5c/0x15c
|
|
| unflatten_device_tree+0x38/0x50
|
|
| setup_arch+0x164/0x1e0
|
|
| start_kernel+0x64/0x38c
|
|
| __primary_switched+0xbc/0xc4
|
|
|
|
Restrict CONFIG_CPU_BIG_ENDIAN to a known good assembler, which is
|
|
either GNU as or LLVM's IAS 15.0.0 and newer, which contains the linked
|
|
commit.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52750</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>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="44" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="44" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:smb: client: fix use-after-free bug in cifs_debug_data_proc_show()Skip SMB sessions that are being teared down(e.g. @ses->ses_status == SES_EXITING) in cifs_debug_data_proc_show()to avoid use-after-free in @ses.This fixes the following GPF when reading from /proc/fs/cifs/DebugDatawhile mounting and umounting [ 816.251274] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6d81: 0000 [#1] PREEMPT SMP NOPTI ... [ 816.260138] Call Trace: [ 816.260329] <TASK> [ 816.260499] ? die_addr+0x36/0x90 [ 816.260762] ? exc_general_protection+0x1b3/0x410 [ 816.261126] ? asm_exc_general_protection+0x26/0x30 [ 816.261502] ? cifs_debug_tcon+0xbd/0x240 [cifs] [ 816.261878] ? cifs_debug_tcon+0xab/0x240 [cifs] [ 816.262249] cifs_debug_data_proc_show+0x516/0xdb0 [cifs] [ 816.262689] ? seq_read_iter+0x379/0x470 [ 816.262995] seq_read_iter+0x118/0x470 [ 816.263291] proc_reg_read_iter+0x53/0x90 [ 816.263596] ? srso_alias_return_thunk+0x5/0x7f [ 816.263945] vfs_read+0x201/0x350 [ 816.264211] ksys_read+0x75/0x100 [ 816.264472] do_syscall_64+0x3f/0x90 [ 816.264750] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 816.265135] RIP: 0033:0x7fd5e669d381</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52752</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-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="45" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="45" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
gfs2: ignore negated quota changes
|
|
|
|
When lots of quota changes are made, there may be cases in which an
|
|
inode's quota information is increased and then decreased, such as when
|
|
blocks are added to a file, then deleted from it. If the timing is
|
|
right, function do_qc can add pending quota changes to a transaction,
|
|
then later, another call to do_qc can negate those changes, resulting
|
|
in a net gain of 0. The quota_change information is recorded in the qc
|
|
buffer (and qd element of the inode as well). The buffer is added to the
|
|
transaction by the first call to do_qc, but a subsequent call changes
|
|
the value from non-zero back to zero. At that point it's too late to
|
|
remove the buffer_head from the transaction. Later, when the quota sync
|
|
code is called, the zero-change qd element is discovered and flagged as
|
|
an assert warning. If the fs is mounted with errors=panic, the kernel
|
|
will panic.
|
|
|
|
This is usually seen when files are truncated and the quota changes are
|
|
negated by punch_hole/truncate which uses gfs2_quota_hold and
|
|
gfs2_quota_unhold rather than block allocations that use gfs2_quota_lock
|
|
and gfs2_quota_unlock which automatically do quota sync.
|
|
|
|
This patch solves the problem by adding a check to qd_check_sync such
|
|
that net-zero quota changes already added to the transaction are no
|
|
longer deemed necessary to be synced, and skipped.
|
|
|
|
In this case references are taken for the qd and the slot from do_qc
|
|
so those need to be put. The normal sequence of events for a normal
|
|
non-zero quota change is as follows:
|
|
|
|
gfs2_quota_change
|
|
do_qc
|
|
qd_hold
|
|
slot_hold
|
|
|
|
Later, when the changes are to be synced:
|
|
|
|
gfs2_quota_sync
|
|
qd_fish
|
|
qd_check_sync
|
|
gets qd ref via lockref_get_not_dead
|
|
do_sync
|
|
do_qc(QC_SYNC)
|
|
qd_put
|
|
lockref_put_or_lock
|
|
qd_unlock
|
|
qd_put
|
|
lockref_put_or_lock
|
|
|
|
In the net-zero change case, we add a check to qd_check_sync so it puts
|
|
the qd and slot references acquired in gfs2_quota_change and skip the
|
|
unneeded sync.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52759</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="46" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="46" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tty: vcc: Add check for kstrdup() in vcc_probe()
|
|
|
|
Add check for the return value of kstrdup() and return the error, if it
|
|
fails in order to avoid NULL pointer dereference.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52789</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>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="47" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="47" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ipvlan: add ipvlan_route_v6_outbound() helper
|
|
|
|
Inspired by syzbot reports using a stack of multiple ipvlan devices.
|
|
|
|
Reduce stack size needed in ipvlan_process_v6_outbound() by moving
|
|
the flowi6 struct used for the route lookup in an non inlined
|
|
helper. ipvlan_route_v6_outbound() needs 120 bytes on the stack,
|
|
immediately reclaimed.
|
|
|
|
Also make sure ipvlan_process_v4_outbound() is not inlined.
|
|
|
|
We might also have to lower MAX_NEST_DEV, because only syzbot uses
|
|
setups with more than four stacked devices.
|
|
|
|
BUG: TASK stack guard page was hit at ffffc9000e803ff8 (stack is ffffc9000e804000..ffffc9000e808000)
|
|
stack guard page: 0000 [#1] SMP KASAN
|
|
CPU: 0 PID: 13442 Comm: syz-executor.4 Not tainted 6.1.52-syzkaller #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023
|
|
RIP: 0010:kasan_check_range+0x4/0x2a0 mm/kasan/generic.c:188
|
|
Code: 48 01 c6 48 89 c7 e8 db 4e c1 03 31 c0 5d c3 cc 0f 0b eb 02 0f 0b b8 ea ff ff ff 5d c3 cc 00 00 cc cc 00 00 cc cc 55 48 89 e5 <41> 57 41 56 41 55 41 54 53 b0 01 48 85 f6 0f 84 a4 01 00 00 48 89
|
|
RSP: 0018:ffffc9000e804000 EFLAGS: 00010246
|
|
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817e5bf2
|
|
RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff887c6568
|
|
RBP: ffffc9000e804000 R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff92001d0080c
|
|
R13: dffffc0000000000 R14: ffffffff87e6b100 R15: 0000000000000000
|
|
FS: 00007fd0c55826c0(0000) GS:ffff8881f6800000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: ffffc9000e803ff8 CR3: 0000000170ef7000 CR4: 00000000003506f0
|
|
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
Call Trace:
|
|
<#DF>
|
|
</#DF>
|
|
<TASK>
|
|
[<ffffffff81f281d1>] __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31
|
|
[<ffffffff817e5bf2>] instrument_atomic_read include/linux/instrumented.h:72 [inline]
|
|
[<ffffffff817e5bf2>] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]
|
|
[<ffffffff817e5bf2>] cpumask_test_cpu include/linux/cpumask.h:506 [inline]
|
|
[<ffffffff817e5bf2>] cpu_online include/linux/cpumask.h:1092 [inline]
|
|
[<ffffffff817e5bf2>] trace_lock_acquire include/trace/events/lock.h:24 [inline]
|
|
[<ffffffff817e5bf2>] lock_acquire+0xe2/0x590 kernel/locking/lockdep.c:5632
|
|
[<ffffffff8563221e>] rcu_lock_acquire+0x2e/0x40 include/linux/rcupdate.h:306
|
|
[<ffffffff8561464d>] rcu_read_lock include/linux/rcupdate.h:747 [inline]
|
|
[<ffffffff8561464d>] ip6_pol_route+0x15d/0x1440 net/ipv6/route.c:2221
|
|
[<ffffffff85618120>] ip6_pol_route_output+0x50/0x80 net/ipv6/route.c:2606
|
|
[<ffffffff856f65b5>] pol_lookup_func include/net/ip6_fib.h:584 [inline]
|
|
[<ffffffff856f65b5>] fib6_rule_lookup+0x265/0x620 net/ipv6/fib6_rules.c:116
|
|
[<ffffffff85618009>] ip6_route_output_flags_noref+0x2d9/0x3a0 net/ipv6/route.c:2638
|
|
[<ffffffff8561821a>] ip6_route_output_flags+0xca/0x340 net/ipv6/route.c:2651
|
|
[<ffffffff838bd5a3>] ip6_route_output include/net/ip6_route.h:100 [inline]
|
|
[<ffffffff838bd5a3>] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:473 [inline]
|
|
[<ffffffff838bd5a3>] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline]
|
|
[<ffffffff838bd5a3>] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]
|
|
[<ffffffff838bd5a3>] ipvlan_queue_xmit+0xc33/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677
|
|
[<ffffffff838c2909>] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229
|
|
[<ffffffff84d03900>] netdev_start_xmit include/linux/netdevice.h:4966 [inline]
|
|
[<ffffffff84d03900>] xmit_one net/core/dev.c:3644 [inline]
|
|
[<ffffffff84d03900>] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660
|
|
[<ffffffff84d080e2>] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324
|
|
[<ffffffff855ce4cd>] dev_queue_xmit include/linux/netdevice.h:3067 [inline]
|
|
[<ffffffff855ce4cd>] neigh_hh_output include/net/neighbour.h:529 [inline]
|
|
[<f
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52796</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="48" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="48" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
jfs: fix array-index-out-of-bounds in dbFindLeaf
|
|
|
|
Currently while searching for dmtree_t for sufficient free blocks there
|
|
is an array out of bounds while getting element in tp->dm_stree. To add
|
|
the required check for out of bound we first need to determine the type
|
|
of dmtree. Thus added an extra parameter to dbFindLeaf so that the type
|
|
of tree can be determined and the required check can be applied.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52799</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>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="49" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="49" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:iio: adc: stm32-adc: harden against NULL pointer deref in stm32_adc_probe()of_match_device() may fail and returns a NULL pointer.In practice there is no known reasonable way to trigger this, butin case one is added in future, harden the code by adding the check</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52802</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-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="50" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="50" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fs/jfs: Add validity check for db_maxag and db_agpref
|
|
|
|
Both db_maxag and db_agpref are used as the index of the
|
|
db_agfree array, but there is currently no validity check for
|
|
db_maxag and db_agpref, which can lead to errors.
|
|
|
|
The following is related bug reported by Syzbot:
|
|
|
|
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:639:20
|
|
index 7936 is out of range for type 'atomic_t[128]'
|
|
|
|
Add checking that the values of db_maxag and db_agpref are valid
|
|
indexes for the db_agfree array.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52804</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="51" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="51" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
jfs: fix array-index-out-of-bounds in diAlloc
|
|
|
|
Currently there is not check against the agno of the iag while
|
|
allocating new inodes to avoid fragmentation problem. Added the check
|
|
which is required.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52805</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>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="52" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="52" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:scsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup()fc_lport_ptp_setup() did not check the return value of fc_rport_create()which can return NULL and would cause a NULL pointer dereference. Addressthis issue by checking return value of fc_rport_create() and log errormessage on fc_rport_create() failed.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52809</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="53" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="53" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amd: Fix UBSAN array-index-out-of-bounds for Polaris and Tonga
|
|
|
|
For pptable structs that use flexible array sizes, use flexible arrays.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52819</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="54" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="54" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
cpu/hotplug: Don't offline the last non-isolated CPU
|
|
|
|
If a system has isolated CPUs via the "isolcpus=" command line parameter,
|
|
then an attempt to offline the last housekeeping CPU will result in a
|
|
WARN_ON() when rebuilding the scheduler domains and a subsequent panic due
|
|
to and unhandled empty CPU mas in partition_sched_domains_locked().
|
|
|
|
cpuset_hotplug_workfn()
|
|
rebuild_sched_domains_locked()
|
|
ndoms = generate_sched_domains(&doms, &attr);
|
|
cpumask_and(doms[0], top_cpuset.effective_cpus, housekeeping_cpumask(HK_FLAG_DOMAIN));
|
|
|
|
Thus results in an empty CPU mask which triggers the warning and then the
|
|
subsequent crash:
|
|
|
|
WARNING: CPU: 4 PID: 80 at kernel/sched/topology.c:2366 build_sched_domains+0x120c/0x1408
|
|
Call trace:
|
|
build_sched_domains+0x120c/0x1408
|
|
partition_sched_domains_locked+0x234/0x880
|
|
rebuild_sched_domains_locked+0x37c/0x798
|
|
rebuild_sched_domains+0x30/0x58
|
|
cpuset_hotplug_workfn+0x2a8/0x930
|
|
|
|
Unable to handle kernel paging request at virtual address fffe80027ab37080
|
|
partition_sched_domains_locked+0x318/0x880
|
|
rebuild_sched_domains_locked+0x37c/0x798
|
|
|
|
Aside of the resulting crash, it does not make any sense to offline the last
|
|
last housekeeping CPU.
|
|
|
|
Prevent this by masking out the non-housekeeping CPUs when selecting a
|
|
target CPU for initiating the CPU unplug operation via the work queue.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52831</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="55" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="55" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: mac80211: don't return unset power in ieee80211_get_tx_power()
|
|
|
|
We can get a UBSAN warning if ieee80211_get_tx_power() returns the
|
|
INT_MIN value mac80211 internally uses for "unset power level".
|
|
|
|
UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5
|
|
-2147483648 * 100 cannot be represented in type 'int'
|
|
CPU: 0 PID: 20433 Comm: insmod Tainted: G WC OE
|
|
Call Trace:
|
|
dump_stack+0x74/0x92
|
|
ubsan_epilogue+0x9/0x50
|
|
handle_overflow+0x8d/0xd0
|
|
__ubsan_handle_mul_overflow+0xe/0x10
|
|
nl80211_send_iface+0x688/0x6b0 [cfg80211]
|
|
[...]
|
|
cfg80211_register_wdev+0x78/0xb0 [cfg80211]
|
|
cfg80211_netdev_notifier_call+0x200/0x620 [cfg80211]
|
|
[...]
|
|
ieee80211_if_add+0x60e/0x8f0 [mac80211]
|
|
ieee80211_register_hw+0xda5/0x1170 [mac80211]
|
|
|
|
In this case, simply return an error instead, to indicate
|
|
that no data is available.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52832</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="56" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="56" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tipc: Change nla_policy for bearer-related names to NLA_NUL_STRING
|
|
|
|
syzbot reported the following uninit-value access issue [1]:
|
|
|
|
=====================================================
|
|
BUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline]
|
|
BUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756
|
|
strlen lib/string.c:418 [inline]
|
|
strstr+0xb8/0x2f0 lib/string.c:756
|
|
tipc_nl_node_reset_link_stats+0x3ea/0xb50 net/tipc/node.c:2595
|
|
genl_family_rcv_msg_doit net/netlink/genetlink.c:971 [inline]
|
|
genl_family_rcv_msg net/netlink/genetlink.c:1051 [inline]
|
|
genl_rcv_msg+0x11ec/0x1290 net/netlink/genetlink.c:1066
|
|
netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2545
|
|
genl_rcv+0x40/0x60 net/netlink/genetlink.c:1075
|
|
netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline]
|
|
netlink_unicast+0xf47/0x1250 net/netlink/af_netlink.c:1368
|
|
netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
sock_sendmsg net/socket.c:753 [inline]
|
|
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541
|
|
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595
|
|
__sys_sendmsg net/socket.c:2624 [inline]
|
|
__do_sys_sendmsg net/socket.c:2633 [inline]
|
|
__se_sys_sendmsg net/socket.c:2631 [inline]
|
|
__x64_sys_sendmsg+0x307/0x490 net/socket.c:2631
|
|
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
|
|
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
|
|
entry_SYSCALL_64_after_hwframe+0x63/0xcd
|
|
|
|
Uninit was created at:
|
|
slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767
|
|
slab_alloc_node mm/slub.c:3478 [inline]
|
|
kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523
|
|
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559
|
|
__alloc_skb+0x318/0x740 net/core/skbuff.c:650
|
|
alloc_skb include/linux/skbuff.h:1286 [inline]
|
|
netlink_alloc_large_skb net/netlink/af_netlink.c:1214 [inline]
|
|
netlink_sendmsg+0xb34/0x13d0 net/netlink/af_netlink.c:1885
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
sock_sendmsg net/socket.c:753 [inline]
|
|
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541
|
|
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595
|
|
__sys_sendmsg net/socket.c:2624 [inline]
|
|
__do_sys_sendmsg net/socket.c:2633 [inline]
|
|
__se_sys_sendmsg net/socket.c:2631 [inline]
|
|
__x64_sys_sendmsg+0x307/0x490 net/socket.c:2631
|
|
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
|
|
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
|
|
entry_SYSCALL_64_after_hwframe+0x63/0xcd
|
|
|
|
TIPC bearer-related names including link names must be null-terminated
|
|
strings. If a link name which is not null-terminated is passed through
|
|
netlink, strstr() and similar functions can cause buffer overrun. This
|
|
causes the above issue.
|
|
|
|
This patch changes the nla_policy for bearer-related names from NLA_STRING
|
|
to NLA_NUL_STRING. This resolves the issue by ensuring that only
|
|
null-terminated strings are accepted as bearer-related names.
|
|
|
|
syzbot reported similar uninit-value issue related to bearer names [2]. The
|
|
root cause of this issue is that a non-null-terminated bearer name was
|
|
passed. This patch also resolved this issue.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52845</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="57" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="57" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
can: dev: can_put_echo_skb(): don't crash kernel if can_priv::echo_skb is accessed out of bounds
|
|
|
|
If the "struct can_priv::echoo_skb" is accessed out of bounds, this
|
|
would cause a kernel crash. Instead, issue a meaningful warning
|
|
message and return with an error.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52878</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="58" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="58" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:USB: core: Fix deadlock in usb_deauthorize_interface()Among the attribute file callback routines indrivers/usb/core/sysfs.c, the interface_authorized_store() function isthe only one which acquires a device lock on an ancestor device: Itcalls usb_deauthorize_interface(), which locks the interface s parentUSB device.The will lead to deadlock if another process already owns that lockand tries to remove the interface, whether through a configurationchange or because the device has been disconnected. As part of theremoval procedure, device_del() waits for all ongoing sysfs attributecallbacks to complete. But usb_deauthorize_interface() can t completeuntil the device lock has been released, and the lock won t bereleased until the removal has finished.The mechanism provided by sysfs to prevent this kind of deadlock isto use the sysfs_break_active_protection() function, which tells sysfsnot to wait for the attribute callback.Reported-and-tested by: Yue Sun <samsun1006219@gmail.com>Reported by: xingwei lee <xrivendell7@gmail.com></Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-26934</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-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="59" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="59" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get()nft_unregister_expr() can concurrent with __nft_expr_type_get(),and there is not any protection when iterate over nf_tables_expressionslist in __nft_expr_type_get(). Therefore, there is potential data-raceof nf_tables_expressions list entry.Use list_for_each_entry_rcu() to iterate over nf_tables_expressionslist in __nft_expr_type_get(), and use rcu_read_lock() in the callernft_expr_type_get() to protect the entire type query process.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-27020</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-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="60" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="60" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout
|
|
|
|
There is a race condition between l2cap_chan_timeout() and
|
|
l2cap_chan_del(). When we use l2cap_chan_del() to delete the
|
|
channel, the chan->conn will be set to null. But the conn could
|
|
be dereferenced again in the mutex_lock() of l2cap_chan_timeout().
|
|
As a result the null pointer dereference bug will happen. The
|
|
KASAN report triggered by POC is shown below:
|
|
|
|
[ 472.074580] ==================================================================
|
|
[ 472.075284] BUG: KASAN: null-ptr-deref in mutex_lock+0x68/0xc0
|
|
[ 472.075308] Write of size 8 at addr 0000000000000158 by task kworker/0:0/7
|
|
[ 472.075308]
|
|
[ 472.075308] CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.9.0-rc5-00356-g78c0094a146b #36
|
|
[ 472.075308] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4
|
|
[ 472.075308] Workqueue: events l2cap_chan_timeout
|
|
[ 472.075308] Call Trace:
|
|
[ 472.075308] <TASK>
|
|
[ 472.075308] dump_stack_lvl+0x137/0x1a0
|
|
[ 472.075308] print_report+0x101/0x250
|
|
[ 472.075308] ? __virt_addr_valid+0x77/0x160
|
|
[ 472.075308] ? mutex_lock+0x68/0xc0
|
|
[ 472.075308] kasan_report+0x139/0x170
|
|
[ 472.075308] ? mutex_lock+0x68/0xc0
|
|
[ 472.075308] kasan_check_range+0x2c3/0x2e0
|
|
[ 472.075308] mutex_lock+0x68/0xc0
|
|
[ 472.075308] l2cap_chan_timeout+0x181/0x300
|
|
[ 472.075308] process_one_work+0x5d2/0xe00
|
|
[ 472.075308] worker_thread+0xe1d/0x1660
|
|
[ 472.075308] ? pr_cont_work+0x5e0/0x5e0
|
|
[ 472.075308] kthread+0x2b7/0x350
|
|
[ 472.075308] ? pr_cont_work+0x5e0/0x5e0
|
|
[ 472.075308] ? kthread_blkcg+0xd0/0xd0
|
|
[ 472.075308] ret_from_fork+0x4d/0x80
|
|
[ 472.075308] ? kthread_blkcg+0xd0/0xd0
|
|
[ 472.075308] ret_from_fork_asm+0x11/0x20
|
|
[ 472.075308] </TASK>
|
|
[ 472.075308] ==================================================================
|
|
[ 472.094860] Disabling lock debugging due to kernel taint
|
|
[ 472.096136] BUG: kernel NULL pointer dereference, address: 0000000000000158
|
|
[ 472.096136] #PF: supervisor write access in kernel mode
|
|
[ 472.096136] #PF: error_code(0x0002) - not-present page
|
|
[ 472.096136] PGD 0 P4D 0
|
|
[ 472.096136] Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI
|
|
[ 472.096136] CPU: 0 PID: 7 Comm: kworker/0:0 Tainted: G B 6.9.0-rc5-00356-g78c0094a146b #36
|
|
[ 472.096136] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4
|
|
[ 472.096136] Workqueue: events l2cap_chan_timeout
|
|
[ 472.096136] RIP: 0010:mutex_lock+0x88/0xc0
|
|
[ 472.096136] Code: be 08 00 00 00 e8 f8 23 1f fd 4c 89 f7 be 08 00 00 00 e8 eb 23 1f fd 42 80 3c 23 00 74 08 48 88
|
|
[ 472.096136] RSP: 0018:ffff88800744fc78 EFLAGS: 00000246
|
|
[ 472.096136] RAX: 0000000000000000 RBX: 1ffff11000e89f8f RCX: ffffffff8457c865
|
|
[ 472.096136] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff88800744fc78
|
|
[ 472.096136] RBP: 0000000000000158 R08: ffff88800744fc7f R09: 1ffff11000e89f8f
|
|
[ 472.096136] R10: dffffc0000000000 R11: ffffed1000e89f90 R12: dffffc0000000000
|
|
[ 472.096136] R13: 0000000000000158 R14: ffff88800744fc78 R15: ffff888007405a00
|
|
[ 472.096136] FS: 0000000000000000(0000) GS:ffff88806d200000(0000) knlGS:0000000000000000
|
|
[ 472.096136] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 472.096136] CR2: 0000000000000158 CR3: 000000000da32000 CR4: 00000000000006f0
|
|
[ 472.096136] Call Trace:
|
|
[ 472.096136] <TASK>
|
|
[ 472.096136] ? __die_body+0x8d/0xe0
|
|
[ 472.096136] ? page_fault_oops+0x6b8/0x9a0
|
|
[ 472.096136] ? kernelmode_fixup_or_oops+0x20c/0x2a0
|
|
[ 472.096136] ? do_user_addr_fault+0x1027/0x1340
|
|
[ 472.096136] ? _printk+0x7a/0xa0
|
|
[ 472.096136] ? mutex_lock+0x68/0xc0
|
|
[ 472.096136] ? add_taint+0x42/0xd0
|
|
[ 472.096136] ? exc_page_fault+0x6a/0x1b0
|
|
[ 472.096136] ? asm_exc_page_fault+0x26/0x30
|
|
[ 472.096136] ? mutex_lock+0x75/0xc0
|
|
[ 472.096136] ? mutex_lock+0x88/0xc0
|
|
[ 472.096136] ? mutex_lock+0x75/0xc0
|
|
[ 472.096136] l2cap_chan_timeo
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-27399</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="61" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="61" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
firewire: nosy: ensure user_length is taken into account when fetching packet contents
|
|
|
|
Ensure that packet_buffer_get respects the user_length provided. If
|
|
the length of the head packet exceeds the user_length, packet_buffer_get
|
|
will now return 0 to signify to the user that no data were read
|
|
and a larger buffer size is required. Helps prevent user space overflows.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-27401</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-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="62" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="62" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: mac80211: check/clear fast rx for non-4addr sta VLAN changes
|
|
|
|
When moving a station out of a VLAN and deleting the VLAN afterwards, the
|
|
fast_rx entry still holds a pointer to the VLAN's netdev, which can cause
|
|
use-after-free bugs. Fix this by immediately calling ieee80211_check_fast_rx
|
|
after the VLAN change.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-35789</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.6</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="63" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="63" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
md/dm-raid: don't call md_reap_sync_thread() directly
|
|
|
|
Currently md_reap_sync_thread() is called from raid_message() directly
|
|
without holding 'reconfig_mutex', this is definitely unsafe because
|
|
md_reap_sync_thread() can change many fields that is protected by
|
|
'reconfig_mutex'.
|
|
|
|
However, hold 'reconfig_mutex' here is still problematic because this
|
|
will cause deadlock, for example, commit 130443d60b1b ("md: refactor
|
|
idle/frozen_sync_thread() to fix deadlock").
|
|
|
|
Fix this problem by using stop_sync_thread() to unregister sync_thread,
|
|
like md/raid did.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-35808</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="64" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="64" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
usb: udc: remove warning when queue disabled ep
|
|
|
|
It is possible trigger below warning message from mass storage function,
|
|
|
|
WARNING: CPU: 6 PID: 3839 at drivers/usb/gadget/udc/core.c:294 usb_ep_queue+0x7c/0x104
|
|
pc : usb_ep_queue+0x7c/0x104
|
|
lr : fsg_main_thread+0x494/0x1b3c
|
|
|
|
Root cause is mass storage function try to queue request from main thread,
|
|
but other thread may already disable ep when function disable.
|
|
|
|
As there is no function failure in the driver, in order to avoid effort
|
|
to fix warning, change WARN_ON_ONCE() in usb_ep_queue() to pr_debug().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-35822</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>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="65" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="65" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
vt: fix unicode buffer corruption when deleting characters
|
|
|
|
This is the same issue that was fixed for the VGA text buffer in commit
|
|
39cdb68c64d8 ("vt: fix memory overlapping when deleting chars in the
|
|
buffer"). The cure is also the same i.e. replace memcpy() with memmove()
|
|
due to the overlaping buffers.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-35823</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="66" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="66" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
x86/mm/pat: fix VM_PAT handling in COW mappings
|
|
|
|
PAT handling won't do the right thing in COW mappings: the first PTE (or,
|
|
in fact, all PTEs) can be replaced during write faults to point at anon
|
|
folios. Reliably recovering the correct PFN and cachemode using
|
|
follow_phys() from PTEs will not work in COW mappings.
|
|
|
|
Using follow_phys(), we might just get the address+protection of the anon
|
|
folio (which is very wrong), or fail on swap/nonswap entries, failing
|
|
follow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and
|
|
track_pfn_copy(), not properly calling free_pfn_range().
|
|
|
|
In free_pfn_range(), we either wouldn't call memtype_free() or would call
|
|
it with the wrong range, possibly leaking memory.
|
|
|
|
To fix that, let's update follow_phys() to refuse returning anon folios,
|
|
and fallback to using the stored PFN inside vma->vm_pgoff for COW mappings
|
|
if we run into that.
|
|
|
|
We will now properly handle untrack_pfn() with COW mappings, where we
|
|
don't need the cachemode. We'll have to fail fork()->track_pfn_copy() if
|
|
the first page was replaced by an anon folio, though: we'd have to store
|
|
the cachemode in the VMA to make this work, likely growing the VMA size.
|
|
|
|
For now, lets keep it simple and let track_pfn_copy() just fail in that
|
|
case: it would have failed in the past with swap/nonswap entries already,
|
|
and it would have done the wrong thing with anon folios.
|
|
|
|
Simple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn():
|
|
|
|
<--- C reproducer --->
|
|
#include <stdio.h>
|
|
#include <sys/mman.h>
|
|
#include <unistd.h>
|
|
#include <liburing.h>
|
|
|
|
int main(void)
|
|
{
|
|
struct io_uring_params p = {};
|
|
int ring_fd;
|
|
size_t size;
|
|
char *map;
|
|
|
|
ring_fd = io_uring_setup(1, &p);
|
|
if (ring_fd < 0) {
|
|
perror("io_uring_setup");
|
|
return 1;
|
|
}
|
|
size = p.sq_off.array + p.sq_entries * sizeof(unsigned);
|
|
|
|
/* Map the submission queue ring MAP_PRIVATE */
|
|
map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE,
|
|
ring_fd, IORING_OFF_SQ_RING);
|
|
if (map == MAP_FAILED) {
|
|
perror("mmap");
|
|
return 1;
|
|
}
|
|
|
|
/* We have at least one page. Let's COW it. */
|
|
*map = 0;
|
|
pause();
|
|
return 0;
|
|
}
|
|
<--- C reproducer --->
|
|
|
|
On a system with 16 GiB RAM and swap configured:
|
|
# ./iouring &
|
|
# memhog 16G
|
|
# killall iouring
|
|
[ 301.552930] ------------[ cut here ]------------
|
|
[ 301.553285] WARNING: CPU: 7 PID: 1402 at arch/x86/mm/pat/memtype.c:1060 untrack_pfn+0xf4/0x100
|
|
[ 301.553989] Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_g
|
|
[ 301.558232] CPU: 7 PID: 1402 Comm: iouring Not tainted 6.7.5-100.fc38.x86_64 #1
|
|
[ 301.558772] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebu4
|
|
[ 301.559569] RIP: 0010:untrack_pfn+0xf4/0x100
|
|
[ 301.559893] Code: 75 c4 eb cf 48 8b 43 10 8b a8 e8 00 00 00 3b 6b 28 74 b8 48 8b 7b 30 e8 ea 1a f7 000
|
|
[ 301.561189] RSP: 0018:ffffba2c0377fab8 EFLAGS: 00010282
|
|
[ 301.561590] RAX: 00000000ffffffea RBX: ffff9208c8ce9cc0 RCX: 000000010455e047
|
|
[ 301.562105] RDX: 07fffffff0eb1e0a RSI: 0000000000000000 RDI: ffff9208c391d200
|
|
[ 301.562628] RBP: 0000000000000000 R08: ffffba2c0377fab8 R09: 0000000000000000
|
|
[ 301.563145] R10: ffff9208d2292d50 R11: 0000000000000002 R12: 00007fea890e0000
|
|
[ 301.563669] R13: 0000000000000000 R14: ffffba2c0377fc08 R15: 0000000000000000
|
|
[ 301.564186] FS: 0000000000000000(0000) GS:ffff920c2fbc0000(0000) knlGS:0000000000000000
|
|
[ 301.564773] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 301.565197] CR2: 00007fea88ee8a20 CR3: 00000001033a8000 CR4: 0000000000750ef0
|
|
[ 301.565725] PKRU: 55555554
|
|
[ 301.565944] Call Trace:
|
|
[ 301.566148] <TASK>
|
|
[ 301.566325] ? untrack_pfn+0xf4/0x100
|
|
[ 301.566618] ? __warn+0x81/0x130
|
|
[ 301.566876] ? untrack_pfn+0xf4/0x100
|
|
[ 3
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-35877</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="67" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="67" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
selinux: avoid dereference of garbage after mount failure
|
|
|
|
In case kern_mount() fails and returns an error pointer return in the
|
|
error branch instead of continuing and dereferencing the error pointer.
|
|
|
|
While on it drop the never read static variable selinuxfs_mount.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-35904</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="68" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="68" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
block: prevent division by zero in blk_rq_stat_sum()
|
|
|
|
The expression dst->nr_samples + src->nr_samples may
|
|
have zero value on overflow. It is necessary to add
|
|
a check to avoid division by zero.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with Svace.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-35925</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="69" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="69" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/mlx5: Properly link new fs rules into the tree
|
|
|
|
Previously, add_rule_fg would only add newly created rules from the
|
|
handle into the tree when they had a refcount of 1. On the other hand,
|
|
create_flow_handle tries hard to find and reference already existing
|
|
identical rules instead of creating new ones.
|
|
|
|
These two behaviors can result in a situation where create_flow_handle
|
|
1) creates a new rule and references it, then
|
|
2) in a subsequent step during the same handle creation references it
|
|
again,
|
|
resulting in a rule with a refcount of 2 that is not linked into the
|
|
tree, will have a NULL parent and root and will result in a crash when
|
|
the flow group is deleted because del_sw_hw_rule, invoked on rule
|
|
deletion, assumes node->parent is != NULL.
|
|
|
|
This happened in the wild, due to another bug related to incorrect
|
|
handling of duplicate pkt_reformat ids, which lead to the code in
|
|
create_flow_handle incorrectly referencing a just-added rule in the same
|
|
flow handle, resulting in the problem described above. Full details are
|
|
at [1].
|
|
|
|
This patch changes add_rule_fg to add new rules without parents into
|
|
the tree, properly initializing them and avoiding the crash. This makes
|
|
it more consistent with how rules are added to an FTE in
|
|
create_flow_handle.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-35960</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="70" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="70" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix memory leak in hci_req_sync_complete()In hci_req_sync_complete() , always free the previous syncrequest state before assigning reference to a new one.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-35978</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="71" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="71" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ACPI: CPPC: Use access_width over bit_width for system memory accesses
|
|
|
|
To align with ACPI 6.3+, since bit_width can be any 8-bit value, it
|
|
cannot be depended on to be always on a clean 8b boundary. This was
|
|
uncovered on the Cobalt 100 platform.
|
|
|
|
SError Interrupt on CPU26, code 0xbe000011 -- SError
|
|
CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1
|
|
Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION
|
|
pstate: 62400009 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--)
|
|
pc : cppc_get_perf_caps+0xec/0x410
|
|
lr : cppc_get_perf_caps+0xe8/0x410
|
|
sp : ffff8000155ab730
|
|
x29: ffff8000155ab730 x28: ffff0080139d0038 x27: ffff0080139d0078
|
|
x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff
|
|
x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000
|
|
x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff
|
|
x17: 0000000000000000 x16: ffffdc7e111bad04 x15: ffff00802b251008
|
|
x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006
|
|
x11: ffffdc7e128f4420 x10: 0000000000000000 x9 : ffffdc7e111badec
|
|
x8 : ffff00802b251980 x7 : 0000000000000000 x6 : ffff0080139d0028
|
|
x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff
|
|
x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000
|
|
Kernel panic - not syncing: Asynchronous SError Interrupt
|
|
CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted
|
|
5.15.2.1-13 #1
|
|
Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION
|
|
Call trace:
|
|
dump_backtrace+0x0/0x1e0
|
|
show_stack+0x24/0x30
|
|
dump_stack_lvl+0x8c/0xb8
|
|
dump_stack+0x18/0x34
|
|
panic+0x16c/0x384
|
|
add_taint+0x0/0xc0
|
|
arm64_serror_panic+0x7c/0x90
|
|
arm64_is_fatal_ras_serror+0x34/0xa4
|
|
do_serror+0x50/0x6c
|
|
el1h_64_error_handler+0x40/0x74
|
|
el1h_64_error+0x7c/0x80
|
|
cppc_get_perf_caps+0xec/0x410
|
|
cppc_cpufreq_cpu_init+0x74/0x400 [cppc_cpufreq]
|
|
cpufreq_online+0x2dc/0xa30
|
|
cpufreq_add_dev+0xc0/0xd4
|
|
subsys_interface_register+0x134/0x14c
|
|
cpufreq_register_driver+0x1b0/0x354
|
|
cppc_cpufreq_init+0x1a8/0x1000 [cppc_cpufreq]
|
|
do_one_initcall+0x50/0x250
|
|
do_init_module+0x60/0x27c
|
|
load_module+0x2300/0x2570
|
|
__do_sys_finit_module+0xa8/0x114
|
|
__arm64_sys_finit_module+0x2c/0x3c
|
|
invoke_syscall+0x78/0x100
|
|
el0_svc_common.constprop.0+0x180/0x1a0
|
|
do_el0_svc+0x84/0xa0
|
|
el0_svc+0x2c/0xc0
|
|
el0t_64_sync_handler+0xa4/0x12c
|
|
el0t_64_sync+0x1a4/0x1a8
|
|
|
|
Instead, use access_width to determine the size and use the offset and
|
|
width to shift and mask the bits to read/write out. Make sure to add a
|
|
check for system memory since pcc redefines the access_width to
|
|
subspace id.
|
|
|
|
If access_width is not set, then fall back to using bit_width.
|
|
|
|
[ rjw: Subject and changelog edits, comment adjustments ]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-35995</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="72" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="72" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
i40e: Do not use WQ_MEM_RECLAIM flag for workqueue
|
|
|
|
Issue reported by customer during SRIOV testing, call trace:
|
|
When both i40e and the i40iw driver are loaded, a warning
|
|
in check_flush_dependency is being triggered. This seems
|
|
to be because of the i40e driver workqueue is allocated with
|
|
the WQ_MEM_RECLAIM flag, and the i40iw one is not.
|
|
|
|
Similar error was encountered on ice too and it was fixed by
|
|
removing the flag. Do the same for i40e too.
|
|
|
|
[Feb 9 09:08] ------------[ cut here ]------------
|
|
[ +0.000004] workqueue: WQ_MEM_RECLAIM i40e:i40e_service_task [i40e] is
|
|
flushing !WQ_MEM_RECLAIM infiniband:0x0
|
|
[ +0.000060] WARNING: CPU: 0 PID: 937 at kernel/workqueue.c:2966
|
|
check_flush_dependency+0x10b/0x120
|
|
[ +0.000007] Modules linked in: snd_seq_dummy snd_hrtimer snd_seq
|
|
snd_timer snd_seq_device snd soundcore nls_utf8 cifs cifs_arc4
|
|
nls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 dns_resolver netfs qrtr
|
|
rfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common irdma
|
|
intel_uncore_frequency intel_uncore_frequency_common ice ipmi_ssif
|
|
isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal
|
|
intel_powerclamp gnss coretemp ib_uverbs rapl intel_cstate ib_core
|
|
iTCO_wdt iTCO_vendor_support acpi_ipmi mei_me ipmi_si intel_uncore
|
|
ioatdma i2c_i801 joydev pcspkr mei ipmi_devintf lpc_ich
|
|
intel_pch_thermal i2c_smbus ipmi_msghandler acpi_power_meter acpi_pad
|
|
xfs libcrc32c ast sd_mod drm_shmem_helper t10_pi drm_kms_helper sg ixgbe
|
|
drm i40e ahci crct10dif_pclmul libahci crc32_pclmul igb crc32c_intel
|
|
libata ghash_clmulni_intel i2c_algo_bit mdio dca wmi dm_mirror
|
|
dm_region_hash dm_log dm_mod fuse
|
|
[ +0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: loaded Not
|
|
tainted 6.8.0-rc2-Feb-net_dev-Qiueue-00279-gbd43c5687e05 #1
|
|
[ +0.000003] Hardware name: Intel Corporation S2600BPB/S2600BPB, BIOS
|
|
SE5C620.86B.02.01.0013.121520200651 12/15/2020
|
|
[ +0.000001] Workqueue: i40e i40e_service_task [i40e]
|
|
[ +0.000024] RIP: 0010:check_flush_dependency+0x10b/0x120
|
|
[ +0.000003] Code: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 48
|
|
81 c6 b0 00 00 00 48 c7 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fd
|
|
ff <0f> 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff ff 90
|
|
[ +0.000002] RSP: 0018:ffffbd294976bcf8 EFLAGS: 00010282
|
|
[ +0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX:
|
|
0000000000000027
|
|
[ +0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI:
|
|
ffff94d47f620bc0
|
|
[ +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09:
|
|
00000000ffff7fff
|
|
[ +0.000001] R10: ffffbd294976bb98 R11: ffffffffa0be65e8 R12:
|
|
ffff94c5451ea180
|
|
[ +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15:
|
|
ffff94c5f1330ab0
|
|
[ +0.000001] FS: 0000000000000000(0000) GS:ffff94d47f600000(0000)
|
|
knlGS:0000000000000000
|
|
[ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ +0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4:
|
|
00000000007706f0
|
|
[ +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
|
|
0000000000000000
|
|
[ +0.000001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
|
|
0000000000000400
|
|
[ +0.000001] PKRU: 55555554
|
|
[ +0.000001] Call Trace:
|
|
[ +0.000001] <TASK>
|
|
[ +0.000002] ? __warn+0x80/0x130
|
|
[ +0.000003] ? check_flush_dependency+0x10b/0x120
|
|
[ +0.000002] ? report_bug+0x195/0x1a0
|
|
[ +0.000005] ? handle_bug+0x3c/0x70
|
|
[ +0.000003] ? exc_invalid_op+0x14/0x70
|
|
[ +0.000002] ? asm_exc_invalid_op+0x16/0x20
|
|
[ +0.000006] ? check_flush_dependency+0x10b/0x120
|
|
[ +0.000002] ? check_flush_dependency+0x10b/0x120
|
|
[ +0.000002] __flush_workqueue+0x126/0x3f0
|
|
[ +0.000015] ib_cache_cleanup_one+0x1c/0xe0 [ib_core]
|
|
[ +0.000056] __ib_unregister_device+0x6a/0xb0 [ib_core]
|
|
[ +0.000023] ib_unregister_device_and_put+0x34/0x50 [ib_core]
|
|
[ +0.000020] i40iw_close+0x4b/0x90 [irdma]
|
|
[ +0.000022] i40e_notify_client_of_netdev_close+0x54/0xc0 [i40e]
|
|
[ +0.000035] i40e_service_task+0x126/0x190 [i40e]
|
|
[ +0.000024] process_one_work+0x174/0x340
|
|
[ +0.000003] worker_th
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-36004</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="73" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="73" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ppdev: Add an error check in register_device
|
|
|
|
In register_device, the return value of ida_simple_get is unchecked,
|
|
in witch ida_simple_get will use an invalid index value.
|
|
|
|
To address this issue, index should be checked after ida_simple_get. When
|
|
the index value is abnormal, a warning message should be printed, the port
|
|
should be dropped, and the value should be recorded.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-36015</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="74" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="74" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
pinctrl: core: delete incorrect free in pinctrl_enable()
|
|
|
|
The "pctldev" struct is allocated in devm_pinctrl_register_and_init().
|
|
It's a devm_ managed pointer that is freed by devm_pinctrl_dev_release(),
|
|
so freeing it in pinctrl_enable() will lead to a double free.
|
|
|
|
The devm_pinctrl_dev_release() function frees the pindescs and destroys
|
|
the mutex as well.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-36940</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1692</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |