6548 lines
278 KiB
XML
6548 lines
278 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
|
|
<DocumentTitle xml:lang="en">An update for kernel is now available for openEuler-20.03-LTS-SP4</DocumentTitle>
|
|
<DocumentType>Security Advisory</DocumentType>
|
|
<DocumentPublisher Type="Vendor">
|
|
<ContactDetails>openeuler-security@openeuler.org</ContactDetails>
|
|
<IssuingAuthority>openEuler security committee</IssuingAuthority>
|
|
</DocumentPublisher>
|
|
<DocumentTracking>
|
|
<Identification>
|
|
<ID>openEuler-SA-2024-1678</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-20.03-LTS-SP4.</Note>
|
|
<Note Title="Description" Type="General" Ordinal="3" xml:lang="en">The Linux Kernel, the operating system core itself.
|
|
|
|
Security Fix(es):
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
usb: dwc3: ep0: fix NULL pointer exception
|
|
|
|
There is no validation of the index from dwc3_wIndex_to_dep() and we might
|
|
be referring a non-existing ep and trigger a NULL pointer exception. In
|
|
certain configurations we might use fewer eps and the index might wrongly
|
|
indicate a larger ep index than existing.
|
|
|
|
By adding this validation from the patch we can actually report a wrong
|
|
index back to the caller.
|
|
|
|
In our usecase we are using a composite device on an older kernel, but
|
|
upstream might use this fix also. Unfortunately, I cannot describe the
|
|
hardware for others to reproduce the issue as it is a proprietary
|
|
implementation.
|
|
|
|
[ 82.958261] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a4
|
|
[ 82.966891] Mem abort info:
|
|
[ 82.969663] ESR = 0x96000006
|
|
[ 82.972703] Exception class = DABT (current EL), IL = 32 bits
|
|
[ 82.978603] SET = 0, FnV = 0
|
|
[ 82.981642] EA = 0, S1PTW = 0
|
|
[ 82.984765] Data abort info:
|
|
[ 82.987631] ISV = 0, ISS = 0x00000006
|
|
[ 82.991449] CM = 0, WnR = 0
|
|
[ 82.994409] user pgtable: 4k pages, 39-bit VAs, pgdp = 00000000c6210ccc
|
|
[ 83.000999] [00000000000000a4] pgd=0000000053aa5003, pud=0000000053aa5003, pmd=0000000000000000
|
|
[ 83.009685] Internal error: Oops: 96000006 [#1] PREEMPT SMP
|
|
[ 83.026433] Process irq/62-dwc3 (pid: 303, stack limit = 0x000000003985154c)
|
|
[ 83.033470] CPU: 0 PID: 303 Comm: irq/62-dwc3 Not tainted 4.19.124 #1
|
|
[ 83.044836] pstate: 60000085 (nZCv daIf -PAN -UAO)
|
|
[ 83.049628] pc : dwc3_ep0_handle_feature+0x414/0x43c
|
|
[ 83.054558] lr : dwc3_ep0_interrupt+0x3b4/0xc94
|
|
|
|
...
|
|
|
|
[ 83.141788] Call trace:
|
|
[ 83.144227] dwc3_ep0_handle_feature+0x414/0x43c
|
|
[ 83.148823] dwc3_ep0_interrupt+0x3b4/0xc94
|
|
[ 83.181546] ---[ end trace aac6b5267d84c32f ]---(CVE-2021-47269)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
isdn: mISDN: netjet: Fix crash in nj_probe:
|
|
|
|
'nj_setup' in netjet.c might fail with -EIO and in this case
|
|
'card->irq' is initialized and is bigger than zero. A subsequent call to
|
|
'nj_release' will free the irq that has not been requested.
|
|
|
|
Fix this bug by deleting the previous assignment to 'card->irq' and just
|
|
keep the assignment before 'request_irq'.
|
|
|
|
The KASAN's log reveals it:
|
|
|
|
[ 3.354615 ] WARNING: CPU: 0 PID: 1 at kernel/irq/manage.c:1826
|
|
free_irq+0x100/0x480
|
|
[ 3.355112 ] Modules linked in:
|
|
[ 3.355310 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
|
|
5.13.0-rc1-00144-g25a1298726e #13
|
|
[ 3.355816 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
|
|
rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
|
|
[ 3.356552 ] RIP: 0010:free_irq+0x100/0x480
|
|
[ 3.356820 ] Code: 6e 08 74 6f 4d 89 f4 e8 5e ac 09 00 4d 8b 74 24 18
|
|
4d 85 f6 75 e3 e8 4f ac 09 00 8b 75 c8 48 c7 c7 78 c1 2e 85 e8 e0 cf f5
|
|
ff <0f> 0b 48 8b 75 c0 4c 89 ff e8 72 33 0b 03 48 8b 43 40 4c 8b a0 80
|
|
[ 3.358012 ] RSP: 0000:ffffc90000017b48 EFLAGS: 00010082
|
|
[ 3.358357 ] RAX: 0000000000000000 RBX: ffff888104dc8000 RCX:
|
|
0000000000000000
|
|
[ 3.358814 ] RDX: ffff8881003c8000 RSI: ffffffff8124a9e6 RDI:
|
|
00000000ffffffff
|
|
[ 3.359272 ] RBP: ffffc90000017b88 R08: 0000000000000000 R09:
|
|
0000000000000000
|
|
[ 3.359732 ] R10: ffffc900000179f0 R11: 0000000000001d04 R12:
|
|
0000000000000000
|
|
[ 3.360195 ] R13: ffff888107dc6000 R14: ffff888107dc6928 R15:
|
|
ffff888104dc80a8
|
|
[ 3.360652 ] FS: 0000000000000000(0000) GS:ffff88817bc00000(0000)
|
|
knlGS:0000000000000000
|
|
[ 3.361170 ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 3.361538 ] CR2: 0000000000000000 CR3: 000000000582e000 CR4:
|
|
00000000000006f0
|
|
[ 3.362003 ] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
|
|
0000000000000000
|
|
[ 3.362175 ] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
|
|
0000000000000400
|
|
[ 3.362175 ] Call Trace:
|
|
[ 3.362175 ] nj_release+0x51/0x1e0
|
|
[ 3.362175 ] nj_probe+0x450/0x950
|
|
[ 3.362175 ] ? pci_device_remove+0x110/0x110
|
|
[ 3.362175 ] local_pci_probe+0x45/0xa0
|
|
[ 3.362175 ] pci_device_probe+0x12b/0x1d0
|
|
[ 3.362175 ] really_probe+0x2a9/0x610
|
|
[ 3.362175 ] driver_probe_device+0x90/0x1d0
|
|
[ 3.362175 ] ? mutex_lock_nested+0x1b/0x20
|
|
[ 3.362175 ] device_driver_attach+0x68/0x70
|
|
[ 3.362175 ] __driver_attach+0x124/0x1b0
|
|
[ 3.362175 ] ? device_driver_attach+0x70/0x70
|
|
[ 3.362175 ] bus_for_each_dev+0xbb/0x110
|
|
[ 3.362175 ] ? rdinit_setup+0x45/0x45
|
|
[ 3.362175 ] driver_attach+0x27/0x30
|
|
[ 3.362175 ] bus_add_driver+0x1eb/0x2a0
|
|
[ 3.362175 ] driver_register+0xa9/0x180
|
|
[ 3.362175 ] __pci_register_driver+0x82/0x90
|
|
[ 3.362175 ] ? w6692_init+0x38/0x38
|
|
[ 3.362175 ] nj_init+0x36/0x38
|
|
[ 3.362175 ] do_one_initcall+0x7f/0x3d0
|
|
[ 3.362175 ] ? rdinit_setup+0x45/0x45
|
|
[ 3.362175 ] ? rcu_read_lock_sched_held+0x4f/0x80
|
|
[ 3.362175 ] kernel_init_freeable+0x2aa/0x301
|
|
[ 3.362175 ] ? rest_init+0x2c0/0x2c0
|
|
[ 3.362175 ] kernel_init+0x18/0x190
|
|
[ 3.362175 ] ? rest_init+0x2c0/0x2c0
|
|
[ 3.362175 ] ? rest_init+0x2c0/0x2c0
|
|
[ 3.362175 ] ret_from_fork+0x1f/0x30
|
|
[ 3.362175 ] Kernel panic - not syncing: panic_on_warn set ...
|
|
[ 3.362175 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
|
|
5.13.0-rc1-00144-g25a1298726e #13
|
|
[ 3.362175 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
|
|
rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
|
|
[ 3.362175 ] Call Trace:
|
|
[ 3.362175 ] dump_stack+0xba/0xf5
|
|
[ 3.362175 ] ? free_irq+0x100/0x480
|
|
[ 3.362175 ] panic+0x15a/0x3f2
|
|
[ 3.362175 ] ? __warn+0xf2/0x150
|
|
[ 3.362175 ] ? free_irq+0x100/0x480
|
|
[ 3.362175 ] __warn+0x108/0x150
|
|
[ 3.362175 ] ? free_irq+0x100/0x480
|
|
[ 3.362175 ] report_bug+0x119/0x1c0
|
|
[ 3.362175 ] handle_bug+0x3b/0x80
|
|
[ 3.362175 ] exc_invalid_op+0x18/0x70
|
|
[ 3.362175 ] asm_exc_invalid_op+0x12/0x20
|
|
[ 3.362175 ] RIP: 0010:free_irq+0x100
|
|
---truncated---(CVE-2021-47284)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
f2fs: fix to avoid racing on fsync_entry_slab by multi filesystem instances
|
|
|
|
As syzbot reported, there is an use-after-free issue during f2fs recovery:
|
|
|
|
Use-after-free write at 0xffff88823bc16040 (in kfence-#10):
|
|
kmem_cache_destroy+0x1f/0x120 mm/slab_common.c:486
|
|
f2fs_recover_fsync_data+0x75b0/0x8380 fs/f2fs/recovery.c:869
|
|
f2fs_fill_super+0x9393/0xa420 fs/f2fs/super.c:3945
|
|
mount_bdev+0x26c/0x3a0 fs/super.c:1367
|
|
legacy_get_tree+0xea/0x180 fs/fs_context.c:592
|
|
vfs_get_tree+0x86/0x270 fs/super.c:1497
|
|
do_new_mount fs/namespace.c:2905 [inline]
|
|
path_mount+0x196f/0x2be0 fs/namespace.c:3235
|
|
do_mount fs/namespace.c:3248 [inline]
|
|
__do_sys_mount fs/namespace.c:3456 [inline]
|
|
__se_sys_mount+0x2f9/0x3b0 fs/namespace.c:3433
|
|
do_syscall_64+0x3f/0xb0 arch/x86/entry/common.c:47
|
|
entry_SYSCALL_64_after_hwframe+0x44/0xae
|
|
|
|
The root cause is multi f2fs filesystem instances can race on accessing
|
|
global fsync_entry_slab pointer, result in use-after-free issue of slab
|
|
cache, fixes to init/destroy this slab cache only once during module
|
|
init/destroy procedure to avoid this issue.(CVE-2021-47335)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
hwmon: (mlxreg-fan) Return non-zero value when fan current state is enforced from sysfs
|
|
|
|
Fan speed minimum can be enforced from sysfs. For example, setting
|
|
current fan speed to 20 is used to enforce fan speed to be at 100%
|
|
speed, 19 - to be not below 90% speed, etcetera. This feature provides
|
|
ability to limit fan speed according to some system wise
|
|
considerations, like absence of some replaceable units or high system
|
|
ambient temperature.
|
|
|
|
Request for changing fan minimum speed is configuration request and can
|
|
be set only through 'sysfs' write procedure. In this situation value of
|
|
argument 'state' is above nominal fan speed maximum.
|
|
|
|
Return non-zero code in this case to avoid
|
|
thermal_cooling_device_stats_update() call, because in this case
|
|
statistics update violates thermal statistics table range.
|
|
The issues is observed in case kernel is configured with option
|
|
CONFIG_THERMAL_STATISTICS.
|
|
|
|
Here is the trace from KASAN:
|
|
[ 159.506659] BUG: KASAN: slab-out-of-bounds in thermal_cooling_device_stats_update+0x7d/0xb0
|
|
[ 159.516016] Read of size 4 at addr ffff888116163840 by task hw-management.s/7444
|
|
[ 159.545625] Call Trace:
|
|
[ 159.548366] dump_stack+0x92/0xc1
|
|
[ 159.552084] ? thermal_cooling_device_stats_update+0x7d/0xb0
|
|
[ 159.635869] thermal_zone_device_update+0x345/0x780
|
|
[ 159.688711] thermal_zone_device_set_mode+0x7d/0xc0
|
|
[ 159.694174] mlxsw_thermal_modules_init+0x48f/0x590 [mlxsw_core]
|
|
[ 159.700972] ? mlxsw_thermal_set_cur_state+0x5a0/0x5a0 [mlxsw_core]
|
|
[ 159.731827] mlxsw_thermal_init+0x763/0x880 [mlxsw_core]
|
|
[ 160.070233] RIP: 0033:0x7fd995909970
|
|
[ 160.074239] Code: 73 01 c3 48 8b 0d 28 d5 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 99 2d 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ..
|
|
[ 160.095242] RSP: 002b:00007fff54f5d938 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
|
|
[ 160.103722] RAX: ffffffffffffffda RBX: 0000000000000013 RCX: 00007fd995909970
|
|
[ 160.111710] RDX: 0000000000000013 RSI: 0000000001906008 RDI: 0000000000000001
|
|
[ 160.119699] RBP: 0000000001906008 R08: 00007fd995bc9760 R09: 00007fd996210700
|
|
[ 160.127687] R10: 0000000000000073 R11: 0000000000000246 R12: 0000000000000013
|
|
[ 160.135673] R13: 0000000000000001 R14: 00007fd995bc8600 R15: 0000000000000013
|
|
[ 160.143671]
|
|
[ 160.145338] Allocated by task 2924:
|
|
[ 160.149242] kasan_save_stack+0x19/0x40
|
|
[ 160.153541] __kasan_kmalloc+0x7f/0xa0
|
|
[ 160.157743] __kmalloc+0x1a2/0x2b0
|
|
[ 160.161552] thermal_cooling_device_setup_sysfs+0xf9/0x1a0
|
|
[ 160.167687] __thermal_cooling_device_register+0x1b5/0x500
|
|
[ 160.173833] devm_thermal_of_cooling_device_register+0x60/0xa0
|
|
[ 160.180356] mlxreg_fan_probe+0x474/0x5e0 [mlxreg_fan]
|
|
[ 160.248140]
|
|
[ 160.249807] The buggy address belongs to the object at ffff888116163400
|
|
[ 160.249807] which belongs to the cache kmalloc-1k of size 1024
|
|
[ 160.263814] The buggy address is located 64 bytes to the right of
|
|
[ 160.263814] 1024-byte region [ffff888116163400, ffff888116163800)
|
|
[ 160.277536] The buggy address belongs to the page:
|
|
[ 160.282898] page:0000000012275840 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888116167000 pfn:0x116160
|
|
[ 160.294872] head:0000000012275840 order:3 compound_mapcount:0 compound_pincount:0
|
|
[ 160.303251] flags: 0x200000000010200(slab|head|node=0|zone=2)
|
|
[ 160.309694] raw: 0200000000010200 ffffea00046f7208 ffffea0004928208 ffff88810004dbc0
|
|
[ 160.318367] raw: ffff888116167000 00000000000a0006 00000001ffffffff 0000000000000000
|
|
[ 160.327033] page dumped because: kasan: bad access detected
|
|
[ 160.333270]
|
|
[ 160.334937] Memory state around the buggy address:
|
|
[ 160.356469] >ffff888116163800: fc ..(CVE-2021-47393)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ptp: Fix possible memory leak in ptp_clock_register()
|
|
|
|
I got memory leak as follows when doing fault injection test:
|
|
|
|
unreferenced object 0xffff88800906c618 (size 8):
|
|
comm "i2c-idt82p33931", pid 4421, jiffies 4294948083 (age 13.188s)
|
|
hex dump (first 8 bytes):
|
|
70 74 70 30 00 00 00 00 ptp0....
|
|
backtrace:
|
|
[<00000000312ed458>] __kmalloc_track_caller+0x19f/0x3a0
|
|
[<0000000079f6e2ff>] kvasprintf+0xb5/0x150
|
|
[<0000000026aae54f>] kvasprintf_const+0x60/0x190
|
|
[<00000000f323a5f7>] kobject_set_name_vargs+0x56/0x150
|
|
[<000000004e35abdd>] dev_set_name+0xc0/0x100
|
|
[<00000000f20cfe25>] ptp_clock_register+0x9f4/0xd30 [ptp]
|
|
[<000000008bb9f0de>] idt82p33_probe.cold+0x8b6/0x1561 [ptp_idt82p33]
|
|
|
|
When posix_clock_register() returns an error, the name allocated
|
|
in dev_set_name() will be leaked, the put_device() should be used
|
|
to give up the device reference, then the name will be freed in
|
|
kobject_cleanup() and other memory will be freed in ptp_clock_release().(CVE-2021-47455)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: qla2xxx: Fix a memory leak in an error path of qla2x00_process_els()
|
|
|
|
Commit 8c0eb596baa5 ("[SCSI] qla2xxx: Fix a memory leak in an error path of
|
|
qla2x00_process_els()"), intended to change:
|
|
|
|
bsg_job->request->msgcode == FC_BSG_HST_ELS_NOLOGIN
|
|
|
|
|
|
bsg_job->request->msgcode != FC_BSG_RPT_ELS
|
|
|
|
but changed it to:
|
|
|
|
bsg_job->request->msgcode == FC_BSG_RPT_ELS
|
|
|
|
instead.
|
|
|
|
Change the == to a != to avoid leaking the fcport structure or freeing
|
|
unallocated memory.(CVE-2021-47473)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells
|
|
|
|
If a cell has 'nbits' equal to a multiple of BITS_PER_BYTE the logic
|
|
|
|
*p &= GENMASK((cell->nbits%BITS_PER_BYTE) - 1, 0);
|
|
|
|
will become undefined behavior because nbits modulo BITS_PER_BYTE is 0, and we
|
|
subtract one from that making a large number that is then shifted more than the
|
|
number of bits that fit into an unsigned long.
|
|
|
|
UBSAN reports this problem:
|
|
|
|
UBSAN: shift-out-of-bounds in drivers/nvmem/core.c:1386:8
|
|
shift exponent 64 is too large for 64-bit type 'unsigned long'
|
|
CPU: 6 PID: 7 Comm: kworker/u16:0 Not tainted 5.15.0-rc3+ #9
|
|
Hardware name: Google Lazor (rev3+) with KB Backlight (DT)
|
|
Workqueue: events_unbound deferred_probe_work_func
|
|
Call trace:
|
|
dump_backtrace+0x0/0x170
|
|
show_stack+0x24/0x30
|
|
dump_stack_lvl+0x64/0x7c
|
|
dump_stack+0x18/0x38
|
|
ubsan_epilogue+0x10/0x54
|
|
__ubsan_handle_shift_out_of_bounds+0x180/0x194
|
|
__nvmem_cell_read+0x1ec/0x21c
|
|
nvmem_cell_read+0x58/0x94
|
|
nvmem_cell_read_variable_common+0x4c/0xb0
|
|
nvmem_cell_read_variable_le_u32+0x40/0x100
|
|
a6xx_gpu_init+0x170/0x2f4
|
|
adreno_bind+0x174/0x284
|
|
component_bind_all+0xf0/0x264
|
|
msm_drm_bind+0x1d8/0x7a0
|
|
try_to_bring_up_master+0x164/0x1ac
|
|
__component_add+0xbc/0x13c
|
|
component_add+0x20/0x2c
|
|
dp_display_probe+0x340/0x384
|
|
platform_probe+0xc0/0x100
|
|
really_probe+0x110/0x304
|
|
__driver_probe_device+0xb8/0x120
|
|
driver_probe_device+0x4c/0xfc
|
|
__device_attach_driver+0xb0/0x128
|
|
bus_for_each_drv+0x90/0xdc
|
|
__device_attach+0xc8/0x174
|
|
device_initial_probe+0x20/0x2c
|
|
bus_probe_device+0x40/0xa4
|
|
deferred_probe_work_func+0x7c/0xb8
|
|
process_one_work+0x128/0x21c
|
|
process_scheduled_works+0x40/0x54
|
|
worker_thread+0x1ec/0x2a8
|
|
kthread+0x138/0x158
|
|
ret_from_fork+0x10/0x20
|
|
|
|
Fix it by making sure there are any bits to mask out.(CVE-2021-47497)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: mpt3sas: Fix use-after-free warning
|
|
|
|
Fix the following use-after-free warning which is observed during
|
|
controller reset:
|
|
|
|
refcount_t: underflow; use-after-free.
|
|
WARNING: CPU: 23 PID: 5399 at lib/refcount.c:28 refcount_warn_saturate+0xa6/0xf0(CVE-2022-48695)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nvmet: fix a use-after-free
|
|
|
|
Fix the following use-after-free complaint triggered by blktests nvme/004:
|
|
|
|
BUG: KASAN: user-memory-access in blk_mq_complete_request_remote+0xac/0x350
|
|
Read of size 4 at addr 0000607bd1835943 by task kworker/13:1/460
|
|
Workqueue: nvmet-wq nvme_loop_execute_work [nvme_loop]
|
|
Call Trace:
|
|
show_stack+0x52/0x58
|
|
dump_stack_lvl+0x49/0x5e
|
|
print_report.cold+0x36/0x1e2
|
|
kasan_report+0xb9/0xf0
|
|
__asan_load4+0x6b/0x80
|
|
blk_mq_complete_request_remote+0xac/0x350
|
|
nvme_loop_queue_response+0x1df/0x275 [nvme_loop]
|
|
__nvmet_req_complete+0x132/0x4f0 [nvmet]
|
|
nvmet_req_complete+0x15/0x40 [nvmet]
|
|
nvmet_execute_io_connect+0x18a/0x1f0 [nvmet]
|
|
nvme_loop_execute_work+0x20/0x30 [nvme_loop]
|
|
process_one_work+0x56e/0xa70
|
|
worker_thread+0x2d1/0x640
|
|
kthread+0x183/0x1c0
|
|
ret_from_fork+0x1f/0x30(CVE-2022-48697)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ALSA: emu10k1: Fix out of bounds access in snd_emu10k1_pcm_channel_alloc()
|
|
|
|
The voice allocator sometimes begins allocating from near the end of the
|
|
array and then wraps around, however snd_emu10k1_pcm_channel_alloc()
|
|
accesses the newly allocated voices as if it never wrapped around.
|
|
|
|
This results in out of bounds access if the first voice has a high enough
|
|
index so that first_voice + requested_voice_count > NUM_G (64).
|
|
The more voices are requested, the more likely it is for this to occur.
|
|
|
|
This was initially discovered using PipeWire, however it can be reproduced
|
|
by calling aplay multiple times with 16 channels:
|
|
aplay -r 48000 -D plughw:CARD=Live,DEV=3 -c 16 /dev/zero
|
|
|
|
UBSAN: array-index-out-of-bounds in sound/pci/emu10k1/emupcm.c:127:40
|
|
index 65 is out of range for type 'snd_emu10k1_voice [64]'
|
|
CPU: 1 PID: 31977 Comm: aplay Tainted: G W IOE 6.0.0-rc2-emu10k1+ #7
|
|
Hardware name: ASUSTEK COMPUTER INC P5W DH Deluxe/P5W DH Deluxe, BIOS 3002 07/22/2010
|
|
Call Trace:
|
|
<TASK>
|
|
dump_stack_lvl+0x49/0x63
|
|
dump_stack+0x10/0x16
|
|
ubsan_epilogue+0x9/0x3f
|
|
__ubsan_handle_out_of_bounds.cold+0x44/0x49
|
|
snd_emu10k1_playback_hw_params+0x3bc/0x420 [snd_emu10k1]
|
|
snd_pcm_hw_params+0x29f/0x600 [snd_pcm]
|
|
snd_pcm_common_ioctl+0x188/0x1410 [snd_pcm]
|
|
? exit_to_user_mode_prepare+0x35/0x170
|
|
? do_syscall_64+0x69/0x90
|
|
? syscall_exit_to_user_mode+0x26/0x50
|
|
? do_syscall_64+0x69/0x90
|
|
? exit_to_user_mode_prepare+0x35/0x170
|
|
snd_pcm_ioctl+0x27/0x40 [snd_pcm]
|
|
__x64_sys_ioctl+0x95/0xd0
|
|
do_syscall_64+0x5c/0x90
|
|
? do_syscall_64+0x69/0x90
|
|
? do_syscall_64+0x69/0x90
|
|
entry_SYSCALL_64_after_hwframe+0x63/0xcd(CVE-2022-48702)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/radeon: add a force flush to delay work when radeon
|
|
|
|
Although radeon card fence and wait for gpu to finish processing current batch rings,
|
|
there is still a corner case that radeon lockup work queue may not be fully flushed,
|
|
and meanwhile the radeon_suspend_kms() function has called pci_set_power_state() to
|
|
put device in D3hot state.
|
|
Per PCI spec rev 4.0 on 5.3.1.4.1 D3hot State.
|
|
> Configuration and Message requests are the only TLPs accepted by a Function in
|
|
> the D3hot state. All other received Requests must be handled as Unsupported Requests,
|
|
> and all received Completions may optionally be handled as Unexpected Completions.
|
|
This issue will happen in following logs:
|
|
Unable to handle kernel paging request at virtual address 00008800e0008010
|
|
CPU 0 kworker/0:3(131): Oops 0
|
|
pc = [<ffffffff811bea5c>] ra = [<ffffffff81240844>] ps = 0000 Tainted: G W
|
|
pc is at si_gpu_check_soft_reset+0x3c/0x240
|
|
ra is at si_dma_is_lockup+0x34/0xd0
|
|
v0 = 0000000000000000 t0 = fff08800e0008010 t1 = 0000000000010000
|
|
t2 = 0000000000008010 t3 = fff00007e3c00000 t4 = fff00007e3c00258
|
|
t5 = 000000000000ffff t6 = 0000000000000001 t7 = fff00007ef078000
|
|
s0 = fff00007e3c016e8 s1 = fff00007e3c00000 s2 = fff00007e3c00018
|
|
s3 = fff00007e3c00000 s4 = fff00007fff59d80 s5 = 0000000000000000
|
|
s6 = fff00007ef07bd98
|
|
a0 = fff00007e3c00000 a1 = fff00007e3c016e8 a2 = 0000000000000008
|
|
a3 = 0000000000000001 a4 = 8f5c28f5c28f5c29 a5 = ffffffff810f4338
|
|
t8 = 0000000000000275 t9 = ffffffff809b66f8 t10 = ff6769c5d964b800
|
|
t11= 000000000000b886 pv = ffffffff811bea20 at = 0000000000000000
|
|
gp = ffffffff81d89690 sp = 00000000aa814126
|
|
Disabling lock debugging due to kernel taint
|
|
Trace:
|
|
[<ffffffff81240844>] si_dma_is_lockup+0x34/0xd0
|
|
[<ffffffff81119610>] radeon_fence_check_lockup+0xd0/0x290
|
|
[<ffffffff80977010>] process_one_work+0x280/0x550
|
|
[<ffffffff80977350>] worker_thread+0x70/0x7c0
|
|
[<ffffffff80977410>] worker_thread+0x130/0x7c0
|
|
[<ffffffff80982040>] kthread+0x200/0x210
|
|
[<ffffffff809772e0>] worker_thread+0x0/0x7c0
|
|
[<ffffffff80981f8c>] kthread+0x14c/0x210
|
|
[<ffffffff80911658>] ret_from_kernel_thread+0x18/0x20
|
|
[<ffffffff80981e40>] kthread+0x0/0x210
|
|
Code: ad3e0008 43f0074a ad7e0018 ad9e0020 8c3001e8 40230101
|
|
<88210000> 4821ed21
|
|
So force lockup work queue flush to fix this problem.(CVE-2022-48704)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/radeon: fix a possible null pointer dereference
|
|
|
|
In radeon_fp_native_mode(), the return value of drm_mode_duplicate()
|
|
is assigned to mode, which will lead to a NULL pointer dereference
|
|
on failure of drm_mode_duplicate(). Add a check to avoid npd.
|
|
|
|
The failure status of drm_cvt_mode() on the other path is checked too.(CVE-2022-48710)
|
|
|
|
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:
|
|
|
|
NTB: fix possible name leak in ntb_register_device()
|
|
|
|
If device_register() fails in ntb_register_device(), the device name
|
|
allocated by dev_set_name() should be freed. As per the comment in
|
|
device_register(), callers should use put_device() to give up the
|
|
reference in the error path. So fix this by calling put_device() in the
|
|
error path so that the name can be freed in kobject_cleanup().
|
|
|
|
As a result of this, put_device() in the error path of
|
|
ntb_register_device() is removed and the actual error is returned.
|
|
|
|
[mani: reworded commit message](CVE-2023-52652)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
SUNRPC: fix a memleak in gss_import_v2_context
|
|
|
|
The ctx->mech_used.data allocated by kmemdup is not freed in neither
|
|
gss_import_v2_context nor it only caller gss_krb5_import_sec_context,
|
|
which frees ctx on error.
|
|
|
|
Thus, this patch reform the last call of gss_import_v2_context to the
|
|
gss_krb5_import_ctx_v2, preventing the memleak while keepping the return
|
|
formation.(CVE-2023-52653)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
io_uring: drop any code related to SCM_RIGHTS
|
|
|
|
This is dead code after we dropped support for passing io_uring fds
|
|
over SCM_RIGHTS, get rid of it.(CVE-2023-52656)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ACPI: LPIT: Avoid u32 multiplication overflow
|
|
|
|
In lpit_update_residency() there is a possibility of overflow
|
|
in multiplication, if tsc_khz is large enough (> UINT_MAX/1000).
|
|
|
|
Change multiplication to mul_u32_u32().
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52683)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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/amd/pm: fix a double-free in si_dpm_init
|
|
|
|
When the allocation of
|
|
adev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries fails,
|
|
amdgpu_free_extended_power_table is called to free some fields of adev.
|
|
However, when the control flow returns to si_dpm_sw_init, it goes to
|
|
label dpm_failed and calls si_dpm_fini, which calls
|
|
amdgpu_free_extended_power_table again and free those fields again. Thus
|
|
a double-free is triggered.(CVE-2023-52691)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
calipso: fix memory leak in netlbl_calipso_add_pass()
|
|
|
|
If IPv6 support is disabled at boot (ipv6.disable=1),
|
|
the calipso_init() -> netlbl_calipso_ops_register() function isn't called,
|
|
and the netlbl_calipso_ops_get() function always returns NULL.
|
|
In this case, the netlbl_calipso_add_pass() function allocates memory
|
|
for the doi_def variable but doesn't free it with the calipso_doi_free().
|
|
|
|
BUG: memory leak
|
|
unreferenced object 0xffff888011d68180 (size 64):
|
|
comm "syz-executor.1", pid 10746, jiffies 4295410986 (age 17.928s)
|
|
hex dump (first 32 bytes):
|
|
00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
backtrace:
|
|
[<...>] kmalloc include/linux/slab.h:552 [inline]
|
|
[<...>] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [inline]
|
|
[<...>] netlbl_calipso_add+0x22e/0x4f0 net/netlabel/netlabel_calipso.c:111
|
|
[<...>] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739
|
|
[<...>] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]
|
|
[<...>] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800
|
|
[<...>] netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2515
|
|
[<...>] genl_rcv+0x29/0x40 net/netlink/genetlink.c:811
|
|
[<...>] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]
|
|
[<...>] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1339
|
|
[<...>] netlink_sendmsg+0x90a/0xdf0 net/netlink/af_netlink.c:1934
|
|
[<...>] sock_sendmsg_nosec net/socket.c:651 [inline]
|
|
[<...>] sock_sendmsg+0x157/0x190 net/socket.c:671
|
|
[<...>] ____sys_sendmsg+0x712/0x870 net/socket.c:2342
|
|
[<...>] ___sys_sendmsg+0xf8/0x170 net/socket.c:2396
|
|
[<...>] __sys_sendmsg+0xea/0x1b0 net/socket.c:2429
|
|
[<...>] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46
|
|
[<...>] entry_SYSCALL_64_after_hwframe+0x61/0xc6
|
|
|
|
Found by InfoTeCS on behalf of Linux Verification Center
|
|
(linuxtesting.org) with Syzkaller
|
|
|
|
[PM: merged via the LSM tree at Jakub Kicinski request](CVE-2023-52698)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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:
|
|
|
|
drm/amd: Fix UBSAN array-index-out-of-bounds for SMU7
|
|
|
|
For pptable structs that use flexible array sizes, use flexible arrays.(CVE-2023-52818)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
perf/core: Bail out early if the request AUX area is out of bound
|
|
|
|
When perf-record with a large AUX area, e.g 4GB, it fails with:
|
|
|
|
#perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1
|
|
failed to mmap with 12 (Cannot allocate memory)
|
|
|
|
and it reveals a WARNING with __alloc_pages():
|
|
|
|
------------[ cut here ]------------
|
|
WARNING: CPU: 44 PID: 17573 at mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248
|
|
Call trace:
|
|
__alloc_pages+0x1ec/0x248
|
|
__kmalloc_large_node+0xc0/0x1f8
|
|
__kmalloc_node+0x134/0x1e8
|
|
rb_alloc_aux+0xe0/0x298
|
|
perf_mmap+0x440/0x660
|
|
mmap_region+0x308/0x8a8
|
|
do_mmap+0x3c0/0x528
|
|
vm_mmap_pgoff+0xf4/0x1b8
|
|
ksys_mmap_pgoff+0x18c/0x218
|
|
__arm64_sys_mmap+0x38/0x58
|
|
invoke_syscall+0x50/0x128
|
|
el0_svc_common.constprop.0+0x58/0x188
|
|
do_el0_svc+0x34/0x50
|
|
el0_svc+0x34/0x108
|
|
el0t_64_sync_handler+0xb8/0xc0
|
|
el0t_64_sync+0x1a4/0x1a8
|
|
|
|
'rb->aux_pages' allocated by kcalloc() is a pointer array which is used to
|
|
maintains AUX trace pages. The allocated page for this array is physically
|
|
contiguous (and virtually contiguous) with an order of 0..MAX_ORDER. If the
|
|
size of pointer array crosses the limitation set by MAX_ORDER, it reveals a
|
|
WARNING.
|
|
|
|
So bail out early with -ENOMEM if the request AUX area is out of bound,
|
|
e.g.:
|
|
|
|
#perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1
|
|
failed to mmap with 12 (Cannot allocate memory)(CVE-2023-52835)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Input: synaptics-rmi4 - fix use after free in rmi_unregister_function()
|
|
|
|
The put_device() calls rmi_release_function() which frees "fn" so the
|
|
dereference on the next line "fn->num_of_irqs" is a use after free.
|
|
Move the put_device() to the end to fix this.(CVE-2023-52840)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: bttv: fix use after free error due to btv->timeout timer
|
|
|
|
There may be some a race condition between timer function
|
|
bttv_irq_timeout and bttv_remove. The timer is setup in
|
|
probe and there is no timer_delete operation in remove
|
|
function. When it hit kfree btv, the function might still be
|
|
invoked, which will cause use after free bug.
|
|
|
|
This bug is found by static analysis, it may be false positive.
|
|
|
|
Fix it by adding del_timer_sync invoking to the remove function.
|
|
|
|
cpu0 cpu1
|
|
bttv_probe
|
|
->timer_setup
|
|
->bttv_set_dma
|
|
->mod_timer;
|
|
bttv_remove
|
|
->kfree(btv);
|
|
->bttv_irq_timeout
|
|
->USE btv(CVE-2023-52847)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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:
|
|
|
|
thermal: core: prevent potential string overflow
|
|
|
|
The dev->id value comes from ida_alloc() so it's a number between zero
|
|
and INT_MAX. If it's too high then these sprintf()s will overflow.(CVE-2023-52868)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nilfs2: prevent kernel bug at submit_bh_wbc()
|
|
|
|
Fix a bug where nilfs_get_block() returns a successful status when
|
|
searching and inserting the specified block both fail inconsistently. If
|
|
this inconsistent behavior is not due to a previously fixed bug, then an
|
|
unexpected race is occurring, so return a temporary error -EAGAIN instead.
|
|
|
|
This prevents callers such as __block_write_begin_int() from requesting a
|
|
read into a buffer that is not mapped, which would cause the BUG_ON check
|
|
for the BH_Mapped flag in submit_bh_wbc() to fail.(CVE-2024-26955)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nilfs2: fix failure to detect DAT corruption in btree and direct mappings
|
|
|
|
Patch series "nilfs2: fix kernel bug at submit_bh_wbc()".
|
|
|
|
This resolves a kernel BUG reported by syzbot. Since there are two
|
|
flaws involved, I've made each one a separate patch.
|
|
|
|
The first patch alone resolves the syzbot-reported bug, but I think
|
|
both fixes should be sent to stable, so I've tagged them as such.
|
|
|
|
|
|
This patch (of 2):
|
|
|
|
Syzbot has reported a kernel bug in submit_bh_wbc() when writing file data
|
|
to a nilfs2 file system whose metadata is corrupted.
|
|
|
|
There are two flaws involved in this issue.
|
|
|
|
The first flaw is that when nilfs_get_block() locates a data block using
|
|
btree or direct mapping, if the disk address translation routine
|
|
nilfs_dat_translate() fails with internal code -ENOENT due to DAT metadata
|
|
corruption, it can be passed back to nilfs_get_block(). This causes
|
|
nilfs_get_block() to misidentify an existing block as non-existent,
|
|
causing both data block lookup and insertion to fail inconsistently.
|
|
|
|
The second flaw is that nilfs_get_block() returns a successful status in
|
|
this inconsistent state. This causes the caller __block_write_begin_int()
|
|
or others to request a read even though the buffer is not mapped,
|
|
resulting in a BUG_ON check for the BH_Mapped flag in submit_bh_wbc()
|
|
failing.
|
|
|
|
This fixes the first issue by changing the return value to code -EINVAL
|
|
when a conversion using DAT fails with code -ENOENT, avoiding the
|
|
conflicting condition that leads to the kernel bug described above. Here,
|
|
code -EINVAL indicates that metadata corruption was detected during the
|
|
block lookup, which will be properly handled as a file system error and
|
|
converted to -EIO when passing through the nilfs2 bmap layer.(CVE-2024-26956)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
s390/zcrypt: fix reference counting on zcrypt card objects
|
|
|
|
Tests with hot-plugging crytpo cards on KVM guests with debug
|
|
kernel build revealed an use after free for the load field of
|
|
the struct zcrypt_card. The reason was an incorrect reference
|
|
handling of the zcrypt card object which could lead to a free
|
|
of the zcrypt card object while it was still in use.
|
|
|
|
This is an example of the slab message:
|
|
|
|
kernel: 0x00000000885a7512-0x00000000885a7513 @offset=1298. First byte 0x68 instead of 0x6b
|
|
kernel: Allocated in zcrypt_card_alloc+0x36/0x70 [zcrypt] age=18046 cpu=3 pid=43
|
|
kernel: kmalloc_trace+0x3f2/0x470
|
|
kernel: zcrypt_card_alloc+0x36/0x70 [zcrypt]
|
|
kernel: zcrypt_cex4_card_probe+0x26/0x380 [zcrypt_cex4]
|
|
kernel: ap_device_probe+0x15c/0x290
|
|
kernel: really_probe+0xd2/0x468
|
|
kernel: driver_probe_device+0x40/0xf0
|
|
kernel: __device_attach_driver+0xc0/0x140
|
|
kernel: bus_for_each_drv+0x8c/0xd0
|
|
kernel: __device_attach+0x114/0x198
|
|
kernel: bus_probe_device+0xb4/0xc8
|
|
kernel: device_add+0x4d2/0x6e0
|
|
kernel: ap_scan_adapter+0x3d0/0x7c0
|
|
kernel: ap_scan_bus+0x5a/0x3b0
|
|
kernel: ap_scan_bus_wq_callback+0x40/0x60
|
|
kernel: process_one_work+0x26e/0x620
|
|
kernel: worker_thread+0x21c/0x440
|
|
kernel: Freed in zcrypt_card_put+0x54/0x80 [zcrypt] age=9024 cpu=3 pid=43
|
|
kernel: kfree+0x37e/0x418
|
|
kernel: zcrypt_card_put+0x54/0x80 [zcrypt]
|
|
kernel: ap_device_remove+0x4c/0xe0
|
|
kernel: device_release_driver_internal+0x1c4/0x270
|
|
kernel: bus_remove_device+0x100/0x188
|
|
kernel: device_del+0x164/0x3c0
|
|
kernel: device_unregister+0x30/0x90
|
|
kernel: ap_scan_adapter+0xc8/0x7c0
|
|
kernel: ap_scan_bus+0x5a/0x3b0
|
|
kernel: ap_scan_bus_wq_callback+0x40/0x60
|
|
kernel: process_one_work+0x26e/0x620
|
|
kernel: worker_thread+0x21c/0x440
|
|
kernel: kthread+0x150/0x168
|
|
kernel: __ret_from_fork+0x3c/0x58
|
|
kernel: ret_from_fork+0xa/0x30
|
|
kernel: Slab 0x00000372022169c0 objects=20 used=18 fp=0x00000000885a7c88 flags=0x3ffff00000000a00(workingset|slab|node=0|zone=1|lastcpupid=0x1ffff)
|
|
kernel: Object 0x00000000885a74b8 @offset=1208 fp=0x00000000885a7c88
|
|
kernel: Redzone 00000000885a74b0: bb bb bb bb bb bb bb bb ........
|
|
kernel: Object 00000000885a74b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
|
|
kernel: Object 00000000885a74c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
|
|
kernel: Object 00000000885a74d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
|
|
kernel: Object 00000000885a74e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
|
|
kernel: Object 00000000885a74f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
|
|
kernel: Object 00000000885a7508: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 68 4b 6b 6b 6b a5 kkkkkkkkkkhKkkk.
|
|
kernel: Redzone 00000000885a7518: bb bb bb bb bb bb bb bb ........
|
|
kernel: Padding 00000000885a756c: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ
|
|
kernel: CPU: 0 PID: 387 Comm: systemd-udevd Not tainted 6.8.0-HF #2
|
|
kernel: Hardware name: IBM 3931 A01 704 (KVM/Linux)
|
|
kernel: Call Trace:
|
|
kernel: [<00000000ca5ab5b8>] dump_stack_lvl+0x90/0x120
|
|
kernel: [<00000000c99d78bc>] check_bytes_and_report+0x114/0x140
|
|
kernel: [<00000000c99d53cc>] check_object+0x334/0x3f8
|
|
kernel: [<00000000c99d820c>] alloc_debug_processing+0xc4/0x1f8
|
|
kernel: [<00000000c99d852e>] get_partial_node.part.0+0x1ee/0x3e0
|
|
kernel: [<00000000c99d94ec>] ___slab_alloc+0xaf4/0x13c8
|
|
kernel: [<00000000c99d9e38>] __slab_alloc.constprop.0+0x78/0xb8
|
|
kernel: [<00000000c99dc8dc>] __kmalloc+0x434/0x590
|
|
kernel: [<00000000c9b4c0ce>] ext4_htree_store_dirent+0x4e/0x1c0
|
|
kernel: [<00000000c9b908a2>] htree_dirblock_to_tree+0x17a/0x3f0
|
|
kernel:
|
|
---truncated---(CVE-2024-26957)
|
|
|
|
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:
|
|
|
|
mm: swap: fix race between free_swap_and_cache() and swapoff()
|
|
|
|
There was previously a theoretical window where swapoff() could run and
|
|
teardown a swap_info_struct while a call to free_swap_and_cache() was
|
|
running in another thread. This could cause, amongst other bad
|
|
possibilities, swap_page_trans_huge_swapped() (called by
|
|
free_swap_and_cache()) to access the freed memory for swap_map.
|
|
|
|
This is a theoretical problem and I haven't been able to provoke it from a
|
|
test case. But there has been agreement based on code review that this is
|
|
possible (see link below).
|
|
|
|
Fix it by using get_swap_device()/put_swap_device(), which will stall
|
|
swapoff(). There was an extra check in _swap_info_get() to confirm that
|
|
the swap entry was not free. This isn't present in get_swap_device()
|
|
because it doesn't make sense in general due to the race between getting
|
|
the reference and swapoff. So I've added an equivalent check directly in
|
|
free_swap_and_cache().
|
|
|
|
Details of how to provoke one possible issue (thanks to David Hildenbrand
|
|
for deriving this):
|
|
|
|
--8<-----
|
|
|
|
__swap_entry_free() might be the last user and result in
|
|
"count == SWAP_HAS_CACHE".
|
|
|
|
swapoff->try_to_unuse() will stop as soon as soon as si->inuse_pages==0.
|
|
|
|
So the question is: could someone reclaim the folio and turn
|
|
si->inuse_pages==0, before we completed swap_page_trans_huge_swapped().
|
|
|
|
Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages are
|
|
still references by swap entries.
|
|
|
|
Process 1 still references subpage 0 via swap entry.
|
|
Process 2 still references subpage 1 via swap entry.
|
|
|
|
Process 1 quits. Calls free_swap_and_cache().
|
|
-> count == SWAP_HAS_CACHE
|
|
[then, preempted in the hypervisor etc.]
|
|
|
|
Process 2 quits. Calls free_swap_and_cache().
|
|
-> count == SWAP_HAS_CACHE
|
|
|
|
Process 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls
|
|
__try_to_reclaim_swap().
|
|
|
|
__try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()->
|
|
put_swap_folio()->free_swap_slot()->swapcache_free_entries()->
|
|
swap_entry_free()->swap_range_free()->
|
|
...
|
|
WRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries);
|
|
|
|
What stops swapoff to succeed after process 2 reclaimed the swap cache
|
|
but before process1 finished its call to swap_page_trans_huge_swapped()?
|
|
|
|
--8<-----(CVE-2024-26960)
|
|
|
|
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:
|
|
|
|
clk: qcom: mmcc-apq8084: 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-26966)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
clk: qcom: gcc-ipq8074: 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-26969)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
crypto: qat - resolve race condition during AER recovery
|
|
|
|
During the PCI AER system's error recovery process, the kernel driver
|
|
may encounter a race condition with freeing the reset_data structure's
|
|
memory. If the device restart will take more than 10 seconds the function
|
|
scheduling that restart will exit due to a timeout, and the reset_data
|
|
structure will be freed. However, this data structure is used for
|
|
completion notification after the restart is completed, which leads
|
|
to a UAF bug.
|
|
|
|
This results in a KFENCE bug notice.
|
|
|
|
BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat]
|
|
Use-after-free read at 0x00000000bc56fddf (in kfence-#142):
|
|
adf_device_reset_worker+0x38/0xa0 [intel_qat]
|
|
process_one_work+0x173/0x340
|
|
|
|
To resolve this race condition, the memory associated to the container
|
|
of the work_struct is freed on the worker if the timeout expired,
|
|
otherwise on the function that schedules the worker.
|
|
The timeout detection can be done by checking if the caller is
|
|
still waiting for completion or not by using completion_done() function.(CVE-2024-26974)
|
|
|
|
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:
|
|
|
|
nilfs2: fix OOB in nilfs_set_de_type
|
|
|
|
The size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is
|
|
defined as "S_IFMT >> S_SHIFT", but the nilfs_set_de_type() function,
|
|
which uses this array, specifies the index to read from the array in the
|
|
same way as "(mode & S_IFMT) >> S_SHIFT".
|
|
|
|
static void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode
|
|
*inode)
|
|
{
|
|
umode_t mode = inode->i_mode;
|
|
|
|
de->file_type = nilfs_type_by_mode[(mode & S_IFMT)>>S_SHIFT]; // oob
|
|
}
|
|
|
|
However, when the index is determined this way, an out-of-bounds (OOB)
|
|
error occurs by referring to an index that is 1 larger than the array size
|
|
when the condition "mode & S_IFMT == S_IFMT" is satisfied. Therefore, a
|
|
patch to resize the nilfs_type_by_mode array should be applied to prevent
|
|
OOB errors.(CVE-2024-26981)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Squashfs: check the inode number is not the invalid value of zero
|
|
|
|
Syskiller has produced an out of bounds access in fill_meta_index().
|
|
|
|
That out of bounds access is ultimately caused because the inode
|
|
has an inode number with the invalid value of zero, which was not checked.
|
|
|
|
The reason this causes the out of bounds access is due to following
|
|
sequence of events:
|
|
|
|
1. Fill_meta_index() is called to allocate (via empty_meta_index())
|
|
and fill a metadata index. It however suffers a data read error
|
|
and aborts, invalidating the newly returned empty metadata index.
|
|
It does this by setting the inode number of the index to zero,
|
|
which means unused (zero is not a valid inode number).
|
|
|
|
2. When fill_meta_index() is subsequently called again on another
|
|
read operation, locate_meta_index() returns the previous index
|
|
because it matches the inode number of 0. Because this index
|
|
has been returned it is expected to have been filled, and because
|
|
it hasn't been, an out of bounds access is performed.
|
|
|
|
This patch adds a sanity check which checks that the inode number
|
|
is not zero when the inode is created and returns -EINVAL if it is.
|
|
|
|
[phillip@squashfs.org.uk: whitespace fix]
|
|
Link: https://lkml.kernel.org/r/20240409204723.446925-1-phillip@squashfs.org.uk(CVE-2024-26982)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fs: sysfs: Fix reference leak in sysfs_break_active_protection()
|
|
|
|
The sysfs_break_active_protection() routine has an obvious reference
|
|
leak in its error path. If the call to kernfs_find_and_get() fails then
|
|
kn will be NULL, so the companion sysfs_unbreak_active_protection()
|
|
routine won't get called (and would only cause an access violation by
|
|
trying to dereference kn->parent if it was called). As a result, the
|
|
reference to kobj acquired at the start of the function will never be
|
|
released.
|
|
|
|
Fix the leak by adding an explicit kobject_put() call when kn is NULL.(CVE-2024-26993)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
speakup: Avoid crash on very long word
|
|
|
|
In case a console is set up really large and contains a really long word
|
|
(> 256 characters), we have to stop before the length of the word buffer.(CVE-2024-26994)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
usb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport error
|
|
|
|
When ncm function is working and then stop usb0 interface for link down,
|
|
eth_stop() is called. At this piont, accidentally if usb transport error
|
|
should happen in usb_ep_enable(), 'in_ep' and/or 'out_ep' may not be enabled.
|
|
|
|
After that, ncm_disable() is called to disable for ncm unbind
|
|
but gether_disconnect() is never called since 'in_ep' is not enabled.
|
|
|
|
As the result, ncm object is released in ncm unbind
|
|
but 'dev->port_usb' associated to 'ncm->port' is not NULL.
|
|
|
|
And when ncm bind again to recover netdev, ncm object is reallocated
|
|
but usb0 interface is already associated to previous released ncm object.
|
|
|
|
Therefore, once usb0 interface is up and eth_start_xmit() is called,
|
|
released ncm object is dereferrenced and it might cause use-after-free memory.
|
|
|
|
[function unlink via configfs]
|
|
usb0: eth_stop dev->port_usb=ffffff9b179c3200
|
|
--> error happens in usb_ep_enable().
|
|
NCM: ncm_disable: ncm=ffffff9b179c3200
|
|
--> no gether_disconnect() since ncm->port.in_ep->enabled is false.
|
|
NCM: ncm_unbind: ncm unbind ncm=ffffff9b179c3200
|
|
NCM: ncm_free: ncm free ncm=ffffff9b179c3200 <-- released ncm
|
|
|
|
[function link via configfs]
|
|
NCM: ncm_alloc: ncm alloc ncm=ffffff9ac4f8a000
|
|
NCM: ncm_bind: ncm bind ncm=ffffff9ac4f8a000
|
|
NCM: ncm_set_alt: ncm=ffffff9ac4f8a000 alt=0
|
|
usb0: eth_open dev->port_usb=ffffff9b179c3200 <-- previous released ncm
|
|
usb0: eth_start dev->port_usb=ffffff9b179c3200 <--
|
|
eth_start_xmit()
|
|
--> dev->wrap()
|
|
Unable to handle kernel paging request at virtual address dead00000000014f
|
|
|
|
This patch addresses the issue by checking if 'ncm->netdev' is not NULL at
|
|
ncm_disable() to call gether_disconnect() to deassociate 'dev->port_usb'.
|
|
It's more reasonable to check 'ncm->netdev' to call gether_connect/disconnect
|
|
rather than check 'ncm->port.in_ep->enabled' since it might not be enabled
|
|
but the gether connection might be established.(CVE-2024-26996)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
serial/pmac_zilog: Remove flawed mitigation for rx irq flood
|
|
|
|
The mitigation was intended to stop the irq completely. That may be
|
|
better than a hard lock-up but it turns out that you get a crash anyway
|
|
if you're using pmac_zilog as a serial console:
|
|
|
|
ttyPZ0: pmz: rx irq flood !
|
|
BUG: spinlock recursion on CPU#0, swapper/0
|
|
|
|
That's because the pr_err() call in pmz_receive_chars() results in
|
|
pmz_console_write() attempting to lock a spinlock already locked in
|
|
pmz_interrupt(). With CONFIG_DEBUG_SPINLOCK=y, this produces a fatal
|
|
BUG splat. The spinlock in question is the one in struct uart_port.
|
|
|
|
Even when it's not fatal, the serial port rx function ceases to work.
|
|
Also, the iteration limit doesn't play nicely with QEMU, as can be
|
|
seen in the bug report linked below.
|
|
|
|
A web search for other reports of the error message "pmz: rx irq flood"
|
|
didn't produce anything. So I don't think this code is needed any more.
|
|
Remove it.(CVE-2024-26999)
|
|
|
|
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:
|
|
|
|
comedi: vmk80xx: fix incomplete endpoint checking
|
|
|
|
While vmk80xx does have endpoint checking implemented, some things
|
|
can fall through the cracks. Depending on the hardware model,
|
|
URBs can have either bulk or interrupt type, and current version
|
|
of vmk80xx_find_usb_endpoints() function does not take that fully
|
|
into account. While this warning does not seem to be too harmful,
|
|
at the very least it will crash systems with 'panic_on_warn' set on
|
|
them.
|
|
|
|
Fix the issue found by Syzkaller [1] by somewhat simplifying the
|
|
endpoint checking process with usb_find_common_endpoints() and
|
|
ensuring that only expected endpoint types are present.
|
|
|
|
This patch has not been tested on real hardware.
|
|
|
|
[1] Syzkaller report:
|
|
usb 1-1: BOGUS urb xfer, pipe 1 != type 3
|
|
WARNING: CPU: 0 PID: 781 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503
|
|
...
|
|
Call Trace:
|
|
<TASK>
|
|
usb_start_wait_urb+0x113/0x520 drivers/usb/core/message.c:59
|
|
vmk80xx_reset_device drivers/comedi/drivers/vmk80xx.c:227 [inline]
|
|
vmk80xx_auto_attach+0xa1c/0x1a40 drivers/comedi/drivers/vmk80xx.c:818
|
|
comedi_auto_config+0x238/0x380 drivers/comedi/drivers.c:1067
|
|
usb_probe_interface+0x5cd/0xb00 drivers/usb/core/driver.c:399
|
|
...
|
|
|
|
Similar issue also found by Syzkaller:(CVE-2024-27001)
|
|
|
|
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:
|
|
|
|
net/sched: Fix mirred deadlock on device recursion
|
|
|
|
When the mirred action is used on a classful egress qdisc and a packet is
|
|
mirrored or redirected to self we hit a qdisc lock deadlock.
|
|
See trace below.
|
|
|
|
[..... other info removed for brevity....]
|
|
[ 82.890906]
|
|
[ 82.890906] ============================================
|
|
[ 82.890906] WARNING: possible recursive locking detected
|
|
[ 82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G W
|
|
[ 82.890906] --------------------------------------------
|
|
[ 82.890906] ping/418 is trying to acquire lock:
|
|
[ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at:
|
|
__dev_queue_xmit+0x1778/0x3550
|
|
[ 82.890906]
|
|
[ 82.890906] but task is already holding lock:
|
|
[ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at:
|
|
__dev_queue_xmit+0x1778/0x3550
|
|
[ 82.890906]
|
|
[ 82.890906] other info that might help us debug this:
|
|
[ 82.890906] Possible unsafe locking scenario:
|
|
[ 82.890906]
|
|
[ 82.890906] CPU0
|
|
[ 82.890906] ----
|
|
[ 82.890906] lock(&sch->q.lock);
|
|
[ 82.890906] lock(&sch->q.lock);
|
|
[ 82.890906]
|
|
[ 82.890906] *** DEADLOCK ***
|
|
[ 82.890906]
|
|
[..... other info removed for brevity....]
|
|
|
|
Example setup (eth0->eth0) to recreate
|
|
tc qdisc add dev eth0 root handle 1: htb default 30
|
|
tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \
|
|
action mirred egress redirect dev eth0
|
|
|
|
Another example(eth0->eth1->eth0) to recreate
|
|
tc qdisc add dev eth0 root handle 1: htb default 30
|
|
tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \
|
|
action mirred egress redirect dev eth1
|
|
|
|
tc qdisc add dev eth1 root handle 1: htb default 30
|
|
tc filter add dev eth1 handle 1: protocol ip prio 2 matchall \
|
|
action mirred egress redirect dev eth0
|
|
|
|
We fix this by adding an owner field (CPU id) to struct Qdisc set after
|
|
root qdisc is entered. When the softirq enters it a second time, if the
|
|
qdisc owner is the same CPU, the packet is dropped to break the loop.(CVE-2024-27010)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nf_tables: fix memleak in map from abort path
|
|
|
|
The delete set command does not rely on the transaction object for
|
|
element removal, therefore, a combination of delete element + delete set
|
|
from the abort path could result in restoring twice the refcount of the
|
|
mapping.
|
|
|
|
Check for inactive element in the next generation for the delete element
|
|
command in the abort path, skip restoring state if next generation bit
|
|
has been already cleared. This is similar to the activate logic using
|
|
the set walk iterator.
|
|
|
|
[ 6170.286929] ------------[ cut here ]------------
|
|
[ 6170.286939] WARNING: CPU: 6 PID: 790302 at net/netfilter/nf_tables_api.c:2086 nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
|
|
[ 6170.287071] Modules linked in: [...]
|
|
[ 6170.287633] CPU: 6 PID: 790302 Comm: kworker/6:2 Not tainted 6.9.0-rc3+ #365
|
|
[ 6170.287768] RIP: 0010:nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
|
|
[ 6170.287886] Code: df 48 8d 7d 58 e8 69 2e 3b df 48 8b 7d 58 e8 80 1b 37 df 48 8d 7d 68 e8 57 2e 3b df 48 8b 7d 68 e8 6e 1b 37 df 48 89 ef eb c4 <0f> 0b 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 0f
|
|
[ 6170.287895] RSP: 0018:ffff888134b8fd08 EFLAGS: 00010202
|
|
[ 6170.287904] RAX: 0000000000000001 RBX: ffff888125bffb28 RCX: dffffc0000000000
|
|
[ 6170.287912] RDX: 0000000000000003 RSI: ffffffffa20298ab RDI: ffff88811ebe4750
|
|
[ 6170.287919] RBP: ffff88811ebe4700 R08: ffff88838e812650 R09: fffffbfff0623a55
|
|
[ 6170.287926] R10: ffffffff8311d2af R11: 0000000000000001 R12: ffff888125bffb10
|
|
[ 6170.287933] R13: ffff888125bffb10 R14: dead000000000122 R15: dead000000000100
|
|
[ 6170.287940] FS: 0000000000000000(0000) GS:ffff888390b00000(0000) knlGS:0000000000000000
|
|
[ 6170.287948] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 6170.287955] CR2: 00007fd31fc00710 CR3: 0000000133f60004 CR4: 00000000001706f0
|
|
[ 6170.287962] Call Trace:
|
|
[ 6170.287967] <TASK>
|
|
[ 6170.287973] ? __warn+0x9f/0x1a0
|
|
[ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
|
|
[ 6170.288092] ? report_bug+0x1b1/0x1e0
|
|
[ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
|
|
[ 6170.288092] ? report_bug+0x1b1/0x1e0
|
|
[ 6170.288104] ? handle_bug+0x3c/0x70
|
|
[ 6170.288112] ? exc_invalid_op+0x17/0x40
|
|
[ 6170.288120] ? asm_exc_invalid_op+0x1a/0x20
|
|
[ 6170.288132] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]
|
|
[ 6170.288243] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
|
|
[ 6170.288366] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]
|
|
[ 6170.288483] nf_tables_trans_destroy_work+0x588/0x590 [nf_tables](CVE-2024-27011)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/rds: fix WARNING in rds_conn_connect_if_down
|
|
|
|
If connection isn't established yet, get_mr() will fail, trigger connection after
|
|
get_mr().(CVE-2024-27024)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
spi: spi-mt65xx: Fix NULL pointer access in interrupt handler
|
|
|
|
The TX buffer in spi_transfer can be a NULL pointer, so the interrupt
|
|
handler may end up writing to the invalid memory and cause crashes.
|
|
|
|
Add a check to trans->tx_buf before using it.(CVE-2024-27028)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
clk: zynq: Prevent null pointer dereference caused by kmalloc failure
|
|
|
|
The kmalloc() in zynq_clk_setup() will return null if the
|
|
physical memory has run out. As a result, if we use snprintf()
|
|
to write data to the null address, the null pointer dereference
|
|
bug will happen.
|
|
|
|
This patch uses a stack variable to replace the kmalloc().(CVE-2024-27037)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nfp: flower: handle acti_netdevs allocation failure
|
|
|
|
The kmalloc_array() in nfp_fl_lag_do_work() will return null, if
|
|
the physical memory has run out. As a result, if we dereference
|
|
the acti_netdevs, the null pointer dereference bugs will happen.
|
|
|
|
This patch adds a check to judge whether allocation failure occurs.
|
|
If it happens, the delayed work will be rescheduled and try again.(CVE-2024-27046)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return value
|
|
|
|
cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it
|
|
and return 0 in case of error.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-27051)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
s390/dasd: fix double module refcount decrement
|
|
|
|
Once the discipline is associated with the device, deleting the device
|
|
takes care of decrementing the module's refcount. Doing it manually on
|
|
this error path causes refcount to artificially decrease on each error
|
|
while it should just stay the same.(CVE-2024-27054)
|
|
|
|
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:
|
|
|
|
nouveau: lock the client object tree.
|
|
|
|
It appears the client object tree has no locking unless I've missed
|
|
something else. Fix races around adding/removing client objects,
|
|
mostly vram bar mappings.
|
|
|
|
4562.099306] general protection fault, probably for non-canonical address 0x6677ed422bceb80c: 0000 [#1] PREEMPT SMP PTI
|
|
[ 4562.099314] CPU: 2 PID: 23171 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27
|
|
[ 4562.099324] Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021
|
|
[ 4562.099330] RIP: 0010:nvkm_object_search+0x1d/0x70 [nouveau]
|
|
[ 4562.099503] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 48 89 f8 48 85 f6 74 39 48 8b 87 a0 00 00 00 48 85 c0 74 12 <48> 8b 48 f8 48 39 ce 73 15 48 8b 40 10 48 85 c0 75 ee 48 c7 c0 fe
|
|
[ 4562.099506] RSP: 0000:ffffa94cc420bbf8 EFLAGS: 00010206
|
|
[ 4562.099512] RAX: 6677ed422bceb814 RBX: ffff98108791f400 RCX: ffff9810f26b8f58
|
|
[ 4562.099517] RDX: 0000000000000000 RSI: ffff9810f26b9158 RDI: ffff98108791f400
|
|
[ 4562.099519] RBP: ffff9810f26b9158 R08: 0000000000000000 R09: 0000000000000000
|
|
[ 4562.099521] R10: ffffa94cc420bc48 R11: 0000000000000001 R12: ffff9810f02a7cc0
|
|
[ 4562.099526] R13: 0000000000000000 R14: 00000000000000ff R15: 0000000000000007
|
|
[ 4562.099528] FS: 00007f629c5017c0(0000) GS:ffff98142c700000(0000) knlGS:0000000000000000
|
|
[ 4562.099534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 4562.099536] CR2: 00007f629a882000 CR3: 000000017019e004 CR4: 00000000003706f0
|
|
[ 4562.099541] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
[ 4562.099542] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
[ 4562.099544] Call Trace:
|
|
[ 4562.099555] <TASK>
|
|
[ 4562.099573] ? die_addr+0x36/0x90
|
|
[ 4562.099583] ? exc_general_protection+0x246/0x4a0
|
|
[ 4562.099593] ? asm_exc_general_protection+0x26/0x30
|
|
[ 4562.099600] ? nvkm_object_search+0x1d/0x70 [nouveau]
|
|
[ 4562.099730] nvkm_ioctl+0xa1/0x250 [nouveau]
|
|
[ 4562.099861] nvif_object_map_handle+0xc8/0x180 [nouveau]
|
|
[ 4562.099986] nouveau_ttm_io_mem_reserve+0x122/0x270 [nouveau]
|
|
[ 4562.100156] ? dma_resv_test_signaled+0x26/0xb0
|
|
[ 4562.100163] ttm_bo_vm_fault_reserved+0x97/0x3c0 [ttm]
|
|
[ 4562.100182] ? __mutex_unlock_slowpath+0x2a/0x270
|
|
[ 4562.100189] nouveau_ttm_fault+0x69/0xb0 [nouveau]
|
|
[ 4562.100356] __do_fault+0x32/0x150
|
|
[ 4562.100362] do_fault+0x7c/0x560
|
|
[ 4562.100369] __handle_mm_fault+0x800/0xc10
|
|
[ 4562.100382] handle_mm_fault+0x17c/0x3e0
|
|
[ 4562.100388] do_user_addr_fault+0x208/0x860
|
|
[ 4562.100395] exc_page_fault+0x7f/0x200
|
|
[ 4562.100402] asm_exc_page_fault+0x26/0x30
|
|
[ 4562.100412] RIP: 0033:0x9b9870
|
|
[ 4562.100419] Code: 85 a8 f7 ff ff 8b 8d 80 f7 ff ff 89 08 e9 18 f2 ff ff 0f 1f 84 00 00 00 00 00 44 89 32 e9 90 fa ff ff 0f 1f 84 00 00 00 00 00 <44> 89 32 e9 f8 f1 ff ff 0f 1f 84 00 00 00 00 00 66 44 89 32 e9 e7
|
|
[ 4562.100422] RSP: 002b:00007fff9ba2dc70 EFLAGS: 00010246
|
|
[ 4562.100426] RAX: 0000000000000004 RBX: 000000000dd65e10 RCX: 000000fff0000000
|
|
[ 4562.100428] RDX: 00007f629a882000 RSI: 00007f629a882000 RDI: 0000000000000066
|
|
[ 4562.100432] RBP: 00007fff9ba2e570 R08: 0000000000000000 R09: 0000000123ddf000
|
|
[ 4562.100434] R10: 0000000000000001 R11: 0000000000000246 R12: 000000007fffffff
|
|
[ 4562.100436] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
|
|
[ 4562.100446] </TASK>
|
|
[ 4562.100448] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink cmac bnep sunrpc iwlmvm intel_rapl_msr intel_rapl_common snd_sof_pci_intel_cnl x86_pkg_temp_thermal intel_powerclamp snd_sof_intel_hda_common mac80211 coretemp snd_soc_acpi_intel_match kvm_intel snd_soc_acpi snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda_mlink
|
|
---truncated---(CVE-2024-27062)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: usbtv: Remove useless locks in usbtv_video_free()
|
|
|
|
Remove locks calls in usbtv_video_free() because
|
|
are useless and may led to a deadlock as reported here:
|
|
https://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000
|
|
Also remove usbtv_stop() call since it will be called when
|
|
unregistering the device.
|
|
|
|
Before 'c838530d230b' this issue would only be noticed if you
|
|
disconnect while streaming and now it is noticeable even when
|
|
disconnecting while not streaming.
|
|
|
|
|
|
[hverkuil: fix minor spelling mistake in log message](CVE-2024-27072)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: ttpci: fix two memleaks in budget_av_attach
|
|
|
|
When saa7146_register_device and saa7146_vv_init fails, budget_av_attach
|
|
should free the resources it allocates, like the error-handling of
|
|
ttpci_budget_init does. Besides, there are two fixme comment refers to
|
|
such deallocations.(CVE-2024-27073)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: dvb-frontends: avoid stack overflow warnings with clang
|
|
|
|
A previous patch worked around a KASAN issue in stv0367, now a similar
|
|
problem showed up with clang:
|
|
|
|
drivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size (3624) exceeds limit (2048) in 'stv0367ter_set_frontend' [-Werror,-Wframe-larger-than]
|
|
1214 | static int stv0367ter_set_frontend(struct dvb_frontend *fe)
|
|
|
|
Rework the stv0367_writereg() function to be simpler and mark both
|
|
register access functions as noinline_for_stack so the temporary
|
|
i2c_msg structures do not get duplicated on the stack when KASAN_STACK
|
|
is enabled.(CVE-2024-27075)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: v4l2-mem2mem: fix a memleak in v4l2_m2m_register_entity
|
|
|
|
The entity->name (i.e. name) is allocated in v4l2_m2m_register_entity
|
|
but isn't freed in its following error-handling paths. This patch
|
|
adds such deallocation to prevent memleak of entity->name.(CVE-2024-27077)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: v4l2-tpg: fix some memleaks in tpg_alloc
|
|
|
|
In tpg_alloc, resources should be deallocated in each and every
|
|
error-handling paths, since they are allocated in for statements.
|
|
Otherwise there would be memleaks because tpg_free is called only when
|
|
tpg_alloc return 0.(CVE-2024-27078)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
SUNRPC: fix some memleaks in gssx_dec_option_array
|
|
|
|
The creds and oa->data need to be freed in the error-handling paths after
|
|
their allocation. So this patch add these deallocations in the
|
|
corresponding paths.(CVE-2024-27388)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nft_flow_offload: reset dst in route object after setting up flow
|
|
|
|
dst is transferred to the flow object, route object does not own it
|
|
anymore. Reset dst in route object, otherwise if flow_offload_add()
|
|
fails, error path releases dst twice, leading to a refcount underflow.(CVE-2024-27403)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netrom: Fix data-races around sysctl_net_busy_read
|
|
|
|
We need to protect the reader reading the sysctl value because the
|
|
value can be changed concurrently.(CVE-2024-27419)
|
|
|
|
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27426)
|
|
|
|
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27427)
|
|
|
|
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27428)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
dm snapshot: fix lockup in dm_exception_table_exit
|
|
|
|
There was reported lockup when we exit a snapshot with many exceptions.
|
|
Fix this by adding "cond_resched" to the loop that frees the exceptions.(CVE-2024-35805)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
soc: fsl: qbman: Always disable interrupts when taking cgr_lock
|
|
|
|
smp_call_function_single disables IRQs when executing the callback. To
|
|
prevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere.
|
|
This is already done by qman_update_cgr and qman_delete_cgr; fix the
|
|
other lockers.(CVE-2024-35806)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversion
|
|
|
|
The first kiocb_set_cancel_fn() argument may point at a struct kiocb
|
|
that is not embedded inside struct aio_kiocb. With the current code,
|
|
depending on the compiler, the req->ki_ctx read happens either before
|
|
the IOCB_AIO_RW test or after that test. Move the req->ki_ctx read such
|
|
that it is guaranteed that the IOCB_AIO_RW test happens first.(CVE-2024-35815)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/mlx5e: fix a double-free in arfs_create_groups
|
|
|
|
When `in` allocated by kvzalloc fails, arfs_create_groups will free
|
|
ft->g and return an error. However, arfs_create_table, the only caller of
|
|
arfs_create_groups, will hold this error and call to
|
|
mlx5e_destroy_flow_table, in which the ft->g will be freed again.(CVE-2024-35835)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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:
|
|
|
|
ipv6: Fix infinite recursion in fib6_dump_done().
|
|
|
|
syzkaller reported infinite recursive calls of fib6_dump_done() during
|
|
netlink socket destruction. [1]
|
|
|
|
From the log, syzkaller sent an AF_UNSPEC RTM_GETROUTE message, and then
|
|
the response was generated. The following recvmmsg() resumed the dump
|
|
for IPv6, but the first call of inet6_dump_fib() failed at kzalloc() due
|
|
to the fault injection. [0]
|
|
|
|
12:01:34 executing program 3:
|
|
r0 = socket$nl_route(0x10, 0x3, 0x0)
|
|
sendmsg$nl_route(r0, ... snip ...)
|
|
recvmmsg(r0, ... snip ...) (fail_nth: 8)
|
|
|
|
Here, fib6_dump_done() was set to nlk_sk(sk)->cb.done, and the next call
|
|
of inet6_dump_fib() set it to nlk_sk(sk)->cb.args[3]. syzkaller stopped
|
|
receiving the response halfway through, and finally netlink_sock_destruct()
|
|
called nlk_sk(sk)->cb.done().
|
|
|
|
fib6_dump_done() calls fib6_dump_end() and nlk_sk(sk)->cb.done() if it
|
|
is still not NULL. fib6_dump_end() rewrites nlk_sk(sk)->cb.done() by
|
|
nlk_sk(sk)->cb.args[3], but it has the same function, not NULL, calling
|
|
itself recursively and hitting the stack guard page.
|
|
|
|
To avoid the issue, let's set the destructor after kzalloc().
|
|
|
|
[0]:
|
|
FAULT_INJECTION: forcing a failure.
|
|
name failslab, interval 1, probability 0, space 0, times 0
|
|
CPU: 1 PID: 432110 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
|
|
Call Trace:
|
|
<TASK>
|
|
dump_stack_lvl (lib/dump_stack.c:117)
|
|
should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153)
|
|
should_failslab (mm/slub.c:3733)
|
|
kmalloc_trace (mm/slub.c:3748 mm/slub.c:3827 mm/slub.c:3992)
|
|
inet6_dump_fib (./include/linux/slab.h:628 ./include/linux/slab.h:749 net/ipv6/ip6_fib.c:662)
|
|
rtnl_dump_all (net/core/rtnetlink.c:4029)
|
|
netlink_dump (net/netlink/af_netlink.c:2269)
|
|
netlink_recvmsg (net/netlink/af_netlink.c:1988)
|
|
____sys_recvmsg (net/socket.c:1046 net/socket.c:2801)
|
|
___sys_recvmsg (net/socket.c:2846)
|
|
do_recvmmsg (net/socket.c:2943)
|
|
__x64_sys_recvmmsg (net/socket.c:3041 net/socket.c:3034 net/socket.c:3034)
|
|
|
|
[1]:
|
|
BUG: TASK stack guard page was hit at 00000000f2fa9af1 (stack is 00000000b7912430..000000009a436beb)
|
|
stack guard page: 0000 [#1] PREEMPT SMP KASAN
|
|
CPU: 1 PID: 223719 Comm: kworker/1:3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
|
|
Workqueue: events netlink_sock_destruct_work
|
|
RIP: 0010:fib6_dump_done (net/ipv6/ip6_fib.c:570)
|
|
Code: 3c 24 e8 f3 e9 51 fd e9 28 fd ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 41 57 41 56 41 55 41 54 55 48 89 fd <53> 48 8d 5d 60 e8 b6 4d 07 fd 48 89 da 48 b8 00 00 00 00 00 fc ff
|
|
RSP: 0018:ffffc9000d980000 EFLAGS: 00010293
|
|
RAX: 0000000000000000 RBX: ffffffff84405990 RCX: ffffffff844059d3
|
|
RDX: ffff8881028e0000 RSI: ffffffff84405ac2 RDI: ffff88810c02f358
|
|
RBP: ffff88810c02f358 R08: 0000000000000007 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000224 R12: 0000000000000000
|
|
R13: ffff888007c82c78 R14: ffff888007c82c68 R15: ffff888007c82c68
|
|
FS: 0000000000000000(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: ffffc9000d97fff8 CR3: 0000000102309002 CR4: 0000000000770ef0
|
|
PKRU: 55555554
|
|
Call Trace:
|
|
<#DF>
|
|
</#DF>
|
|
<TASK>
|
|
fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))
|
|
fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))
|
|
...
|
|
fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))
|
|
fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))
|
|
netlink_sock_destruct (net/netlink/af_netlink.c:401)
|
|
__sk_destruct (net/core/sock.c:2177 (discriminator 2))
|
|
sk_destruct (net/core/sock.c:2224)
|
|
__sk_free (net/core/sock.c:2235)
|
|
sk_free (net/core/sock.c:2246)
|
|
process_one_work (kernel/workqueue.c:3259)
|
|
worker_thread (kernel/workqueue.c:3329 kernel/workqueue.
|
|
---truncated---(CVE-2024-35886)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get()
|
|
|
|
nft_unregister_flowtable_type() within nf_flow_inet_module_exit() can
|
|
concurrent with __nft_flowtable_type_get() within nf_tables_newflowtable().
|
|
And thhere is not any protection when iterate over nf_tables_flowtables
|
|
list in __nft_flowtable_type_get(). Therefore, there is pertential
|
|
data-race of nf_tables_flowtables list entry.
|
|
|
|
Use list_for_each_entry_rcu() to iterate over nf_tables_flowtables list
|
|
in __nft_flowtable_type_get(), and use rcu_read_lock() in the caller
|
|
nft_flowtable_type_get() to protect the entire type query process.(CVE-2024-35898)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fbmon: prevent division by zero in fb_videomode_from_videomode()
|
|
|
|
The expression htotal * vtotal can have a zero value on
|
|
overflow. It is necessary to prevent division by zero like in
|
|
fb_var_to_videomode().
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-35922)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()
|
|
|
|
The call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an
|
|
unsuccessful status. In such cases, the elsiocb is not issued, the
|
|
completion is not called, and thus the elsiocb resource is leaked.
|
|
|
|
Check return value after calling lpfc_sli4_resume_rpi() and conditionally
|
|
release the elsiocb resource.(CVE-2024-35930)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()
|
|
|
|
The unhandled case in btrfs_relocate_sys_chunks() loop is a corruption,
|
|
as it could be caused only by two impossible conditions:
|
|
|
|
- at first the search key is set up to look for a chunk tree item, with
|
|
offset -1, this is an inexact search and the key->offset will contain
|
|
the correct offset upon a successful search, a valid chunk tree item
|
|
cannot have an offset -1
|
|
|
|
- after first successful search, the found_key corresponds to a chunk
|
|
item, the offset is decremented by 1 before the next loop, it's
|
|
impossible to find a chunk item there due to alignment and size
|
|
constraints(CVE-2024-35936)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/client: Fully protect modes[] with dev->mode_config.mutex
|
|
|
|
The modes[] array contains pointers to modes on the connectors'
|
|
mode lists, which are protected by dev->mode_config.mutex.
|
|
Thus we need to extend modes[] the same protection or by the
|
|
time we use it the elements may already be pointing to
|
|
freed/reused memory.(CVE-2024-35950)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
xsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING
|
|
|
|
syzbot reported an illegal copy in xsk_setsockopt() [1]
|
|
|
|
Make sure to validate setsockopt() @optlen parameter.
|
|
|
|
[1]
|
|
|
|
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
|
|
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]
|
|
BUG: KASAN: slab-out-of-bounds in xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420
|
|
Read of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549
|
|
|
|
CPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
|
|
print_address_description mm/kasan/report.c:377 [inline]
|
|
print_report+0x169/0x550 mm/kasan/report.c:488
|
|
kasan_report+0x143/0x180 mm/kasan/report.c:601
|
|
copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
|
|
copy_from_sockptr include/linux/sockptr.h:55 [inline]
|
|
xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420
|
|
do_sock_setsockopt+0x3af/0x720 net/socket.c:2311
|
|
__sys_setsockopt+0x1ae/0x250 net/socket.c:2334
|
|
__do_sys_setsockopt net/socket.c:2343 [inline]
|
|
__se_sys_setsockopt net/socket.c:2340 [inline]
|
|
__x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
|
|
do_syscall_64+0xfb/0x240
|
|
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
|
RIP: 0033:0x7fb40587de69
|
|
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
|
|
RSP: 002b:00007fb40665a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
|
|
RAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69
|
|
RDX: 0000000000000005 RSI: 000000000000011b RDI: 0000000000000006
|
|
RBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000
|
|
R10: 0000000020001980 R11: 0000000000000246 R12: 0000000000000000
|
|
R13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08
|
|
</TASK>
|
|
|
|
Allocated by task 7549:
|
|
kasan_save_stack mm/kasan/common.c:47 [inline]
|
|
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
|
|
poison_kmalloc_redzone mm/kasan/common.c:370 [inline]
|
|
__kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387
|
|
kasan_kmalloc include/linux/kasan.h:211 [inline]
|
|
__do_kmalloc_node mm/slub.c:3966 [inline]
|
|
__kmalloc+0x233/0x4a0 mm/slub.c:3979
|
|
kmalloc include/linux/slab.h:632 [inline]
|
|
__cgroup_bpf_run_filter_setsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869
|
|
do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293
|
|
__sys_setsockopt+0x1ae/0x250 net/socket.c:2334
|
|
__do_sys_setsockopt net/socket.c:2343 [inline]
|
|
__se_sys_setsockopt net/socket.c:2340 [inline]
|
|
__x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
|
|
do_syscall_64+0xfb/0x240
|
|
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
|
|
|
The buggy address belongs to the object at ffff888028c6cde0
|
|
which belongs to the cache kmalloc-8 of size 8
|
|
The buggy address is located 1 bytes to the right of
|
|
allocated 2-byte region [ffff888028c6cde0, ffff888028c6cde2)
|
|
|
|
The buggy address belongs to the physical page:
|
|
page:ffffea0000a31b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888028c6c9c0 pfn:0x28c6c
|
|
anon flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff)
|
|
page_type: 0xffffffff()
|
|
raw: 00fff00000000800 ffff888014c41280 0000000000000000 dead000000000001
|
|
raw: ffff888028c6c9c0 0000000080800057 00000001ffffffff 0000000000000000
|
|
page dumped because: kasan: bad access detected
|
|
page_owner tracks the page as allocated
|
|
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 6648, tgid 6644 (syz-executor.0), ts 133906047828, free_ts 133859922223
|
|
set_page_owner include/linux/page_owner.h:31 [inline]
|
|
post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533
|
|
prep_new_page mm/page_alloc.c:
|
|
---truncated---(CVE-2024-35976)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up
|
|
|
|
The flag I2C_HID_READ_PENDING is used to serialize I2C operations.
|
|
However, this is not necessary, because I2C core already has its own
|
|
locking for that.
|
|
|
|
More importantly, this flag can cause a lock-up: if the flag is set in
|
|
i2c_hid_xfer() and an interrupt happens, the interrupt handler
|
|
(i2c_hid_irq) will check this flag and return immediately without doing
|
|
anything, then the interrupt handler will be invoked again in an
|
|
infinite loop.
|
|
|
|
Since interrupt handler is an RT task, it takes over the CPU and the
|
|
flag-clearing task never gets scheduled, thus we have a lock-up.
|
|
|
|
Delete this unnecessary flag.(CVE-2024-35997)</Note>
|
|
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-20.03-LTS-SP4.
|
|
|
|
openEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.</Note>
|
|
<Note Title="Severity" Type="General" Ordinal="5" xml:lang="en">High</Note>
|
|
<Note Title="Affected Component" Type="General" Ordinal="6" xml:lang="en">kernel</Note>
|
|
</DocumentNotes>
|
|
<DocumentReferences>
|
|
<Reference Type="Self">
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47269</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47284</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47335</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47393</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47455</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47473</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47497</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2022-48695</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2022-48697</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2022-48702</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2022-48704</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2022-48710</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52650</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52652</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52653</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52656</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52683</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-52691</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52698</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52817</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52818</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52835</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52840</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52847</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52867</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52868</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26955</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26956</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26957</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-26960</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-26966</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26969</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26974</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-26981</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26982</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26993</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26994</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26996</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26999</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-27001</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-27010</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27011</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27024</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27028</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27037</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27046</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27051</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27054</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-27062</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27072</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27073</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27075</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27077</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27078</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27388</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27403</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27419</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27426</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27427</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27428</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35805</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35806</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35815</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35835</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35849</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35886</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35898</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35922</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35930</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35936</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35950</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35976</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35997</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47269</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47284</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47335</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47393</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47455</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47473</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47497</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48695</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48697</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48702</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48704</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48710</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52650</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52652</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52653</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52656</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52683</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52685</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52691</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52698</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52817</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52818</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52835</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52840</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52847</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52867</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52868</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26955</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26956</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26957</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26958</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26960</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-26966</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26969</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26974</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26976</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26981</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26982</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26993</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26994</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26996</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26999</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27000</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27001</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27008</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27010</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27011</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27024</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27028</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27037</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27046</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27051</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27054</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27059</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27062</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27072</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27073</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27075</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27077</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27078</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27388</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27403</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27419</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27426</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27427</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27428</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35805</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35806</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35815</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35835</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35849</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35886</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35898</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35922</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35930</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35936</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35950</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35976</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35997</URL>
|
|
</Reference>
|
|
</DocumentReferences>
|
|
<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
|
|
<Branch Type="Product Name" Name="openEuler">
|
|
<FullProductName ProductID="openEuler-20.03-LTS-SP4" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">openEuler-20.03-LTS-SP4</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debugsource-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-source-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-devel-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-devel-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2405.5.0.0278.oe2003sp4.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="python2-perf-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debugsource-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-devel-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-devel-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-source-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2405.5.0.0278" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-debuginfo-4.19.90-2405.5.0.0278.oe2003sp4.x86_64.rpm</FullProductName>
|
|
</Branch>
|
|
</ProductTree>
|
|
<Vulnerability Ordinal="1" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
usb: dwc3: ep0: fix NULL pointer exception
|
|
|
|
There is no validation of the index from dwc3_wIndex_to_dep() and we might
|
|
be referring a non-existing ep and trigger a NULL pointer exception. In
|
|
certain configurations we might use fewer eps and the index might wrongly
|
|
indicate a larger ep index than existing.
|
|
|
|
By adding this validation from the patch we can actually report a wrong
|
|
index back to the caller.
|
|
|
|
In our usecase we are using a composite device on an older kernel, but
|
|
upstream might use this fix also. Unfortunately, I cannot describe the
|
|
hardware for others to reproduce the issue as it is a proprietary
|
|
implementation.
|
|
|
|
[ 82.958261] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a4
|
|
[ 82.966891] Mem abort info:
|
|
[ 82.969663] ESR = 0x96000006
|
|
[ 82.972703] Exception class = DABT (current EL), IL = 32 bits
|
|
[ 82.978603] SET = 0, FnV = 0
|
|
[ 82.981642] EA = 0, S1PTW = 0
|
|
[ 82.984765] Data abort info:
|
|
[ 82.987631] ISV = 0, ISS = 0x00000006
|
|
[ 82.991449] CM = 0, WnR = 0
|
|
[ 82.994409] user pgtable: 4k pages, 39-bit VAs, pgdp = 00000000c6210ccc
|
|
[ 83.000999] [00000000000000a4] pgd=0000000053aa5003, pud=0000000053aa5003, pmd=0000000000000000
|
|
[ 83.009685] Internal error: Oops: 96000006 [#1] PREEMPT SMP
|
|
[ 83.026433] Process irq/62-dwc3 (pid: 303, stack limit = 0x000000003985154c)
|
|
[ 83.033470] CPU: 0 PID: 303 Comm: irq/62-dwc3 Not tainted 4.19.124 #1
|
|
[ 83.044836] pstate: 60000085 (nZCv daIf -PAN -UAO)
|
|
[ 83.049628] pc : dwc3_ep0_handle_feature+0x414/0x43c
|
|
[ 83.054558] lr : dwc3_ep0_interrupt+0x3b4/0xc94
|
|
|
|
...
|
|
|
|
[ 83.141788] Call trace:
|
|
[ 83.144227] dwc3_ep0_handle_feature+0x414/0x43c
|
|
[ 83.148823] dwc3_ep0_interrupt+0x3b4/0xc94
|
|
[ 83.181546] ---[ end trace aac6b5267d84c32f ]---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2021-47269</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</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:
|
|
|
|
isdn: mISDN: netjet: Fix crash in nj_probe:
|
|
|
|
'nj_setup' in netjet.c might fail with -EIO and in this case
|
|
'card->irq' is initialized and is bigger than zero. A subsequent call to
|
|
'nj_release' will free the irq that has not been requested.
|
|
|
|
Fix this bug by deleting the previous assignment to 'card->irq' and just
|
|
keep the assignment before 'request_irq'.
|
|
|
|
The KASAN's log reveals it:
|
|
|
|
[ 3.354615 ] WARNING: CPU: 0 PID: 1 at kernel/irq/manage.c:1826
|
|
free_irq+0x100/0x480
|
|
[ 3.355112 ] Modules linked in:
|
|
[ 3.355310 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
|
|
5.13.0-rc1-00144-g25a1298726e #13
|
|
[ 3.355816 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
|
|
rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
|
|
[ 3.356552 ] RIP: 0010:free_irq+0x100/0x480
|
|
[ 3.356820 ] Code: 6e 08 74 6f 4d 89 f4 e8 5e ac 09 00 4d 8b 74 24 18
|
|
4d 85 f6 75 e3 e8 4f ac 09 00 8b 75 c8 48 c7 c7 78 c1 2e 85 e8 e0 cf f5
|
|
ff <0f> 0b 48 8b 75 c0 4c 89 ff e8 72 33 0b 03 48 8b 43 40 4c 8b a0 80
|
|
[ 3.358012 ] RSP: 0000:ffffc90000017b48 EFLAGS: 00010082
|
|
[ 3.358357 ] RAX: 0000000000000000 RBX: ffff888104dc8000 RCX:
|
|
0000000000000000
|
|
[ 3.358814 ] RDX: ffff8881003c8000 RSI: ffffffff8124a9e6 RDI:
|
|
00000000ffffffff
|
|
[ 3.359272 ] RBP: ffffc90000017b88 R08: 0000000000000000 R09:
|
|
0000000000000000
|
|
[ 3.359732 ] R10: ffffc900000179f0 R11: 0000000000001d04 R12:
|
|
0000000000000000
|
|
[ 3.360195 ] R13: ffff888107dc6000 R14: ffff888107dc6928 R15:
|
|
ffff888104dc80a8
|
|
[ 3.360652 ] FS: 0000000000000000(0000) GS:ffff88817bc00000(0000)
|
|
knlGS:0000000000000000
|
|
[ 3.361170 ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 3.361538 ] CR2: 0000000000000000 CR3: 000000000582e000 CR4:
|
|
00000000000006f0
|
|
[ 3.362003 ] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
|
|
0000000000000000
|
|
[ 3.362175 ] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
|
|
0000000000000400
|
|
[ 3.362175 ] Call Trace:
|
|
[ 3.362175 ] nj_release+0x51/0x1e0
|
|
[ 3.362175 ] nj_probe+0x450/0x950
|
|
[ 3.362175 ] ? pci_device_remove+0x110/0x110
|
|
[ 3.362175 ] local_pci_probe+0x45/0xa0
|
|
[ 3.362175 ] pci_device_probe+0x12b/0x1d0
|
|
[ 3.362175 ] really_probe+0x2a9/0x610
|
|
[ 3.362175 ] driver_probe_device+0x90/0x1d0
|
|
[ 3.362175 ] ? mutex_lock_nested+0x1b/0x20
|
|
[ 3.362175 ] device_driver_attach+0x68/0x70
|
|
[ 3.362175 ] __driver_attach+0x124/0x1b0
|
|
[ 3.362175 ] ? device_driver_attach+0x70/0x70
|
|
[ 3.362175 ] bus_for_each_dev+0xbb/0x110
|
|
[ 3.362175 ] ? rdinit_setup+0x45/0x45
|
|
[ 3.362175 ] driver_attach+0x27/0x30
|
|
[ 3.362175 ] bus_add_driver+0x1eb/0x2a0
|
|
[ 3.362175 ] driver_register+0xa9/0x180
|
|
[ 3.362175 ] __pci_register_driver+0x82/0x90
|
|
[ 3.362175 ] ? w6692_init+0x38/0x38
|
|
[ 3.362175 ] nj_init+0x36/0x38
|
|
[ 3.362175 ] do_one_initcall+0x7f/0x3d0
|
|
[ 3.362175 ] ? rdinit_setup+0x45/0x45
|
|
[ 3.362175 ] ? rcu_read_lock_sched_held+0x4f/0x80
|
|
[ 3.362175 ] kernel_init_freeable+0x2aa/0x301
|
|
[ 3.362175 ] ? rest_init+0x2c0/0x2c0
|
|
[ 3.362175 ] kernel_init+0x18/0x190
|
|
[ 3.362175 ] ? rest_init+0x2c0/0x2c0
|
|
[ 3.362175 ] ? rest_init+0x2c0/0x2c0
|
|
[ 3.362175 ] ret_from_fork+0x1f/0x30
|
|
[ 3.362175 ] Kernel panic - not syncing: panic_on_warn set ...
|
|
[ 3.362175 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
|
|
5.13.0-rc1-00144-g25a1298726e #13
|
|
[ 3.362175 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
|
|
rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
|
|
[ 3.362175 ] Call Trace:
|
|
[ 3.362175 ] dump_stack+0xba/0xf5
|
|
[ 3.362175 ] ? free_irq+0x100/0x480
|
|
[ 3.362175 ] panic+0x15a/0x3f2
|
|
[ 3.362175 ] ? __warn+0xf2/0x150
|
|
[ 3.362175 ] ? free_irq+0x100/0x480
|
|
[ 3.362175 ] __warn+0x108/0x150
|
|
[ 3.362175 ] ? free_irq+0x100/0x480
|
|
[ 3.362175 ] report_bug+0x119/0x1c0
|
|
[ 3.362175 ] handle_bug+0x3b/0x80
|
|
[ 3.362175 ] exc_invalid_op+0x18/0x70
|
|
[ 3.362175 ] asm_exc_invalid_op+0x12/0x20
|
|
[ 3.362175 ] RIP: 0010:free_irq+0x100
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2021-47284</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</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:
|
|
|
|
f2fs: fix to avoid racing on fsync_entry_slab by multi filesystem instances
|
|
|
|
As syzbot reported, there is an use-after-free issue during f2fs recovery:
|
|
|
|
Use-after-free write at 0xffff88823bc16040 (in kfence-#10):
|
|
kmem_cache_destroy+0x1f/0x120 mm/slab_common.c:486
|
|
f2fs_recover_fsync_data+0x75b0/0x8380 fs/f2fs/recovery.c:869
|
|
f2fs_fill_super+0x9393/0xa420 fs/f2fs/super.c:3945
|
|
mount_bdev+0x26c/0x3a0 fs/super.c:1367
|
|
legacy_get_tree+0xea/0x180 fs/fs_context.c:592
|
|
vfs_get_tree+0x86/0x270 fs/super.c:1497
|
|
do_new_mount fs/namespace.c:2905 [inline]
|
|
path_mount+0x196f/0x2be0 fs/namespace.c:3235
|
|
do_mount fs/namespace.c:3248 [inline]
|
|
__do_sys_mount fs/namespace.c:3456 [inline]
|
|
__se_sys_mount+0x2f9/0x3b0 fs/namespace.c:3433
|
|
do_syscall_64+0x3f/0xb0 arch/x86/entry/common.c:47
|
|
entry_SYSCALL_64_after_hwframe+0x44/0xae
|
|
|
|
The root cause is multi f2fs filesystem instances can race on accessing
|
|
global fsync_entry_slab pointer, result in use-after-free issue of slab
|
|
cache, fixes to init/destroy this slab cache only once during module
|
|
init/destroy procedure to avoid this issue.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2021-47335</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.4</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-1678</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:
|
|
|
|
hwmon: (mlxreg-fan) Return non-zero value when fan current state is enforced from sysfs
|
|
|
|
Fan speed minimum can be enforced from sysfs. For example, setting
|
|
current fan speed to 20 is used to enforce fan speed to be at 100%
|
|
speed, 19 - to be not below 90% speed, etcetera. This feature provides
|
|
ability to limit fan speed according to some system wise
|
|
considerations, like absence of some replaceable units or high system
|
|
ambient temperature.
|
|
|
|
Request for changing fan minimum speed is configuration request and can
|
|
be set only through 'sysfs' write procedure. In this situation value of
|
|
argument 'state' is above nominal fan speed maximum.
|
|
|
|
Return non-zero code in this case to avoid
|
|
thermal_cooling_device_stats_update() call, because in this case
|
|
statistics update violates thermal statistics table range.
|
|
The issues is observed in case kernel is configured with option
|
|
CONFIG_THERMAL_STATISTICS.
|
|
|
|
Here is the trace from KASAN:
|
|
[ 159.506659] BUG: KASAN: slab-out-of-bounds in thermal_cooling_device_stats_update+0x7d/0xb0
|
|
[ 159.516016] Read of size 4 at addr ffff888116163840 by task hw-management.s/7444
|
|
[ 159.545625] Call Trace:
|
|
[ 159.548366] dump_stack+0x92/0xc1
|
|
[ 159.552084] ? thermal_cooling_device_stats_update+0x7d/0xb0
|
|
[ 159.635869] thermal_zone_device_update+0x345/0x780
|
|
[ 159.688711] thermal_zone_device_set_mode+0x7d/0xc0
|
|
[ 159.694174] mlxsw_thermal_modules_init+0x48f/0x590 [mlxsw_core]
|
|
[ 159.700972] ? mlxsw_thermal_set_cur_state+0x5a0/0x5a0 [mlxsw_core]
|
|
[ 159.731827] mlxsw_thermal_init+0x763/0x880 [mlxsw_core]
|
|
[ 160.070233] RIP: 0033:0x7fd995909970
|
|
[ 160.074239] Code: 73 01 c3 48 8b 0d 28 d5 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 99 2d 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ..
|
|
[ 160.095242] RSP: 002b:00007fff54f5d938 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
|
|
[ 160.103722] RAX: ffffffffffffffda RBX: 0000000000000013 RCX: 00007fd995909970
|
|
[ 160.111710] RDX: 0000000000000013 RSI: 0000000001906008 RDI: 0000000000000001
|
|
[ 160.119699] RBP: 0000000001906008 R08: 00007fd995bc9760 R09: 00007fd996210700
|
|
[ 160.127687] R10: 0000000000000073 R11: 0000000000000246 R12: 0000000000000013
|
|
[ 160.135673] R13: 0000000000000001 R14: 00007fd995bc8600 R15: 0000000000000013
|
|
[ 160.143671]
|
|
[ 160.145338] Allocated by task 2924:
|
|
[ 160.149242] kasan_save_stack+0x19/0x40
|
|
[ 160.153541] __kasan_kmalloc+0x7f/0xa0
|
|
[ 160.157743] __kmalloc+0x1a2/0x2b0
|
|
[ 160.161552] thermal_cooling_device_setup_sysfs+0xf9/0x1a0
|
|
[ 160.167687] __thermal_cooling_device_register+0x1b5/0x500
|
|
[ 160.173833] devm_thermal_of_cooling_device_register+0x60/0xa0
|
|
[ 160.180356] mlxreg_fan_probe+0x474/0x5e0 [mlxreg_fan]
|
|
[ 160.248140]
|
|
[ 160.249807] The buggy address belongs to the object at ffff888116163400
|
|
[ 160.249807] which belongs to the cache kmalloc-1k of size 1024
|
|
[ 160.263814] The buggy address is located 64 bytes to the right of
|
|
[ 160.263814] 1024-byte region [ffff888116163400, ffff888116163800)
|
|
[ 160.277536] The buggy address belongs to the page:
|
|
[ 160.282898] page:0000000012275840 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888116167000 pfn:0x116160
|
|
[ 160.294872] head:0000000012275840 order:3 compound_mapcount:0 compound_pincount:0
|
|
[ 160.303251] flags: 0x200000000010200(slab|head|node=0|zone=2)
|
|
[ 160.309694] raw: 0200000000010200 ffffea00046f7208 ffffea0004928208 ffff88810004dbc0
|
|
[ 160.318367] raw: ffff888116167000 00000000000a0006 00000001ffffffff 0000000000000000
|
|
[ 160.327033] page dumped because: kasan: bad access detected
|
|
[ 160.333270]
|
|
[ 160.334937] Memory state around the buggy address:
|
|
[ 160.356469] >ffff888116163800: fc ..</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2021-47393</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</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:
|
|
|
|
ptp: Fix possible memory leak in ptp_clock_register()
|
|
|
|
I got memory leak as follows when doing fault injection test:
|
|
|
|
unreferenced object 0xffff88800906c618 (size 8):
|
|
comm "i2c-idt82p33931", pid 4421, jiffies 4294948083 (age 13.188s)
|
|
hex dump (first 8 bytes):
|
|
70 74 70 30 00 00 00 00 ptp0....
|
|
backtrace:
|
|
[<00000000312ed458>] __kmalloc_track_caller+0x19f/0x3a0
|
|
[<0000000079f6e2ff>] kvasprintf+0xb5/0x150
|
|
[<0000000026aae54f>] kvasprintf_const+0x60/0x190
|
|
[<00000000f323a5f7>] kobject_set_name_vargs+0x56/0x150
|
|
[<000000004e35abdd>] dev_set_name+0xc0/0x100
|
|
[<00000000f20cfe25>] ptp_clock_register+0x9f4/0xd30 [ptp]
|
|
[<000000008bb9f0de>] idt82p33_probe.cold+0x8b6/0x1561 [ptp_idt82p33]
|
|
|
|
When posix_clock_register() returns an error, the name allocated
|
|
in dev_set_name() will be leaked, the put_device() should be used
|
|
to give up the device reference, then the name will be freed in
|
|
kobject_cleanup() and other memory will be freed in ptp_clock_release().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2021-47455</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</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:
|
|
|
|
scsi: qla2xxx: Fix a memory leak in an error path of qla2x00_process_els()
|
|
|
|
Commit 8c0eb596baa5 ("[SCSI] qla2xxx: Fix a memory leak in an error path of
|
|
qla2x00_process_els()"), intended to change:
|
|
|
|
bsg_job->request->msgcode == FC_BSG_HST_ELS_NOLOGIN
|
|
|
|
|
|
bsg_job->request->msgcode != FC_BSG_RPT_ELS
|
|
|
|
but changed it to:
|
|
|
|
bsg_job->request->msgcode == FC_BSG_RPT_ELS
|
|
|
|
instead.
|
|
|
|
Change the == to a != to avoid leaking the fcport structure or freeing
|
|
unallocated memory.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2021-47473</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</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:
|
|
|
|
nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells
|
|
|
|
If a cell has 'nbits' equal to a multiple of BITS_PER_BYTE the logic
|
|
|
|
*p &= GENMASK((cell->nbits%BITS_PER_BYTE) - 1, 0);
|
|
|
|
will become undefined behavior because nbits modulo BITS_PER_BYTE is 0, and we
|
|
subtract one from that making a large number that is then shifted more than the
|
|
number of bits that fit into an unsigned long.
|
|
|
|
UBSAN reports this problem:
|
|
|
|
UBSAN: shift-out-of-bounds in drivers/nvmem/core.c:1386:8
|
|
shift exponent 64 is too large for 64-bit type 'unsigned long'
|
|
CPU: 6 PID: 7 Comm: kworker/u16:0 Not tainted 5.15.0-rc3+ #9
|
|
Hardware name: Google Lazor (rev3+) with KB Backlight (DT)
|
|
Workqueue: events_unbound deferred_probe_work_func
|
|
Call trace:
|
|
dump_backtrace+0x0/0x170
|
|
show_stack+0x24/0x30
|
|
dump_stack_lvl+0x64/0x7c
|
|
dump_stack+0x18/0x38
|
|
ubsan_epilogue+0x10/0x54
|
|
__ubsan_handle_shift_out_of_bounds+0x180/0x194
|
|
__nvmem_cell_read+0x1ec/0x21c
|
|
nvmem_cell_read+0x58/0x94
|
|
nvmem_cell_read_variable_common+0x4c/0xb0
|
|
nvmem_cell_read_variable_le_u32+0x40/0x100
|
|
a6xx_gpu_init+0x170/0x2f4
|
|
adreno_bind+0x174/0x284
|
|
component_bind_all+0xf0/0x264
|
|
msm_drm_bind+0x1d8/0x7a0
|
|
try_to_bring_up_master+0x164/0x1ac
|
|
__component_add+0xbc/0x13c
|
|
component_add+0x20/0x2c
|
|
dp_display_probe+0x340/0x384
|
|
platform_probe+0xc0/0x100
|
|
really_probe+0x110/0x304
|
|
__driver_probe_device+0xb8/0x120
|
|
driver_probe_device+0x4c/0xfc
|
|
__device_attach_driver+0xb0/0x128
|
|
bus_for_each_drv+0x90/0xdc
|
|
__device_attach+0xc8/0x174
|
|
device_initial_probe+0x20/0x2c
|
|
bus_probe_device+0x40/0xa4
|
|
deferred_probe_work_func+0x7c/0xb8
|
|
process_one_work+0x128/0x21c
|
|
process_scheduled_works+0x40/0x54
|
|
worker_thread+0x1ec/0x2a8
|
|
kthread+0x138/0x158
|
|
ret_from_fork+0x10/0x20
|
|
|
|
Fix it by making sure there are any bits to mask out.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2021-47497</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</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:
|
|
|
|
scsi: mpt3sas: Fix use-after-free warning
|
|
|
|
Fix the following use-after-free warning which is observed during
|
|
controller reset:
|
|
|
|
refcount_t: underflow; use-after-free.
|
|
WARNING: CPU: 23 PID: 5399 at lib/refcount.c:28 refcount_warn_saturate+0xa6/0xf0</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2022-48695</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</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:
|
|
|
|
nvmet: fix a use-after-free
|
|
|
|
Fix the following use-after-free complaint triggered by blktests nvme/004:
|
|
|
|
BUG: KASAN: user-memory-access in blk_mq_complete_request_remote+0xac/0x350
|
|
Read of size 4 at addr 0000607bd1835943 by task kworker/13:1/460
|
|
Workqueue: nvmet-wq nvme_loop_execute_work [nvme_loop]
|
|
Call Trace:
|
|
show_stack+0x52/0x58
|
|
dump_stack_lvl+0x49/0x5e
|
|
print_report.cold+0x36/0x1e2
|
|
kasan_report+0xb9/0xf0
|
|
__asan_load4+0x6b/0x80
|
|
blk_mq_complete_request_remote+0xac/0x350
|
|
nvme_loop_queue_response+0x1df/0x275 [nvme_loop]
|
|
__nvmet_req_complete+0x132/0x4f0 [nvmet]
|
|
nvmet_req_complete+0x15/0x40 [nvmet]
|
|
nvmet_execute_io_connect+0x18a/0x1f0 [nvmet]
|
|
nvme_loop_execute_work+0x20/0x30 [nvme_loop]
|
|
process_one_work+0x56e/0xa70
|
|
worker_thread+0x2d1/0x640
|
|
kthread+0x183/0x1c0
|
|
ret_from_fork+0x1f/0x30</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2022-48697</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.5</BaseScore>
|
|
<Vector>AV:N/AC:L/PR:N/UI:R/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-1678</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:
|
|
|
|
ALSA: emu10k1: Fix out of bounds access in snd_emu10k1_pcm_channel_alloc()
|
|
|
|
The voice allocator sometimes begins allocating from near the end of the
|
|
array and then wraps around, however snd_emu10k1_pcm_channel_alloc()
|
|
accesses the newly allocated voices as if it never wrapped around.
|
|
|
|
This results in out of bounds access if the first voice has a high enough
|
|
index so that first_voice + requested_voice_count > NUM_G (64).
|
|
The more voices are requested, the more likely it is for this to occur.
|
|
|
|
This was initially discovered using PipeWire, however it can be reproduced
|
|
by calling aplay multiple times with 16 channels:
|
|
aplay -r 48000 -D plughw:CARD=Live,DEV=3 -c 16 /dev/zero
|
|
|
|
UBSAN: array-index-out-of-bounds in sound/pci/emu10k1/emupcm.c:127:40
|
|
index 65 is out of range for type 'snd_emu10k1_voice [64]'
|
|
CPU: 1 PID: 31977 Comm: aplay Tainted: G W IOE 6.0.0-rc2-emu10k1+ #7
|
|
Hardware name: ASUSTEK COMPUTER INC P5W DH Deluxe/P5W DH Deluxe, BIOS 3002 07/22/2010
|
|
Call Trace:
|
|
<TASK>
|
|
dump_stack_lvl+0x49/0x63
|
|
dump_stack+0x10/0x16
|
|
ubsan_epilogue+0x9/0x3f
|
|
__ubsan_handle_out_of_bounds.cold+0x44/0x49
|
|
snd_emu10k1_playback_hw_params+0x3bc/0x420 [snd_emu10k1]
|
|
snd_pcm_hw_params+0x29f/0x600 [snd_pcm]
|
|
snd_pcm_common_ioctl+0x188/0x1410 [snd_pcm]
|
|
? exit_to_user_mode_prepare+0x35/0x170
|
|
? do_syscall_64+0x69/0x90
|
|
? syscall_exit_to_user_mode+0x26/0x50
|
|
? do_syscall_64+0x69/0x90
|
|
? exit_to_user_mode_prepare+0x35/0x170
|
|
snd_pcm_ioctl+0x27/0x40 [snd_pcm]
|
|
__x64_sys_ioctl+0x95/0xd0
|
|
do_syscall_64+0x5c/0x90
|
|
? do_syscall_64+0x69/0x90
|
|
? do_syscall_64+0x69/0x90
|
|
entry_SYSCALL_64_after_hwframe+0x63/0xcd</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2022-48702</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.4</BaseScore>
|
|
<Vector>AV:N/AC:L/PR:L/UI:N/S:U/C:L/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-1678</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:
|
|
|
|
drm/radeon: add a force flush to delay work when radeon
|
|
|
|
Although radeon card fence and wait for gpu to finish processing current batch rings,
|
|
there is still a corner case that radeon lockup work queue may not be fully flushed,
|
|
and meanwhile the radeon_suspend_kms() function has called pci_set_power_state() to
|
|
put device in D3hot state.
|
|
Per PCI spec rev 4.0 on 5.3.1.4.1 D3hot State.
|
|
> Configuration and Message requests are the only TLPs accepted by a Function in
|
|
> the D3hot state. All other received Requests must be handled as Unsupported Requests,
|
|
> and all received Completions may optionally be handled as Unexpected Completions.
|
|
This issue will happen in following logs:
|
|
Unable to handle kernel paging request at virtual address 00008800e0008010
|
|
CPU 0 kworker/0:3(131): Oops 0
|
|
pc = [<ffffffff811bea5c>] ra = [<ffffffff81240844>] ps = 0000 Tainted: G W
|
|
pc is at si_gpu_check_soft_reset+0x3c/0x240
|
|
ra is at si_dma_is_lockup+0x34/0xd0
|
|
v0 = 0000000000000000 t0 = fff08800e0008010 t1 = 0000000000010000
|
|
t2 = 0000000000008010 t3 = fff00007e3c00000 t4 = fff00007e3c00258
|
|
t5 = 000000000000ffff t6 = 0000000000000001 t7 = fff00007ef078000
|
|
s0 = fff00007e3c016e8 s1 = fff00007e3c00000 s2 = fff00007e3c00018
|
|
s3 = fff00007e3c00000 s4 = fff00007fff59d80 s5 = 0000000000000000
|
|
s6 = fff00007ef07bd98
|
|
a0 = fff00007e3c00000 a1 = fff00007e3c016e8 a2 = 0000000000000008
|
|
a3 = 0000000000000001 a4 = 8f5c28f5c28f5c29 a5 = ffffffff810f4338
|
|
t8 = 0000000000000275 t9 = ffffffff809b66f8 t10 = ff6769c5d964b800
|
|
t11= 000000000000b886 pv = ffffffff811bea20 at = 0000000000000000
|
|
gp = ffffffff81d89690 sp = 00000000aa814126
|
|
Disabling lock debugging due to kernel taint
|
|
Trace:
|
|
[<ffffffff81240844>] si_dma_is_lockup+0x34/0xd0
|
|
[<ffffffff81119610>] radeon_fence_check_lockup+0xd0/0x290
|
|
[<ffffffff80977010>] process_one_work+0x280/0x550
|
|
[<ffffffff80977350>] worker_thread+0x70/0x7c0
|
|
[<ffffffff80977410>] worker_thread+0x130/0x7c0
|
|
[<ffffffff80982040>] kthread+0x200/0x210
|
|
[<ffffffff809772e0>] worker_thread+0x0/0x7c0
|
|
[<ffffffff80981f8c>] kthread+0x14c/0x210
|
|
[<ffffffff80911658>] ret_from_kernel_thread+0x18/0x20
|
|
[<ffffffff80981e40>] kthread+0x0/0x210
|
|
Code: ad3e0008 43f0074a ad7e0018 ad9e0020 8c3001e8 40230101
|
|
<88210000> 4821ed21
|
|
So force lockup work queue flush to fix this problem.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2022-48704</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="12" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="12" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/radeon: fix a possible null pointer dereference
|
|
|
|
In radeon_fp_native_mode(), the return value of drm_mode_duplicate()
|
|
is assigned to mode, which will lead to a NULL pointer dereference
|
|
on failure of drm_mode_duplicate(). Add a check to avoid npd.
|
|
|
|
The failure status of drm_cvt_mode() on the other path is checked too.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2022-48710</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</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:
|
|
|
|
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-20.03-LTS-SP4</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-1678</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:
|
|
|
|
NTB: fix possible name leak in ntb_register_device()
|
|
|
|
If device_register() fails in ntb_register_device(), the device name
|
|
allocated by dev_set_name() should be freed. As per the comment in
|
|
device_register(), callers should use put_device() to give up the
|
|
reference in the error path. So fix this by calling put_device() in the
|
|
error path so that the name can be freed in kobject_cleanup().
|
|
|
|
As a result of this, put_device() in the error path of
|
|
ntb_register_device() is removed and the actual error is returned.
|
|
|
|
[mani: reworded commit message]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52652</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.3</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</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:
|
|
|
|
SUNRPC: fix a memleak in gss_import_v2_context
|
|
|
|
The ctx->mech_used.data allocated by kmemdup is not freed in neither
|
|
gss_import_v2_context nor it only caller gss_krb5_import_sec_context,
|
|
which frees ctx on error.
|
|
|
|
Thus, this patch reform the last call of gss_import_v2_context to the
|
|
gss_krb5_import_ctx_v2, preventing the memleak while keepping the return
|
|
formation.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52653</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.3</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</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:
|
|
|
|
io_uring: drop any code related to SCM_RIGHTS
|
|
|
|
This is dead code after we dropped support for passing io_uring fds
|
|
over SCM_RIGHTS, get rid of it.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52656</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</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:
|
|
|
|
ACPI: LPIT: Avoid u32 multiplication overflow
|
|
|
|
In lpit_update_residency() there is a possibility of overflow
|
|
in multiplication, if tsc_khz is large enough (> UINT_MAX/1000).
|
|
|
|
Change multiplication to mul_u32_u32().
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52683</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</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:
|
|
|
|
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-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</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:
|
|
|
|
drm/amd/pm: fix a double-free in si_dpm_init
|
|
|
|
When the allocation of
|
|
adev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries fails,
|
|
amdgpu_free_extended_power_table is called to free some fields of adev.
|
|
However, when the control flow returns to si_dpm_sw_init, it goes to
|
|
label dpm_failed and calls si_dpm_fini, which calls
|
|
amdgpu_free_extended_power_table again and free those fields again. Thus
|
|
a double-free is triggered.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52691</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</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:
|
|
|
|
calipso: fix memory leak in netlbl_calipso_add_pass()
|
|
|
|
If IPv6 support is disabled at boot (ipv6.disable=1),
|
|
the calipso_init() -> netlbl_calipso_ops_register() function isn't called,
|
|
and the netlbl_calipso_ops_get() function always returns NULL.
|
|
In this case, the netlbl_calipso_add_pass() function allocates memory
|
|
for the doi_def variable but doesn't free it with the calipso_doi_free().
|
|
|
|
BUG: memory leak
|
|
unreferenced object 0xffff888011d68180 (size 64):
|
|
comm "syz-executor.1", pid 10746, jiffies 4295410986 (age 17.928s)
|
|
hex dump (first 32 bytes):
|
|
00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
backtrace:
|
|
[<...>] kmalloc include/linux/slab.h:552 [inline]
|
|
[<...>] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [inline]
|
|
[<...>] netlbl_calipso_add+0x22e/0x4f0 net/netlabel/netlabel_calipso.c:111
|
|
[<...>] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739
|
|
[<...>] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]
|
|
[<...>] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800
|
|
[<...>] netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2515
|
|
[<...>] genl_rcv+0x29/0x40 net/netlink/genetlink.c:811
|
|
[<...>] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]
|
|
[<...>] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1339
|
|
[<...>] netlink_sendmsg+0x90a/0xdf0 net/netlink/af_netlink.c:1934
|
|
[<...>] sock_sendmsg_nosec net/socket.c:651 [inline]
|
|
[<...>] sock_sendmsg+0x157/0x190 net/socket.c:671
|
|
[<...>] ____sys_sendmsg+0x712/0x870 net/socket.c:2342
|
|
[<...>] ___sys_sendmsg+0xf8/0x170 net/socket.c:2396
|
|
[<...>] __sys_sendmsg+0xea/0x1b0 net/socket.c:2429
|
|
[<...>] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46
|
|
[<...>] entry_SYSCALL_64_after_hwframe+0x61/0xc6
|
|
|
|
Found by InfoTeCS on behalf of Linux Verification Center
|
|
(linuxtesting.org) with Syzkaller
|
|
|
|
[PM: merged via the LSM tree at Jakub Kicinski request]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52698</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="21" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="21" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:drm/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-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</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:
|
|
|
|
drm/amd: Fix UBSAN array-index-out-of-bounds for SMU7
|
|
|
|
For pptable structs that use flexible array sizes, use flexible arrays.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52818</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.6</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</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:
|
|
|
|
perf/core: Bail out early if the request AUX area is out of bound
|
|
|
|
When perf-record with a large AUX area, e.g 4GB, it fails with:
|
|
|
|
#perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1
|
|
failed to mmap with 12 (Cannot allocate memory)
|
|
|
|
and it reveals a WARNING with __alloc_pages():
|
|
|
|
------------[ cut here ]------------
|
|
WARNING: CPU: 44 PID: 17573 at mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248
|
|
Call trace:
|
|
__alloc_pages+0x1ec/0x248
|
|
__kmalloc_large_node+0xc0/0x1f8
|
|
__kmalloc_node+0x134/0x1e8
|
|
rb_alloc_aux+0xe0/0x298
|
|
perf_mmap+0x440/0x660
|
|
mmap_region+0x308/0x8a8
|
|
do_mmap+0x3c0/0x528
|
|
vm_mmap_pgoff+0xf4/0x1b8
|
|
ksys_mmap_pgoff+0x18c/0x218
|
|
__arm64_sys_mmap+0x38/0x58
|
|
invoke_syscall+0x50/0x128
|
|
el0_svc_common.constprop.0+0x58/0x188
|
|
do_el0_svc+0x34/0x50
|
|
el0_svc+0x34/0x108
|
|
el0t_64_sync_handler+0xb8/0xc0
|
|
el0t_64_sync+0x1a4/0x1a8
|
|
|
|
'rb->aux_pages' allocated by kcalloc() is a pointer array which is used to
|
|
maintains AUX trace pages. The allocated page for this array is physically
|
|
contiguous (and virtually contiguous) with an order of 0..MAX_ORDER. If the
|
|
size of pointer array crosses the limitation set by MAX_ORDER, it reveals a
|
|
WARNING.
|
|
|
|
So bail out early with -ENOMEM if the request AUX area is out of bound,
|
|
e.g.:
|
|
|
|
#perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1
|
|
failed to mmap with 12 (Cannot allocate memory)</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52835</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</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:
|
|
|
|
Input: synaptics-rmi4 - fix use after free in rmi_unregister_function()
|
|
|
|
The put_device() calls rmi_release_function() which frees "fn" so the
|
|
dereference on the next line "fn->num_of_irqs" is a use after free.
|
|
Move the put_device() to the end to fix this.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52840</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</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:
|
|
|
|
media: bttv: fix use after free error due to btv->timeout timer
|
|
|
|
There may be some a race condition between timer function
|
|
bttv_irq_timeout and bttv_remove. The timer is setup in
|
|
probe and there is no timer_delete operation in remove
|
|
function. When it hit kfree btv, the function might still be
|
|
invoked, which will cause use after free bug.
|
|
|
|
This bug is found by static analysis, it may be false positive.
|
|
|
|
Fix it by adding del_timer_sync invoking to the remove function.
|
|
|
|
cpu0 cpu1
|
|
bttv_probe
|
|
->timer_setup
|
|
->bttv_set_dma
|
|
->mod_timer;
|
|
bttv_remove
|
|
->kfree(btv);
|
|
->bttv_irq_timeout
|
|
->USE btv</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52847</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.8</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="26" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="26" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="27" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="27" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
thermal: core: prevent potential string overflow
|
|
|
|
The dev->id value comes from ida_alloc() so it's a number between zero
|
|
and INT_MAX. If it's too high then these sprintf()s will overflow.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2023-52868</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector></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-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="28" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="28" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nilfs2: prevent kernel bug at submit_bh_wbc()
|
|
|
|
Fix a bug where nilfs_get_block() returns a successful status when
|
|
searching and inserting the specified block both fail inconsistently. If
|
|
this inconsistent behavior is not due to a previously fixed bug, then an
|
|
unexpected race is occurring, so return a temporary error -EAGAIN instead.
|
|
|
|
This prevents callers such as __block_write_begin_int() from requesting a
|
|
read into a buffer that is not mapped, which would cause the BUG_ON check
|
|
for the BH_Mapped flag in submit_bh_wbc() to fail.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-26955</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="29" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="29" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nilfs2: fix failure to detect DAT corruption in btree and direct mappings
|
|
|
|
Patch series "nilfs2: fix kernel bug at submit_bh_wbc()".
|
|
|
|
This resolves a kernel BUG reported by syzbot. Since there are two
|
|
flaws involved, I've made each one a separate patch.
|
|
|
|
The first patch alone resolves the syzbot-reported bug, but I think
|
|
both fixes should be sent to stable, so I've tagged them as such.
|
|
|
|
|
|
This patch (of 2):
|
|
|
|
Syzbot has reported a kernel bug in submit_bh_wbc() when writing file data
|
|
to a nilfs2 file system whose metadata is corrupted.
|
|
|
|
There are two flaws involved in this issue.
|
|
|
|
The first flaw is that when nilfs_get_block() locates a data block using
|
|
btree or direct mapping, if the disk address translation routine
|
|
nilfs_dat_translate() fails with internal code -ENOENT due to DAT metadata
|
|
corruption, it can be passed back to nilfs_get_block(). This causes
|
|
nilfs_get_block() to misidentify an existing block as non-existent,
|
|
causing both data block lookup and insertion to fail inconsistently.
|
|
|
|
The second flaw is that nilfs_get_block() returns a successful status in
|
|
this inconsistent state. This causes the caller __block_write_begin_int()
|
|
or others to request a read even though the buffer is not mapped,
|
|
resulting in a BUG_ON check for the BH_Mapped flag in submit_bh_wbc()
|
|
failing.
|
|
|
|
This fixes the first issue by changing the return value to code -EINVAL
|
|
when a conversion using DAT fails with code -ENOENT, avoiding the
|
|
conflicting condition that leads to the kernel bug described above. Here,
|
|
code -EINVAL indicates that metadata corruption was detected during the
|
|
block lookup, which will be properly handled as a file system error and
|
|
converted to -EIO when passing through the nilfs2 bmap layer.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-26956</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="30" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="30" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
s390/zcrypt: fix reference counting on zcrypt card objects
|
|
|
|
Tests with hot-plugging crytpo cards on KVM guests with debug
|
|
kernel build revealed an use after free for the load field of
|
|
the struct zcrypt_card. The reason was an incorrect reference
|
|
handling of the zcrypt card object which could lead to a free
|
|
of the zcrypt card object while it was still in use.
|
|
|
|
This is an example of the slab message:
|
|
|
|
kernel: 0x00000000885a7512-0x00000000885a7513 @offset=1298. First byte 0x68 instead of 0x6b
|
|
kernel: Allocated in zcrypt_card_alloc+0x36/0x70 [zcrypt] age=18046 cpu=3 pid=43
|
|
kernel: kmalloc_trace+0x3f2/0x470
|
|
kernel: zcrypt_card_alloc+0x36/0x70 [zcrypt]
|
|
kernel: zcrypt_cex4_card_probe+0x26/0x380 [zcrypt_cex4]
|
|
kernel: ap_device_probe+0x15c/0x290
|
|
kernel: really_probe+0xd2/0x468
|
|
kernel: driver_probe_device+0x40/0xf0
|
|
kernel: __device_attach_driver+0xc0/0x140
|
|
kernel: bus_for_each_drv+0x8c/0xd0
|
|
kernel: __device_attach+0x114/0x198
|
|
kernel: bus_probe_device+0xb4/0xc8
|
|
kernel: device_add+0x4d2/0x6e0
|
|
kernel: ap_scan_adapter+0x3d0/0x7c0
|
|
kernel: ap_scan_bus+0x5a/0x3b0
|
|
kernel: ap_scan_bus_wq_callback+0x40/0x60
|
|
kernel: process_one_work+0x26e/0x620
|
|
kernel: worker_thread+0x21c/0x440
|
|
kernel: Freed in zcrypt_card_put+0x54/0x80 [zcrypt] age=9024 cpu=3 pid=43
|
|
kernel: kfree+0x37e/0x418
|
|
kernel: zcrypt_card_put+0x54/0x80 [zcrypt]
|
|
kernel: ap_device_remove+0x4c/0xe0
|
|
kernel: device_release_driver_internal+0x1c4/0x270
|
|
kernel: bus_remove_device+0x100/0x188
|
|
kernel: device_del+0x164/0x3c0
|
|
kernel: device_unregister+0x30/0x90
|
|
kernel: ap_scan_adapter+0xc8/0x7c0
|
|
kernel: ap_scan_bus+0x5a/0x3b0
|
|
kernel: ap_scan_bus_wq_callback+0x40/0x60
|
|
kernel: process_one_work+0x26e/0x620
|
|
kernel: worker_thread+0x21c/0x440
|
|
kernel: kthread+0x150/0x168
|
|
kernel: __ret_from_fork+0x3c/0x58
|
|
kernel: ret_from_fork+0xa/0x30
|
|
kernel: Slab 0x00000372022169c0 objects=20 used=18 fp=0x00000000885a7c88 flags=0x3ffff00000000a00(workingset|slab|node=0|zone=1|lastcpupid=0x1ffff)
|
|
kernel: Object 0x00000000885a74b8 @offset=1208 fp=0x00000000885a7c88
|
|
kernel: Redzone 00000000885a74b0: bb bb bb bb bb bb bb bb ........
|
|
kernel: Object 00000000885a74b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
|
|
kernel: Object 00000000885a74c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
|
|
kernel: Object 00000000885a74d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
|
|
kernel: Object 00000000885a74e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
|
|
kernel: Object 00000000885a74f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
|
|
kernel: Object 00000000885a7508: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 68 4b 6b 6b 6b a5 kkkkkkkkkkhKkkk.
|
|
kernel: Redzone 00000000885a7518: bb bb bb bb bb bb bb bb ........
|
|
kernel: Padding 00000000885a756c: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ
|
|
kernel: CPU: 0 PID: 387 Comm: systemd-udevd Not tainted 6.8.0-HF #2
|
|
kernel: Hardware name: IBM 3931 A01 704 (KVM/Linux)
|
|
kernel: Call Trace:
|
|
kernel: [<00000000ca5ab5b8>] dump_stack_lvl+0x90/0x120
|
|
kernel: [<00000000c99d78bc>] check_bytes_and_report+0x114/0x140
|
|
kernel: [<00000000c99d53cc>] check_object+0x334/0x3f8
|
|
kernel: [<00000000c99d820c>] alloc_debug_processing+0xc4/0x1f8
|
|
kernel: [<00000000c99d852e>] get_partial_node.part.0+0x1ee/0x3e0
|
|
kernel: [<00000000c99d94ec>] ___slab_alloc+0xaf4/0x13c8
|
|
kernel: [<00000000c99d9e38>] __slab_alloc.constprop.0+0x78/0xb8
|
|
kernel: [<00000000c99dc8dc>] __kmalloc+0x434/0x590
|
|
kernel: [<00000000c9b4c0ce>] ext4_htree_store_dirent+0x4e/0x1c0
|
|
kernel: [<00000000c9b908a2>] htree_dirblock_to_tree+0x17a/0x3f0
|
|
kernel:
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-26957</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.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-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="31" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="31" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="32" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="32" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mm: swap: fix race between free_swap_and_cache() and swapoff()
|
|
|
|
There was previously a theoretical window where swapoff() could run and
|
|
teardown a swap_info_struct while a call to free_swap_and_cache() was
|
|
running in another thread. This could cause, amongst other bad
|
|
possibilities, swap_page_trans_huge_swapped() (called by
|
|
free_swap_and_cache()) to access the freed memory for swap_map.
|
|
|
|
This is a theoretical problem and I haven't been able to provoke it from a
|
|
test case. But there has been agreement based on code review that this is
|
|
possible (see link below).
|
|
|
|
Fix it by using get_swap_device()/put_swap_device(), which will stall
|
|
swapoff(). There was an extra check in _swap_info_get() to confirm that
|
|
the swap entry was not free. This isn't present in get_swap_device()
|
|
because it doesn't make sense in general due to the race between getting
|
|
the reference and swapoff. So I've added an equivalent check directly in
|
|
free_swap_and_cache().
|
|
|
|
Details of how to provoke one possible issue (thanks to David Hildenbrand
|
|
for deriving this):
|
|
|
|
--8<-----
|
|
|
|
__swap_entry_free() might be the last user and result in
|
|
"count == SWAP_HAS_CACHE".
|
|
|
|
swapoff->try_to_unuse() will stop as soon as soon as si->inuse_pages==0.
|
|
|
|
So the question is: could someone reclaim the folio and turn
|
|
si->inuse_pages==0, before we completed swap_page_trans_huge_swapped().
|
|
|
|
Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages are
|
|
still references by swap entries.
|
|
|
|
Process 1 still references subpage 0 via swap entry.
|
|
Process 2 still references subpage 1 via swap entry.
|
|
|
|
Process 1 quits. Calls free_swap_and_cache().
|
|
-> count == SWAP_HAS_CACHE
|
|
[then, preempted in the hypervisor etc.]
|
|
|
|
Process 2 quits. Calls free_swap_and_cache().
|
|
-> count == SWAP_HAS_CACHE
|
|
|
|
Process 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls
|
|
__try_to_reclaim_swap().
|
|
|
|
__try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()->
|
|
put_swap_folio()->free_swap_slot()->swapcache_free_entries()->
|
|
swap_entry_free()->swap_range_free()->
|
|
...
|
|
WRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries);
|
|
|
|
What stops swapoff to succeed after process 2 reclaimed the swap cache
|
|
but before process1 finished its call to swap_page_trans_huge_swapped()?
|
|
|
|
--8<-----</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-26960</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector></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-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="33" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="33" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="34" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="34" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="35" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="35" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
clk: qcom: mmcc-apq8084: 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-26966</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="36" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="36" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
clk: qcom: gcc-ipq8074: 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-26969</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="37" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="37" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
crypto: qat - resolve race condition during AER recovery
|
|
|
|
During the PCI AER system's error recovery process, the kernel driver
|
|
may encounter a race condition with freeing the reset_data structure's
|
|
memory. If the device restart will take more than 10 seconds the function
|
|
scheduling that restart will exit due to a timeout, and the reset_data
|
|
structure will be freed. However, this data structure is used for
|
|
completion notification after the restart is completed, which leads
|
|
to a UAF bug.
|
|
|
|
This results in a KFENCE bug notice.
|
|
|
|
BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat]
|
|
Use-after-free read at 0x00000000bc56fddf (in kfence-#142):
|
|
adf_device_reset_worker+0x38/0xa0 [intel_qat]
|
|
process_one_work+0x173/0x340
|
|
|
|
To resolve this race condition, the memory associated to the container
|
|
of the work_struct is freed on the worker if the timeout expired,
|
|
otherwise on the function that schedules the worker.
|
|
The timeout detection can be done by checking if the caller is
|
|
still waiting for completion or not by using completion_done() function.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-26974</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.8</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/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-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="38" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="38" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="39" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="39" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nilfs2: fix OOB in nilfs_set_de_type
|
|
|
|
The size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is
|
|
defined as "S_IFMT >> S_SHIFT", but the nilfs_set_de_type() function,
|
|
which uses this array, specifies the index to read from the array in the
|
|
same way as "(mode & S_IFMT) >> S_SHIFT".
|
|
|
|
static void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode
|
|
*inode)
|
|
{
|
|
umode_t mode = inode->i_mode;
|
|
|
|
de->file_type = nilfs_type_by_mode[(mode & S_IFMT)>>S_SHIFT]; // oob
|
|
}
|
|
|
|
However, when the index is determined this way, an out-of-bounds (OOB)
|
|
error occurs by referring to an index that is 1 larger than the array size
|
|
when the condition "mode & S_IFMT == S_IFMT" is satisfied. Therefore, a
|
|
patch to resize the nilfs_type_by_mode array should be applied to prevent
|
|
OOB errors.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-26981</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="40" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="40" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Squashfs: check the inode number is not the invalid value of zero
|
|
|
|
Syskiller has produced an out of bounds access in fill_meta_index().
|
|
|
|
That out of bounds access is ultimately caused because the inode
|
|
has an inode number with the invalid value of zero, which was not checked.
|
|
|
|
The reason this causes the out of bounds access is due to following
|
|
sequence of events:
|
|
|
|
1. Fill_meta_index() is called to allocate (via empty_meta_index())
|
|
and fill a metadata index. It however suffers a data read error
|
|
and aborts, invalidating the newly returned empty metadata index.
|
|
It does this by setting the inode number of the index to zero,
|
|
which means unused (zero is not a valid inode number).
|
|
|
|
2. When fill_meta_index() is subsequently called again on another
|
|
read operation, locate_meta_index() returns the previous index
|
|
because it matches the inode number of 0. Because this index
|
|
has been returned it is expected to have been filled, and because
|
|
it hasn't been, an out of bounds access is performed.
|
|
|
|
This patch adds a sanity check which checks that the inode number
|
|
is not zero when the inode is created and returns -EINVAL if it is.
|
|
|
|
[phillip@squashfs.org.uk: whitespace fix]
|
|
Link: https://lkml.kernel.org/r/20240409204723.446925-1-phillip@squashfs.org.uk</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-26982</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="41" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="41" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="42" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="42" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
speakup: Avoid crash on very long word
|
|
|
|
In case a console is set up really large and contains a really long word
|
|
(> 256 characters), we have to stop before the length of the word buffer.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-26994</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="43" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="43" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
usb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport error
|
|
|
|
When ncm function is working and then stop usb0 interface for link down,
|
|
eth_stop() is called. At this piont, accidentally if usb transport error
|
|
should happen in usb_ep_enable(), 'in_ep' and/or 'out_ep' may not be enabled.
|
|
|
|
After that, ncm_disable() is called to disable for ncm unbind
|
|
but gether_disconnect() is never called since 'in_ep' is not enabled.
|
|
|
|
As the result, ncm object is released in ncm unbind
|
|
but 'dev->port_usb' associated to 'ncm->port' is not NULL.
|
|
|
|
And when ncm bind again to recover netdev, ncm object is reallocated
|
|
but usb0 interface is already associated to previous released ncm object.
|
|
|
|
Therefore, once usb0 interface is up and eth_start_xmit() is called,
|
|
released ncm object is dereferrenced and it might cause use-after-free memory.
|
|
|
|
[function unlink via configfs]
|
|
usb0: eth_stop dev->port_usb=ffffff9b179c3200
|
|
--> error happens in usb_ep_enable().
|
|
NCM: ncm_disable: ncm=ffffff9b179c3200
|
|
--> no gether_disconnect() since ncm->port.in_ep->enabled is false.
|
|
NCM: ncm_unbind: ncm unbind ncm=ffffff9b179c3200
|
|
NCM: ncm_free: ncm free ncm=ffffff9b179c3200 <-- released ncm
|
|
|
|
[function link via configfs]
|
|
NCM: ncm_alloc: ncm alloc ncm=ffffff9ac4f8a000
|
|
NCM: ncm_bind: ncm bind ncm=ffffff9ac4f8a000
|
|
NCM: ncm_set_alt: ncm=ffffff9ac4f8a000 alt=0
|
|
usb0: eth_open dev->port_usb=ffffff9b179c3200 <-- previous released ncm
|
|
usb0: eth_start dev->port_usb=ffffff9b179c3200 <--
|
|
eth_start_xmit()
|
|
--> dev->wrap()
|
|
Unable to handle kernel paging request at virtual address dead00000000014f
|
|
|
|
This patch addresses the issue by checking if 'ncm->netdev' is not NULL at
|
|
ncm_disable() to call gether_disconnect() to deassociate 'dev->port_usb'.
|
|
It's more reasonable to check 'ncm->netdev' to call gether_connect/disconnect
|
|
rather than check 'ncm->port.in_ep->enabled' since it might not be enabled
|
|
but the gether connection might be established.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-26996</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.4</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="44" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="44" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
serial/pmac_zilog: Remove flawed mitigation for rx irq flood
|
|
|
|
The mitigation was intended to stop the irq completely. That may be
|
|
better than a hard lock-up but it turns out that you get a crash anyway
|
|
if you're using pmac_zilog as a serial console:
|
|
|
|
ttyPZ0: pmz: rx irq flood !
|
|
BUG: spinlock recursion on CPU#0, swapper/0
|
|
|
|
That's because the pr_err() call in pmz_receive_chars() results in
|
|
pmz_console_write() attempting to lock a spinlock already locked in
|
|
pmz_interrupt(). With CONFIG_DEBUG_SPINLOCK=y, this produces a fatal
|
|
BUG splat. The spinlock in question is the one in struct uart_port.
|
|
|
|
Even when it's not fatal, the serial port rx function ceases to work.
|
|
Also, the iteration limit doesn't play nicely with QEMU, as can be
|
|
seen in the bug report linked below.
|
|
|
|
A web search for other reports of the error message "pmz: rx irq flood"
|
|
didn't produce anything. So I don't think this code is needed any more.
|
|
Remove it.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-26999</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="45" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="45" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.3</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="46" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="46" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
comedi: vmk80xx: fix incomplete endpoint checking
|
|
|
|
While vmk80xx does have endpoint checking implemented, some things
|
|
can fall through the cracks. Depending on the hardware model,
|
|
URBs can have either bulk or interrupt type, and current version
|
|
of vmk80xx_find_usb_endpoints() function does not take that fully
|
|
into account. While this warning does not seem to be too harmful,
|
|
at the very least it will crash systems with 'panic_on_warn' set on
|
|
them.
|
|
|
|
Fix the issue found by Syzkaller [1] by somewhat simplifying the
|
|
endpoint checking process with usb_find_common_endpoints() and
|
|
ensuring that only expected endpoint types are present.
|
|
|
|
This patch has not been tested on real hardware.
|
|
|
|
[1] Syzkaller report:
|
|
usb 1-1: BOGUS urb xfer, pipe 1 != type 3
|
|
WARNING: CPU: 0 PID: 781 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503
|
|
...
|
|
Call Trace:
|
|
<TASK>
|
|
usb_start_wait_urb+0x113/0x520 drivers/usb/core/message.c:59
|
|
vmk80xx_reset_device drivers/comedi/drivers/vmk80xx.c:227 [inline]
|
|
vmk80xx_auto_attach+0xa1c/0x1a40 drivers/comedi/drivers/vmk80xx.c:818
|
|
comedi_auto_config+0x238/0x380 drivers/comedi/drivers.c:1067
|
|
usb_probe_interface+0x5cd/0xb00 drivers/usb/core/driver.c:399
|
|
...
|
|
|
|
Similar issue also found by Syzkaller:</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-27001</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="47" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="47" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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-20.03-LTS-SP4</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-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="48" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="48" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/sched: Fix mirred deadlock on device recursion
|
|
|
|
When the mirred action is used on a classful egress qdisc and a packet is
|
|
mirrored or redirected to self we hit a qdisc lock deadlock.
|
|
See trace below.
|
|
|
|
[..... other info removed for brevity....]
|
|
[ 82.890906]
|
|
[ 82.890906] ============================================
|
|
[ 82.890906] WARNING: possible recursive locking detected
|
|
[ 82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G W
|
|
[ 82.890906] --------------------------------------------
|
|
[ 82.890906] ping/418 is trying to acquire lock:
|
|
[ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at:
|
|
__dev_queue_xmit+0x1778/0x3550
|
|
[ 82.890906]
|
|
[ 82.890906] but task is already holding lock:
|
|
[ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at:
|
|
__dev_queue_xmit+0x1778/0x3550
|
|
[ 82.890906]
|
|
[ 82.890906] other info that might help us debug this:
|
|
[ 82.890906] Possible unsafe locking scenario:
|
|
[ 82.890906]
|
|
[ 82.890906] CPU0
|
|
[ 82.890906] ----
|
|
[ 82.890906] lock(&sch->q.lock);
|
|
[ 82.890906] lock(&sch->q.lock);
|
|
[ 82.890906]
|
|
[ 82.890906] *** DEADLOCK ***
|
|
[ 82.890906]
|
|
[..... other info removed for brevity....]
|
|
|
|
Example setup (eth0->eth0) to recreate
|
|
tc qdisc add dev eth0 root handle 1: htb default 30
|
|
tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \
|
|
action mirred egress redirect dev eth0
|
|
|
|
Another example(eth0->eth1->eth0) to recreate
|
|
tc qdisc add dev eth0 root handle 1: htb default 30
|
|
tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \
|
|
action mirred egress redirect dev eth1
|
|
|
|
tc qdisc add dev eth1 root handle 1: htb default 30
|
|
tc filter add dev eth1 handle 1: protocol ip prio 2 matchall \
|
|
action mirred egress redirect dev eth0
|
|
|
|
We fix this by adding an owner field (CPU id) to struct Qdisc set after
|
|
root qdisc is entered. When the softirq enters it a second time, if the
|
|
qdisc owner is the same CPU, the packet is dropped to break the loop.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-27010</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="49" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="49" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nf_tables: fix memleak in map from abort path
|
|
|
|
The delete set command does not rely on the transaction object for
|
|
element removal, therefore, a combination of delete element + delete set
|
|
from the abort path could result in restoring twice the refcount of the
|
|
mapping.
|
|
|
|
Check for inactive element in the next generation for the delete element
|
|
command in the abort path, skip restoring state if next generation bit
|
|
has been already cleared. This is similar to the activate logic using
|
|
the set walk iterator.
|
|
|
|
[ 6170.286929] ------------[ cut here ]------------
|
|
[ 6170.286939] WARNING: CPU: 6 PID: 790302 at net/netfilter/nf_tables_api.c:2086 nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
|
|
[ 6170.287071] Modules linked in: [...]
|
|
[ 6170.287633] CPU: 6 PID: 790302 Comm: kworker/6:2 Not tainted 6.9.0-rc3+ #365
|
|
[ 6170.287768] RIP: 0010:nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
|
|
[ 6170.287886] Code: df 48 8d 7d 58 e8 69 2e 3b df 48 8b 7d 58 e8 80 1b 37 df 48 8d 7d 68 e8 57 2e 3b df 48 8b 7d 68 e8 6e 1b 37 df 48 89 ef eb c4 <0f> 0b 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 0f
|
|
[ 6170.287895] RSP: 0018:ffff888134b8fd08 EFLAGS: 00010202
|
|
[ 6170.287904] RAX: 0000000000000001 RBX: ffff888125bffb28 RCX: dffffc0000000000
|
|
[ 6170.287912] RDX: 0000000000000003 RSI: ffffffffa20298ab RDI: ffff88811ebe4750
|
|
[ 6170.287919] RBP: ffff88811ebe4700 R08: ffff88838e812650 R09: fffffbfff0623a55
|
|
[ 6170.287926] R10: ffffffff8311d2af R11: 0000000000000001 R12: ffff888125bffb10
|
|
[ 6170.287933] R13: ffff888125bffb10 R14: dead000000000122 R15: dead000000000100
|
|
[ 6170.287940] FS: 0000000000000000(0000) GS:ffff888390b00000(0000) knlGS:0000000000000000
|
|
[ 6170.287948] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 6170.287955] CR2: 00007fd31fc00710 CR3: 0000000133f60004 CR4: 00000000001706f0
|
|
[ 6170.287962] Call Trace:
|
|
[ 6170.287967] <TASK>
|
|
[ 6170.287973] ? __warn+0x9f/0x1a0
|
|
[ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
|
|
[ 6170.288092] ? report_bug+0x1b1/0x1e0
|
|
[ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
|
|
[ 6170.288092] ? report_bug+0x1b1/0x1e0
|
|
[ 6170.288104] ? handle_bug+0x3c/0x70
|
|
[ 6170.288112] ? exc_invalid_op+0x17/0x40
|
|
[ 6170.288120] ? asm_exc_invalid_op+0x1a/0x20
|
|
[ 6170.288132] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]
|
|
[ 6170.288243] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
|
|
[ 6170.288366] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]
|
|
[ 6170.288483] nf_tables_trans_destroy_work+0x588/0x590 [nf_tables]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-27011</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="50" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="50" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/rds: fix WARNING in rds_conn_connect_if_down
|
|
|
|
If connection isn't established yet, get_mr() will fail, trigger connection after
|
|
get_mr().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-27024</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.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-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="51" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="51" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
spi: spi-mt65xx: Fix NULL pointer access in interrupt handler
|
|
|
|
The TX buffer in spi_transfer can be a NULL pointer, so the interrupt
|
|
handler may end up writing to the invalid memory and cause crashes.
|
|
|
|
Add a check to trans->tx_buf before using it.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-27028</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.6</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/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-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="52" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="52" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
clk: zynq: Prevent null pointer dereference caused by kmalloc failure
|
|
|
|
The kmalloc() in zynq_clk_setup() will return null if the
|
|
physical memory has run out. As a result, if we use snprintf()
|
|
to write data to the null address, the null pointer dereference
|
|
bug will happen.
|
|
|
|
This patch uses a stack variable to replace the kmalloc().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-27037</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="53" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="53" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nfp: flower: handle acti_netdevs allocation failure
|
|
|
|
The kmalloc_array() in nfp_fl_lag_do_work() will return null, if
|
|
the physical memory has run out. As a result, if we dereference
|
|
the acti_netdevs, the null pointer dereference bugs will happen.
|
|
|
|
This patch adds a check to judge whether allocation failure occurs.
|
|
If it happens, the delayed work will be rescheduled and try again.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-27046</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="54" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="54" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return value
|
|
|
|
cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it
|
|
and return 0 in case of error.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-27051</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.6</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/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-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="55" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="55" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
s390/dasd: fix double module refcount decrement
|
|
|
|
Once the discipline is associated with the device, deleting the device
|
|
takes care of decrementing the module's refcount. Doing it manually on
|
|
this error path causes refcount to artificially decrease on each error
|
|
while it should just stay the same.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-27054</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="56" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="56" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="57" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="57" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nouveau: lock the client object tree.
|
|
|
|
It appears the client object tree has no locking unless I've missed
|
|
something else. Fix races around adding/removing client objects,
|
|
mostly vram bar mappings.
|
|
|
|
4562.099306] general protection fault, probably for non-canonical address 0x6677ed422bceb80c: 0000 [#1] PREEMPT SMP PTI
|
|
[ 4562.099314] CPU: 2 PID: 23171 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27
|
|
[ 4562.099324] Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021
|
|
[ 4562.099330] RIP: 0010:nvkm_object_search+0x1d/0x70 [nouveau]
|
|
[ 4562.099503] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 48 89 f8 48 85 f6 74 39 48 8b 87 a0 00 00 00 48 85 c0 74 12 <48> 8b 48 f8 48 39 ce 73 15 48 8b 40 10 48 85 c0 75 ee 48 c7 c0 fe
|
|
[ 4562.099506] RSP: 0000:ffffa94cc420bbf8 EFLAGS: 00010206
|
|
[ 4562.099512] RAX: 6677ed422bceb814 RBX: ffff98108791f400 RCX: ffff9810f26b8f58
|
|
[ 4562.099517] RDX: 0000000000000000 RSI: ffff9810f26b9158 RDI: ffff98108791f400
|
|
[ 4562.099519] RBP: ffff9810f26b9158 R08: 0000000000000000 R09: 0000000000000000
|
|
[ 4562.099521] R10: ffffa94cc420bc48 R11: 0000000000000001 R12: ffff9810f02a7cc0
|
|
[ 4562.099526] R13: 0000000000000000 R14: 00000000000000ff R15: 0000000000000007
|
|
[ 4562.099528] FS: 00007f629c5017c0(0000) GS:ffff98142c700000(0000) knlGS:0000000000000000
|
|
[ 4562.099534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 4562.099536] CR2: 00007f629a882000 CR3: 000000017019e004 CR4: 00000000003706f0
|
|
[ 4562.099541] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
[ 4562.099542] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
[ 4562.099544] Call Trace:
|
|
[ 4562.099555] <TASK>
|
|
[ 4562.099573] ? die_addr+0x36/0x90
|
|
[ 4562.099583] ? exc_general_protection+0x246/0x4a0
|
|
[ 4562.099593] ? asm_exc_general_protection+0x26/0x30
|
|
[ 4562.099600] ? nvkm_object_search+0x1d/0x70 [nouveau]
|
|
[ 4562.099730] nvkm_ioctl+0xa1/0x250 [nouveau]
|
|
[ 4562.099861] nvif_object_map_handle+0xc8/0x180 [nouveau]
|
|
[ 4562.099986] nouveau_ttm_io_mem_reserve+0x122/0x270 [nouveau]
|
|
[ 4562.100156] ? dma_resv_test_signaled+0x26/0xb0
|
|
[ 4562.100163] ttm_bo_vm_fault_reserved+0x97/0x3c0 [ttm]
|
|
[ 4562.100182] ? __mutex_unlock_slowpath+0x2a/0x270
|
|
[ 4562.100189] nouveau_ttm_fault+0x69/0xb0 [nouveau]
|
|
[ 4562.100356] __do_fault+0x32/0x150
|
|
[ 4562.100362] do_fault+0x7c/0x560
|
|
[ 4562.100369] __handle_mm_fault+0x800/0xc10
|
|
[ 4562.100382] handle_mm_fault+0x17c/0x3e0
|
|
[ 4562.100388] do_user_addr_fault+0x208/0x860
|
|
[ 4562.100395] exc_page_fault+0x7f/0x200
|
|
[ 4562.100402] asm_exc_page_fault+0x26/0x30
|
|
[ 4562.100412] RIP: 0033:0x9b9870
|
|
[ 4562.100419] Code: 85 a8 f7 ff ff 8b 8d 80 f7 ff ff 89 08 e9 18 f2 ff ff 0f 1f 84 00 00 00 00 00 44 89 32 e9 90 fa ff ff 0f 1f 84 00 00 00 00 00 <44> 89 32 e9 f8 f1 ff ff 0f 1f 84 00 00 00 00 00 66 44 89 32 e9 e7
|
|
[ 4562.100422] RSP: 002b:00007fff9ba2dc70 EFLAGS: 00010246
|
|
[ 4562.100426] RAX: 0000000000000004 RBX: 000000000dd65e10 RCX: 000000fff0000000
|
|
[ 4562.100428] RDX: 00007f629a882000 RSI: 00007f629a882000 RDI: 0000000000000066
|
|
[ 4562.100432] RBP: 00007fff9ba2e570 R08: 0000000000000000 R09: 0000000123ddf000
|
|
[ 4562.100434] R10: 0000000000000001 R11: 0000000000000246 R12: 000000007fffffff
|
|
[ 4562.100436] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
|
|
[ 4562.100446] </TASK>
|
|
[ 4562.100448] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink cmac bnep sunrpc iwlmvm intel_rapl_msr intel_rapl_common snd_sof_pci_intel_cnl x86_pkg_temp_thermal intel_powerclamp snd_sof_intel_hda_common mac80211 coretemp snd_soc_acpi_intel_match kvm_intel snd_soc_acpi snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda_mlink
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-27062</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="58" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="58" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: usbtv: Remove useless locks in usbtv_video_free()
|
|
|
|
Remove locks calls in usbtv_video_free() because
|
|
are useless and may led to a deadlock as reported here:
|
|
https://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000
|
|
Also remove usbtv_stop() call since it will be called when
|
|
unregistering the device.
|
|
|
|
Before 'c838530d230b' this issue would only be noticed if you
|
|
disconnect while streaming and now it is noticeable even when
|
|
disconnecting while not streaming.
|
|
|
|
|
|
[hverkuil: fix minor spelling mistake in log message]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-27072</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="59" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="59" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="60" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="60" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="61" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="61" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: v4l2-mem2mem: fix a memleak in v4l2_m2m_register_entity
|
|
|
|
The entity->name (i.e. name) is allocated in v4l2_m2m_register_entity
|
|
but isn't freed in its following error-handling paths. This patch
|
|
adds such deallocation to prevent memleak of entity->name.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-27077</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="62" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="62" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: v4l2-tpg: fix some memleaks in tpg_alloc
|
|
|
|
In tpg_alloc, resources should be deallocated in each and every
|
|
error-handling paths, since they are allocated in for statements.
|
|
Otherwise there would be memleaks because tpg_free is called only when
|
|
tpg_alloc return 0.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-27078</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.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-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="63" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="63" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
SUNRPC: fix some memleaks in gssx_dec_option_array
|
|
|
|
The creds and oa->data need to be freed in the error-handling paths after
|
|
their allocation. So this patch add these deallocations in the
|
|
corresponding paths.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-27388</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="64" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="64" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nft_flow_offload: reset dst in route object after setting up flow
|
|
|
|
dst is transferred to the flow object, route object does not own it
|
|
anymore. Reset dst in route object, otherwise if flow_offload_add()
|
|
fails, error path releases dst twice, leading to a refcount underflow.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-27403</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="65" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="65" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netrom: Fix data-races around sysctl_net_busy_read
|
|
|
|
We need to protect the reader reading the sysctl value because the
|
|
value can be changed concurrently.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-27419</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.3</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="66" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="66" xml:lang="en">Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-27426</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="67" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="67" xml:lang="en">Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-27427</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="68" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="68" xml:lang="en">Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-27428</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="69" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="69" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
dm snapshot: fix lockup in dm_exception_table_exit
|
|
|
|
There was reported lockup when we exit a snapshot with many exceptions.
|
|
Fix this by adding "cond_resched" to the loop that frees the exceptions.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-35805</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="70" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="70" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
soc: fsl: qbman: Always disable interrupts when taking cgr_lock
|
|
|
|
smp_call_function_single disables IRQs when executing the callback. To
|
|
prevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere.
|
|
This is already done by qman_update_cgr and qman_delete_cgr; fix the
|
|
other lockers.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-35806</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="71" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="71" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversion
|
|
|
|
The first kiocb_set_cancel_fn() argument may point at a struct kiocb
|
|
that is not embedded inside struct aio_kiocb. With the current code,
|
|
depending on the compiler, the req->ki_ctx read happens either before
|
|
the IOCB_AIO_RW test or after that test. Move the req->ki_ctx read such
|
|
that it is guaranteed that the IOCB_AIO_RW test happens first.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-35815</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="72" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="72" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/mlx5e: fix a double-free in arfs_create_groups
|
|
|
|
When `in` allocated by kvzalloc fails, arfs_create_groups will free
|
|
ft->g and return an error. However, arfs_create_table, the only caller of
|
|
arfs_create_groups, will hold this error and call to
|
|
mlx5e_destroy_flow_table, in which the ft->g will be freed again.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-35835</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="73" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="73" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="74" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="74" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ipv6: Fix infinite recursion in fib6_dump_done().
|
|
|
|
syzkaller reported infinite recursive calls of fib6_dump_done() during
|
|
netlink socket destruction. [1]
|
|
|
|
From the log, syzkaller sent an AF_UNSPEC RTM_GETROUTE message, and then
|
|
the response was generated. The following recvmmsg() resumed the dump
|
|
for IPv6, but the first call of inet6_dump_fib() failed at kzalloc() due
|
|
to the fault injection. [0]
|
|
|
|
12:01:34 executing program 3:
|
|
r0 = socket$nl_route(0x10, 0x3, 0x0)
|
|
sendmsg$nl_route(r0, ... snip ...)
|
|
recvmmsg(r0, ... snip ...) (fail_nth: 8)
|
|
|
|
Here, fib6_dump_done() was set to nlk_sk(sk)->cb.done, and the next call
|
|
of inet6_dump_fib() set it to nlk_sk(sk)->cb.args[3]. syzkaller stopped
|
|
receiving the response halfway through, and finally netlink_sock_destruct()
|
|
called nlk_sk(sk)->cb.done().
|
|
|
|
fib6_dump_done() calls fib6_dump_end() and nlk_sk(sk)->cb.done() if it
|
|
is still not NULL. fib6_dump_end() rewrites nlk_sk(sk)->cb.done() by
|
|
nlk_sk(sk)->cb.args[3], but it has the same function, not NULL, calling
|
|
itself recursively and hitting the stack guard page.
|
|
|
|
To avoid the issue, let's set the destructor after kzalloc().
|
|
|
|
[0]:
|
|
FAULT_INJECTION: forcing a failure.
|
|
name failslab, interval 1, probability 0, space 0, times 0
|
|
CPU: 1 PID: 432110 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
|
|
Call Trace:
|
|
<TASK>
|
|
dump_stack_lvl (lib/dump_stack.c:117)
|
|
should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153)
|
|
should_failslab (mm/slub.c:3733)
|
|
kmalloc_trace (mm/slub.c:3748 mm/slub.c:3827 mm/slub.c:3992)
|
|
inet6_dump_fib (./include/linux/slab.h:628 ./include/linux/slab.h:749 net/ipv6/ip6_fib.c:662)
|
|
rtnl_dump_all (net/core/rtnetlink.c:4029)
|
|
netlink_dump (net/netlink/af_netlink.c:2269)
|
|
netlink_recvmsg (net/netlink/af_netlink.c:1988)
|
|
____sys_recvmsg (net/socket.c:1046 net/socket.c:2801)
|
|
___sys_recvmsg (net/socket.c:2846)
|
|
do_recvmmsg (net/socket.c:2943)
|
|
__x64_sys_recvmmsg (net/socket.c:3041 net/socket.c:3034 net/socket.c:3034)
|
|
|
|
[1]:
|
|
BUG: TASK stack guard page was hit at 00000000f2fa9af1 (stack is 00000000b7912430..000000009a436beb)
|
|
stack guard page: 0000 [#1] PREEMPT SMP KASAN
|
|
CPU: 1 PID: 223719 Comm: kworker/1:3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
|
|
Workqueue: events netlink_sock_destruct_work
|
|
RIP: 0010:fib6_dump_done (net/ipv6/ip6_fib.c:570)
|
|
Code: 3c 24 e8 f3 e9 51 fd e9 28 fd ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 41 57 41 56 41 55 41 54 55 48 89 fd <53> 48 8d 5d 60 e8 b6 4d 07 fd 48 89 da 48 b8 00 00 00 00 00 fc ff
|
|
RSP: 0018:ffffc9000d980000 EFLAGS: 00010293
|
|
RAX: 0000000000000000 RBX: ffffffff84405990 RCX: ffffffff844059d3
|
|
RDX: ffff8881028e0000 RSI: ffffffff84405ac2 RDI: ffff88810c02f358
|
|
RBP: ffff88810c02f358 R08: 0000000000000007 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000224 R12: 0000000000000000
|
|
R13: ffff888007c82c78 R14: ffff888007c82c68 R15: ffff888007c82c68
|
|
FS: 0000000000000000(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: ffffc9000d97fff8 CR3: 0000000102309002 CR4: 0000000000770ef0
|
|
PKRU: 55555554
|
|
Call Trace:
|
|
<#DF>
|
|
</#DF>
|
|
<TASK>
|
|
fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))
|
|
fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))
|
|
...
|
|
fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))
|
|
fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))
|
|
netlink_sock_destruct (net/netlink/af_netlink.c:401)
|
|
__sk_destruct (net/core/sock.c:2177 (discriminator 2))
|
|
sk_destruct (net/core/sock.c:2224)
|
|
__sk_free (net/core/sock.c:2235)
|
|
sk_free (net/core/sock.c:2246)
|
|
process_one_work (kernel/workqueue.c:3259)
|
|
worker_thread (kernel/workqueue.c:3329 kernel/workqueue.
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-35886</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="75" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="75" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get()
|
|
|
|
nft_unregister_flowtable_type() within nf_flow_inet_module_exit() can
|
|
concurrent with __nft_flowtable_type_get() within nf_tables_newflowtable().
|
|
And thhere is not any protection when iterate over nf_tables_flowtables
|
|
list in __nft_flowtable_type_get(). Therefore, there is pertential
|
|
data-race of nf_tables_flowtables list entry.
|
|
|
|
Use list_for_each_entry_rcu() to iterate over nf_tables_flowtables list
|
|
in __nft_flowtable_type_get(), and use rcu_read_lock() in the caller
|
|
nft_flowtable_type_get() to protect the entire type query process.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-35898</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="76" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="76" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fbmon: prevent division by zero in fb_videomode_from_videomode()
|
|
|
|
The expression htotal * vtotal can have a zero value on
|
|
overflow. It is necessary to prevent division by zero like in
|
|
fb_var_to_videomode().
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with Svace.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-35922</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="77" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="77" 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-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="78" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="78" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()
|
|
|
|
The unhandled case in btrfs_relocate_sys_chunks() loop is a corruption,
|
|
as it could be caused only by two impossible conditions:
|
|
|
|
- at first the search key is set up to look for a chunk tree item, with
|
|
offset -1, this is an inexact search and the key->offset will contain
|
|
the correct offset upon a successful search, a valid chunk tree item
|
|
cannot have an offset -1
|
|
|
|
- after first successful search, the found_key corresponds to a chunk
|
|
item, the offset is decremented by 1 before the next loop, it's
|
|
impossible to find a chunk item there due to alignment and size
|
|
constraints</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-35936</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="79" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="79" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/client: Fully protect modes[] with dev->mode_config.mutex
|
|
|
|
The modes[] array contains pointers to modes on the connectors'
|
|
mode lists, which are protected by dev->mode_config.mutex.
|
|
Thus we need to extend modes[] the same protection or by the
|
|
time we use it the elements may already be pointing to
|
|
freed/reused memory.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-35950</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR: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-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="80" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="80" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
xsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING
|
|
|
|
syzbot reported an illegal copy in xsk_setsockopt() [1]
|
|
|
|
Make sure to validate setsockopt() @optlen parameter.
|
|
|
|
[1]
|
|
|
|
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
|
|
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]
|
|
BUG: KASAN: slab-out-of-bounds in xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420
|
|
Read of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549
|
|
|
|
CPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
|
|
print_address_description mm/kasan/report.c:377 [inline]
|
|
print_report+0x169/0x550 mm/kasan/report.c:488
|
|
kasan_report+0x143/0x180 mm/kasan/report.c:601
|
|
copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
|
|
copy_from_sockptr include/linux/sockptr.h:55 [inline]
|
|
xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420
|
|
do_sock_setsockopt+0x3af/0x720 net/socket.c:2311
|
|
__sys_setsockopt+0x1ae/0x250 net/socket.c:2334
|
|
__do_sys_setsockopt net/socket.c:2343 [inline]
|
|
__se_sys_setsockopt net/socket.c:2340 [inline]
|
|
__x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
|
|
do_syscall_64+0xfb/0x240
|
|
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
|
RIP: 0033:0x7fb40587de69
|
|
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
|
|
RSP: 002b:00007fb40665a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
|
|
RAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69
|
|
RDX: 0000000000000005 RSI: 000000000000011b RDI: 0000000000000006
|
|
RBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000
|
|
R10: 0000000020001980 R11: 0000000000000246 R12: 0000000000000000
|
|
R13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08
|
|
</TASK>
|
|
|
|
Allocated by task 7549:
|
|
kasan_save_stack mm/kasan/common.c:47 [inline]
|
|
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
|
|
poison_kmalloc_redzone mm/kasan/common.c:370 [inline]
|
|
__kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387
|
|
kasan_kmalloc include/linux/kasan.h:211 [inline]
|
|
__do_kmalloc_node mm/slub.c:3966 [inline]
|
|
__kmalloc+0x233/0x4a0 mm/slub.c:3979
|
|
kmalloc include/linux/slab.h:632 [inline]
|
|
__cgroup_bpf_run_filter_setsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869
|
|
do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293
|
|
__sys_setsockopt+0x1ae/0x250 net/socket.c:2334
|
|
__do_sys_setsockopt net/socket.c:2343 [inline]
|
|
__se_sys_setsockopt net/socket.c:2340 [inline]
|
|
__x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
|
|
do_syscall_64+0xfb/0x240
|
|
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
|
|
|
The buggy address belongs to the object at ffff888028c6cde0
|
|
which belongs to the cache kmalloc-8 of size 8
|
|
The buggy address is located 1 bytes to the right of
|
|
allocated 2-byte region [ffff888028c6cde0, ffff888028c6cde2)
|
|
|
|
The buggy address belongs to the physical page:
|
|
page:ffffea0000a31b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888028c6c9c0 pfn:0x28c6c
|
|
anon flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff)
|
|
page_type: 0xffffffff()
|
|
raw: 00fff00000000800 ffff888014c41280 0000000000000000 dead000000000001
|
|
raw: ffff888028c6c9c0 0000000080800057 00000001ffffffff 0000000000000000
|
|
page dumped because: kasan: bad access detected
|
|
page_owner tracks the page as allocated
|
|
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 6648, tgid 6644 (syz-executor.0), ts 133906047828, free_ts 133859922223
|
|
set_page_owner include/linux/page_owner.h:31 [inline]
|
|
post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533
|
|
prep_new_page mm/page_alloc.c:
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-35976</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="81" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="81" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-upThe flag I2C_HID_READ_PENDING is used to serialize I2C operations.However, this is not necessary, because I2C core already has its ownlocking for that.More importantly, this flag can cause a lock-up: if the flag is set ini2c_hid_xfer() and an interrupt happens, the interrupt handler(i2c_hid_irq) will check this flag and return immediately without doinganything, then the interrupt handler will be invoked again in aninfinite loop.Since interrupt handler is an RT task, it takes over the CPU and theflag-clearing task never gets scheduled, thus we have a lock-up.Delete this unnecessary flag.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-05-31</ReleaseDate>
|
|
<CVE>CVE-2024-35997</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-05-31</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1678</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |