2115 lines
94 KiB
XML
2115 lines
94 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</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-1679</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.</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/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:
|
|
|
|
pstore: ram_core: fix possible overflow in persistent_ram_init_ecc()
|
|
|
|
In persistent_ram_init_ecc(), on 64-bit arches DIV_ROUND_UP() will return
|
|
64-bit value since persistent_ram_zone::buffer_size has type size_t which
|
|
is derived from the 64-bit *unsigned long*, while the ecc_blocks variable
|
|
this value gets assigned to has (always 32-bit) *int* type. Even if that
|
|
value fits into *int* type, an overflow is still possible when calculating
|
|
the size_t typed ecc_total variable further below since there's no cast to
|
|
any 64-bit type before multiplication. Declaring the ecc_blocks variable
|
|
as *size_t* should fix this mess...
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with the SVACE static
|
|
analysis tool.(CVE-2023-52685)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/bridge: tpd12s015: Drop buggy __exit annotation for remove function
|
|
|
|
With tpd12s015_remove() marked with __exit this function is discarded
|
|
when the driver is compiled as a built-in. The result is that when the
|
|
driver unbinds there is no cleanup done which results in resource
|
|
leakage or worse.(CVE-2023-52694)
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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: 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:
|
|
|
|
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:
|
|
|
|
btrfs: fix information leak in btrfs_ioctl_logical_to_ino()
|
|
|
|
Syzbot reported the following information leak for in
|
|
btrfs_ioctl_logical_to_ino():
|
|
|
|
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
|
BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40
|
|
instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
|
_copy_to_user+0xbc/0x110 lib/usercopy.c:40
|
|
copy_to_user include/linux/uaccess.h:191 [inline]
|
|
btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499
|
|
btrfs_ioctl+0x714/0x1260
|
|
vfs_ioctl fs/ioctl.c:51 [inline]
|
|
__do_sys_ioctl fs/ioctl.c:904 [inline]
|
|
__se_sys_ioctl+0x261/0x450 fs/ioctl.c:890
|
|
__x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890
|
|
x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
|
|
|
Uninit was created at:
|
|
__kmalloc_large_node+0x231/0x370 mm/slub.c:3921
|
|
__do_kmalloc_node mm/slub.c:3954 [inline]
|
|
__kmalloc_node+0xb07/0x1060 mm/slub.c:3973
|
|
kmalloc_node include/linux/slab.h:648 [inline]
|
|
kvmalloc_node+0xc0/0x2d0 mm/util.c:634
|
|
kvmalloc include/linux/slab.h:766 [inline]
|
|
init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779
|
|
btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480
|
|
btrfs_ioctl+0x714/0x1260
|
|
vfs_ioctl fs/ioctl.c:51 [inline]
|
|
__do_sys_ioctl fs/ioctl.c:904 [inline]
|
|
__se_sys_ioctl+0x261/0x450 fs/ioctl.c:890
|
|
__x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890
|
|
x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
|
|
|
Bytes 40-65535 of 65536 are uninitialized
|
|
Memory access of size 65536 starts at ffff888045a40000
|
|
|
|
This happens, because we're copying a 'struct btrfs_data_container' back
|
|
to user-space. This btrfs_data_container is allocated in
|
|
'init_data_container()' via kvmalloc(), which does not zero-fill the
|
|
memory.
|
|
|
|
Fix this by using kvzalloc() which zeroes out the memory on allocation.(CVE-2024-35849)
|
|
|
|
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)</Note>
|
|
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS.
|
|
|
|
openEuler Security has rated this update as having a security impact of medium. 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">Medium</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-1679</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<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-52685</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52694</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-52837</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-52879</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-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-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-35845</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35849</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35930</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52650</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52685</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52694</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-52837</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52867</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52879</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-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-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-35845</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35849</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35930</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" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">openEuler-22.03-LTS</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="kernel-source-5.10.0-60.139.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-source-5.10.0-60.139.0.166.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-5.10.0-60.139.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">bpftool-debuginfo-5.10.0-60.139.0.166.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-5.10.0-60.139.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-5.10.0-60.139.0.166.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-5.10.0-60.139.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">bpftool-5.10.0-60.139.0.166.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-60.139.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">perf-debuginfo-5.10.0-60.139.0.166.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-60.139.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-devel-5.10.0-60.139.0.166.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-60.139.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">perf-5.10.0-60.139.0.166.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-60.139.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-debugsource-5.10.0-60.139.0.166.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-60.139.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">python3-perf-debuginfo-5.10.0-60.139.0.166.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-60.139.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">python3-perf-5.10.0-60.139.0.166.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-60.139.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-5.10.0-60.139.0.166.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-60.139.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-debuginfo-5.10.0-60.139.0.166.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-60.139.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-headers-5.10.0-60.139.0.166.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-60.139.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-devel-5.10.0-60.139.0.166.oe2203.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-60.139.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-debuginfo-5.10.0-60.139.0.166.oe2203.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-5.10.0-60.139.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-5.10.0-60.139.0.166.oe2203.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="kernel-5.10.0-60.139.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-5.10.0-60.139.0.166.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-60.139.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-headers-5.10.0-60.139.0.166.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-60.139.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">perf-5.10.0-60.139.0.166.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-5.10.0-60.139.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">bpftool-5.10.0-60.139.0.166.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-60.139.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">python3-perf-debuginfo-5.10.0-60.139.0.166.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-60.139.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-5.10.0-60.139.0.166.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-60.139.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-debuginfo-5.10.0-60.139.0.166.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-5.10.0-60.139.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">bpftool-debuginfo-5.10.0-60.139.0.166.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-60.139.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">python3-perf-5.10.0-60.139.0.166.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-60.139.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-debuginfo-5.10.0-60.139.0.166.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-60.139.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">perf-debuginfo-5.10.0-60.139.0.166.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-60.139.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-devel-5.10.0-60.139.0.166.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-60.139.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-source-5.10.0-60.139.0.166.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-60.139.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-devel-5.10.0-60.139.0.166.oe2203.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-60.139.0.166" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-debugsource-5.10.0-60.139.0.166.oe2203.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/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</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-1679</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:
|
|
|
|
pstore: ram_core: fix possible overflow in persistent_ram_init_ecc()
|
|
|
|
In persistent_ram_init_ecc(), on 64-bit arches DIV_ROUND_UP() will return
|
|
64-bit value since persistent_ram_zone::buffer_size has type size_t which
|
|
is derived from the 64-bit *unsigned long*, while the ecc_blocks variable
|
|
this value gets assigned to has (always 32-bit) *int* type. Even if that
|
|
value fits into *int* type, an overflow is still possible when calculating
|
|
the size_t typed ecc_total variable further below since there's no cast to
|
|
any 64-bit type before multiplication. Declaring the ecc_blocks variable
|
|
as *size_t* should fix this mess...
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with the SVACE static
|
|
analysis tool.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52685</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-1679</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:
|
|
|
|
drm/bridge: tpd12s015: Drop buggy __exit annotation for remove function
|
|
|
|
With tpd12s015_remove() marked with __exit this function is discarded
|
|
when the driver is compiled as a built-in. The result is that when the
|
|
driver unbinds there is no cleanup done which results in resource
|
|
leakage or worse.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52694</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-1679</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:
|
|
|
|
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</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-1679</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/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</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-1679</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:
|
|
|
|
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</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-1679</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:
|
|
|
|
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</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-1679</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:
|
|
|
|
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</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-1679</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:
|
|
|
|
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</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-1679</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="10" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="10" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nfs: 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</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-1679</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:
|
|
|
|
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</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-1679</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:
|
|
|
|
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</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-1679</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:
|
|
|
|
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</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-1679</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:
|
|
|
|
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</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-1679</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:
|
|
|
|
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</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-1679</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:
|
|
|
|
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</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-1679</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:
|
|
|
|
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</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-1679</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:
|
|
|
|
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</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-1679</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:
|
|
|
|
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</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-1679</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:
|
|
|
|
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</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-1679</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:
|
|
|
|
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</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-1679</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: 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</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-1679</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:
|
|
|
|
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</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-1679</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:
|
|
|
|
btrfs: fix information leak in btrfs_ioctl_logical_to_ino()
|
|
|
|
Syzbot reported the following information leak for in
|
|
btrfs_ioctl_logical_to_ino():
|
|
|
|
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
|
BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40
|
|
instrument_copy_to_user include/linux/instrumented.h:114 [inline]
|
|
_copy_to_user+0xbc/0x110 lib/usercopy.c:40
|
|
copy_to_user include/linux/uaccess.h:191 [inline]
|
|
btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499
|
|
btrfs_ioctl+0x714/0x1260
|
|
vfs_ioctl fs/ioctl.c:51 [inline]
|
|
__do_sys_ioctl fs/ioctl.c:904 [inline]
|
|
__se_sys_ioctl+0x261/0x450 fs/ioctl.c:890
|
|
__x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890
|
|
x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
|
|
|
Uninit was created at:
|
|
__kmalloc_large_node+0x231/0x370 mm/slub.c:3921
|
|
__do_kmalloc_node mm/slub.c:3954 [inline]
|
|
__kmalloc_node+0xb07/0x1060 mm/slub.c:3973
|
|
kmalloc_node include/linux/slab.h:648 [inline]
|
|
kvmalloc_node+0xc0/0x2d0 mm/util.c:634
|
|
kvmalloc include/linux/slab.h:766 [inline]
|
|
init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779
|
|
btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480
|
|
btrfs_ioctl+0x714/0x1260
|
|
vfs_ioctl fs/ioctl.c:51 [inline]
|
|
__do_sys_ioctl fs/ioctl.c:904 [inline]
|
|
__se_sys_ioctl+0x261/0x450 fs/ioctl.c:890
|
|
__x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890
|
|
x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
|
|
|
Bytes 40-65535 of 65536 are uninitialized
|
|
Memory access of size 65536 starts at ffff888045a40000
|
|
|
|
This happens, because we're copying a 'struct btrfs_data_container' back
|
|
to user-space. This btrfs_data_container is allocated in
|
|
'init_data_container()' via kvmalloc(), which does not zero-fill the
|
|
memory.
|
|
|
|
Fix this by using kvzalloc() which zeroes out the memory on allocation.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-35849</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS</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-1679</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:
|
|
|
|
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</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-1679</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |