4741 lines
194 KiB
XML
4741 lines
194 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-22.03-LTS-SP1</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-1680</ID>
|
|
</Identification>
|
|
<Status>Final</Status>
|
|
<Version>1.0</Version>
|
|
<RevisionHistory>
|
|
<Revision>
|
|
<Number>1.0</Number>
|
|
<Date>2024-05-31</Date>
|
|
<Description>Initial</Description>
|
|
</Revision>
|
|
</RevisionHistory>
|
|
<InitialReleaseDate>2024-05-31</InitialReleaseDate>
|
|
<CurrentReleaseDate>2024-05-31</CurrentReleaseDate>
|
|
<Generator>
|
|
<Engine>openEuler SA Tool V1.0</Engine>
|
|
<Date>2024-05-31</Date>
|
|
</Generator>
|
|
</DocumentTracking>
|
|
<DocumentNotes>
|
|
<Note Title="Synopsis" Type="General" Ordinal="1" xml:lang="en">kernel security update</Note>
|
|
<Note Title="Summary" Type="General" Ordinal="2" xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP1.</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:
|
|
|
|
drm/amdgpu: handle the case of pci_channel_io_frozen only in amdgpu_pci_resume
|
|
|
|
In current code, when a PCI error state pci_channel_io_normal is detectd,
|
|
it will report PCI_ERS_RESULT_CAN_RECOVER status to PCI driver, and PCI
|
|
driver will continue the execution of PCI resume callback report_resume by
|
|
pci_walk_bridge, and the callback will go into amdgpu_pci_resume
|
|
finally, where write lock is releasd unconditionally without acquiring
|
|
such lock first. In this case, a deadlock will happen when other threads
|
|
start to acquire the read lock.
|
|
|
|
To fix this, add a member in amdgpu_device strucutre to cache
|
|
pci_channel_state, and only continue the execution in amdgpu_pci_resume
|
|
when it's pci_channel_io_frozen.(CVE-2021-47421)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ptp: Fix possible memory leak in ptp_clock_register()
|
|
|
|
I got memory leak as follows when doing fault injection test:
|
|
|
|
unreferenced object 0xffff88800906c618 (size 8):
|
|
comm "i2c-idt82p33931", pid 4421, jiffies 4294948083 (age 13.188s)
|
|
hex dump (first 8 bytes):
|
|
70 74 70 30 00 00 00 00 ptp0....
|
|
backtrace:
|
|
[<00000000312ed458>] __kmalloc_track_caller+0x19f/0x3a0
|
|
[<0000000079f6e2ff>] kvasprintf+0xb5/0x150
|
|
[<0000000026aae54f>] kvasprintf_const+0x60/0x190
|
|
[<00000000f323a5f7>] kobject_set_name_vargs+0x56/0x150
|
|
[<000000004e35abdd>] dev_set_name+0xc0/0x100
|
|
[<00000000f20cfe25>] ptp_clock_register+0x9f4/0xd30 [ptp]
|
|
[<000000008bb9f0de>] idt82p33_probe.cold+0x8b6/0x1561 [ptp_idt82p33]
|
|
|
|
When posix_clock_register() returns an error, the name allocated
|
|
in dev_set_name() will be leaked, the put_device() should be used
|
|
to give up the device reference, then the name will be freed in
|
|
kobject_cleanup() and other memory will be freed in ptp_clock_release().(CVE-2021-47455)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: ebtables: fix memory leak when blob is malformed
|
|
|
|
The bug fix was incomplete, it "replaced" crash with a memory leak.
|
|
The old code had an assignment to "ret" embedded into the conditional,
|
|
restore this.(CVE-2022-48641)
|
|
|
|
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:
|
|
|
|
drm/tegra: dsi: Add missing check for of_find_device_by_node
|
|
|
|
Add check for the return value of of_find_device_by_node() and return
|
|
the error if it fails in order to avoid NULL pointer dereference.(CVE-2023-52650)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
io_uring: drop any code related to SCM_RIGHTS
|
|
|
|
This is dead code after we dropped support for passing io_uring fds
|
|
over SCM_RIGHTS, get rid of it.(CVE-2023-52656)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: atlantic: eliminate double free in error handling logic
|
|
|
|
Driver has a logic leak in ring data allocation/free,
|
|
where aq_ring_free could be called multiple times on same ring,
|
|
if system is under stress and got memory allocation error.
|
|
|
|
Ring pointer was used as an indicator of failure, but this is
|
|
not correct since only ring data is allocated/deallocated.
|
|
Ring itself is an array member.
|
|
|
|
Changing ring allocation functions to return error code directly.
|
|
This simplifies error handling and eliminates aq_ring_free
|
|
on higher layer.(CVE-2023-52664)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ACPI: LPIT: Avoid u32 multiplication overflow
|
|
|
|
In lpit_update_residency() there is a possibility of overflow
|
|
in multiplication, if tsc_khz is large enough (> UINT_MAX/1000).
|
|
|
|
Change multiplication to mul_u32_u32().
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52683)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
calipso: fix memory leak in netlbl_calipso_add_pass()
|
|
|
|
If IPv6 support is disabled at boot (ipv6.disable=1),
|
|
the calipso_init() -> netlbl_calipso_ops_register() function isn't called,
|
|
and the netlbl_calipso_ops_get() function always returns NULL.
|
|
In this case, the netlbl_calipso_add_pass() function allocates memory
|
|
for the doi_def variable but doesn't free it with the calipso_doi_free().
|
|
|
|
BUG: memory leak
|
|
unreferenced object 0xffff888011d68180 (size 64):
|
|
comm "syz-executor.1", pid 10746, jiffies 4295410986 (age 17.928s)
|
|
hex dump (first 32 bytes):
|
|
00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
backtrace:
|
|
[<...>] kmalloc include/linux/slab.h:552 [inline]
|
|
[<...>] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [inline]
|
|
[<...>] netlbl_calipso_add+0x22e/0x4f0 net/netlabel/netlabel_calipso.c:111
|
|
[<...>] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739
|
|
[<...>] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]
|
|
[<...>] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800
|
|
[<...>] netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2515
|
|
[<...>] genl_rcv+0x29/0x40 net/netlink/genetlink.c:811
|
|
[<...>] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]
|
|
[<...>] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1339
|
|
[<...>] netlink_sendmsg+0x90a/0xdf0 net/netlink/af_netlink.c:1934
|
|
[<...>] sock_sendmsg_nosec net/socket.c:651 [inline]
|
|
[<...>] sock_sendmsg+0x157/0x190 net/socket.c:671
|
|
[<...>] ____sys_sendmsg+0x712/0x870 net/socket.c:2342
|
|
[<...>] ___sys_sendmsg+0xf8/0x170 net/socket.c:2396
|
|
[<...>] __sys_sendmsg+0xea/0x1b0 net/socket.c:2429
|
|
[<...>] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46
|
|
[<...>] entry_SYSCALL_64_after_hwframe+0x61/0xc6
|
|
|
|
Found by InfoTeCS on behalf of Linux Verification Center
|
|
(linuxtesting.org) with Syzkaller
|
|
|
|
[PM: merged via the LSM tree at Jakub Kicinski request](CVE-2023-52698)
|
|
|
|
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:
|
|
|
|
crypto: pcrypt - Fix hungtask for PADATA_RESET
|
|
|
|
We found a hungtask bug in test_aead_vec_cfg as follows:
|
|
|
|
INFO: task cryptomgr_test:391009 blocked for more than 120 seconds.
|
|
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
|
|
Call trace:
|
|
__switch_to+0x98/0xe0
|
|
__schedule+0x6c4/0xf40
|
|
schedule+0xd8/0x1b4
|
|
schedule_timeout+0x474/0x560
|
|
wait_for_common+0x368/0x4e0
|
|
wait_for_completion+0x20/0x30
|
|
wait_for_completion+0x20/0x30
|
|
test_aead_vec_cfg+0xab4/0xd50
|
|
test_aead+0x144/0x1f0
|
|
alg_test_aead+0xd8/0x1e0
|
|
alg_test+0x634/0x890
|
|
cryptomgr_test+0x40/0x70
|
|
kthread+0x1e0/0x220
|
|
ret_from_fork+0x10/0x18
|
|
Kernel panic - not syncing: hung_task: blocked tasks
|
|
|
|
For padata_do_parallel, when the return err is 0 or -EBUSY, it will call
|
|
wait_for_completion(&wait->completion) in test_aead_vec_cfg. In normal
|
|
case, aead_request_complete() will be called in pcrypt_aead_serial and the
|
|
return err is 0 for padata_do_parallel. But, when pinst->flags is
|
|
PADATA_RESET, the return err is -EBUSY for padata_do_parallel, and it
|
|
won't call aead_request_complete(). Therefore, test_aead_vec_cfg will
|
|
hung at wait_for_completion(&wait->completion), which will cause
|
|
hungtask.
|
|
|
|
The problem comes as following:
|
|
(padata_do_parallel) |
|
|
rcu_read_lock_bh(); |
|
|
err = -EINVAL; | (padata_replace)
|
|
| pinst->flags |= PADATA_RESET;
|
|
err = -EBUSY |
|
|
if (pinst->flags & PADATA_RESET) |
|
|
rcu_read_unlock_bh() |
|
|
return err
|
|
|
|
In order to resolve the problem, we replace the return err -EBUSY with
|
|
-EAGAIN, which means parallel_data is changing, and the caller should call
|
|
it again.
|
|
|
|
v3:
|
|
remove retry and just change the return err.
|
|
v2:
|
|
introduce padata_try_do_parallel() in pcrypt_aead_encrypt and
|
|
pcrypt_aead_decrypt to solve the hungtask.(CVE-2023-52813)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULL
|
|
|
|
In certain types of chips, such as VEGA20, reading the amdgpu_regs_smc file could result in an abnormal null pointer access when the smc_rreg pointer is NULL. Below are the steps to reproduce this issue and the corresponding exception log:
|
|
|
|
1. Navigate to the directory: /sys/kernel/debug/dri/0
|
|
2. Execute command: cat amdgpu_regs_smc
|
|
3. Exception Log::
|
|
[4005007.702554] BUG: kernel NULL pointer dereference, address: 0000000000000000
|
|
[4005007.702562] #PF: supervisor instruction fetch in kernel mode
|
|
[4005007.702567] #PF: error_code(0x0010) - not-present page
|
|
[4005007.702570] PGD 0 P4D 0
|
|
[4005007.702576] Oops: 0010 [#1] SMP NOPTI
|
|
[4005007.702581] CPU: 4 PID: 62563 Comm: cat Tainted: G OE 5.15.0-43-generic #46-Ubunt u
|
|
[4005007.702590] RIP: 0010:0x0
|
|
[4005007.702598] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.
|
|
[4005007.702600] RSP: 0018:ffffa82b46d27da0 EFLAGS: 00010206
|
|
[4005007.702605] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffa82b46d27e68
|
|
[4005007.702609] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9940656e0000
|
|
[4005007.702612] RBP: ffffa82b46d27dd8 R08: 0000000000000000 R09: ffff994060c07980
|
|
[4005007.702615] R10: 0000000000020000 R11: 0000000000000000 R12: 00007f5e06753000
|
|
[4005007.702618] R13: ffff9940656e0000 R14: ffffa82b46d27e68 R15: 00007f5e06753000
|
|
[4005007.702622] FS: 00007f5e0755b740(0000) GS:ffff99479d300000(0000) knlGS:0000000000000000
|
|
[4005007.702626] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[4005007.702629] CR2: ffffffffffffffd6 CR3: 00000003253fc000 CR4: 00000000003506e0
|
|
[4005007.702633] Call Trace:
|
|
[4005007.702636] <TASK>
|
|
[4005007.702640] amdgpu_debugfs_regs_smc_read+0xb0/0x120 [amdgpu]
|
|
[4005007.703002] full_proxy_read+0x5c/0x80
|
|
[4005007.703011] vfs_read+0x9f/0x1a0
|
|
[4005007.703019] ksys_read+0x67/0xe0
|
|
[4005007.703023] __x64_sys_read+0x19/0x20
|
|
[4005007.703028] do_syscall_64+0x5c/0xc0
|
|
[4005007.703034] ? do_user_addr_fault+0x1e3/0x670
|
|
[4005007.703040] ? exit_to_user_mode_prepare+0x37/0xb0
|
|
[4005007.703047] ? irqentry_exit_to_user_mode+0x9/0x20
|
|
[4005007.703052] ? irqentry_exit+0x19/0x30
|
|
[4005007.703057] ? exc_page_fault+0x89/0x160
|
|
[4005007.703062] ? asm_exc_page_fault+0x8/0x30
|
|
[4005007.703068] entry_SYSCALL_64_after_hwframe+0x44/0xae
|
|
[4005007.703075] RIP: 0033:0x7f5e07672992
|
|
[4005007.703079] Code: c0 e9 b2 fe ff ff 50 48 8d 3d fa b2 0c 00 e8 c5 1d 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 e c 28 48 89 54 24
|
|
[4005007.703083] RSP: 002b:00007ffe03097898 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
|
|
[4005007.703088] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5e07672992
|
|
[4005007.703091] RDX: 0000000000020000 RSI: 00007f5e06753000 RDI: 0000000000000003
|
|
[4005007.703094] RBP: 00007f5e06753000 R08: 00007f5e06752010 R09: 00007f5e06752010
|
|
[4005007.703096] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000022000
|
|
[4005007.703099] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000
|
|
[4005007.703105] </TASK>
|
|
[4005007.703107] Modules linked in: nf_tables libcrc32c nfnetlink algif_hash af_alg binfmt_misc nls_ iso8859_1 ipmi_ssif ast intel_rapl_msr intel_rapl_common drm_vram_helper drm_ttm_helper amd64_edac t tm edac_mce_amd kvm_amd ccp mac_hid k10temp kvm acpi_ipmi ipmi_si rapl sch_fq_codel ipmi_devintf ipm i_msghandler msr parport_pc ppdev lp parport mtd pstore_blk efi_pstore ramoops pstore_zone reed_solo mon ip_tables x_tables autofs4 ib_uverbs ib_core amdgpu(OE) amddrm_ttm_helper(OE) amdttm(OE) iommu_v 2 amd_sched(OE) amdkcl(OE) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec rc_core drm igb ahci xhci_pci libahci i2c_piix4 i2c_algo_bit xhci_pci_renesas dca
|
|
[4005007.703184] CR2: 0000000000000000
|
|
[4005007.703188] ---[ en
|
|
---truncated---(CVE-2023-52817)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
perf/core: Bail out early if the request AUX area is out of bound
|
|
|
|
When perf-record with a large AUX area, e.g 4GB, it fails with:
|
|
|
|
#perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1
|
|
failed to mmap with 12 (Cannot allocate memory)
|
|
|
|
and it reveals a WARNING with __alloc_pages():
|
|
|
|
------------[ cut here ]------------
|
|
WARNING: CPU: 44 PID: 17573 at mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248
|
|
Call trace:
|
|
__alloc_pages+0x1ec/0x248
|
|
__kmalloc_large_node+0xc0/0x1f8
|
|
__kmalloc_node+0x134/0x1e8
|
|
rb_alloc_aux+0xe0/0x298
|
|
perf_mmap+0x440/0x660
|
|
mmap_region+0x308/0x8a8
|
|
do_mmap+0x3c0/0x528
|
|
vm_mmap_pgoff+0xf4/0x1b8
|
|
ksys_mmap_pgoff+0x18c/0x218
|
|
__arm64_sys_mmap+0x38/0x58
|
|
invoke_syscall+0x50/0x128
|
|
el0_svc_common.constprop.0+0x58/0x188
|
|
do_el0_svc+0x34/0x50
|
|
el0_svc+0x34/0x108
|
|
el0t_64_sync_handler+0xb8/0xc0
|
|
el0t_64_sync+0x1a4/0x1a8
|
|
|
|
'rb->aux_pages' allocated by kcalloc() is a pointer array which is used to
|
|
maintains AUX trace pages. The allocated page for this array is physically
|
|
contiguous (and virtually contiguous) with an order of 0..MAX_ORDER. If the
|
|
size of pointer array crosses the limitation set by MAX_ORDER, it reveals a
|
|
WARNING.
|
|
|
|
So bail out early with -ENOMEM if the request AUX area is out of bound,
|
|
e.g.:
|
|
|
|
#perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1
|
|
failed to mmap with 12 (Cannot allocate memory)(CVE-2023-52835)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nbd: fix uaf in nbd_open
|
|
|
|
Commit 4af5f2e03013 ("nbd: use blk_mq_alloc_disk and
|
|
blk_cleanup_disk") cleans up disk by blk_cleanup_disk() and it won't set
|
|
disk->private_data as NULL as before. UAF may be triggered in nbd_open()
|
|
if someone tries to open nbd device right after nbd_put() since nbd has
|
|
been free in nbd_dev_remove().
|
|
|
|
Fix this by implementing ->free_disk and free private data in it.(CVE-2023-52837)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Input: synaptics-rmi4 - fix use after free in rmi_unregister_function()
|
|
|
|
The put_device() calls rmi_release_function() which frees "fn" so the
|
|
dereference on the next line "fn->num_of_irqs" is a use after free.
|
|
Move the put_device() to the end to fix this.(CVE-2023-52840)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: vidtv: psi: Add check for kstrdup
|
|
|
|
Add check for the return value of kstrdup() and return the error
|
|
if it fails in order to avoid NULL pointer dereference.(CVE-2023-52844)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: bttv: fix use after free error due to btv->timeout timer
|
|
|
|
There may be some a race condition between timer function
|
|
bttv_irq_timeout and bttv_remove. The timer is setup in
|
|
probe and there is no timer_delete operation in remove
|
|
function. When it hit kfree btv, the function might still be
|
|
invoked, which will cause use after free bug.
|
|
|
|
This bug is found by static analysis, it may be false positive.
|
|
|
|
Fix it by adding del_timer_sync invoking to the remove function.
|
|
|
|
cpu0 cpu1
|
|
bttv_probe
|
|
->timer_setup
|
|
->bttv_set_dma
|
|
->mod_timer;
|
|
bttv_remove
|
|
->kfree(btv);
|
|
->bttv_irq_timeout
|
|
->USE btv(CVE-2023-52847)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
padata: Fix refcnt handling in padata_free_shell()
|
|
|
|
In a high-load arm64 environment, the pcrypt_aead01 test in LTP can lead
|
|
to system UAF (Use-After-Free) issues. Due to the lengthy analysis of
|
|
the pcrypt_aead01 function call, I'll describe the problem scenario
|
|
using a simplified model:
|
|
|
|
Suppose there's a user of padata named `user_function` that adheres to
|
|
the padata requirement of calling `padata_free_shell` after `serial()`
|
|
has been invoked, as demonstrated in the following code:
|
|
|
|
```c
|
|
struct request {
|
|
struct padata_priv padata;
|
|
struct completion *done;
|
|
};
|
|
|
|
void parallel(struct padata_priv *padata) {
|
|
do_something();
|
|
}
|
|
|
|
void serial(struct padata_priv *padata) {
|
|
struct request *request = container_of(padata,
|
|
struct request,
|
|
padata);
|
|
complete(request->done);
|
|
}
|
|
|
|
void user_function() {
|
|
DECLARE_COMPLETION(done)
|
|
padata->parallel = parallel;
|
|
padata->serial = serial;
|
|
padata_do_parallel();
|
|
wait_for_completion(&done);
|
|
padata_free_shell();
|
|
}
|
|
```
|
|
|
|
In the corresponding padata.c file, there's the following code:
|
|
|
|
```c
|
|
static void padata_serial_worker(struct work_struct *serial_work) {
|
|
...
|
|
cnt = 0;
|
|
|
|
while (!list_empty(&local_list)) {
|
|
...
|
|
padata->serial(padata);
|
|
cnt++;
|
|
}
|
|
|
|
local_bh_enable();
|
|
|
|
if (refcount_sub_and_test(cnt, &pd->refcnt))
|
|
padata_free_pd(pd);
|
|
}
|
|
```
|
|
|
|
Because of the high system load and the accumulation of unexecuted
|
|
softirq at this moment, `local_bh_enable()` in padata takes longer
|
|
to execute than usual. Subsequently, when accessing `pd->refcnt`,
|
|
`pd` has already been released by `padata_free_shell()`, resulting
|
|
in a UAF issue with `pd->refcnt`.
|
|
|
|
The fix is straightforward: add `refcount_dec_and_test` before calling
|
|
`padata_free_pd` in `padata_free_shell`.(CVE-2023-52854)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drivers/perf: hisi: use cpuhp_state_remove_instance_nocalls() for hisi_hns3_pmu uninit process
|
|
|
|
When tearing down a 'hisi_hns3' PMU, we mistakenly run the CPU hotplug
|
|
callbacks after the device has been unregistered, leading to fireworks
|
|
when we try to execute empty function callbacks within the driver:
|
|
|
|
| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
|
|
| CPU: 0 PID: 15 Comm: cpuhp/0 Tainted: G W O 5.12.0-rc4+ #1
|
|
| Hardware name: , BIOS KpxxxFPGA 1P B600 V143 04/22/2021
|
|
| pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--)
|
|
| pc : perf_pmu_migrate_context+0x98/0x38c
|
|
| lr : perf_pmu_migrate_context+0x94/0x38c
|
|
|
|
|
| Call trace:
|
|
| perf_pmu_migrate_context+0x98/0x38c
|
|
| hisi_hns3_pmu_offline_cpu+0x104/0x12c [hisi_hns3_pmu]
|
|
|
|
Use cpuhp_state_remove_instance_nocalls() instead of
|
|
cpuhp_state_remove_instance() so that the notifiers don't execute after
|
|
the PMU device has been unregistered.
|
|
|
|
[will: Rewrote commit message](CVE-2023-52860)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
hwmon: (axi-fan-control) Fix possible NULL pointer dereference
|
|
|
|
axi_fan_control_irq_handler(), dependent on the private
|
|
axi_fan_control_data structure, might be called before the hwmon
|
|
device is registered. That will cause an "Unable to handle kernel
|
|
NULL pointer dereference" error.(CVE-2023-52863)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/radeon: possible buffer overflow
|
|
|
|
Buffer 'afmt_status' of size 6 could overflow, since index 'afmt_idx' is
|
|
checked after access.(CVE-2023-52867)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
pstore/platform: Add check for kstrdup
|
|
|
|
Add check for the return value of kstrdup() and return the error
|
|
if it fails in order to avoid NULL pointer dereference.(CVE-2023-52869)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
clk: mediatek: clk-mt7629-eth: Add check for mtk_alloc_clk_data
|
|
|
|
Add the check for the return value of mtk_alloc_clk_data() in order to
|
|
avoid NULL pointer dereference.(CVE-2023-52876)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tracing: Have trace_event_file have ref counters
|
|
|
|
The following can crash the kernel:
|
|
|
|
# cd /sys/kernel/tracing
|
|
# echo 'p:sched schedule' > kprobe_events
|
|
# exec 5>>events/kprobes/sched/enable
|
|
# > kprobe_events
|
|
# exec 5>&-
|
|
|
|
The above commands:
|
|
|
|
1. Change directory to the tracefs directory
|
|
2. Create a kprobe event (doesn't matter what one)
|
|
3. Open bash file descriptor 5 on the enable file of the kprobe event
|
|
4. Delete the kprobe event (removes the files too)
|
|
5. Close the bash file descriptor 5
|
|
|
|
The above causes a crash!
|
|
|
|
BUG: kernel NULL pointer dereference, address: 0000000000000028
|
|
#PF: supervisor read access in kernel mode
|
|
#PF: error_code(0x0000) - not-present page
|
|
PGD 0 P4D 0
|
|
Oops: 0000 [#1] PREEMPT SMP PTI
|
|
CPU: 6 PID: 877 Comm: bash Not tainted 6.5.0-rc4-test-00008-g2c6b6b1029d4-dirty #186
|
|
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
|
|
RIP: 0010:tracing_release_file_tr+0xc/0x50
|
|
|
|
What happens here is that the kprobe event creates a trace_event_file
|
|
"file" descriptor that represents the file in tracefs to the event. It
|
|
maintains state of the event (is it enabled for the given instance?).
|
|
Opening the "enable" file gets a reference to the event "file" descriptor
|
|
via the open file descriptor. When the kprobe event is deleted, the file is
|
|
also deleted from the tracefs system which also frees the event "file"
|
|
descriptor.
|
|
|
|
But as the tracefs file is still opened by user space, it will not be
|
|
totally removed until the final dput() is called on it. But this is not
|
|
true with the event "file" descriptor that is already freed. If the user
|
|
does a write to or simply closes the file descriptor it will reference the
|
|
event "file" descriptor that was just freed, causing a use-after-free bug.
|
|
|
|
To solve this, add a ref count to the event "file" descriptor as well as a
|
|
new flag called "FREED". The "file" will not be freed until the last
|
|
reference is released. But the FREE flag will be set when the event is
|
|
removed to prevent any more modifications to that event from happening,
|
|
even if there's still a reference to the event "file" descriptor.(CVE-2023-52879)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
vfio/fsl-mc: Block calling interrupt handler without trigger
|
|
|
|
The eventfd_ctx trigger pointer of the vfio_fsl_mc_irq object is
|
|
initially NULL and may become NULL if the user sets the trigger
|
|
eventfd to -1. The interrupt handler itself is guaranteed that
|
|
trigger is always valid between request_irq() and free_irq(), but
|
|
the loopback testing mechanisms to invoke the handler function
|
|
need to test the trigger. The triggering and setting ioctl paths
|
|
both make use of igate and are therefore mutually exclusive.
|
|
|
|
The vfio-fsl-mc driver does not make use of irqfds, nor does it
|
|
support any sort of masking operations, therefore unlike vfio-pci
|
|
and vfio-platform, the flow can remain essentially unchanged.(CVE-2024-26814)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
af_unix: Fix garbage collector racing against connect()
|
|
|
|
Garbage collector does not take into account the risk of embryo getting
|
|
enqueued during the garbage collection. If such embryo has a peer that
|
|
carries SCM_RIGHTS, two consecutive passes of scan_children() may see a
|
|
different set of children. Leading to an incorrectly elevated inflight
|
|
count, and then a dangling pointer within the gc_inflight_list.
|
|
|
|
sockets are AF_UNIX/SOCK_STREAM
|
|
S is an unconnected socket
|
|
L is a listening in-flight socket bound to addr, not in fdtable
|
|
V's fd will be passed via sendmsg(), gets inflight count bumped
|
|
|
|
connect(S, addr) sendmsg(S, [V]); close(V) __unix_gc()
|
|
---------------- ------------------------- -----------
|
|
|
|
NS = unix_create1()
|
|
skb1 = sock_wmalloc(NS)
|
|
L = unix_find_other(addr)
|
|
unix_state_lock(L)
|
|
unix_peer(S) = NS
|
|
// V count=1 inflight=0
|
|
|
|
NS = unix_peer(S)
|
|
skb2 = sock_alloc()
|
|
skb_queue_tail(NS, skb2[V])
|
|
|
|
// V became in-flight
|
|
// V count=2 inflight=1
|
|
|
|
close(V)
|
|
|
|
// V count=1 inflight=1
|
|
// GC candidate condition met
|
|
|
|
for u in gc_inflight_list:
|
|
if (total_refs == inflight_refs)
|
|
add u to gc_candidates
|
|
|
|
// gc_candidates={L, V}
|
|
|
|
for u in gc_candidates:
|
|
scan_children(u, dec_inflight)
|
|
|
|
// embryo (skb1) was not
|
|
// reachable from L yet, so V's
|
|
// inflight remains unchanged
|
|
__skb_queue_tail(L, skb1)
|
|
unix_state_unlock(L)
|
|
for u in gc_candidates:
|
|
if (u.inflight)
|
|
scan_children(u, inc_inflight_move_tail)
|
|
|
|
// V count=1 inflight=2 (!)
|
|
|
|
If there is a GC-candidate listening socket, lock/unlock its state. This
|
|
makes GC wait until the end of any ongoing connect() to that socket. After
|
|
flipping the lock, a possibly SCM-laden embryo is already enqueued. And if
|
|
there is another embryo coming, it can not possibly carry SCM_RIGHTS. At
|
|
this point, unix_inflight() can not happen because unix_gc_lock is already
|
|
taken. Inflight graph remains unaffected.(CVE-2024-26923)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wireguard: netlink: access device through ctx instead of peer
|
|
|
|
The previous commit fixed a bug that led to a NULL peer->device being
|
|
dereferenced. It's actually easier and faster performance-wise to
|
|
instead get the device from ctx->wg. This semantically makes more sense
|
|
too, since ctx->wg->peer_allowedips.seq is compared with
|
|
ctx->allowedips_seq, basing them both in ctx. This also acts as a
|
|
defence in depth provision against freed peers.(CVE-2024-26950)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nfs: fix UAF in direct writes
|
|
|
|
In production we have been hitting the following warning consistently
|
|
|
|
------------[ cut here ]------------
|
|
refcount_t: underflow; use-after-free.
|
|
WARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0
|
|
Workqueue: nfsiod nfs_direct_write_schedule_work [nfs]
|
|
RIP: 0010:refcount_warn_saturate+0x9c/0xe0
|
|
PKRU: 55555554
|
|
Call Trace:
|
|
<TASK>
|
|
? __warn+0x9f/0x130
|
|
? refcount_warn_saturate+0x9c/0xe0
|
|
? report_bug+0xcc/0x150
|
|
? handle_bug+0x3d/0x70
|
|
? exc_invalid_op+0x16/0x40
|
|
? asm_exc_invalid_op+0x16/0x20
|
|
? refcount_warn_saturate+0x9c/0xe0
|
|
nfs_direct_write_schedule_work+0x237/0x250 [nfs]
|
|
process_one_work+0x12f/0x4a0
|
|
worker_thread+0x14e/0x3b0
|
|
? ZSTD_getCParams_internal+0x220/0x220
|
|
kthread+0xdc/0x120
|
|
? __btf_name_valid+0xa0/0xa0
|
|
ret_from_fork+0x1f/0x30
|
|
|
|
This is because we're completing the nfs_direct_request twice in a row.
|
|
|
|
The source of this is when we have our commit requests to submit, we
|
|
process them and send them off, and then in the completion path for the
|
|
commit requests we have
|
|
|
|
if (nfs_commit_end(cinfo.mds))
|
|
nfs_direct_write_complete(dreq);
|
|
|
|
However since we're submitting asynchronous requests we sometimes have
|
|
one that completes before we submit the next one, so we end up calling
|
|
complete on the nfs_direct_request twice.
|
|
|
|
The only other place we use nfs_generic_commit_list() is in
|
|
__nfs_commit_inode, which wraps this call in a
|
|
|
|
nfs_commit_begin();
|
|
nfs_commit_end();
|
|
|
|
Which is a common pattern for this style of completion handling, one
|
|
that is also repeated in the direct code with get_dreq()/put_dreq()
|
|
calls around where we process events as well as in the completion paths.
|
|
|
|
Fix this by using the same pattern for the commit requests.
|
|
|
|
Before with my 200 node rocksdb stress running this warning would pop
|
|
every 10ish minutes. With my patch the stress test has been running for
|
|
several hours without popping.(CVE-2024-26958)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mac802154: fix llsec key resources release in mac802154_llsec_key_del
|
|
|
|
mac802154_llsec_key_del() can free resources of a key directly without
|
|
following the RCU rules for waiting before the end of a grace period. This
|
|
may lead to use-after-free in case llsec_lookup_key() is traversing the
|
|
list of keys in parallel with a key deletion:
|
|
|
|
refcount_t: addition on 0; use-after-free.
|
|
WARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0
|
|
Modules linked in:
|
|
CPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
|
|
RIP: 0010:refcount_warn_saturate+0x162/0x2a0
|
|
Call Trace:
|
|
<TASK>
|
|
llsec_lookup_key.isra.0+0x890/0x9e0
|
|
mac802154_llsec_encrypt+0x30c/0x9c0
|
|
ieee802154_subif_start_xmit+0x24/0x1e0
|
|
dev_hard_start_xmit+0x13e/0x690
|
|
sch_direct_xmit+0x2ae/0xbc0
|
|
__dev_queue_xmit+0x11dd/0x3c20
|
|
dgram_sendmsg+0x90b/0xd60
|
|
__sys_sendto+0x466/0x4c0
|
|
__x64_sys_sendto+0xe0/0x1c0
|
|
do_syscall_64+0x45/0xf0
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
|
|
Also, ieee802154_llsec_key_entry structures are not freed by
|
|
mac802154_llsec_key_del():
|
|
|
|
unreferenced object 0xffff8880613b6980 (size 64):
|
|
comm "iwpan", pid 2176, jiffies 4294761134 (age 60.475s)
|
|
hex dump (first 32 bytes):
|
|
78 0d 8f 18 80 88 ff ff 22 01 00 00 00 00 ad de x.......".......
|
|
00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00 ................
|
|
backtrace:
|
|
[<ffffffff81dcfa62>] __kmem_cache_alloc_node+0x1e2/0x2d0
|
|
[<ffffffff81c43865>] kmalloc_trace+0x25/0xc0
|
|
[<ffffffff88968b09>] mac802154_llsec_key_add+0xac9/0xcf0
|
|
[<ffffffff8896e41a>] ieee802154_add_llsec_key+0x5a/0x80
|
|
[<ffffffff8892adc6>] nl802154_add_llsec_key+0x426/0x5b0
|
|
[<ffffffff86ff293e>] genl_family_rcv_msg_doit+0x1fe/0x2f0
|
|
[<ffffffff86ff46d1>] genl_rcv_msg+0x531/0x7d0
|
|
[<ffffffff86fee7a9>] netlink_rcv_skb+0x169/0x440
|
|
[<ffffffff86ff1d88>] genl_rcv+0x28/0x40
|
|
[<ffffffff86fec15c>] netlink_unicast+0x53c/0x820
|
|
[<ffffffff86fecd8b>] netlink_sendmsg+0x93b/0xe60
|
|
[<ffffffff86b91b35>] ____sys_sendmsg+0xac5/0xca0
|
|
[<ffffffff86b9c3dd>] ___sys_sendmsg+0x11d/0x1c0
|
|
[<ffffffff86b9c65a>] __sys_sendmsg+0xfa/0x1d0
|
|
[<ffffffff88eadbf5>] do_syscall_64+0x45/0xf0
|
|
[<ffffffff890000ea>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
|
|
Handle the proper resource release in the RCU callback function
|
|
mac802154_llsec_key_del_rcu().
|
|
|
|
Note that if llsec_lookup_key() finds a key, it gets a refcount via
|
|
llsec_key_get() and locally copies key id from key_entry (which is a
|
|
list element). So it's safe to call llsec_key_put() and free the list
|
|
entry after the RCU grace period elapses.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org).(CVE-2024-26961)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
clk: qcom: mmcc-msm8974: fix terminating of frequency table arrays
|
|
|
|
The frequency table arrays are supposed to be terminated with an
|
|
empty element. Add such entry to the end of the arrays where it
|
|
is missing in order to avoid possible out-of-bound access when
|
|
the table is traversed by functions like qcom_find_freq() or
|
|
qcom_find_freq_floor().
|
|
|
|
Only compile tested.(CVE-2024-26965)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path
|
|
|
|
For error handling path in ubifs_symlink(), inode will be marked as
|
|
bad first, then iput() is invoked. If inode->i_link is initialized by
|
|
fscrypt_encrypt_symlink() in encryption scenario, inode->i_link won't
|
|
be freed by callchain ubifs_free_inode -> fscrypt_free_inode in error
|
|
handling path, because make_bad_inode() has changed 'inode->i_mode' as
|
|
'S_IFREG'.
|
|
Following kmemleak is easy to be reproduced by injecting error in
|
|
ubifs_jnl_update() when doing symlink in encryption scenario:
|
|
unreferenced object 0xffff888103da3d98 (size 8):
|
|
comm "ln", pid 1692, jiffies 4294914701 (age 12.045s)
|
|
backtrace:
|
|
kmemdup+0x32/0x70
|
|
__fscrypt_encrypt_symlink+0xed/0x1c0
|
|
ubifs_symlink+0x210/0x300 [ubifs]
|
|
vfs_symlink+0x216/0x360
|
|
do_symlinkat+0x11a/0x190
|
|
do_syscall_64+0x3b/0xe0
|
|
There are two ways fixing it:
|
|
1. Remove make_bad_inode() in error handling path. We can do that
|
|
because ubifs_evict_inode() will do same processes for good
|
|
symlink inode and bad symlink inode, for inode->i_nlink checking
|
|
is before is_bad_inode().
|
|
2. Free inode->i_link before marking inode bad.
|
|
Method 2 is picked, it has less influence, personally, I think.(CVE-2024-26972)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
KVM: Always flush async #PF workqueue when vCPU is being destroyed
|
|
|
|
Always flush the per-vCPU async #PF workqueue when a vCPU is clearing its
|
|
completion queue, e.g. when a VM and all its vCPUs is being destroyed.
|
|
KVM must ensure that none of its workqueue callbacks is running when the
|
|
last reference to the KVM _module_ is put. Gifting a reference to the
|
|
associated VM prevents the workqueue callback from dereferencing freed
|
|
vCPU/VM memory, but does not prevent the KVM module from being unloaded
|
|
before the callback completes.
|
|
|
|
Drop the misguided VM refcount gifting, as calling kvm_put_kvm() from
|
|
async_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will
|
|
result in deadlock. async_pf_execute() can't return until kvm_put_kvm()
|
|
finishes, and kvm_put_kvm() can't return until async_pf_execute() finishes:
|
|
|
|
WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm]
|
|
Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass
|
|
CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119
|
|
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
|
|
Workqueue: events async_pf_execute [kvm]
|
|
RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm]
|
|
Call Trace:
|
|
<TASK>
|
|
async_pf_execute+0x198/0x260 [kvm]
|
|
process_one_work+0x145/0x2d0
|
|
worker_thread+0x27e/0x3a0
|
|
kthread+0xba/0xe0
|
|
ret_from_fork+0x2d/0x50
|
|
ret_from_fork_asm+0x11/0x20
|
|
</TASK>
|
|
---[ end trace 0000000000000000 ]---
|
|
INFO: task kworker/8:1:251 blocked for more than 120 seconds.
|
|
Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119
|
|
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
|
|
task:kworker/8:1 state:D stack:0 pid:251 ppid:2 flags:0x00004000
|
|
Workqueue: events async_pf_execute [kvm]
|
|
Call Trace:
|
|
<TASK>
|
|
__schedule+0x33f/0xa40
|
|
schedule+0x53/0xc0
|
|
schedule_timeout+0x12a/0x140
|
|
__wait_for_common+0x8d/0x1d0
|
|
__flush_work.isra.0+0x19f/0x2c0
|
|
kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm]
|
|
kvm_arch_destroy_vm+0x78/0x1b0 [kvm]
|
|
kvm_put_kvm+0x1c1/0x320 [kvm]
|
|
async_pf_execute+0x198/0x260 [kvm]
|
|
process_one_work+0x145/0x2d0
|
|
worker_thread+0x27e/0x3a0
|
|
kthread+0xba/0xe0
|
|
ret_from_fork+0x2d/0x50
|
|
ret_from_fork_asm+0x11/0x20
|
|
</TASK>
|
|
|
|
If kvm_clear_async_pf_completion_queue() actually flushes the workqueue,
|
|
then there's no need to gift async_pf_execute() a reference because all
|
|
invocations of async_pf_execute() will be forced to complete before the
|
|
vCPU and its VM are destroyed/freed. And that in turn fixes the module
|
|
unloading bug as __fput() won't do module_put() on the last vCPU reference
|
|
until the vCPU has been freed, e.g. if closing the vCPU file also puts the
|
|
last reference to the KVM module.
|
|
|
|
Note that kvm_check_async_pf_completion() may also take the work item off
|
|
the completion queue and so also needs to flush the work queue, as the
|
|
work will not be seen by kvm_clear_async_pf_completion_queue(). Waiting
|
|
on the workqueue could theoretically delay a vCPU due to waiting for the
|
|
work to complete, but that's a very, very small chance, and likely a very
|
|
small delay. kvm_arch_async_page_present_queued() unconditionally makes a
|
|
new request, i.e. will effectively delay entering the guest, so the
|
|
remaining work is really just:
|
|
|
|
trace_kvm_async_pf_completed(addr, cr2_or_gpa);
|
|
|
|
__kvm_vcpu_wake_up(vcpu);
|
|
|
|
mmput(mm);
|
|
|
|
and mmput() can't drop the last reference to the page tables if the vCPU is
|
|
still alive, i.e. the vCPU won't get stuck tearing down page tables.
|
|
|
|
Add a helper to do the flushing, specifically to deal with "wakeup all"
|
|
work items, as they aren't actually work items, i.e. are never placed in a
|
|
workqueue. Trying to flush a bogus workqueue entry rightly makes
|
|
__flush_work() complain (kudos to whoever added that sanity check).
|
|
|
|
Note, commit 5f6de5cbebee ("KVM: Prevent module exit until al
|
|
---truncated---(CVE-2024-26976)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Squashfs: check the inode number is not the invalid value of zero
|
|
|
|
Syskiller has produced an out of bounds access in fill_meta_index().
|
|
|
|
That out of bounds access is ultimately caused because the inode
|
|
has an inode number with the invalid value of zero, which was not checked.
|
|
|
|
The reason this causes the out of bounds access is due to following
|
|
sequence of events:
|
|
|
|
1. Fill_meta_index() is called to allocate (via empty_meta_index())
|
|
and fill a metadata index. It however suffers a data read error
|
|
and aborts, invalidating the newly returned empty metadata index.
|
|
It does this by setting the inode number of the index to zero,
|
|
which means unused (zero is not a valid inode number).
|
|
|
|
2. When fill_meta_index() is subsequently called again on another
|
|
read operation, locate_meta_index() returns the previous index
|
|
because it matches the inode number of 0. Because this index
|
|
has been returned it is expected to have been filled, and because
|
|
it hasn't been, an out of bounds access is performed.
|
|
|
|
This patch adds a sanity check which checks that the inode number
|
|
is not zero when the inode is created and returns -EINVAL if it is.
|
|
|
|
[phillip@squashfs.org.uk: whitespace fix]
|
|
Link: https://lkml.kernel.org/r/20240409204723.446925-1-phillip@squashfs.org.uk(CVE-2024-26982)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fs: sysfs: Fix reference leak in sysfs_break_active_protection()
|
|
|
|
The sysfs_break_active_protection() routine has an obvious reference
|
|
leak in its error path. If the call to kernfs_find_and_get() fails then
|
|
kn will be NULL, so the companion sysfs_unbreak_active_protection()
|
|
routine won't get called (and would only cause an access violation by
|
|
trying to dereference kn->parent if it was called). As a result, the
|
|
reference to kobj acquired at the start of the function will never be
|
|
released.
|
|
|
|
Fix the leak by adding an explicit kobject_put() call when kn is NULL.(CVE-2024-26993)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
serial: mxs-auart: add spinlock around changing cts state
|
|
|
|
The uart_handle_cts_change() function in serial_core expects the caller
|
|
to hold uport->lock. For example, I have seen the below kernel splat,
|
|
when the Bluetooth driver is loaded on an i.MX28 board.
|
|
|
|
[ 85.119255] ------------[ cut here ]------------
|
|
[ 85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec
|
|
[ 85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs
|
|
[ 85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1
|
|
[ 85.151396] Hardware name: Freescale MXS (Device Tree)
|
|
[ 85.156679] Workqueue: hci0 hci_power_on [bluetooth]
|
|
(...)
|
|
[ 85.191765] uart_handle_cts_change from mxs_auart_irq_handle+0x380/0x3f4
|
|
[ 85.198787] mxs_auart_irq_handle from __handle_irq_event_percpu+0x88/0x210
|
|
(...)(CVE-2024-27000)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm: nv04: Fix out of bounds access
|
|
|
|
When Output Resource (dcb->or) value is assigned in
|
|
fabricate_dcb_output(), there may be out of bounds access to
|
|
dac_users array in case dcb->or is zero because ffs(dcb->or) is
|
|
used as index there.
|
|
The 'or' argument of fabricate_dcb_output() must be interpreted as a
|
|
number of bit to set, not value.
|
|
|
|
Utilize macros from 'enum nouveau_or' in calls instead of hardcoding.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-27008)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amd/display: Fix a potential buffer overflow in 'dp_dsc_clock_en_read()'
|
|
|
|
Tell snprintf() to store at most 10 bytes in the output buffer
|
|
instead of 30.
|
|
|
|
Fixes the below:
|
|
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:1508 dp_dsc_clock_en_read() error: snprintf() is printing too much 30 vs 10(CVE-2024-27045)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
USB: usb-storage: Prevent divide-by-0 error in isd200_ata_command
|
|
|
|
The isd200 sub-driver in usb-storage uses the HEADS and SECTORS values
|
|
in the ATA ID information to calculate cylinder and head values when
|
|
creating a CDB for READ or WRITE commands. The calculation involves
|
|
division and modulus operations, which will cause a crash if either of
|
|
these values is 0. While this never happens with a genuine device, it
|
|
could happen with a flawed or subversive emulation, as reported by the
|
|
syzbot fuzzer.
|
|
|
|
Protect against this possibility by refusing to bind to the device if
|
|
either the ATA_ID_HEADS or ATA_ID_SECTORS value in the device's ID
|
|
information is 0. This requires isd200_Initialization() to return a
|
|
negative error code when initialization fails; currently it always
|
|
returns 0 (even when there is an error).(CVE-2024-27059)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: usbtv: Remove useless locks in usbtv_video_free()
|
|
|
|
Remove locks calls in usbtv_video_free() because
|
|
are useless and may led to a deadlock as reported here:
|
|
https://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000
|
|
Also remove usbtv_stop() call since it will be called when
|
|
unregistering the device.
|
|
|
|
Before 'c838530d230b' this issue would only be noticed if you
|
|
disconnect while streaming and now it is noticeable even when
|
|
disconnecting while not streaming.
|
|
|
|
|
|
[hverkuil: fix minor spelling mistake in log message](CVE-2024-27072)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: ttpci: fix two memleaks in budget_av_attach
|
|
|
|
When saa7146_register_device and saa7146_vv_init fails, budget_av_attach
|
|
should free the resources it allocates, like the error-handling of
|
|
ttpci_budget_init does. Besides, there are two fixme comment refers to
|
|
such deallocations.(CVE-2024-27073)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: dvb-frontends: avoid stack overflow warnings with clang
|
|
|
|
A previous patch worked around a KASAN issue in stv0367, now a similar
|
|
problem showed up with clang:
|
|
|
|
drivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size (3624) exceeds limit (2048) in 'stv0367ter_set_frontend' [-Werror,-Wframe-larger-than]
|
|
1214 | static int stv0367ter_set_frontend(struct dvb_frontend *fe)
|
|
|
|
Rework the stv0367_writereg() function to be simpler and mark both
|
|
register access functions as noinline_for_stack so the temporary
|
|
i2c_msg structures do not get duplicated on the stack when KASAN_STACK
|
|
is enabled.(CVE-2024-27075)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
pstore: inode: Only d_invalidate() is needed
|
|
|
|
Unloading a modular pstore backend with records in pstorefs would
|
|
trigger the dput() double-drop warning:
|
|
|
|
WARNING: CPU: 0 PID: 2569 at fs/dcache.c:762 dput.part.0+0x3f3/0x410
|
|
|
|
Using the combo of d_drop()/dput() (as mentioned in
|
|
Documentation/filesystems/vfs.rst) isn't the right approach here, and
|
|
leads to the reference counting problem seen above. Use d_invalidate()
|
|
and update the code to not bother checking for error codes that can
|
|
never happen.
|
|
|
|
---(CVE-2024-27389)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fs/ntfs3: Fixed overflow check in mi_enum_attr()(CVE-2024-27407)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netrom: Fix data-races around sysctl_net_busy_read
|
|
|
|
We need to protect the reader reading the sysctl value because the
|
|
value can be changed concurrently.(CVE-2024-27419)
|
|
|
|
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27426)
|
|
|
|
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27427)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
KVM: SVM: Flush pages under kvm->lock to fix UAF in svm_register_enc_region()
|
|
|
|
Do the cache flush of converted pages in svm_register_enc_region() before
|
|
dropping kvm->lock to fix use-after-free issues where region and/or its
|
|
array of pages could be freed by a different task, e.g. if userspace has
|
|
__unregister_enc_region_locked() already queued up for the region.
|
|
|
|
Note, the "obvious" alternative of using local variables doesn't fully
|
|
resolve the bug, as region->pages is also dynamically allocated. I.e. the
|
|
region structure itself would be fine, but region->pages could be freed.
|
|
|
|
Flushing multiple pages under kvm->lock is unfortunate, but the entire
|
|
flow is a rare slow path, and the manual flush is only needed on CPUs that
|
|
lack coherency for encrypted memory.(CVE-2024-35791)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
x86/fpu: Keep xfd_state in sync with MSR_IA32_XFD
|
|
Commit 672365477ae8 ("x86/fpu: Update XFD state where required") and
|
|
commit 8bf26758ca96 ("x86/fpu: Add XFD state to fpstate") introduced a
|
|
per CPU variable xfd_state to keep the MSR_IA32_XFD value cached, in
|
|
order to avoid unnecessary writes to the MSR.
|
|
On CPU hotplug MSR_IA32_XFD is reset to the init_fpstate.xfd, which
|
|
wipes out any stale state. But the per CPU cached xfd value is not
|
|
reset, which brings them out of sync.
|
|
As a consequence a subsequent xfd_update_state() might fail to update
|
|
the MSR which in turn can result in XRSTOR raising a #NM in kernel
|
|
space, which crashes the kernel.
|
|
To fix this, introduce xfd_set_state() to write xfd_state together
|
|
with MSR_IA32_XFD, and use it in all places that set MSR_IA32_XFD.(CVE-2024-35801)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
dm snapshot: fix lockup in dm_exception_table_exit
|
|
|
|
There was reported lockup when we exit a snapshot with many exceptions.
|
|
Fix this by adding "cond_resched" to the loop that frees the exceptions.(CVE-2024-35805)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
soc: fsl: qbman: Always disable interrupts when taking cgr_lock
|
|
|
|
smp_call_function_single disables IRQs when executing the callback. To
|
|
prevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere.
|
|
This is already done by qman_update_cgr and qman_delete_cgr; fix the
|
|
other lockers.(CVE-2024-35806)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
LoongArch: Define the __io_aw() hook as mmiowb()
|
|
|
|
Commit fb24ea52f78e0d595852e ("drivers: Remove explicit invocations of
|
|
mmiowb()") remove all mmiowb() in drivers, but it says:
|
|
|
|
"NOTE: mmiowb() has only ever guaranteed ordering in conjunction with
|
|
spin_unlock(). However, pairing each mmiowb() removal in this patch with
|
|
the corresponding call to spin_unlock() is not at all trivial, so there
|
|
is a small chance that this change may regress any drivers incorrectly
|
|
relying on mmiowb() to order MMIO writes between CPUs using lock-free
|
|
synchronisation."
|
|
|
|
The mmio in radeon_ring_commit() is protected by a mutex rather than a
|
|
spinlock, but in the mutex fastpath it behaves similar to spinlock. We
|
|
can add mmiowb() calls in the radeon driver but the maintainer says he
|
|
doesn't like such a workaround, and radeon is not the only example of
|
|
mutex protected mmio.
|
|
|
|
So we should extend the mmiowb tracking system from spinlock to mutex,
|
|
and maybe other locking primitives. This is not easy and error prone, so
|
|
we solve it in the architectural code, by simply defining the __io_aw()
|
|
hook as mmiowb(). And we no longer need to override queued_spin_unlock()
|
|
so use the generic definition.
|
|
|
|
Without this, we get such an error when run 'glxgears' on weak ordering
|
|
architectures such as LoongArch:
|
|
|
|
radeon 0000:04:00.0: ring 0 stalled for more than 10324msec
|
|
radeon 0000:04:00.0: ring 3 stalled for more than 10240msec
|
|
radeon 0000:04:00.0: GPU lockup (current fence id 0x000000000001f412 last fence id 0x000000000001f414 on ring 3)
|
|
radeon 0000:04:00.0: GPU lockup (current fence id 0x000000000000f940 last fence id 0x000000000000f941 on ring 0)
|
|
radeon 0000:04:00.0: scheduling IB failed (-35).
|
|
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
|
|
radeon 0000:04:00.0: scheduling IB failed (-35).
|
|
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
|
|
radeon 0000:04:00.0: scheduling IB failed (-35).
|
|
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
|
|
radeon 0000:04:00.0: scheduling IB failed (-35).
|
|
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
|
|
radeon 0000:04:00.0: scheduling IB failed (-35).
|
|
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
|
|
radeon 0000:04:00.0: scheduling IB failed (-35).
|
|
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
|
|
radeon 0000:04:00.0: scheduling IB failed (-35).
|
|
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)(CVE-2024-35818)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/mlx5e: fix a double-free in arfs_create_groups
|
|
|
|
When `in` allocated by kvzalloc fails, arfs_create_groups will free
|
|
ft->g and return an error. However, arfs_create_table, the only caller of
|
|
arfs_create_groups, will hold this error and call to
|
|
mlx5e_destroy_flow_table, in which the ft->g will be freed again.(CVE-2024-35835)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
f2fs: compress: fix reserve_cblocks counting error when out of space
|
|
|
|
When a file only needs one direct_node, performing the following
|
|
operations will cause the file to be unrepairable:
|
|
|
|
unisoc # ./f2fs_io compress test.apk
|
|
unisoc #df -h | grep dm-48
|
|
/dev/block/dm-48 112G 112G 1.2M 100% /data
|
|
|
|
unisoc # ./f2fs_io release_cblocks test.apk
|
|
924
|
|
unisoc # df -h | grep dm-48
|
|
/dev/block/dm-48 112G 112G 4.8M 100% /data
|
|
|
|
unisoc # dd if=/dev/random of=file4 bs=1M count=3
|
|
3145728 bytes (3.0 M) copied, 0.025 s, 120 M/s
|
|
unisoc # df -h | grep dm-48
|
|
/dev/block/dm-48 112G 112G 1.8M 100% /data
|
|
|
|
unisoc # ./f2fs_io reserve_cblocks test.apk
|
|
F2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device
|
|
|
|
adb reboot
|
|
unisoc # df -h | grep dm-48
|
|
/dev/block/dm-48 112G 112G 11M 100% /data
|
|
unisoc # ./f2fs_io reserve_cblocks test.apk
|
|
0
|
|
|
|
This is because the file has only one direct_node. After returning
|
|
to -ENOSPC, reserved_blocks += ret will not be executed. As a result,
|
|
the reserved_blocks at this time is still 0, which is not the real
|
|
number of reserved blocks. Therefore, fsck cannot be set to repair
|
|
the file.
|
|
|
|
After this patch, the fsck flag will be set to fix this problem.
|
|
|
|
unisoc # df -h | grep dm-48
|
|
/dev/block/dm-48 112G 112G 1.8M 100% /data
|
|
unisoc # ./f2fs_io reserve_cblocks test.apk
|
|
F2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device
|
|
|
|
adb reboot then fsck will be executed
|
|
unisoc # df -h | grep dm-48
|
|
/dev/block/dm-48 112G 112G 11M 100% /data
|
|
unisoc # ./f2fs_io reserve_cblocks test.apk
|
|
924(CVE-2024-35844)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: iwlwifi: dbg-tlv: ensure NUL termination
|
|
|
|
The iwl_fw_ini_debug_info_tlv is used as a string, so we must
|
|
ensure the string is terminated correctly before using it.(CVE-2024-35845)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
eeprom: at24: fix memory corruption race condition
|
|
|
|
If the eeprom is not accessible, an nvmem device will be registered, the
|
|
read will fail, and the device will be torn down. If another driver
|
|
accesses the nvmem device after the teardown, it will reference
|
|
invalid memory.
|
|
|
|
Move the failure point before registering the nvmem device.(CVE-2024-35848)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get()
|
|
|
|
nft_unregister_flowtable_type() within nf_flow_inet_module_exit() can
|
|
concurrent with __nft_flowtable_type_get() within nf_tables_newflowtable().
|
|
And thhere is not any protection when iterate over nf_tables_flowtables
|
|
list in __nft_flowtable_type_get(). Therefore, there is pertential
|
|
data-race of nf_tables_flowtables list entry.
|
|
|
|
Use list_for_each_entry_rcu() to iterate over nf_tables_flowtables list
|
|
in __nft_flowtable_type_get(), and use rcu_read_lock() in the caller
|
|
nft_flowtable_type_get() to protect the entire type query process.(CVE-2024-35898)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fbmon: prevent division by zero in fb_videomode_from_videomode()
|
|
|
|
The expression htotal * vtotal can have a zero value on
|
|
overflow. It is necessary to prevent division by zero like in
|
|
fb_var_to_videomode().
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-35922)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()
|
|
|
|
The call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an
|
|
unsuccessful status. In such cases, the elsiocb is not issued, the
|
|
completion is not called, and thus the elsiocb resource is leaked.
|
|
|
|
Check return value after calling lpfc_sli4_resume_rpi() and conditionally
|
|
release the elsiocb resource.(CVE-2024-35930)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()
|
|
|
|
The unhandled case in btrfs_relocate_sys_chunks() loop is a corruption,
|
|
as it could be caused only by two impossible conditions:
|
|
|
|
- at first the search key is set up to look for a chunk tree item, with
|
|
offset -1, this is an inexact search and the key->offset will contain
|
|
the correct offset upon a successful search, a valid chunk tree item
|
|
cannot have an offset -1
|
|
|
|
- after first successful search, the found_key corresponds to a chunk
|
|
item, the offset is decremented by 1 before the next loop, it's
|
|
impossible to find a chunk item there due to alignment and size
|
|
constraints(CVE-2024-35936)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
pstore/zone: Add a null pointer check to the psz_kmsg_read
|
|
|
|
kasprintf() returns a pointer to dynamically allocated memory
|
|
which can be NULL upon failure. Ensure the allocation was successful
|
|
by checking the pointer validity.(CVE-2024-35940)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
xsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING
|
|
|
|
syzbot reported an illegal copy in xsk_setsockopt() [1]
|
|
|
|
Make sure to validate setsockopt() @optlen parameter.
|
|
|
|
[1]
|
|
|
|
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
|
|
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]
|
|
BUG: KASAN: slab-out-of-bounds in xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420
|
|
Read of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549
|
|
|
|
CPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
|
|
print_address_description mm/kasan/report.c:377 [inline]
|
|
print_report+0x169/0x550 mm/kasan/report.c:488
|
|
kasan_report+0x143/0x180 mm/kasan/report.c:601
|
|
copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
|
|
copy_from_sockptr include/linux/sockptr.h:55 [inline]
|
|
xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420
|
|
do_sock_setsockopt+0x3af/0x720 net/socket.c:2311
|
|
__sys_setsockopt+0x1ae/0x250 net/socket.c:2334
|
|
__do_sys_setsockopt net/socket.c:2343 [inline]
|
|
__se_sys_setsockopt net/socket.c:2340 [inline]
|
|
__x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
|
|
do_syscall_64+0xfb/0x240
|
|
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
|
RIP: 0033:0x7fb40587de69
|
|
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
|
|
RSP: 002b:00007fb40665a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
|
|
RAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69
|
|
RDX: 0000000000000005 RSI: 000000000000011b RDI: 0000000000000006
|
|
RBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000
|
|
R10: 0000000020001980 R11: 0000000000000246 R12: 0000000000000000
|
|
R13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08
|
|
</TASK>
|
|
|
|
Allocated by task 7549:
|
|
kasan_save_stack mm/kasan/common.c:47 [inline]
|
|
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
|
|
poison_kmalloc_redzone mm/kasan/common.c:370 [inline]
|
|
__kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387
|
|
kasan_kmalloc include/linux/kasan.h:211 [inline]
|
|
__do_kmalloc_node mm/slub.c:3966 [inline]
|
|
__kmalloc+0x233/0x4a0 mm/slub.c:3979
|
|
kmalloc include/linux/slab.h:632 [inline]
|
|
__cgroup_bpf_run_filter_setsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869
|
|
do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293
|
|
__sys_setsockopt+0x1ae/0x250 net/socket.c:2334
|
|
__do_sys_setsockopt net/socket.c:2343 [inline]
|
|
__se_sys_setsockopt net/socket.c:2340 [inline]
|
|
__x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
|
|
do_syscall_64+0xfb/0x240
|
|
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
|
|
|
The buggy address belongs to the object at ffff888028c6cde0
|
|
which belongs to the cache kmalloc-8 of size 8
|
|
The buggy address is located 1 bytes to the right of
|
|
allocated 2-byte region [ffff888028c6cde0, ffff888028c6cde2)
|
|
|
|
The buggy address belongs to the physical page:
|
|
page:ffffea0000a31b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888028c6c9c0 pfn:0x28c6c
|
|
anon flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff)
|
|
page_type: 0xffffffff()
|
|
raw: 00fff00000000800 ffff888014c41280 0000000000000000 dead000000000001
|
|
raw: ffff888028c6c9c0 0000000080800057 00000001ffffffff 0000000000000000
|
|
page dumped because: kasan: bad access detected
|
|
page_owner tracks the page as allocated
|
|
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 6648, tgid 6644 (syz-executor.0), ts 133906047828, free_ts 133859922223
|
|
set_page_owner include/linux/page_owner.h:31 [inline]
|
|
post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533
|
|
prep_new_page mm/page_alloc.c:
|
|
---truncated---(CVE-2024-35976)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up
|
|
|
|
The flag I2C_HID_READ_PENDING is used to serialize I2C operations.
|
|
However, this is not necessary, because I2C core already has its own
|
|
locking for that.
|
|
|
|
More importantly, this flag can cause a lock-up: if the flag is set in
|
|
i2c_hid_xfer() and an interrupt happens, the interrupt handler
|
|
(i2c_hid_irq) will check this flag and return immediately without doing
|
|
anything, then the interrupt handler will be invoked again in an
|
|
infinite loop.
|
|
|
|
Since interrupt handler is an RT task, it takes over the CPU and the
|
|
flag-clearing task never gets scheduled, thus we have a lock-up.
|
|
|
|
Delete this unnecessary flag.(CVE-2024-35997)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mlxsw: spectrum_acl_tcam: Fix incorrect list API usage
|
|
|
|
Both the function that migrates all the chunks within a region and the
|
|
function that migrates all the entries within a chunk call
|
|
list_first_entry() on the respective lists without checking that the
|
|
lists are not empty. This is incorrect usage of the API, which leads to
|
|
the following warning [1].
|
|
|
|
Fix by returning if the lists are empty as there is nothing to migrate
|
|
in this case.
|
|
|
|
[1]
|
|
WARNING: CPU: 0 PID: 6437 at drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c:1266 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0>
|
|
Modules linked in:
|
|
CPU: 0 PID: 6437 Comm: kworker/0:37 Not tainted 6.9.0-rc3-custom-00883-g94a65f079ef6 #39
|
|
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
|
|
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
|
|
RIP: 0010:mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0x2c0
|
|
[...]
|
|
Call Trace:
|
|
<TASK>
|
|
mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x4a0
|
|
process_one_work+0x151/0x370
|
|
worker_thread+0x2cb/0x3e0
|
|
kthread+0xd0/0x100
|
|
ret_from_fork+0x34/0x50
|
|
ret_from_fork_asm+0x1a/0x30
|
|
</TASK>(CVE-2024-36006)</Note>
|
|
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP1.
|
|
|
|
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-1680</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47421</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47455</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2022-48641</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-52650</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52656</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52664</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52683</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52698</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-52813</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52817</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52835</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52837</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52840</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52844</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52847</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52854</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52860</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52863</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52867</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52869</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52876</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52879</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26814</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26923</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26950</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26958</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26961</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26965</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26972</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26976</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26982</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26993</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27000</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27008</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27045</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27059</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27072</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27073</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27075</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27389</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27407</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27419</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27426</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27427</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35791</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35801</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35805</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35806</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35818</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35835</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35844</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35845</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35848</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35898</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35922</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35930</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35936</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35940</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35976</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35997</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36006</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47421</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47455</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48641</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48708</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52650</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52656</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52664</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52683</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52698</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52809</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52813</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52817</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52835</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52837</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52840</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52844</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52847</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52854</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52860</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52863</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52867</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52869</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52876</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52879</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26814</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26923</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26950</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26958</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26961</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26965</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26972</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26976</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26982</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26993</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27000</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27008</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27045</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27059</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27072</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27073</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27075</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27389</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27407</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27419</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27426</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27427</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35791</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35801</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35805</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35806</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35818</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35835</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35844</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35845</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35848</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35898</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35922</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35930</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35936</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35940</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35976</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35997</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36006</URL>
|
|
</Reference>
|
|
</DocumentReferences>
|
|
<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
|
|
<Branch Type="Product Name" Name="openEuler">
|
|
<FullProductName ProductID="openEuler-22.03-LTS-SP1" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">openEuler-22.03-LTS-SP1</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-136.77.0.157" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-debuginfo-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-136.77.0.157" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-debuginfo-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-136.77.0.157" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-devel-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-136.77.0.157" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-136.77.0.157" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-headers-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-5.10.0-136.77.0.157" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-136.77.0.157" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debuginfo-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-136.77.0.157" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-devel-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-136.77.0.157" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-136.77.0.157" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-source-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-136.77.0.157" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-debuginfo-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-136.77.0.157" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debugsource-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-136.77.0.157" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-5.10.0-136.77.0.157" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-5.10.0-136.77.0.157.oe2203sp1.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="kernel-5.10.0-136.77.0.157" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-136.77.0.157" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-source-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-136.77.0.157" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-136.77.0.157" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debuginfo-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-136.77.0.157" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-headers-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-136.77.0.157" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-136.77.0.157" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-debuginfo-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-136.77.0.157" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-devel-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-136.77.0.157" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-debuginfo-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-136.77.0.157" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-136.77.0.157" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-devel-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-136.77.0.157" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-debuginfo-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-136.77.0.157" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debugsource-5.10.0-136.77.0.157.oe2203sp1.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:
|
|
|
|
drm/amdgpu: handle the case of pci_channel_io_frozen only in amdgpu_pci_resume
|
|
|
|
In current code, when a PCI error state pci_channel_io_normal is detectd,
|
|
it will report PCI_ERS_RESULT_CAN_RECOVER status to PCI driver, and PCI
|
|
driver will continue the execution of PCI resume callback report_resume by
|
|
pci_walk_bridge, and the callback will go into amdgpu_pci_resume
|
|
finally, where write lock is releasd unconditionally without acquiring
|
|
such lock first. In this case, a deadlock will happen when other threads
|
|
start to acquire the read lock.
|
|
|
|
To fix this, add a member in amdgpu_device strucutre to cache
|
|
pci_channel_state, and only continue the execution in amdgpu_pci_resume
|
|
when it's pci_channel_io_frozen.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2021-47421</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
ptp: Fix possible memory leak in ptp_clock_register()
|
|
|
|
I got memory leak as follows when doing fault injection test:
|
|
|
|
unreferenced object 0xffff88800906c618 (size 8):
|
|
comm "i2c-idt82p33931", pid 4421, jiffies 4294948083 (age 13.188s)
|
|
hex dump (first 8 bytes):
|
|
70 74 70 30 00 00 00 00 ptp0....
|
|
backtrace:
|
|
[<00000000312ed458>] __kmalloc_track_caller+0x19f/0x3a0
|
|
[<0000000079f6e2ff>] kvasprintf+0xb5/0x150
|
|
[<0000000026aae54f>] kvasprintf_const+0x60/0x190
|
|
[<00000000f323a5f7>] kobject_set_name_vargs+0x56/0x150
|
|
[<000000004e35abdd>] dev_set_name+0xc0/0x100
|
|
[<00000000f20cfe25>] ptp_clock_register+0x9f4/0xd30 [ptp]
|
|
[<000000008bb9f0de>] idt82p33_probe.cold+0x8b6/0x1561 [ptp_idt82p33]
|
|
|
|
When posix_clock_register() returns an error, the name allocated
|
|
in dev_set_name() will be leaked, the put_device() should be used
|
|
to give up the device reference, then the name will be freed in
|
|
kobject_cleanup() and other memory will be freed in ptp_clock_release().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2021-47455</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
netfilter: ebtables: fix memory leak when blob is malformed
|
|
|
|
The bug fix was incomplete, it "replaced" crash with a memory leak.
|
|
The old code had an assignment to "ret" embedded into the conditional,
|
|
restore this.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2022-48641</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
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-05-31</ReleaseDate>
|
|
<CVE>CVE-2022-48708</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
drm/tegra: dsi: Add missing check for of_find_device_by_node
|
|
|
|
Add check for the return value of of_find_device_by_node() and return
|
|
the error if it fails in order to avoid NULL pointer dereference.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52650</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
io_uring: drop any code related to SCM_RIGHTS
|
|
|
|
This is dead code after we dropped support for passing io_uring fds
|
|
over SCM_RIGHTS, get rid of it.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52656</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
net: atlantic: eliminate double free in error handling logic
|
|
|
|
Driver has a logic leak in ring data allocation/free,
|
|
where aq_ring_free could be called multiple times on same ring,
|
|
if system is under stress and got memory allocation error.
|
|
|
|
Ring pointer was used as an indicator of failure, but this is
|
|
not correct since only ring data is allocated/deallocated.
|
|
Ring itself is an array member.
|
|
|
|
Changing ring allocation functions to return error code directly.
|
|
This simplifies error handling and eliminates aq_ring_free
|
|
on higher layer.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52664</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
ACPI: LPIT: Avoid u32 multiplication overflow
|
|
|
|
In lpit_update_residency() there is a possibility of overflow
|
|
in multiplication, if tsc_khz is large enough (> UINT_MAX/1000).
|
|
|
|
Change multiplication to mul_u32_u32().
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52683</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
calipso: fix memory leak in netlbl_calipso_add_pass()
|
|
|
|
If IPv6 support is disabled at boot (ipv6.disable=1),
|
|
the calipso_init() -> netlbl_calipso_ops_register() function isn't called,
|
|
and the netlbl_calipso_ops_get() function always returns NULL.
|
|
In this case, the netlbl_calipso_add_pass() function allocates memory
|
|
for the doi_def variable but doesn't free it with the calipso_doi_free().
|
|
|
|
BUG: memory leak
|
|
unreferenced object 0xffff888011d68180 (size 64):
|
|
comm "syz-executor.1", pid 10746, jiffies 4295410986 (age 17.928s)
|
|
hex dump (first 32 bytes):
|
|
00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
backtrace:
|
|
[<...>] kmalloc include/linux/slab.h:552 [inline]
|
|
[<...>] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [inline]
|
|
[<...>] netlbl_calipso_add+0x22e/0x4f0 net/netlabel/netlabel_calipso.c:111
|
|
[<...>] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739
|
|
[<...>] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]
|
|
[<...>] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800
|
|
[<...>] netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2515
|
|
[<...>] genl_rcv+0x29/0x40 net/netlink/genetlink.c:811
|
|
[<...>] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]
|
|
[<...>] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1339
|
|
[<...>] netlink_sendmsg+0x90a/0xdf0 net/netlink/af_netlink.c:1934
|
|
[<...>] sock_sendmsg_nosec net/socket.c:651 [inline]
|
|
[<...>] sock_sendmsg+0x157/0x190 net/socket.c:671
|
|
[<...>] ____sys_sendmsg+0x712/0x870 net/socket.c:2342
|
|
[<...>] ___sys_sendmsg+0xf8/0x170 net/socket.c:2396
|
|
[<...>] __sys_sendmsg+0xea/0x1b0 net/socket.c:2429
|
|
[<...>] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46
|
|
[<...>] entry_SYSCALL_64_after_hwframe+0x61/0xc6
|
|
|
|
Found by InfoTeCS on behalf of Linux Verification Center
|
|
(linuxtesting.org) with Syzkaller
|
|
|
|
[PM: merged via the LSM tree at Jakub Kicinski request]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52698</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
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.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52809</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
crypto: pcrypt - Fix hungtask for PADATA_RESET
|
|
|
|
We found a hungtask bug in test_aead_vec_cfg as follows:
|
|
|
|
INFO: task cryptomgr_test:391009 blocked for more than 120 seconds.
|
|
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
|
|
Call trace:
|
|
__switch_to+0x98/0xe0
|
|
__schedule+0x6c4/0xf40
|
|
schedule+0xd8/0x1b4
|
|
schedule_timeout+0x474/0x560
|
|
wait_for_common+0x368/0x4e0
|
|
wait_for_completion+0x20/0x30
|
|
wait_for_completion+0x20/0x30
|
|
test_aead_vec_cfg+0xab4/0xd50
|
|
test_aead+0x144/0x1f0
|
|
alg_test_aead+0xd8/0x1e0
|
|
alg_test+0x634/0x890
|
|
cryptomgr_test+0x40/0x70
|
|
kthread+0x1e0/0x220
|
|
ret_from_fork+0x10/0x18
|
|
Kernel panic - not syncing: hung_task: blocked tasks
|
|
|
|
For padata_do_parallel, when the return err is 0 or -EBUSY, it will call
|
|
wait_for_completion(&wait->completion) in test_aead_vec_cfg. In normal
|
|
case, aead_request_complete() will be called in pcrypt_aead_serial and the
|
|
return err is 0 for padata_do_parallel. But, when pinst->flags is
|
|
PADATA_RESET, the return err is -EBUSY for padata_do_parallel, and it
|
|
won't call aead_request_complete(). Therefore, test_aead_vec_cfg will
|
|
hung at wait_for_completion(&wait->completion), which will cause
|
|
hungtask.
|
|
|
|
The problem comes as following:
|
|
(padata_do_parallel) |
|
|
rcu_read_lock_bh(); |
|
|
err = -EINVAL; | (padata_replace)
|
|
| pinst->flags |= PADATA_RESET;
|
|
err = -EBUSY |
|
|
if (pinst->flags & PADATA_RESET) |
|
|
rcu_read_unlock_bh() |
|
|
return err
|
|
|
|
In order to resolve the problem, we replace the return err -EBUSY with
|
|
-EAGAIN, which means parallel_data is changing, and the caller should call
|
|
it again.
|
|
|
|
v3:
|
|
remove retry and just change the return err.
|
|
v2:
|
|
introduce padata_try_do_parallel() in pcrypt_aead_encrypt and
|
|
pcrypt_aead_decrypt to solve the hungtask.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52813</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:drm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULLIn certain types of chips, such as VEGA20, reading the amdgpu_regs_smc file could result in an abnormal null pointer access when the smc_rreg pointer is NULL. Below are the steps to reproduce this issue and the corresponding exception log:1. Navigate to the directory: /sys/kernel/debug/dri/02. Execute command: cat amdgpu_regs_smc3. Exception Log::[4005007.702554] BUG: kernel NULL pointer dereference, address: 0000000000000000[4005007.702562] #PF: supervisor instruction fetch in kernel mode[4005007.702567] #PF: error_code(0x0010) - not-present page[4005007.702570] PGD 0 P4D 0[4005007.702576] Oops: 0010 [#1] SMP NOPTI[4005007.702581] CPU: 4 PID: 62563 Comm: cat Tainted: G OE 5.15.0-43-generic #46-Ubunt u[4005007.702590] RIP: 0010:0x0[4005007.702598] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.[4005007.702600] RSP: 0018:ffffa82b46d27da0 EFLAGS: 00010206[4005007.702605] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffa82b46d27e68[4005007.702609] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9940656e0000[4005007.702612] RBP: ffffa82b46d27dd8 R08: 0000000000000000 R09: ffff994060c07980[4005007.702615] R10: 0000000000020000 R11: 0000000000000000 R12: 00007f5e06753000[4005007.702618] R13: ffff9940656e0000 R14: ffffa82b46d27e68 R15: 00007f5e06753000[4005007.702622] FS: 00007f5e0755b740(0000) GS:ffff99479d300000(0000) knlGS:0000000000000000[4005007.702626] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[4005007.702629] CR2: ffffffffffffffd6 CR3: 00000003253fc000 CR4: 00000000003506e0[4005007.702633] Call Trace:[4005007.702636] <TASK>[4005007.702640] amdgpu_debugfs_regs_smc_read+0xb0/0x120 [amdgpu][4005007.703002] full_proxy_read+0x5c/0x80[4005007.703011] vfs_read+0x9f/0x1a0[4005007.703019] ksys_read+0x67/0xe0[4005007.703023] __x64_sys_read+0x19/0x20[4005007.703028] do_syscall_64+0x5c/0xc0[4005007.703034] ? do_user_addr_fault+0x1e3/0x670[4005007.703040] ? exit_to_user_mode_prepare+0x37/0xb0[4005007.703047] ? irqentry_exit_to_user_mode+0x9/0x20[4005007.703052] ? irqentry_exit+0x19/0x30[4005007.703057] ? exc_page_fault+0x89/0x160[4005007.703062] ? asm_exc_page_fault+0x8/0x30[4005007.703068] entry_SYSCALL_64_after_hwframe+0x44/0xae[4005007.703075] RIP: 0033:0x7f5e07672992[4005007.703079] Code: c0 e9 b2 fe ff ff 50 48 8d 3d fa b2 0c 00 e8 c5 1d 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 e c 28 48 89 54 24[4005007.703083] RSP: 002b:00007ffe03097898 EFLAGS: 00000246 ORIG_RAX: 0000000000000000[4005007.703088] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5e07672992[4005007.703091] RDX: 0000000000020000 RSI: 00007f5e06753000 RDI: 0000000000000003[4005007.703094] RBP: 00007f5e06753000 R08: 00007f5e06752010 R09: 00007f5e06752010[4005007.703096] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000022000[4005007.703099] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000[4005007.703105] </TASK>[4005007.703107] Modules linked in: nf_tables libcrc32c nfnetlink algif_hash af_alg binfmt_misc nls_ iso8859_1 ipmi_ssif ast intel_rapl_msr intel_rapl_common drm_vram_helper drm_ttm_helper amd64_edac t tm edac_mce_amd kvm_amd ccp mac_hid k10temp kvm acpi_ipmi ipmi_si rapl sch_fq_codel ipmi_devintf ipm i_msghandler msr parport_pc ppdev lp parport mtd pstore_blk efi_pstore ramoops pstore_zone reed_solo mon ip_tables x_tables autofs4 ib_uverbs ib_core amdgpu(OE) amddrm_ttm_helper(OE) amdttm(OE) iommu_v 2 amd_sched(OE) amdkcl(OE) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec rc_core drm igb ahci xhci_pci libahci i2c_piix4 i2c_algo_bit xhci_pci_renesas dca[4005007.703184] CR2: 0000000000000000[4005007.703188] ---[ en---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52817</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
perf/core: Bail out early if the request AUX area is out of bound
|
|
|
|
When perf-record with a large AUX area, e.g 4GB, it fails with:
|
|
|
|
#perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1
|
|
failed to mmap with 12 (Cannot allocate memory)
|
|
|
|
and it reveals a WARNING with __alloc_pages():
|
|
|
|
------------[ cut here ]------------
|
|
WARNING: CPU: 44 PID: 17573 at mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248
|
|
Call trace:
|
|
__alloc_pages+0x1ec/0x248
|
|
__kmalloc_large_node+0xc0/0x1f8
|
|
__kmalloc_node+0x134/0x1e8
|
|
rb_alloc_aux+0xe0/0x298
|
|
perf_mmap+0x440/0x660
|
|
mmap_region+0x308/0x8a8
|
|
do_mmap+0x3c0/0x528
|
|
vm_mmap_pgoff+0xf4/0x1b8
|
|
ksys_mmap_pgoff+0x18c/0x218
|
|
__arm64_sys_mmap+0x38/0x58
|
|
invoke_syscall+0x50/0x128
|
|
el0_svc_common.constprop.0+0x58/0x188
|
|
do_el0_svc+0x34/0x50
|
|
el0_svc+0x34/0x108
|
|
el0t_64_sync_handler+0xb8/0xc0
|
|
el0t_64_sync+0x1a4/0x1a8
|
|
|
|
'rb->aux_pages' allocated by kcalloc() is a pointer array which is used to
|
|
maintains AUX trace pages. The allocated page for this array is physically
|
|
contiguous (and virtually contiguous) with an order of 0..MAX_ORDER. If the
|
|
size of pointer array crosses the limitation set by MAX_ORDER, it reveals a
|
|
WARNING.
|
|
|
|
So bail out early with -ENOMEM if the request AUX area is out of bound,
|
|
e.g.:
|
|
|
|
#perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1
|
|
failed to mmap with 12 (Cannot allocate memory)</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52835</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
nbd: fix uaf in nbd_open
|
|
|
|
Commit 4af5f2e03013 ("nbd: use blk_mq_alloc_disk and
|
|
blk_cleanup_disk") cleans up disk by blk_cleanup_disk() and it won't set
|
|
disk->private_data as NULL as before. UAF may be triggered in nbd_open()
|
|
if someone tries to open nbd device right after nbd_put() since nbd has
|
|
been free in nbd_dev_remove().
|
|
|
|
Fix this by implementing ->free_disk and free private data in it.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52837</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
Input: synaptics-rmi4 - fix use after free in rmi_unregister_function()
|
|
|
|
The put_device() calls rmi_release_function() which frees "fn" so the
|
|
dereference on the next line "fn->num_of_irqs" is a use after free.
|
|
Move the put_device() to the end to fix this.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52840</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
media: vidtv: psi: Add check for kstrdup
|
|
|
|
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-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52844</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
media: bttv: fix use after free error due to btv->timeout timer
|
|
|
|
There may be some a race condition between timer function
|
|
bttv_irq_timeout and bttv_remove. The timer is setup in
|
|
probe and there is no timer_delete operation in remove
|
|
function. When it hit kfree btv, the function might still be
|
|
invoked, which will cause use after free bug.
|
|
|
|
This bug is found by static analysis, it may be false positive.
|
|
|
|
Fix it by adding del_timer_sync invoking to the remove function.
|
|
|
|
cpu0 cpu1
|
|
bttv_probe
|
|
->timer_setup
|
|
->bttv_set_dma
|
|
->mod_timer;
|
|
bttv_remove
|
|
->kfree(btv);
|
|
->bttv_irq_timeout
|
|
->USE btv</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52847</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.8</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
padata: Fix refcnt handling in padata_free_shell()
|
|
|
|
In a high-load arm64 environment, the pcrypt_aead01 test in LTP can lead
|
|
to system UAF (Use-After-Free) issues. Due to the lengthy analysis of
|
|
the pcrypt_aead01 function call, I'll describe the problem scenario
|
|
using a simplified model:
|
|
|
|
Suppose there's a user of padata named `user_function` that adheres to
|
|
the padata requirement of calling `padata_free_shell` after `serial()`
|
|
has been invoked, as demonstrated in the following code:
|
|
|
|
```c
|
|
struct request {
|
|
struct padata_priv padata;
|
|
struct completion *done;
|
|
};
|
|
|
|
void parallel(struct padata_priv *padata) {
|
|
do_something();
|
|
}
|
|
|
|
void serial(struct padata_priv *padata) {
|
|
struct request *request = container_of(padata,
|
|
struct request,
|
|
padata);
|
|
complete(request->done);
|
|
}
|
|
|
|
void user_function() {
|
|
DECLARE_COMPLETION(done)
|
|
padata->parallel = parallel;
|
|
padata->serial = serial;
|
|
padata_do_parallel();
|
|
wait_for_completion(&done);
|
|
padata_free_shell();
|
|
}
|
|
```
|
|
|
|
In the corresponding padata.c file, there's the following code:
|
|
|
|
```c
|
|
static void padata_serial_worker(struct work_struct *serial_work) {
|
|
...
|
|
cnt = 0;
|
|
|
|
while (!list_empty(&local_list)) {
|
|
...
|
|
padata->serial(padata);
|
|
cnt++;
|
|
}
|
|
|
|
local_bh_enable();
|
|
|
|
if (refcount_sub_and_test(cnt, &pd->refcnt))
|
|
padata_free_pd(pd);
|
|
}
|
|
```
|
|
|
|
Because of the high system load and the accumulation of unexecuted
|
|
softirq at this moment, `local_bh_enable()` in padata takes longer
|
|
to execute than usual. Subsequently, when accessing `pd->refcnt`,
|
|
`pd` has already been released by `padata_free_shell()`, resulting
|
|
in a UAF issue with `pd->refcnt`.
|
|
|
|
The fix is straightforward: add `refcount_dec_and_test` before calling
|
|
`padata_free_pd` in `padata_free_shell`.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52854</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
drivers/perf: hisi: use cpuhp_state_remove_instance_nocalls() for hisi_hns3_pmu uninit process
|
|
|
|
When tearing down a 'hisi_hns3' PMU, we mistakenly run the CPU hotplug
|
|
callbacks after the device has been unregistered, leading to fireworks
|
|
when we try to execute empty function callbacks within the driver:
|
|
|
|
| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
|
|
| CPU: 0 PID: 15 Comm: cpuhp/0 Tainted: G W O 5.12.0-rc4+ #1
|
|
| Hardware name: , BIOS KpxxxFPGA 1P B600 V143 04/22/2021
|
|
| pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--)
|
|
| pc : perf_pmu_migrate_context+0x98/0x38c
|
|
| lr : perf_pmu_migrate_context+0x94/0x38c
|
|
|
|
|
| Call trace:
|
|
| perf_pmu_migrate_context+0x98/0x38c
|
|
| hisi_hns3_pmu_offline_cpu+0x104/0x12c [hisi_hns3_pmu]
|
|
|
|
Use cpuhp_state_remove_instance_nocalls() instead of
|
|
cpuhp_state_remove_instance() so that the notifiers don't execute after
|
|
the PMU device has been unregistered.
|
|
|
|
[will: Rewrote commit message]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52860</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
hwmon: (axi-fan-control) Fix possible NULL pointer dereference
|
|
|
|
axi_fan_control_irq_handler(), dependent on the private
|
|
axi_fan_control_data structure, might be called before the hwmon
|
|
device is registered. That will cause an "Unable to handle kernel
|
|
NULL pointer dereference" error.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52863</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
drm/radeon: possible buffer overflow
|
|
|
|
Buffer 'afmt_status' of size 6 could overflow, since index 'afmt_idx' is
|
|
checked after access.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52867</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
pstore/platform: Add check for kstrdup
|
|
|
|
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-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52869</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
clk: mediatek: clk-mt7629-eth: Add check for mtk_alloc_clk_data
|
|
|
|
Add the check for the return value of mtk_alloc_clk_data() in order to
|
|
avoid NULL pointer dereference.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52876</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.7</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
tracing: Have trace_event_file have ref counters
|
|
|
|
The following can crash the kernel:
|
|
|
|
# cd /sys/kernel/tracing
|
|
# echo 'p:sched schedule' > kprobe_events
|
|
# exec 5>>events/kprobes/sched/enable
|
|
# > kprobe_events
|
|
# exec 5>&-
|
|
|
|
The above commands:
|
|
|
|
1. Change directory to the tracefs directory
|
|
2. Create a kprobe event (doesn't matter what one)
|
|
3. Open bash file descriptor 5 on the enable file of the kprobe event
|
|
4. Delete the kprobe event (removes the files too)
|
|
5. Close the bash file descriptor 5
|
|
|
|
The above causes a crash!
|
|
|
|
BUG: kernel NULL pointer dereference, address: 0000000000000028
|
|
#PF: supervisor read access in kernel mode
|
|
#PF: error_code(0x0000) - not-present page
|
|
PGD 0 P4D 0
|
|
Oops: 0000 [#1] PREEMPT SMP PTI
|
|
CPU: 6 PID: 877 Comm: bash Not tainted 6.5.0-rc4-test-00008-g2c6b6b1029d4-dirty #186
|
|
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
|
|
RIP: 0010:tracing_release_file_tr+0xc/0x50
|
|
|
|
What happens here is that the kprobe event creates a trace_event_file
|
|
"file" descriptor that represents the file in tracefs to the event. It
|
|
maintains state of the event (is it enabled for the given instance?).
|
|
Opening the "enable" file gets a reference to the event "file" descriptor
|
|
via the open file descriptor. When the kprobe event is deleted, the file is
|
|
also deleted from the tracefs system which also frees the event "file"
|
|
descriptor.
|
|
|
|
But as the tracefs file is still opened by user space, it will not be
|
|
totally removed until the final dput() is called on it. But this is not
|
|
true with the event "file" descriptor that is already freed. If the user
|
|
does a write to or simply closes the file descriptor it will reference the
|
|
event "file" descriptor that was just freed, causing a use-after-free bug.
|
|
|
|
To solve this, add a ref count to the event "file" descriptor as well as a
|
|
new flag called "FREED". The "file" will not be freed until the last
|
|
reference is released. But the FREE flag will be set when the event is
|
|
removed to prevent any more modifications to that event from happening,
|
|
even if there's still a reference to the event "file" descriptor.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52879</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
vfio/fsl-mc: Block calling interrupt handler without trigger
|
|
|
|
The eventfd_ctx trigger pointer of the vfio_fsl_mc_irq object is
|
|
initially NULL and may become NULL if the user sets the trigger
|
|
eventfd to -1. The interrupt handler itself is guaranteed that
|
|
trigger is always valid between request_irq() and free_irq(), but
|
|
the loopback testing mechanisms to invoke the handler function
|
|
need to test the trigger. The triggering and setting ioctl paths
|
|
both make use of igate and are therefore mutually exclusive.
|
|
|
|
The vfio-fsl-mc driver does not make use of irqfds, nor does it
|
|
support any sort of masking operations, therefore unlike vfio-pci
|
|
and vfio-platform, the flow can remain essentially unchanged.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-26814</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
af_unix: Fix garbage collector racing against connect()
|
|
|
|
Garbage collector does not take into account the risk of embryo getting
|
|
enqueued during the garbage collection. If such embryo has a peer that
|
|
carries SCM_RIGHTS, two consecutive passes of scan_children() may see a
|
|
different set of children. Leading to an incorrectly elevated inflight
|
|
count, and then a dangling pointer within the gc_inflight_list.
|
|
|
|
sockets are AF_UNIX/SOCK_STREAM
|
|
S is an unconnected socket
|
|
L is a listening in-flight socket bound to addr, not in fdtable
|
|
V's fd will be passed via sendmsg(), gets inflight count bumped
|
|
|
|
connect(S, addr) sendmsg(S, [V]); close(V) __unix_gc()
|
|
---------------- ------------------------- -----------
|
|
|
|
NS = unix_create1()
|
|
skb1 = sock_wmalloc(NS)
|
|
L = unix_find_other(addr)
|
|
unix_state_lock(L)
|
|
unix_peer(S) = NS
|
|
// V count=1 inflight=0
|
|
|
|
NS = unix_peer(S)
|
|
skb2 = sock_alloc()
|
|
skb_queue_tail(NS, skb2[V])
|
|
|
|
// V became in-flight
|
|
// V count=2 inflight=1
|
|
|
|
close(V)
|
|
|
|
// V count=1 inflight=1
|
|
// GC candidate condition met
|
|
|
|
for u in gc_inflight_list:
|
|
if (total_refs == inflight_refs)
|
|
add u to gc_candidates
|
|
|
|
// gc_candidates={L, V}
|
|
|
|
for u in gc_candidates:
|
|
scan_children(u, dec_inflight)
|
|
|
|
// embryo (skb1) was not
|
|
// reachable from L yet, so V's
|
|
// inflight remains unchanged
|
|
__skb_queue_tail(L, skb1)
|
|
unix_state_unlock(L)
|
|
for u in gc_candidates:
|
|
if (u.inflight)
|
|
scan_children(u, inc_inflight_move_tail)
|
|
|
|
// V count=1 inflight=2 (!)
|
|
|
|
If there is a GC-candidate listening socket, lock/unlock its state. This
|
|
makes GC wait until the end of any ongoing connect() to that socket. After
|
|
flipping the lock, a possibly SCM-laden embryo is already enqueued. And if
|
|
there is another embryo coming, it can not possibly carry SCM_RIGHTS. At
|
|
this point, unix_inflight() can not happen because unix_gc_lock is already
|
|
taken. Inflight graph remains unaffected.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-26923</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
wireguard: netlink: access device through ctx instead of peer
|
|
|
|
The previous commit fixed a bug that led to a NULL peer->device being
|
|
dereferenced. It's actually easier and faster performance-wise to
|
|
instead get the device from ctx->wg. This semantically makes more sense
|
|
too, since ctx->wg->peer_allowedips.seq is compared with
|
|
ctx->allowedips_seq, basing them both in ctx. This also acts as a
|
|
defence in depth provision against freed peers.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-26950</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
nfs: fix UAF in direct writes
|
|
|
|
In production we have been hitting the following warning consistently
|
|
|
|
------------[ cut here ]------------
|
|
refcount_t: underflow; use-after-free.
|
|
WARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0
|
|
Workqueue: nfsiod nfs_direct_write_schedule_work [nfs]
|
|
RIP: 0010:refcount_warn_saturate+0x9c/0xe0
|
|
PKRU: 55555554
|
|
Call Trace:
|
|
<TASK>
|
|
? __warn+0x9f/0x130
|
|
? refcount_warn_saturate+0x9c/0xe0
|
|
? report_bug+0xcc/0x150
|
|
? handle_bug+0x3d/0x70
|
|
? exc_invalid_op+0x16/0x40
|
|
? asm_exc_invalid_op+0x16/0x20
|
|
? refcount_warn_saturate+0x9c/0xe0
|
|
nfs_direct_write_schedule_work+0x237/0x250 [nfs]
|
|
process_one_work+0x12f/0x4a0
|
|
worker_thread+0x14e/0x3b0
|
|
? ZSTD_getCParams_internal+0x220/0x220
|
|
kthread+0xdc/0x120
|
|
? __btf_name_valid+0xa0/0xa0
|
|
ret_from_fork+0x1f/0x30
|
|
|
|
This is because we're completing the nfs_direct_request twice in a row.
|
|
|
|
The source of this is when we have our commit requests to submit, we
|
|
process them and send them off, and then in the completion path for the
|
|
commit requests we have
|
|
|
|
if (nfs_commit_end(cinfo.mds))
|
|
nfs_direct_write_complete(dreq);
|
|
|
|
However since we're submitting asynchronous requests we sometimes have
|
|
one that completes before we submit the next one, so we end up calling
|
|
complete on the nfs_direct_request twice.
|
|
|
|
The only other place we use nfs_generic_commit_list() is in
|
|
__nfs_commit_inode, which wraps this call in a
|
|
|
|
nfs_commit_begin();
|
|
nfs_commit_end();
|
|
|
|
Which is a common pattern for this style of completion handling, one
|
|
that is also repeated in the direct code with get_dreq()/put_dreq()
|
|
calls around where we process events as well as in the completion paths.
|
|
|
|
Fix this by using the same pattern for the commit requests.
|
|
|
|
Before with my 200 node rocksdb stress running this warning would pop
|
|
every 10ish minutes. With my patch the stress test has been running for
|
|
several hours without popping.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-26958</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
mac802154: fix llsec key resources release in mac802154_llsec_key_del
|
|
|
|
mac802154_llsec_key_del() can free resources of a key directly without
|
|
following the RCU rules for waiting before the end of a grace period. This
|
|
may lead to use-after-free in case llsec_lookup_key() is traversing the
|
|
list of keys in parallel with a key deletion:
|
|
|
|
refcount_t: addition on 0; use-after-free.
|
|
WARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0
|
|
Modules linked in:
|
|
CPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
|
|
RIP: 0010:refcount_warn_saturate+0x162/0x2a0
|
|
Call Trace:
|
|
<TASK>
|
|
llsec_lookup_key.isra.0+0x890/0x9e0
|
|
mac802154_llsec_encrypt+0x30c/0x9c0
|
|
ieee802154_subif_start_xmit+0x24/0x1e0
|
|
dev_hard_start_xmit+0x13e/0x690
|
|
sch_direct_xmit+0x2ae/0xbc0
|
|
__dev_queue_xmit+0x11dd/0x3c20
|
|
dgram_sendmsg+0x90b/0xd60
|
|
__sys_sendto+0x466/0x4c0
|
|
__x64_sys_sendto+0xe0/0x1c0
|
|
do_syscall_64+0x45/0xf0
|
|
entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
|
|
Also, ieee802154_llsec_key_entry structures are not freed by
|
|
mac802154_llsec_key_del():
|
|
|
|
unreferenced object 0xffff8880613b6980 (size 64):
|
|
comm "iwpan", pid 2176, jiffies 4294761134 (age 60.475s)
|
|
hex dump (first 32 bytes):
|
|
78 0d 8f 18 80 88 ff ff 22 01 00 00 00 00 ad de x.......".......
|
|
00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00 ................
|
|
backtrace:
|
|
[<ffffffff81dcfa62>] __kmem_cache_alloc_node+0x1e2/0x2d0
|
|
[<ffffffff81c43865>] kmalloc_trace+0x25/0xc0
|
|
[<ffffffff88968b09>] mac802154_llsec_key_add+0xac9/0xcf0
|
|
[<ffffffff8896e41a>] ieee802154_add_llsec_key+0x5a/0x80
|
|
[<ffffffff8892adc6>] nl802154_add_llsec_key+0x426/0x5b0
|
|
[<ffffffff86ff293e>] genl_family_rcv_msg_doit+0x1fe/0x2f0
|
|
[<ffffffff86ff46d1>] genl_rcv_msg+0x531/0x7d0
|
|
[<ffffffff86fee7a9>] netlink_rcv_skb+0x169/0x440
|
|
[<ffffffff86ff1d88>] genl_rcv+0x28/0x40
|
|
[<ffffffff86fec15c>] netlink_unicast+0x53c/0x820
|
|
[<ffffffff86fecd8b>] netlink_sendmsg+0x93b/0xe60
|
|
[<ffffffff86b91b35>] ____sys_sendmsg+0xac5/0xca0
|
|
[<ffffffff86b9c3dd>] ___sys_sendmsg+0x11d/0x1c0
|
|
[<ffffffff86b9c65a>] __sys_sendmsg+0xfa/0x1d0
|
|
[<ffffffff88eadbf5>] do_syscall_64+0x45/0xf0
|
|
[<ffffffff890000ea>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
|
|
|
|
Handle the proper resource release in the RCU callback function
|
|
mac802154_llsec_key_del_rcu().
|
|
|
|
Note that if llsec_lookup_key() finds a key, it gets a refcount via
|
|
llsec_key_get() and locally copies key id from key_entry (which is a
|
|
list element). So it's safe to call llsec_key_put() and free the list
|
|
entry after the RCU grace period elapses.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org).</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-26961</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
clk: qcom: mmcc-msm8974: fix terminating of frequency table arrays
|
|
|
|
The frequency table arrays are supposed to be terminated with an
|
|
empty element. Add such entry to the end of the arrays where it
|
|
is missing in order to avoid possible out-of-bound access when
|
|
the table is traversed by functions like qcom_find_freq() or
|
|
qcom_find_freq_floor().
|
|
|
|
Only compile tested.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-26965</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path
|
|
|
|
For error handling path in ubifs_symlink(), inode will be marked as
|
|
bad first, then iput() is invoked. If inode->i_link is initialized by
|
|
fscrypt_encrypt_symlink() in encryption scenario, inode->i_link won't
|
|
be freed by callchain ubifs_free_inode -> fscrypt_free_inode in error
|
|
handling path, because make_bad_inode() has changed 'inode->i_mode' as
|
|
'S_IFREG'.
|
|
Following kmemleak is easy to be reproduced by injecting error in
|
|
ubifs_jnl_update() when doing symlink in encryption scenario:
|
|
unreferenced object 0xffff888103da3d98 (size 8):
|
|
comm "ln", pid 1692, jiffies 4294914701 (age 12.045s)
|
|
backtrace:
|
|
kmemdup+0x32/0x70
|
|
__fscrypt_encrypt_symlink+0xed/0x1c0
|
|
ubifs_symlink+0x210/0x300 [ubifs]
|
|
vfs_symlink+0x216/0x360
|
|
do_symlinkat+0x11a/0x190
|
|
do_syscall_64+0x3b/0xe0
|
|
There are two ways fixing it:
|
|
1. Remove make_bad_inode() in error handling path. We can do that
|
|
because ubifs_evict_inode() will do same processes for good
|
|
symlink inode and bad symlink inode, for inode->i_nlink checking
|
|
is before is_bad_inode().
|
|
2. Free inode->i_link before marking inode bad.
|
|
Method 2 is picked, it has less influence, personally, I think.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-26972</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
KVM: Always flush async #PF workqueue when vCPU is being destroyed
|
|
|
|
Always flush the per-vCPU async #PF workqueue when a vCPU is clearing its
|
|
completion queue, e.g. when a VM and all its vCPUs is being destroyed.
|
|
KVM must ensure that none of its workqueue callbacks is running when the
|
|
last reference to the KVM _module_ is put. Gifting a reference to the
|
|
associated VM prevents the workqueue callback from dereferencing freed
|
|
vCPU/VM memory, but does not prevent the KVM module from being unloaded
|
|
before the callback completes.
|
|
|
|
Drop the misguided VM refcount gifting, as calling kvm_put_kvm() from
|
|
async_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will
|
|
result in deadlock. async_pf_execute() can't return until kvm_put_kvm()
|
|
finishes, and kvm_put_kvm() can't return until async_pf_execute() finishes:
|
|
|
|
WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm]
|
|
Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass
|
|
CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119
|
|
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
|
|
Workqueue: events async_pf_execute [kvm]
|
|
RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm]
|
|
Call Trace:
|
|
<TASK>
|
|
async_pf_execute+0x198/0x260 [kvm]
|
|
process_one_work+0x145/0x2d0
|
|
worker_thread+0x27e/0x3a0
|
|
kthread+0xba/0xe0
|
|
ret_from_fork+0x2d/0x50
|
|
ret_from_fork_asm+0x11/0x20
|
|
</TASK>
|
|
---[ end trace 0000000000000000 ]---
|
|
INFO: task kworker/8:1:251 blocked for more than 120 seconds.
|
|
Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119
|
|
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
|
|
task:kworker/8:1 state:D stack:0 pid:251 ppid:2 flags:0x00004000
|
|
Workqueue: events async_pf_execute [kvm]
|
|
Call Trace:
|
|
<TASK>
|
|
__schedule+0x33f/0xa40
|
|
schedule+0x53/0xc0
|
|
schedule_timeout+0x12a/0x140
|
|
__wait_for_common+0x8d/0x1d0
|
|
__flush_work.isra.0+0x19f/0x2c0
|
|
kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm]
|
|
kvm_arch_destroy_vm+0x78/0x1b0 [kvm]
|
|
kvm_put_kvm+0x1c1/0x320 [kvm]
|
|
async_pf_execute+0x198/0x260 [kvm]
|
|
process_one_work+0x145/0x2d0
|
|
worker_thread+0x27e/0x3a0
|
|
kthread+0xba/0xe0
|
|
ret_from_fork+0x2d/0x50
|
|
ret_from_fork_asm+0x11/0x20
|
|
</TASK>
|
|
|
|
If kvm_clear_async_pf_completion_queue() actually flushes the workqueue,
|
|
then there's no need to gift async_pf_execute() a reference because all
|
|
invocations of async_pf_execute() will be forced to complete before the
|
|
vCPU and its VM are destroyed/freed. And that in turn fixes the module
|
|
unloading bug as __fput() won't do module_put() on the last vCPU reference
|
|
until the vCPU has been freed, e.g. if closing the vCPU file also puts the
|
|
last reference to the KVM module.
|
|
|
|
Note that kvm_check_async_pf_completion() may also take the work item off
|
|
the completion queue and so also needs to flush the work queue, as the
|
|
work will not be seen by kvm_clear_async_pf_completion_queue(). Waiting
|
|
on the workqueue could theoretically delay a vCPU due to waiting for the
|
|
work to complete, but that's a very, very small chance, and likely a very
|
|
small delay. kvm_arch_async_page_present_queued() unconditionally makes a
|
|
new request, i.e. will effectively delay entering the guest, so the
|
|
remaining work is really just:
|
|
|
|
trace_kvm_async_pf_completed(addr, cr2_or_gpa);
|
|
|
|
__kvm_vcpu_wake_up(vcpu);
|
|
|
|
mmput(mm);
|
|
|
|
and mmput() can't drop the last reference to the page tables if the vCPU is
|
|
still alive, i.e. the vCPU won't get stuck tearing down page tables.
|
|
|
|
Add a helper to do the flushing, specifically to deal with "wakeup all"
|
|
work items, as they aren't actually work items, i.e. are never placed in a
|
|
workqueue. Trying to flush a bogus workqueue entry rightly makes
|
|
__flush_work() complain (kudos to whoever added that sanity check).
|
|
|
|
Note, commit 5f6de5cbebee ("KVM: Prevent module exit until al
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-26976</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
Squashfs: check the inode number is not the invalid value of zero
|
|
|
|
Syskiller has produced an out of bounds access in fill_meta_index().
|
|
|
|
That out of bounds access is ultimately caused because the inode
|
|
has an inode number with the invalid value of zero, which was not checked.
|
|
|
|
The reason this causes the out of bounds access is due to following
|
|
sequence of events:
|
|
|
|
1. Fill_meta_index() is called to allocate (via empty_meta_index())
|
|
and fill a metadata index. It however suffers a data read error
|
|
and aborts, invalidating the newly returned empty metadata index.
|
|
It does this by setting the inode number of the index to zero,
|
|
which means unused (zero is not a valid inode number).
|
|
|
|
2. When fill_meta_index() is subsequently called again on another
|
|
read operation, locate_meta_index() returns the previous index
|
|
because it matches the inode number of 0. Because this index
|
|
has been returned it is expected to have been filled, and because
|
|
it hasn't been, an out of bounds access is performed.
|
|
|
|
This patch adds a sanity check which checks that the inode number
|
|
is not zero when the inode is created and returns -EINVAL if it is.
|
|
|
|
[phillip@squashfs.org.uk: whitespace fix]
|
|
Link: https://lkml.kernel.org/r/20240409204723.446925-1-phillip@squashfs.org.uk</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-26982</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
fs: sysfs: Fix reference leak in sysfs_break_active_protection()
|
|
|
|
The sysfs_break_active_protection() routine has an obvious reference
|
|
leak in its error path. If the call to kernfs_find_and_get() fails then
|
|
kn will be NULL, so the companion sysfs_unbreak_active_protection()
|
|
routine won't get called (and would only cause an access violation by
|
|
trying to dereference kn->parent if it was called). As a result, the
|
|
reference to kobj acquired at the start of the function will never be
|
|
released.
|
|
|
|
Fix the leak by adding an explicit kobject_put() call when kn is NULL.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-26993</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
serial: mxs-auart: add spinlock around changing cts state
|
|
|
|
The uart_handle_cts_change() function in serial_core expects the caller
|
|
to hold uport->lock. For example, I have seen the below kernel splat,
|
|
when the Bluetooth driver is loaded on an i.MX28 board.
|
|
|
|
[ 85.119255] ------------[ cut here ]------------
|
|
[ 85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec
|
|
[ 85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs
|
|
[ 85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1
|
|
[ 85.151396] Hardware name: Freescale MXS (Device Tree)
|
|
[ 85.156679] Workqueue: hci0 hci_power_on [bluetooth]
|
|
(...)
|
|
[ 85.191765] uart_handle_cts_change from mxs_auart_irq_handle+0x380/0x3f4
|
|
[ 85.198787] mxs_auart_irq_handle from __handle_irq_event_percpu+0x88/0x210
|
|
(...)</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-27000</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.3</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
drm: nv04: Fix out of bounds access
|
|
|
|
When Output Resource (dcb->or) value is assigned in
|
|
fabricate_dcb_output(), there may be out of bounds access to
|
|
dac_users array in case dcb->or is zero because ffs(dcb->or) is
|
|
used as index there.
|
|
The 'or' argument of fabricate_dcb_output() must be interpreted as a
|
|
number of bit to set, not value.
|
|
|
|
Utilize macros from 'enum nouveau_or' in calls instead of hardcoding.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-27008</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.3</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
drm/amd/display: Fix a potential buffer overflow in 'dp_dsc_clock_en_read()'
|
|
|
|
Tell snprintf() to store at most 10 bytes in the output buffer
|
|
instead of 30.
|
|
|
|
Fixes the below:
|
|
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:1508 dp_dsc_clock_en_read() error: snprintf() is printing too much 30 vs 10</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-27045</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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:H/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
USB: usb-storage: Prevent divide-by-0 error in isd200_ata_command
|
|
|
|
The isd200 sub-driver in usb-storage uses the HEADS and SECTORS values
|
|
in the ATA ID information to calculate cylinder and head values when
|
|
creating a CDB for READ or WRITE commands. The calculation involves
|
|
division and modulus operations, which will cause a crash if either of
|
|
these values is 0. While this never happens with a genuine device, it
|
|
could happen with a flawed or subversive emulation, as reported by the
|
|
syzbot fuzzer.
|
|
|
|
Protect against this possibility by refusing to bind to the device if
|
|
either the ATA_ID_HEADS or ATA_ID_SECTORS value in the device's ID
|
|
information is 0. This requires isd200_Initialization() to return a
|
|
negative error code when initialization fails; currently it always
|
|
returns 0 (even when there is an error).</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-27059</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
media: usbtv: Remove useless locks in usbtv_video_free()
|
|
|
|
Remove locks calls in usbtv_video_free() because
|
|
are useless and may led to a deadlock as reported here:
|
|
https://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000
|
|
Also remove usbtv_stop() call since it will be called when
|
|
unregistering the device.
|
|
|
|
Before 'c838530d230b' this issue would only be noticed if you
|
|
disconnect while streaming and now it is noticeable even when
|
|
disconnecting while not streaming.
|
|
|
|
|
|
[hverkuil: fix minor spelling mistake in log message]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-27072</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
media: ttpci: fix two memleaks in budget_av_attach
|
|
|
|
When saa7146_register_device and saa7146_vv_init fails, budget_av_attach
|
|
should free the resources it allocates, like the error-handling of
|
|
ttpci_budget_init does. Besides, there are two fixme comment refers to
|
|
such deallocations.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-27073</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
media: dvb-frontends: avoid stack overflow warnings with clang
|
|
|
|
A previous patch worked around a KASAN issue in stv0367, now a similar
|
|
problem showed up with clang:
|
|
|
|
drivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size (3624) exceeds limit (2048) in 'stv0367ter_set_frontend' [-Werror,-Wframe-larger-than]
|
|
1214 | static int stv0367ter_set_frontend(struct dvb_frontend *fe)
|
|
|
|
Rework the stv0367_writereg() function to be simpler and mark both
|
|
register access functions as noinline_for_stack so the temporary
|
|
i2c_msg structures do not get duplicated on the stack when KASAN_STACK
|
|
is enabled.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-27075</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
pstore: inode: Only d_invalidate() is needed
|
|
|
|
Unloading a modular pstore backend with records in pstorefs would
|
|
trigger the dput() double-drop warning:
|
|
|
|
WARNING: CPU: 0 PID: 2569 at fs/dcache.c:762 dput.part.0+0x3f3/0x410
|
|
|
|
Using the combo of d_drop()/dput() (as mentioned in
|
|
Documentation/filesystems/vfs.rst) isn't the right approach here, and
|
|
leads to the reference counting problem seen above. Use d_invalidate()
|
|
and update the code to not bother checking for error codes that can
|
|
never happen.
|
|
|
|
---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-27389</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.7</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
fs/ntfs3: Fixed overflow check in mi_enum_attr()</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-27407</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
netrom: Fix data-races around sysctl_net_busy_read
|
|
|
|
We need to protect the reader reading the sysctl value because the
|
|
value can be changed concurrently.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-27419</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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">Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-27426</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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">Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-27427</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
KVM: SVM: Flush pages under kvm->lock to fix UAF in svm_register_enc_region()
|
|
|
|
Do the cache flush of converted pages in svm_register_enc_region() before
|
|
dropping kvm->lock to fix use-after-free issues where region and/or its
|
|
array of pages could be freed by a different task, e.g. if userspace has
|
|
__unregister_enc_region_locked() already queued up for the region.
|
|
|
|
Note, the "obvious" alternative of using local variables doesn't fully
|
|
resolve the bug, as region->pages is also dynamically allocated. I.e. the
|
|
region structure itself would be fine, but region->pages could be freed.
|
|
|
|
Flushing multiple pages under kvm->lock is unfortunate, but the entire
|
|
flow is a rare slow path, and the manual flush is only needed on CPUs that
|
|
lack coherency for encrypted memory.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-35791</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
x86/fpu: Keep xfd_state in sync with MSR_IA32_XFD
|
|
|
|
Commit 672365477ae8 ("x86/fpu: Update XFD state where required") and
|
|
commit 8bf26758ca96 ("x86/fpu: Add XFD state to fpstate") introduced a
|
|
per CPU variable xfd_state to keep the MSR_IA32_XFD value cached, in
|
|
order to avoid unnecessary writes to the MSR.
|
|
|
|
On CPU hotplug MSR_IA32_XFD is reset to the init_fpstate.xfd, which
|
|
wipes out any stale state. But the per CPU cached xfd value is not
|
|
reset, which brings them out of sync.
|
|
|
|
As a consequence a subsequent xfd_update_state() might fail to update
|
|
the MSR which in turn can result in XRSTOR raising a #NM in kernel
|
|
space, which crashes the kernel.
|
|
|
|
To fix this, introduce xfd_set_state() to write xfd_state together
|
|
with MSR_IA32_XFD, and use it in all places that set MSR_IA32_XFD.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-35801</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
dm snapshot: fix lockup in dm_exception_table_exit
|
|
|
|
There was reported lockup when we exit a snapshot with many exceptions.
|
|
Fix this by adding "cond_resched" to the loop that frees the exceptions.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-35805</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
soc: fsl: qbman: Always disable interrupts when taking cgr_lock
|
|
|
|
smp_call_function_single disables IRQs when executing the callback. To
|
|
prevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere.
|
|
This is already done by qman_update_cgr and qman_delete_cgr; fix the
|
|
other lockers.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-35806</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
LoongArch: Define the __io_aw() hook as mmiowb()
|
|
|
|
Commit fb24ea52f78e0d595852e ("drivers: Remove explicit invocations of
|
|
mmiowb()") remove all mmiowb() in drivers, but it says:
|
|
|
|
"NOTE: mmiowb() has only ever guaranteed ordering in conjunction with
|
|
spin_unlock(). However, pairing each mmiowb() removal in this patch with
|
|
the corresponding call to spin_unlock() is not at all trivial, so there
|
|
is a small chance that this change may regress any drivers incorrectly
|
|
relying on mmiowb() to order MMIO writes between CPUs using lock-free
|
|
synchronisation."
|
|
|
|
The mmio in radeon_ring_commit() is protected by a mutex rather than a
|
|
spinlock, but in the mutex fastpath it behaves similar to spinlock. We
|
|
can add mmiowb() calls in the radeon driver but the maintainer says he
|
|
doesn't like such a workaround, and radeon is not the only example of
|
|
mutex protected mmio.
|
|
|
|
So we should extend the mmiowb tracking system from spinlock to mutex,
|
|
and maybe other locking primitives. This is not easy and error prone, so
|
|
we solve it in the architectural code, by simply defining the __io_aw()
|
|
hook as mmiowb(). And we no longer need to override queued_spin_unlock()
|
|
so use the generic definition.
|
|
|
|
Without this, we get such an error when run 'glxgears' on weak ordering
|
|
architectures such as LoongArch:
|
|
|
|
radeon 0000:04:00.0: ring 0 stalled for more than 10324msec
|
|
radeon 0000:04:00.0: ring 3 stalled for more than 10240msec
|
|
radeon 0000:04:00.0: GPU lockup (current fence id 0x000000000001f412 last fence id 0x000000000001f414 on ring 3)
|
|
radeon 0000:04:00.0: GPU lockup (current fence id 0x000000000000f940 last fence id 0x000000000000f941 on ring 0)
|
|
radeon 0000:04:00.0: scheduling IB failed (-35).
|
|
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
|
|
radeon 0000:04:00.0: scheduling IB failed (-35).
|
|
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
|
|
radeon 0000:04:00.0: scheduling IB failed (-35).
|
|
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
|
|
radeon 0000:04:00.0: scheduling IB failed (-35).
|
|
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
|
|
radeon 0000:04:00.0: scheduling IB failed (-35).
|
|
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
|
|
radeon 0000:04:00.0: scheduling IB failed (-35).
|
|
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
|
|
radeon 0000:04:00.0: scheduling IB failed (-35).
|
|
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-35818</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
net/mlx5e: fix a double-free in arfs_create_groups
|
|
|
|
When `in` allocated by kvzalloc fails, arfs_create_groups will free
|
|
ft->g and return an error. However, arfs_create_table, the only caller of
|
|
arfs_create_groups, will hold this error and call to
|
|
mlx5e_destroy_flow_table, in which the ft->g will be freed again.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-35835</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
f2fs: compress: fix reserve_cblocks counting error when out of space
|
|
|
|
When a file only needs one direct_node, performing the following
|
|
operations will cause the file to be unrepairable:
|
|
|
|
unisoc # ./f2fs_io compress test.apk
|
|
unisoc #df -h | grep dm-48
|
|
/dev/block/dm-48 112G 112G 1.2M 100% /data
|
|
|
|
unisoc # ./f2fs_io release_cblocks test.apk
|
|
924
|
|
unisoc # df -h | grep dm-48
|
|
/dev/block/dm-48 112G 112G 4.8M 100% /data
|
|
|
|
unisoc # dd if=/dev/random of=file4 bs=1M count=3
|
|
3145728 bytes (3.0 M) copied, 0.025 s, 120 M/s
|
|
unisoc # df -h | grep dm-48
|
|
/dev/block/dm-48 112G 112G 1.8M 100% /data
|
|
|
|
unisoc # ./f2fs_io reserve_cblocks test.apk
|
|
F2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device
|
|
|
|
adb reboot
|
|
unisoc # df -h | grep dm-48
|
|
/dev/block/dm-48 112G 112G 11M 100% /data
|
|
unisoc # ./f2fs_io reserve_cblocks test.apk
|
|
0
|
|
|
|
This is because the file has only one direct_node. After returning
|
|
to -ENOSPC, reserved_blocks += ret will not be executed. As a result,
|
|
the reserved_blocks at this time is still 0, which is not the real
|
|
number of reserved blocks. Therefore, fsck cannot be set to repair
|
|
the file.
|
|
|
|
After this patch, the fsck flag will be set to fix this problem.
|
|
|
|
unisoc # df -h | grep dm-48
|
|
/dev/block/dm-48 112G 112G 1.8M 100% /data
|
|
unisoc # ./f2fs_io reserve_cblocks test.apk
|
|
F2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device
|
|
|
|
adb reboot then fsck will be executed
|
|
unisoc # df -h | grep dm-48
|
|
/dev/block/dm-48 112G 112G 11M 100% /data
|
|
unisoc # ./f2fs_io reserve_cblocks test.apk
|
|
924</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-35844</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
wifi: iwlwifi: dbg-tlv: ensure NUL termination
|
|
|
|
The iwl_fw_ini_debug_info_tlv is used as a string, so we must
|
|
ensure the string is terminated correctly before using it.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-35845</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
eeprom: at24: fix memory corruption race condition
|
|
|
|
If the eeprom is not accessible, an nvmem device will be registered, the
|
|
read will fail, and the device will be torn down. If another driver
|
|
accesses the nvmem device after the teardown, it will reference
|
|
invalid memory.
|
|
|
|
Move the failure point before registering the nvmem device.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-35848</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get()
|
|
|
|
nft_unregister_flowtable_type() within nf_flow_inet_module_exit() can
|
|
concurrent with __nft_flowtable_type_get() within nf_tables_newflowtable().
|
|
And thhere is not any protection when iterate over nf_tables_flowtables
|
|
list in __nft_flowtable_type_get(). Therefore, there is pertential
|
|
data-race of nf_tables_flowtables list entry.
|
|
|
|
Use list_for_each_entry_rcu() to iterate over nf_tables_flowtables list
|
|
in __nft_flowtable_type_get(), and use rcu_read_lock() in the caller
|
|
nft_flowtable_type_get() to protect the entire type query process.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-35898</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
fbmon: prevent division by zero in fb_videomode_from_videomode()
|
|
|
|
The expression htotal * vtotal can have a zero value on
|
|
overflow. It is necessary to prevent division by zero like in
|
|
fb_var_to_videomode().
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with Svace.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-35922</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()
|
|
|
|
The call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an
|
|
unsuccessful status. In such cases, the elsiocb is not issued, the
|
|
completion is not called, and thus the elsiocb resource is leaked.
|
|
|
|
Check return value after calling lpfc_sli4_resume_rpi() and conditionally
|
|
release the elsiocb resource.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-35930</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()
|
|
|
|
The unhandled case in btrfs_relocate_sys_chunks() loop is a corruption,
|
|
as it could be caused only by two impossible conditions:
|
|
|
|
- at first the search key is set up to look for a chunk tree item, with
|
|
offset -1, this is an inexact search and the key->offset will contain
|
|
the correct offset upon a successful search, a valid chunk tree item
|
|
cannot have an offset -1
|
|
|
|
- after first successful search, the found_key corresponds to a chunk
|
|
item, the offset is decremented by 1 before the next loop, it's
|
|
impossible to find a chunk item there due to alignment and size
|
|
constraints</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-35936</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
pstore/zone: Add a null pointer check to the psz_kmsg_read
|
|
|
|
kasprintf() returns a pointer to dynamically allocated memory
|
|
which can be NULL upon failure. Ensure the allocation was successful
|
|
by checking the pointer validity.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-35940</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
xsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING
|
|
|
|
syzbot reported an illegal copy in xsk_setsockopt() [1]
|
|
|
|
Make sure to validate setsockopt() @optlen parameter.
|
|
|
|
[1]
|
|
|
|
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
|
|
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]
|
|
BUG: KASAN: slab-out-of-bounds in xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420
|
|
Read of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549
|
|
|
|
CPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
|
|
print_address_description mm/kasan/report.c:377 [inline]
|
|
print_report+0x169/0x550 mm/kasan/report.c:488
|
|
kasan_report+0x143/0x180 mm/kasan/report.c:601
|
|
copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
|
|
copy_from_sockptr include/linux/sockptr.h:55 [inline]
|
|
xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420
|
|
do_sock_setsockopt+0x3af/0x720 net/socket.c:2311
|
|
__sys_setsockopt+0x1ae/0x250 net/socket.c:2334
|
|
__do_sys_setsockopt net/socket.c:2343 [inline]
|
|
__se_sys_setsockopt net/socket.c:2340 [inline]
|
|
__x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
|
|
do_syscall_64+0xfb/0x240
|
|
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
|
RIP: 0033:0x7fb40587de69
|
|
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
|
|
RSP: 002b:00007fb40665a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
|
|
RAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69
|
|
RDX: 0000000000000005 RSI: 000000000000011b RDI: 0000000000000006
|
|
RBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000
|
|
R10: 0000000020001980 R11: 0000000000000246 R12: 0000000000000000
|
|
R13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08
|
|
</TASK>
|
|
|
|
Allocated by task 7549:
|
|
kasan_save_stack mm/kasan/common.c:47 [inline]
|
|
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
|
|
poison_kmalloc_redzone mm/kasan/common.c:370 [inline]
|
|
__kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387
|
|
kasan_kmalloc include/linux/kasan.h:211 [inline]
|
|
__do_kmalloc_node mm/slub.c:3966 [inline]
|
|
__kmalloc+0x233/0x4a0 mm/slub.c:3979
|
|
kmalloc include/linux/slab.h:632 [inline]
|
|
__cgroup_bpf_run_filter_setsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869
|
|
do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293
|
|
__sys_setsockopt+0x1ae/0x250 net/socket.c:2334
|
|
__do_sys_setsockopt net/socket.c:2343 [inline]
|
|
__se_sys_setsockopt net/socket.c:2340 [inline]
|
|
__x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
|
|
do_syscall_64+0xfb/0x240
|
|
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
|
|
|
The buggy address belongs to the object at ffff888028c6cde0
|
|
which belongs to the cache kmalloc-8 of size 8
|
|
The buggy address is located 1 bytes to the right of
|
|
allocated 2-byte region [ffff888028c6cde0, ffff888028c6cde2)
|
|
|
|
The buggy address belongs to the physical page:
|
|
page:ffffea0000a31b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888028c6c9c0 pfn:0x28c6c
|
|
anon flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff)
|
|
page_type: 0xffffffff()
|
|
raw: 00fff00000000800 ffff888014c41280 0000000000000000 dead000000000001
|
|
raw: ffff888028c6c9c0 0000000080800057 00000001ffffffff 0000000000000000
|
|
page dumped because: kasan: bad access detected
|
|
page_owner tracks the page as allocated
|
|
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 6648, tgid 6644 (syz-executor.0), ts 133906047828, free_ts 133859922223
|
|
set_page_owner include/linux/page_owner.h:31 [inline]
|
|
post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533
|
|
prep_new_page mm/page_alloc.c:
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-35976</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-upThe flag I2C_HID_READ_PENDING is used to serialize I2C operations.However, this is not necessary, because I2C core already has its ownlocking for that.More importantly, this flag can cause a lock-up: if the flag is set ini2c_hid_xfer() and an interrupt happens, the interrupt handler(i2c_hid_irq) will check this flag and return immediately without doinganything, then the interrupt handler will be invoked again in aninfinite loop.Since interrupt handler is an RT task, it takes over the CPU and theflag-clearing task never gets scheduled, thus we have a lock-up.Delete this unnecessary flag.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-35997</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</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:
|
|
|
|
mlxsw: spectrum_acl_tcam: Fix incorrect list API usage
|
|
|
|
Both the function that migrates all the chunks within a region and the
|
|
function that migrates all the entries within a chunk call
|
|
list_first_entry() on the respective lists without checking that the
|
|
lists are not empty. This is incorrect usage of the API, which leads to
|
|
the following warning [1].
|
|
|
|
Fix by returning if the lists are empty as there is nothing to migrate
|
|
in this case.
|
|
|
|
[1]
|
|
WARNING: CPU: 0 PID: 6437 at drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c:1266 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0>
|
|
Modules linked in:
|
|
CPU: 0 PID: 6437 Comm: kworker/0:37 Not tainted 6.9.0-rc3-custom-00883-g94a65f079ef6 #39
|
|
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
|
|
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
|
|
RIP: 0010:mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0x2c0
|
|
[...]
|
|
Call Trace:
|
|
<TASK>
|
|
mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x4a0
|
|
process_one_work+0x151/0x370
|
|
worker_thread+0x2cb/0x3e0
|
|
kthread+0xd0/0x100
|
|
ret_from_fork+0x34/0x50
|
|
ret_from_fork_asm+0x1a/0x30
|
|
</TASK></Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-36006</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1680</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |