3321 lines
143 KiB
XML
3321 lines
143 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
|
|
<DocumentTitle xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP3</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-1942</ID>
|
|
</Identification>
|
|
<Status>Final</Status>
|
|
<Version>1.0</Version>
|
|
<RevisionHistory>
|
|
<Revision>
|
|
<Number>1.0</Number>
|
|
<Date>2024-08-02</Date>
|
|
<Description>Initial</Description>
|
|
</Revision>
|
|
</RevisionHistory>
|
|
<InitialReleaseDate>2024-08-02</InitialReleaseDate>
|
|
<CurrentReleaseDate>2024-08-02</CurrentReleaseDate>
|
|
<Generator>
|
|
<Engine>openEuler SA Tool V1.0</Engine>
|
|
<Date>2024-08-02</Date>
|
|
</Generator>
|
|
</DocumentTracking>
|
|
<DocumentNotes>
|
|
<Note Title="Synopsis" Type="General" Ordinal="1" xml:lang="en">kernel security update</Note>
|
|
<Note Title="Summary" Type="General" Ordinal="2" xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP3.</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:
|
|
|
|
clk: sunxi-ng: Unregister clocks/resets when unbinding
|
|
|
|
Currently, unbinding a CCU driver unmaps the device's MMIO region, while
|
|
leaving its clocks/resets and their providers registered. This can cause
|
|
a page fault later when some clock operation tries to perform MMIO. Fix
|
|
this by separating the CCU initialization from the memory allocation,
|
|
and then using a devres callback to unregister the clocks and resets.
|
|
|
|
This also fixes a memory leak of the `struct ccu_reset`, and uses the
|
|
correct owner (the specific platform driver) for the clocks and resets.
|
|
|
|
Early OF clock providers are never unregistered, and limited error
|
|
handling is possible, so they are mostly unchanged. The error reporting
|
|
is made more consistent by moving the message inside of_sunxi_ccu_probe.(CVE-2021-47205)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
thermal/int340x_thermal: handle data_vault when the value is ZERO_SIZE_PTR
|
|
|
|
In some case, the GDDV returns a package with a buffer which has
|
|
zero length. It causes that kmemdup() returns ZERO_SIZE_PTR (0x10).
|
|
|
|
Then the data_vault_read() got NULL point dereference problem when
|
|
accessing the 0x10 value in data_vault.
|
|
|
|
[ 71.024560] BUG: kernel NULL pointer dereference, address:
|
|
0000000000000010
|
|
|
|
This patch uses ZERO_OR_NULL_PTR() for checking ZERO_SIZE_PTR or
|
|
NULL value in data_vault.(CVE-2022-48703)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: marvell: prestera: Add missing of_node_put() in prestera_switch_set_base_mac_addr
|
|
|
|
This node pointer is returned by of_find_compatible_node() with
|
|
refcount incremented. Calling of_node_put() to aovid the refcount leak.(CVE-2022-48859)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
of: Fix double free in of_parse_phandle_with_args_map
|
|
|
|
In of_parse_phandle_with_args_map() the inner loop that
|
|
iterates through the map entries calls of_node_put(new)
|
|
to free the reference acquired by the previous iteration
|
|
of the inner loop. This assumes that the value of "new" is
|
|
NULL on the first iteration of the inner loop.
|
|
|
|
Make sure that this is true in all iterations of the outer
|
|
loop by setting "new" to NULL after its value is assigned to "cur".
|
|
|
|
Extend the unittest to detect the double free and add an additional
|
|
test case that actually triggers this path.(CVE-2023-52679)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: gspca: cpia1: shift-out-of-bounds in set_flicker
|
|
|
|
Syzkaller reported the following issue:
|
|
UBSAN: shift-out-of-bounds in drivers/media/usb/gspca/cpia1.c:1031:27
|
|
shift exponent 245 is too large for 32-bit type 'int'
|
|
|
|
When the value of the variable "sd->params.exposure.gain" exceeds the
|
|
number of bits in an integer, a shift-out-of-bounds error is reported. It
|
|
is triggered because the variable "currentexp" cannot be left-shifted by
|
|
more than the number of bits in an integer. In order to avoid invalid
|
|
range during left-shift, the conditional expression is added.(CVE-2023-52764)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
init/main.c: Fix potential static_command_line memory overflow
|
|
|
|
We allocate memory of size 'xlen + strlen(boot_command_line) + 1' for
|
|
static_command_line, but the strings copied into static_command_line are
|
|
extra_command_line and command_line, rather than extra_command_line and
|
|
boot_command_line.
|
|
|
|
When strlen(command_line) > strlen(boot_command_line), static_command_line
|
|
will overflow.
|
|
|
|
This patch just recovers strlen(command_line) which was miss-consolidated
|
|
with strlen(boot_command_line) in the commit f5c7310ac73e ("init/main: add
|
|
checks for the return value of memblock_alloc*()")(CVE-2024-26988)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nf_tables: restore set elements when delete set fails
|
|
|
|
From abort path, nft_mapelem_activate() needs to restore refcounters to
|
|
the original state. Currently, it uses the set->ops->walk() to iterate
|
|
over these set elements. The existing set iterator skips inactive
|
|
elements in the next generation, this does not work from the abort path
|
|
to restore the original state since it has to skip active elements
|
|
instead (not inactive ones).
|
|
|
|
This patch moves the check for inactive elements to the set iterator
|
|
callback, then it reverses the logic for the .activate case which
|
|
needs to skip active elements.
|
|
|
|
Toggle next generation bit for elements when delete set command is
|
|
invoked and call nft_clear() from .activate (abort) path to restore the
|
|
next generation bit.
|
|
|
|
The splat below shows an object in mappings memleak:
|
|
|
|
[43929.457523] ------------[ cut here ]------------
|
|
[43929.457532] WARNING: CPU: 0 PID: 1139 at include/net/netfilter/nf_tables.h:1237 nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]
|
|
[...]
|
|
[43929.458014] RIP: 0010:nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]
|
|
[43929.458076] Code: 83 f8 01 77 ab 49 8d 7c 24 08 e8 37 5e d0 de 49 8b 6c 24 08 48 8d 7d 50 e8 e9 5c d0 de 8b 45 50 8d 50 ff 89 55 50 85 c0 75 86 <0f> 0b eb 82 0f 0b eb b3 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90
|
|
[43929.458081] RSP: 0018:ffff888140f9f4b0 EFLAGS: 00010246
|
|
[43929.458086] RAX: 0000000000000000 RBX: ffff8881434f5288 RCX: dffffc0000000000
|
|
[43929.458090] RDX: 00000000ffffffff RSI: ffffffffa26d28a7 RDI: ffff88810ecc9550
|
|
[43929.458093] RBP: ffff88810ecc9500 R08: 0000000000000001 R09: ffffed10281f3e8f
|
|
[43929.458096] R10: 0000000000000003 R11: ffff0000ffff0000 R12: ffff8881434f52a0
|
|
[43929.458100] R13: ffff888140f9f5f4 R14: ffff888151c7a800 R15: 0000000000000002
|
|
[43929.458103] FS: 00007f0c687c4740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000
|
|
[43929.458107] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[43929.458111] CR2: 00007f58dbe5b008 CR3: 0000000123602005 CR4: 00000000001706f0
|
|
[43929.458114] Call Trace:
|
|
[43929.458118] <TASK>
|
|
[43929.458121] ? __warn+0x9f/0x1a0
|
|
[43929.458127] ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]
|
|
[43929.458188] ? report_bug+0x1b1/0x1e0
|
|
[43929.458196] ? handle_bug+0x3c/0x70
|
|
[43929.458200] ? exc_invalid_op+0x17/0x40
|
|
[43929.458211] ? nft_setelem_data_deactivate+0xd7/0xf0 [nf_tables]
|
|
[43929.458271] ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]
|
|
[43929.458332] nft_mapelem_deactivate+0x24/0x30 [nf_tables]
|
|
[43929.458392] nft_rhash_walk+0xdd/0x180 [nf_tables]
|
|
[43929.458453] ? __pfx_nft_rhash_walk+0x10/0x10 [nf_tables]
|
|
[43929.458512] ? rb_insert_color+0x2e/0x280
|
|
[43929.458520] nft_map_deactivate+0xdc/0x1e0 [nf_tables]
|
|
[43929.458582] ? __pfx_nft_map_deactivate+0x10/0x10 [nf_tables]
|
|
[43929.458642] ? __pfx_nft_mapelem_deactivate+0x10/0x10 [nf_tables]
|
|
[43929.458701] ? __rcu_read_unlock+0x46/0x70
|
|
[43929.458709] nft_delset+0xff/0x110 [nf_tables]
|
|
[43929.458769] nft_flush_table+0x16f/0x460 [nf_tables]
|
|
[43929.458830] nf_tables_deltable+0x501/0x580 [nf_tables](CVE-2024-27012)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
f2fs: fix to avoid potential panic during recovery
|
|
|
|
During recovery, if FAULT_BLOCK is on, it is possible that
|
|
f2fs_reserve_new_block() will return -ENOSPC during recovery,
|
|
then it may trigger panic.
|
|
|
|
Also, if fault injection rate is 1 and only FAULT_BLOCK fault
|
|
type is on, it may encounter deadloop in loop of block reservation.
|
|
|
|
Let's change as below to fix these issues:
|
|
- remove bug_on() to avoid panic.
|
|
- limit the loop count of block reservation to avoid potential
|
|
deadloop.(CVE-2024-27032)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
clk: Fix clk_core_get NULL dereference
|
|
|
|
It is possible for clk_core_get to dereference a NULL in the following
|
|
sequence:
|
|
|
|
clk_core_get()
|
|
of_clk_get_hw_from_clkspec()
|
|
__of_clk_get_hw_from_provider()
|
|
__clk_get_hw()
|
|
|
|
__clk_get_hw() can return NULL which is dereferenced by clk_core_get() at
|
|
hw->core.
|
|
|
|
Prior to commit dde4eff47c82 ("clk: Look for parents with clkdev based
|
|
clk_lookups") the check IS_ERR_OR_NULL() was performed which would have
|
|
caught the NULL.
|
|
|
|
Reading the description of this function it talks about returning NULL but
|
|
that cannot be so at the moment.
|
|
|
|
Update the function to check for hw before dereferencing it and return NULL
|
|
if hw is NULL.(CVE-2024-27038)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: phy: fix phy_get_internal_delay accessing an empty array
|
|
|
|
The phy_get_internal_delay function could try to access to an empty
|
|
array in the case that the driver is calling phy_get_internal_delay
|
|
without defining delay_values and rx-internal-delay-ps or
|
|
tx-internal-delay-ps is defined to 0 in the device-tree.
|
|
This will lead to "unable to handle kernel NULL pointer dereference at
|
|
virtual address 0". To avoid this kernel oops, the test should be delay
|
|
>= 0. As there is already delay < 0 test just before, the test could
|
|
only be size == 0.(CVE-2024-27047)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: rtl8xxxu: add cancel_work_sync() for c2hcmd_work
|
|
|
|
The workqueue might still be running, when the driver is stopped. To
|
|
avoid a use-after-free, call cancel_work_sync() in rtl8xxxu_stop().(CVE-2024-27052)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nf_tables: do not compare internal table flags on updates
|
|
|
|
Restore skipping transaction if table update does not modify flags.(CVE-2024-27065)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
power: supply: bq27xxx-i2c: Do not free non existing IRQ
|
|
|
|
The bq27xxx i2c-client may not have an IRQ, in which case
|
|
client->irq will be 0. bq27xxx_battery_i2c_probe() already has
|
|
an if (client->irq) check wrapping the request_threaded_irq().
|
|
|
|
But bq27xxx_battery_i2c_remove() unconditionally calls
|
|
free_irq(client->irq) leading to:
|
|
|
|
[ 190.310742] ------------[ cut here ]------------
|
|
[ 190.310843] Trying to free already-free IRQ 0
|
|
[ 190.310861] WARNING: CPU: 2 PID: 1304 at kernel/irq/manage.c:1893 free_irq+0x1b8/0x310
|
|
|
|
Followed by a backtrace when unbinding the driver. Add
|
|
an if (client->irq) to bq27xxx_battery_i2c_remove() mirroring
|
|
probe() to fix this.(CVE-2024-27412)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Bluetooth: hci_event: Fix handling of HCI_EV_IO_CAPA_REQUEST
|
|
|
|
If we received HCI_EV_IO_CAPA_REQUEST while
|
|
HCI_OP_READ_REMOTE_EXT_FEATURES is yet to be responded assume the remote
|
|
does support SSP since otherwise this event shouldn't be generated.(CVE-2024-27416)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
dma-mapping: benchmark: fix node id validation
|
|
|
|
While validating node ids in map_benchmark_ioctl(), node_possible() may
|
|
be provided with invalid argument outside of [0,MAX_NUMNODES-1] range
|
|
leading to:
|
|
|
|
BUG: KASAN: wild-memory-access in map_benchmark_ioctl (kernel/dma/map_benchmark.c:214)
|
|
Read of size 8 at addr 1fffffff8ccb6398 by task dma_map_benchma/971
|
|
CPU: 7 PID: 971 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #37
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
|
|
Call Trace:
|
|
<TASK>
|
|
dump_stack_lvl (lib/dump_stack.c:117)
|
|
kasan_report (mm/kasan/report.c:603)
|
|
kasan_check_range (mm/kasan/generic.c:189)
|
|
variable_test_bit (arch/x86/include/asm/bitops.h:227) [inline]
|
|
arch_test_bit (arch/x86/include/asm/bitops.h:239) [inline]
|
|
_test_bit at (include/asm-generic/bitops/instrumented-non-atomic.h:142) [inline]
|
|
node_state (include/linux/nodemask.h:423) [inline]
|
|
map_benchmark_ioctl (kernel/dma/map_benchmark.c:214)
|
|
full_proxy_unlocked_ioctl (fs/debugfs/file.c:333)
|
|
__x64_sys_ioctl (fs/ioctl.c:890)
|
|
do_syscall_64 (arch/x86/entry/common.c:83)
|
|
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
|
|
|
|
Compare node ids with sane bounds first. NUMA_NO_NODE is considered a
|
|
special valid case meaning that benchmarking kthreads won't be bound to a
|
|
cpuset of a given node.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org).(CVE-2024-34777)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: mvpp2: clear BM pool before initialization
|
|
|
|
Register value persist after booting the kernel using
|
|
kexec which results in kernel panic. Thus clear the
|
|
BM pool registers before initialisation to fix the issue.(CVE-2024-35837)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amdgpu: Skip do PCI error slot reset during RAS recovery
|
|
|
|
Why:
|
|
The PCI error slot reset maybe triggered after inject ue to UMC multi times, this
|
|
caused system hang.
|
|
[ 557.371857] amdgpu 0000:af:00.0: amdgpu: GPU reset succeeded, trying to resume
|
|
[ 557.373718] [drm] PCIE GART of 512M enabled.
|
|
[ 557.373722] [drm] PTB located at 0x0000031FED700000
|
|
[ 557.373788] [drm] VRAM is lost due to GPU reset!
|
|
[ 557.373789] [drm] PSP is resuming...
|
|
[ 557.547012] mlx5_core 0000:55:00.0: mlx5_pci_err_detected Device state = 1 pci_status: 0. Exit, result = 3, need reset
|
|
[ 557.547067] [drm] PCI error: detected callback, state(1)!!
|
|
[ 557.547069] [drm] No support for XGMI hive yet...
|
|
[ 557.548125] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 0. Enter
|
|
[ 557.607763] mlx5_core 0000:55:00.0: wait vital counter value 0x16b5b after 1 iterations
|
|
[ 557.607777] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 1. Exit, err = 0, result = 5, recovered
|
|
[ 557.610492] [drm] PCI error: slot reset callback!!
|
|
...
|
|
[ 560.689382] amdgpu 0000:3f:00.0: amdgpu: GPU reset(2) succeeded!
|
|
[ 560.689546] amdgpu 0000:5a:00.0: amdgpu: GPU reset(2) succeeded!
|
|
[ 560.689562] general protection fault, probably for non-canonical address 0x5f080b54534f611f: 0000 [#1] SMP NOPTI
|
|
[ 560.701008] CPU: 16 PID: 2361 Comm: kworker/u448:9 Tainted: G OE 5.15.0-91-generic #101-Ubuntu
|
|
[ 560.712057] Hardware name: Microsoft C278A/C278A, BIOS C2789.5.BS.1C11.AG.1 11/08/2023
|
|
[ 560.720959] Workqueue: amdgpu-reset-hive amdgpu_ras_do_recovery [amdgpu]
|
|
[ 560.728887] RIP: 0010:amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu]
|
|
[ 560.736891] Code: ff 41 89 c6 e9 1b ff ff ff 44 0f b6 45 b0 e9 4f ff ff ff be 01 00 00 00 4c 89 e7 e8 76 c9 8b ff 44 0f b6 45 b0 e9 3c fd ff ff <48> 83 ba 18 02 00 00 00 0f 84 6a f8 ff ff 48 8d 7a 78 be 01 00 00
|
|
[ 560.757967] RSP: 0018:ffa0000032e53d80 EFLAGS: 00010202
|
|
[ 560.763848] RAX: ffa00000001dfd10 RBX: ffa0000000197090 RCX: ffa0000032e53db0
|
|
[ 560.771856] RDX: 5f080b54534f5f07 RSI: 0000000000000000 RDI: ff11000128100010
|
|
[ 560.779867] RBP: ffa0000032e53df0 R08: 0000000000000000 R09: ffffffffffe77f08
|
|
[ 560.787879] R10: 0000000000ffff0a R11: 0000000000000001 R12: 0000000000000000
|
|
[ 560.795889] R13: ffa0000032e53e00 R14: 0000000000000000 R15: 0000000000000000
|
|
[ 560.803889] FS: 0000000000000000(0000) GS:ff11007e7e800000(0000) knlGS:0000000000000000
|
|
[ 560.812973] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 560.819422] CR2: 000055a04c118e68 CR3: 0000000007410005 CR4: 0000000000771ee0
|
|
[ 560.827433] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
[ 560.835433] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
|
|
[ 560.843444] PKRU: 55555554
|
|
[ 560.846480] Call Trace:
|
|
[ 560.849225] <TASK>
|
|
[ 560.851580] ? show_trace_log_lvl+0x1d6/0x2ea
|
|
[ 560.856488] ? show_trace_log_lvl+0x1d6/0x2ea
|
|
[ 560.861379] ? amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu]
|
|
[ 560.867778] ? show_regs.part.0+0x23/0x29
|
|
[ 560.872293] ? __die_body.cold+0x8/0xd
|
|
[ 560.876502] ? die_addr+0x3e/0x60
|
|
[ 560.880238] ? exc_general_protection+0x1c5/0x410
|
|
[ 560.885532] ? asm_exc_general_protection+0x27/0x30
|
|
[ 560.891025] ? amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu]
|
|
[ 560.898323] amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu]
|
|
[ 560.904520] process_one_work+0x228/0x3d0
|
|
How:
|
|
In RAS recovery, mode-1 reset is issued from RAS fatal error handling and expected
|
|
all the nodes in a hive to be reset. no need to issue another mode-1 during this procedure.(CVE-2024-35931)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fs/9p: fix uninitialized values during inode evict
|
|
|
|
If an iget fails due to not being able to retrieve information
|
|
from the server then the inode structure is only partially
|
|
initialized. When the inode gets evicted, references to
|
|
uninitialized structures (like fscache cookies) were being
|
|
made.
|
|
|
|
This patch checks for a bad_inode before doing anything other
|
|
than clearing the inode from the cache. Since the inode is
|
|
bad, it shouldn't have any state associated with it that needs
|
|
to be written back (and there really isn't a way to complete
|
|
those anyways).(CVE-2024-36923)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nilfs2: fix potential kernel bug due to lack of writeback flag waiting
|
|
|
|
Destructive writes to a block device on which nilfs2 is mounted can cause
|
|
a kernel bug in the folio/page writeback start routine or writeback end
|
|
routine (__folio_start_writeback in the log below):
|
|
|
|
kernel BUG at mm/page-writeback.c:3070!
|
|
Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
|
|
...
|
|
RIP: 0010:__folio_start_writeback+0xbaa/0x10e0
|
|
Code: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff
|
|
e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 <0f>
|
|
0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00
|
|
...
|
|
Call Trace:
|
|
<TASK>
|
|
nilfs_segctor_do_construct+0x4654/0x69d0 [nilfs2]
|
|
nilfs_segctor_construct+0x181/0x6b0 [nilfs2]
|
|
nilfs_segctor_thread+0x548/0x11c0 [nilfs2]
|
|
kthread+0x2f0/0x390
|
|
ret_from_fork+0x4b/0x80
|
|
ret_from_fork_asm+0x1a/0x30
|
|
</TASK>
|
|
|
|
This is because when the log writer starts a writeback for segment summary
|
|
blocks or a super root block that use the backing device's page cache, it
|
|
does not wait for the ongoing folio/page writeback, resulting in an
|
|
inconsistent writeback state.
|
|
|
|
Fix this issue by waiting for ongoing writebacks when putting
|
|
folios/pages on the backing device into writeback state.(CVE-2024-37078)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference
|
|
|
|
In cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() is
|
|
assigned to mhdp_state->current_mode, and there is a dereference of it in
|
|
drm_mode_set_name(), which will lead to a NULL pointer dereference on
|
|
failure of drm_mode_duplicate().
|
|
|
|
Fix this bug add a check of mhdp_state->current_mode.(CVE-2024-38548)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: carl9170: add a proper sanity check for endpoints
|
|
|
|
Syzkaller reports [1] hitting a warning which is caused by presence
|
|
of a wrong endpoint type at the URB sumbitting stage. While there
|
|
was a check for a specific 4th endpoint, since it can switch types
|
|
between bulk and interrupt, other endpoints are trusted implicitly.
|
|
Similar warning is triggered in a couple of other syzbot issues [2].
|
|
|
|
Fix the issue by doing a comprehensive check of all endpoints
|
|
taking into account difference between high- and full-speed
|
|
configuration.
|
|
|
|
[1] Syzkaller report:
|
|
...
|
|
WARNING: CPU: 0 PID: 4721 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504
|
|
...
|
|
Call Trace:
|
|
<TASK>
|
|
carl9170_usb_send_rx_irq_urb+0x273/0x340 drivers/net/wireless/ath/carl9170/usb.c:504
|
|
carl9170_usb_init_device drivers/net/wireless/ath/carl9170/usb.c:939 [inline]
|
|
carl9170_usb_firmware_finish drivers/net/wireless/ath/carl9170/usb.c:999 [inline]
|
|
carl9170_usb_firmware_step2+0x175/0x240 drivers/net/wireless/ath/carl9170/usb.c:1028
|
|
request_firmware_work_func+0x130/0x240 drivers/base/firmware_loader/main.c:1107
|
|
process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289
|
|
worker_thread+0x669/0x1090 kernel/workqueue.c:2436
|
|
kthread+0x2e8/0x3a0 kernel/kthread.c:376
|
|
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
|
|
</TASK>
|
|
|
|
[2] Related syzkaller crashes:(CVE-2024-38567)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
macintosh/via-macii: Fix "BUG: sleeping function called from invalid context"
|
|
|
|
The via-macii ADB driver calls request_irq() after disabling hard
|
|
interrupts. But disabling interrupts isn't necessary here because the
|
|
VIA shift register interrupt was masked during VIA1 initialization.(CVE-2024-38607)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: i2c: et8ek8: Don't strip remove function when driver is builtin
|
|
|
|
Using __exit for the remove function results in the remove callback
|
|
being discarded with CONFIG_VIDEO_ET8EK8=y. When such a device gets
|
|
unbound (e.g. using sysfs or hotplug), the driver is just removed
|
|
without the cleanup being performed. This results in resource leaks. Fix
|
|
it by compiling in the remove callback unconditionally.
|
|
|
|
This also fixes a W=1 modpost warning:
|
|
|
|
WARNING: modpost: drivers/media/i2c/et8ek8/et8ek8: section mismatch in reference: et8ek8_i2c_driver+0x10 (section: .data) -> et8ek8_remove (section: .exit.text)(CVE-2024-38611)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amdgpu: add error handle to avoid out-of-bounds
|
|
|
|
if the sdma_v4_0_irq_id_to_seq return -EINVAL, the process should
|
|
be stop to avoid out-of-bounds read, so directly return -EINVAL.(CVE-2024-39471)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fbdev: savage: Handle err return when savagefb_check_var failed
|
|
|
|
The commit 04e5eac8f3ab("fbdev: savage: Error out if pixclock equals zero")
|
|
checks the value of pixclock to avoid divide-by-zero error. However
|
|
the function savagefb_probe doesn't handle the error return of
|
|
savagefb_check_var. When pixclock is 0, it will cause divide-by-zero error.(CVE-2024-39475)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING
|
|
|
|
Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with
|
|
small possibility, the root cause is exactly the same as commit
|
|
bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"")
|
|
|
|
However, Dan reported another hang after that, and junxiao investigated
|
|
the problem and found out that this is caused by plugged bio can't issue
|
|
from raid5d().
|
|
|
|
Current implementation in raid5d() has a weird dependence:
|
|
|
|
1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear
|
|
MD_SB_CHANGE_PENDING;
|
|
2) raid5d() handles IO in a deadloop, until all IO are issued;
|
|
3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;
|
|
|
|
This behaviour is introduce before v2.6, and for consequence, if other
|
|
context hold 'reconfig_mutex', and md_check_recovery() can't update
|
|
super_block, then raid5d() will waste one cpu 100% by the deadloop, until
|
|
'reconfig_mutex' is released.
|
|
|
|
Refer to the implementation from raid1 and raid10, fix this problem by
|
|
skipping issue IO if MD_SB_CHANGE_PENDING is still set after
|
|
md_check_recovery(), daemon thread will be woken up when 'reconfig_mutex'
|
|
is released. Meanwhile, the hang problem will be fixed as well.(CVE-2024-39476)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mmc: davinci: Don't strip remove function when driver is builtin
|
|
|
|
Using __exit for the remove function results in the remove callback being
|
|
discarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g.
|
|
using sysfs or hotplug), the driver is just removed without the cleanup
|
|
being performed. This results in resource leaks. Fix it by compiling in the
|
|
remove callback unconditionally.
|
|
|
|
This also fixes a W=1 modpost warning:
|
|
|
|
WARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch in
|
|
reference: davinci_mmcsd_driver+0x10 (section: .data) ->
|
|
davinci_mmcsd_remove (section: .exit.text)(CVE-2024-39484)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet
|
|
|
|
In lio_vf_rep_copy_packet() pg_info->page is compared to a NULL value,
|
|
but then it is unconditionally passed to skb_add_rx_frag() which looks
|
|
strange and could lead to null pointer dereference.
|
|
|
|
lio_vf_rep_copy_packet() call trace looks like:
|
|
octeon_droq_process_packets
|
|
octeon_droq_fast_process_packets
|
|
octeon_droq_dispatch_pkt
|
|
octeon_create_recv_info
|
|
...search in the dispatch_list...
|
|
->disp_fn(rdisp->rinfo, ...)
|
|
lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...)
|
|
In this path there is no code which sets pg_info->page to NULL.
|
|
So this check looks unneeded and doesn't solve potential problem.
|
|
But I guess the author had reason to add a check and I have no such card
|
|
and can't do real test.
|
|
In addition, the code in the function liquidio_push_packet() in
|
|
liquidio/lio_core.c does exactly the same.
|
|
|
|
Based on this, I consider the most acceptable compromise solution to
|
|
adjust this issue by moving skb_add_rx_frag() into conditional scope.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-39506)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
io_uring/io-wq: Use set_bit() and test_bit() at worker->flags
|
|
|
|
Utilize set_bit() and test_bit() on worker->flags within io_uring/io-wq
|
|
to address potential data races.
|
|
|
|
The structure io_worker->flags may be accessed through various data
|
|
paths, leading to concurrency issues. When KCSAN is enabled, it reveals
|
|
data races occurring in io_worker_handle_work and
|
|
io_wq_activate_free_worker functions.
|
|
|
|
BUG: KCSAN: data-race in io_worker_handle_work / io_wq_activate_free_worker
|
|
write to 0xffff8885c4246404 of 4 bytes by task 49071 on cpu 28:
|
|
io_worker_handle_work (io_uring/io-wq.c:434 io_uring/io-wq.c:569)
|
|
io_wq_worker (io_uring/io-wq.c:?)
|
|
<snip>
|
|
|
|
read to 0xffff8885c4246404 of 4 bytes by task 49024 on cpu 5:
|
|
io_wq_activate_free_worker (io_uring/io-wq.c:? io_uring/io-wq.c:285)
|
|
io_wq_enqueue (io_uring/io-wq.c:947)
|
|
io_queue_iowq (io_uring/io_uring.c:524)
|
|
io_req_task_submit (io_uring/io_uring.c:1511)
|
|
io_handle_tw_list (io_uring/io_uring.c:1198)
|
|
<snip>
|
|
|
|
Line numbers against commit 18daea77cca6 ("Merge tag 'for-linus' of
|
|
git://git.kernel.org/pub/scm/virt/kvm/kvm").
|
|
|
|
These races involve writes and reads to the same memory location by
|
|
different tasks running on different CPUs. To mitigate this, refactor
|
|
the code to use atomic operations such as set_bit(), test_bit(), and
|
|
clear_bit() instead of basic "and" and "or" operations. This ensures
|
|
thread-safe manipulation of worker flags.
|
|
|
|
Also, move `create_index` to avoid holes in the structure.(CVE-2024-39508)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
riscv: rewrite __kernel_map_pages() to fix sleeping in invalid context
|
|
|
|
__kernel_map_pages() is a debug function which clears the valid bit in page
|
|
table entry for deallocated pages to detect illegal memory accesses to
|
|
freed pages.
|
|
|
|
This function set/clear the valid bit using __set_memory(). __set_memory()
|
|
acquires init_mm's semaphore, and this operation may sleep. This is
|
|
problematic, because __kernel_map_pages() can be called in atomic context,
|
|
and thus is illegal to sleep. An example warning that this causes:
|
|
|
|
BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1578
|
|
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2, name: kthreadd
|
|
preempt_count: 2, expected: 0
|
|
CPU: 0 PID: 2 Comm: kthreadd Not tainted 6.9.0-g1d4c6d784ef6 #37
|
|
Hardware name: riscv-virtio,qemu (DT)
|
|
Call Trace:
|
|
[<ffffffff800060dc>] dump_backtrace+0x1c/0x24
|
|
[<ffffffff8091ef6e>] show_stack+0x2c/0x38
|
|
[<ffffffff8092baf8>] dump_stack_lvl+0x5a/0x72
|
|
[<ffffffff8092bb24>] dump_stack+0x14/0x1c
|
|
[<ffffffff8003b7ac>] __might_resched+0x104/0x10e
|
|
[<ffffffff8003b7f4>] __might_sleep+0x3e/0x62
|
|
[<ffffffff8093276a>] down_write+0x20/0x72
|
|
[<ffffffff8000cf00>] __set_memory+0x82/0x2fa
|
|
[<ffffffff8000d324>] __kernel_map_pages+0x5a/0xd4
|
|
[<ffffffff80196cca>] __alloc_pages_bulk+0x3b2/0x43a
|
|
[<ffffffff8018ee82>] __vmalloc_node_range+0x196/0x6ba
|
|
[<ffffffff80011904>] copy_process+0x72c/0x17ec
|
|
[<ffffffff80012ab4>] kernel_clone+0x60/0x2fe
|
|
[<ffffffff80012f62>] kernel_thread+0x82/0xa0
|
|
[<ffffffff8003552c>] kthreadd+0x14a/0x1be
|
|
[<ffffffff809357de>] ret_from_fork+0xe/0x1c
|
|
|
|
Rewrite this function with apply_to_existing_page_range(). It is fine to
|
|
not have any locking, because __kernel_map_pages() works with pages being
|
|
allocated/deallocated and those pages are not changed by anyone else in the
|
|
meantime.(CVE-2024-40915)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
iommu: Return right value in iommu_sva_bind_device()
|
|
|
|
iommu_sva_bind_device() should return either a sva bond handle or an
|
|
ERR_PTR value in error cases. Existing drivers (idxd and uacce) only
|
|
check the return value with IS_ERR(). This could potentially lead to
|
|
a kernel NULL pointer dereference issue if the function returns NULL
|
|
instead of an error pointer.
|
|
|
|
In reality, this doesn't cause any problems because iommu_sva_bind_device()
|
|
only returns NULL when the kernel is not configured with CONFIG_IOMMU_SVA.
|
|
In this case, iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_SVA) will
|
|
return an error, and the device drivers won't call iommu_sva_bind_device()
|
|
at all.(CVE-2024-40945)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ima: Avoid blocking in RCU read-side critical section
|
|
|
|
A panic happens in ima_match_policy:
|
|
|
|
BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
|
|
PGD 42f873067 P4D 0
|
|
Oops: 0000 [#1] SMP NOPTI
|
|
CPU: 5 PID: 1286325 Comm: kubeletmonit.sh
|
|
Kdump: loaded Tainted: P
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
|
|
BIOS 0.0.0 02/06/2015
|
|
RIP: 0010:ima_match_policy+0x84/0x450
|
|
Code: 49 89 fc 41 89 cf 31 ed 89 44 24 14 eb 1c 44 39
|
|
7b 18 74 26 41 83 ff 05 74 20 48 8b 1b 48 3b 1d
|
|
f2 b9 f4 00 0f 84 9c 01 00 00 <44> 85 73 10 74 ea
|
|
44 8b 6b 14 41 f6 c5 01 75 d4 41 f6 c5 02 74 0f
|
|
RSP: 0018:ff71570009e07a80 EFLAGS: 00010207
|
|
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000200
|
|
RDX: ffffffffad8dc7c0 RSI: 0000000024924925 RDI: ff3e27850dea2000
|
|
RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffffabfce739
|
|
R10: ff3e27810cc42400 R11: 0000000000000000 R12: ff3e2781825ef970
|
|
R13: 00000000ff3e2785 R14: 000000000000000c R15: 0000000000000001
|
|
FS: 00007f5195b51740(0000)
|
|
GS:ff3e278b12d40000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000000000000010 CR3: 0000000626d24002 CR4: 0000000000361ee0
|
|
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
Call Trace:
|
|
ima_get_action+0x22/0x30
|
|
process_measurement+0xb0/0x830
|
|
? page_add_file_rmap+0x15/0x170
|
|
? alloc_set_pte+0x269/0x4c0
|
|
? prep_new_page+0x81/0x140
|
|
? simple_xattr_get+0x75/0xa0
|
|
? selinux_file_open+0x9d/0xf0
|
|
ima_file_check+0x64/0x90
|
|
path_openat+0x571/0x1720
|
|
do_filp_open+0x9b/0x110
|
|
? page_counter_try_charge+0x57/0xc0
|
|
? files_cgroup_alloc_fd+0x38/0x60
|
|
? __alloc_fd+0xd4/0x250
|
|
? do_sys_open+0x1bd/0x250
|
|
do_sys_open+0x1bd/0x250
|
|
do_syscall_64+0x5d/0x1d0
|
|
entry_SYSCALL_64_after_hwframe+0x65/0xca
|
|
|
|
Commit c7423dbdbc9e ("ima: Handle -ESTALE returned by
|
|
ima_filter_rule_match()") introduced call to ima_lsm_copy_rule within a
|
|
RCU read-side critical section which contains kmalloc with GFP_KERNEL.
|
|
This implies a possible sleep and violates limitations of RCU read-side
|
|
critical sections on non-PREEMPT systems.
|
|
|
|
Sleeping within RCU read-side critical section might cause
|
|
synchronize_rcu() returning early and break RCU protection, allowing a
|
|
UAF to happen.
|
|
|
|
The root cause of this issue could be described as follows:
|
|
| Thread A | Thread B |
|
|
| |ima_match_policy |
|
|
| | rcu_read_lock |
|
|
|ima_lsm_update_rule | |
|
|
| synchronize_rcu | |
|
|
| | kmalloc(GFP_KERNEL)|
|
|
| | sleep |
|
|
==> synchronize_rcu returns early
|
|
| kfree(entry) | |
|
|
| | entry = entry->next|
|
|
==> UAF happens and entry now becomes NULL (or could be anything).
|
|
| | entry->action |
|
|
==> Accessing entry might cause panic.
|
|
|
|
To fix this issue, we are converting all kmalloc that is called within
|
|
RCU read-side critical section to use GFP_ATOMIC.
|
|
|
|
[PM: fixed missing comment, long lines, !CONFIG_IMA_LSM_RULES case](CVE-2024-40947)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
dmaengine: idxd: Fix possible Use-After-Free in irq_process_work_list
|
|
|
|
Use list_for_each_entry_safe() to allow iterating through the list and
|
|
deleting the entry in the iteration process. The descriptor is freed via
|
|
idxd_desc_complete() and there's a slight chance may cause issue for
|
|
the list iterator when the descriptor is reused by another thread
|
|
without it being deleted from the list.(CVE-2024-40956)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ipv6: prevent possible NULL dereference in rt6_probe()
|
|
|
|
syzbot caught a NULL dereference in rt6_probe() [1]
|
|
|
|
Bail out if __in6_dev_get() returns NULL.
|
|
|
|
[1]
|
|
Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cb: 0000 [#1] PREEMPT SMP KASAN PTI
|
|
KASAN: null-ptr-deref in range [0x0000000000000658-0x000000000000065f]
|
|
CPU: 1 PID: 22444 Comm: syz-executor.0 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
|
|
RIP: 0010:rt6_probe net/ipv6/route.c:656 [inline]
|
|
RIP: 0010:find_match+0x8c4/0xf50 net/ipv6/route.c:758
|
|
Code: 14 fd f7 48 8b 85 38 ff ff ff 48 c7 45 b0 00 00 00 00 48 8d b8 5c 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 19
|
|
RSP: 0018:ffffc900034af070 EFLAGS: 00010203
|
|
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004521000
|
|
RDX: 00000000000000cb RSI: ffffffff8990d0cd RDI: 000000000000065c
|
|
RBP: ffffc900034af150 R08: 0000000000000005 R09: 0000000000000000
|
|
R10: 0000000000000001 R11: 0000000000000002 R12: 000000000000000a
|
|
R13: 1ffff92000695e18 R14: ffff8880244a1d20 R15: 0000000000000000
|
|
FS: 00007f4844a5a6c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000001b31b27000 CR3: 000000002d42c000 CR4: 00000000003506f0
|
|
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
Call Trace:
|
|
<TASK>
|
|
rt6_nh_find_match+0xfa/0x1a0 net/ipv6/route.c:784
|
|
nexthop_for_each_fib6_nh+0x26d/0x4a0 net/ipv4/nexthop.c:1496
|
|
__find_rr_leaf+0x6e7/0xe00 net/ipv6/route.c:825
|
|
find_rr_leaf net/ipv6/route.c:853 [inline]
|
|
rt6_select net/ipv6/route.c:897 [inline]
|
|
fib6_table_lookup+0x57e/0xa30 net/ipv6/route.c:2195
|
|
ip6_pol_route+0x1cd/0x1150 net/ipv6/route.c:2231
|
|
pol_lookup_func include/net/ip6_fib.h:616 [inline]
|
|
fib6_rule_lookup+0x386/0x720 net/ipv6/fib6_rules.c:121
|
|
ip6_route_output_flags_noref net/ipv6/route.c:2639 [inline]
|
|
ip6_route_output_flags+0x1d0/0x640 net/ipv6/route.c:2651
|
|
ip6_dst_lookup_tail.constprop.0+0x961/0x1760 net/ipv6/ip6_output.c:1147
|
|
ip6_dst_lookup_flow+0x99/0x1d0 net/ipv6/ip6_output.c:1250
|
|
rawv6_sendmsg+0xdab/0x4340 net/ipv6/raw.c:898
|
|
inet_sendmsg+0x119/0x140 net/ipv4/af_inet.c:853
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg net/socket.c:745 [inline]
|
|
sock_write_iter+0x4b8/0x5c0 net/socket.c:1160
|
|
new_sync_write fs/read_write.c:497 [inline]
|
|
vfs_write+0x6b6/0x1140 fs/read_write.c:590
|
|
ksys_write+0x1f8/0x260 fs/read_write.c:643
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-40960)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mips: bmips: BCM6358: make sure CBR is correctly set
|
|
|
|
It was discovered that some device have CBR address set to 0 causing
|
|
kernel panic when arch_sync_dma_for_cpu_all is called.
|
|
|
|
This was notice in situation where the system is booted from TP1 and
|
|
BMIPS_GET_CBR() returns 0 instead of a valid address and
|
|
!!(read_c0_brcm_cmt_local() & (1 << 31)); not failing.
|
|
|
|
The current check whether RAC flush should be disabled or not are not
|
|
enough hence lets check if CBR is a valid address or not.(CVE-2024-40963)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
serial: imx: Introduce timeout when waiting on transmitter empty
|
|
|
|
By waiting at most 1 second for USR2_TXDC to be set, we avoid a potential
|
|
deadlock.
|
|
|
|
In case of the timeout, there is not much we can do, so we simply ignore
|
|
the transmitter state and optimistically try to continue.(CVE-2024-40967)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ext4: do not create EA inode under buffer lock
|
|
|
|
ext4_xattr_set_entry() creates new EA inodes while holding buffer lock
|
|
on the external xattr block. This is problematic as it nests all the
|
|
allocation locking (which acquires locks on other buffers) under the
|
|
buffer lock. This can even deadlock when the filesystem is corrupted and
|
|
e.g. quota file is setup to contain xattr block as data block. Move the
|
|
allocation of EA inode out of ext4_xattr_set_entry() into the callers.(CVE-2024-40972)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drop_monitor: replace spin_lock by raw_spin_lock
|
|
|
|
trace_drop_common() is called with preemption disabled, and it acquires
|
|
a spin_lock. This is problematic for RT kernels because spin_locks are
|
|
sleeping locks in this configuration, which causes the following splat:
|
|
|
|
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
|
|
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 449, name: rcuc/47
|
|
preempt_count: 1, expected: 0
|
|
RCU nest depth: 2, expected: 2
|
|
5 locks held by rcuc/47/449:
|
|
#0: ff1100086ec30a60 ((softirq_ctrl.lock)){+.+.}-{2:2}, at: __local_bh_disable_ip+0x105/0x210
|
|
#1: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: rt_spin_lock+0xbf/0x130
|
|
#2: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: __local_bh_disable_ip+0x11c/0x210
|
|
#3: ffffffffb394a160 (rcu_callback){....}-{0:0}, at: rcu_do_batch+0x360/0xc70
|
|
#4: ff1100086ee07520 (&data->lock){+.+.}-{2:2}, at: trace_drop_common.constprop.0+0xb5/0x290
|
|
irq event stamp: 139909
|
|
hardirqs last enabled at (139908): [<ffffffffb1df2b33>] _raw_spin_unlock_irqrestore+0x63/0x80
|
|
hardirqs last disabled at (139909): [<ffffffffb19bd03d>] trace_drop_common.constprop.0+0x26d/0x290
|
|
softirqs last enabled at (139892): [<ffffffffb07a1083>] __local_bh_enable_ip+0x103/0x170
|
|
softirqs last disabled at (139898): [<ffffffffb0909b33>] rcu_cpu_kthread+0x93/0x1f0
|
|
Preemption disabled at:
|
|
[<ffffffffb1de786b>] rt_mutex_slowunlock+0xab/0x2e0
|
|
CPU: 47 PID: 449 Comm: rcuc/47 Not tainted 6.9.0-rc2-rt1+ #7
|
|
Hardware name: Dell Inc. PowerEdge R650/0Y2G81, BIOS 1.6.5 04/15/2022
|
|
Call Trace:
|
|
<TASK>
|
|
dump_stack_lvl+0x8c/0xd0
|
|
dump_stack+0x14/0x20
|
|
__might_resched+0x21e/0x2f0
|
|
rt_spin_lock+0x5e/0x130
|
|
? trace_drop_common.constprop.0+0xb5/0x290
|
|
? skb_queue_purge_reason.part.0+0x1bf/0x230
|
|
trace_drop_common.constprop.0+0xb5/0x290
|
|
? preempt_count_sub+0x1c/0xd0
|
|
? _raw_spin_unlock_irqrestore+0x4a/0x80
|
|
? __pfx_trace_drop_common.constprop.0+0x10/0x10
|
|
? rt_mutex_slowunlock+0x26a/0x2e0
|
|
? skb_queue_purge_reason.part.0+0x1bf/0x230
|
|
? __pfx_rt_mutex_slowunlock+0x10/0x10
|
|
? skb_queue_purge_reason.part.0+0x1bf/0x230
|
|
trace_kfree_skb_hit+0x15/0x20
|
|
trace_kfree_skb+0xe9/0x150
|
|
kfree_skb_reason+0x7b/0x110
|
|
skb_queue_purge_reason.part.0+0x1bf/0x230
|
|
? __pfx_skb_queue_purge_reason.part.0+0x10/0x10
|
|
? mark_lock.part.0+0x8a/0x520
|
|
...
|
|
|
|
trace_drop_common() also disables interrupts, but this is a minor issue
|
|
because we could easily replace it with a local_lock.
|
|
|
|
Replace the spin_lock with raw_spin_lock to avoid sleeping in atomic
|
|
context.(CVE-2024-40980)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
batman-adv: bypass empty buckets in batadv_purge_orig_ref()
|
|
|
|
Many syzbot reports are pointing to soft lockups in
|
|
batadv_purge_orig_ref() [1]
|
|
|
|
Root cause is unknown, but we can avoid spending too much
|
|
time there and perhaps get more interesting reports.
|
|
|
|
[1]
|
|
|
|
watchdog: BUG: soft lockup - CPU#0 stuck for 27s! [kworker/u4:6:621]
|
|
Modules linked in:
|
|
irq event stamp: 6182794
|
|
hardirqs last enabled at (6182793): [<ffff8000801dae10>] __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386
|
|
hardirqs last disabled at (6182794): [<ffff80008ad66a78>] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]
|
|
hardirqs last disabled at (6182794): [<ffff80008ad66a78>] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551
|
|
softirqs last enabled at (6182792): [<ffff80008aab71c4>] spin_unlock_bh include/linux/spinlock.h:396 [inline]
|
|
softirqs last enabled at (6182792): [<ffff80008aab71c4>] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287
|
|
softirqs last disabled at (6182790): [<ffff80008aab61dc>] spin_lock_bh include/linux/spinlock.h:356 [inline]
|
|
softirqs last disabled at (6182790): [<ffff80008aab61dc>] batadv_purge_orig_ref+0x164/0x1228 net/batman-adv/originator.c:1271
|
|
CPU: 0 PID: 621 Comm: kworker/u4:6 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
|
|
Workqueue: bat_events batadv_purge_orig
|
|
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
|
pc : should_resched arch/arm64/include/asm/preempt.h:79 [inline]
|
|
pc : __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:388
|
|
lr : __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386
|
|
sp : ffff800099007970
|
|
x29: ffff800099007980 x28: 1fffe00018fce1bd x27: dfff800000000000
|
|
x26: ffff0000d2620008 x25: ffff0000c7e70de8 x24: 0000000000000001
|
|
x23: 1fffe00018e57781 x22: dfff800000000000 x21: ffff80008aab71c4
|
|
x20: ffff0001b40136c0 x19: ffff0000c72bbc08 x18: 1fffe0001a817bb0
|
|
x17: ffff800125414000 x16: ffff80008032116c x15: 0000000000000001
|
|
x14: 1fffe0001ee9d610 x13: 0000000000000000 x12: 0000000000000003
|
|
x11: 0000000000000000 x10: 0000000000ff0100 x9 : 0000000000000000
|
|
x8 : 00000000005e5789 x7 : ffff80008aab61dc x6 : 0000000000000000
|
|
x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000
|
|
x2 : 0000000000000006 x1 : 0000000000000080 x0 : ffff800125414000
|
|
Call trace:
|
|
__daif_local_irq_enable arch/arm64/include/asm/irqflags.h:27 [inline]
|
|
arch_local_irq_enable arch/arm64/include/asm/irqflags.h:49 [inline]
|
|
__local_bh_enable_ip+0x228/0x44c kernel/softirq.c:386
|
|
__raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline]
|
|
_raw_spin_unlock_bh+0x3c/0x4c kernel/locking/spinlock.c:210
|
|
spin_unlock_bh include/linux/spinlock.h:396 [inline]
|
|
batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287
|
|
batadv_purge_orig+0x20/0x70 net/batman-adv/originator.c:1300
|
|
process_one_work+0x694/0x1204 kernel/workqueue.c:2633
|
|
process_scheduled_works kernel/workqueue.c:2706 [inline]
|
|
worker_thread+0x938/0xef4 kernel/workqueue.c:2787
|
|
kthread+0x288/0x310 kernel/kthread.c:388
|
|
ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860
|
|
Sending NMI from CPU 0 to CPUs 1:
|
|
NMI backtrace for cpu 1
|
|
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
|
|
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
|
pc : arch_local_irq_enable+0x8/0xc arch/arm64/include/asm/irqflags.h:51
|
|
lr : default_idle_call+0xf8/0x128 kernel/sched/idle.c:103
|
|
sp : ffff800093a17d30
|
|
x29: ffff800093a17d30 x28: dfff800000000000 x27: 1ffff00012742fb4
|
|
x26: ffff80008ec9d000 x25: 0000000000000000 x24: 0000000000000002
|
|
x23: 1ffff00011d93a74 x22: ffff80008ec9d3a0 x21: 0000000000000000
|
|
x20: ffff0000c19dbc00 x19: ffff8000802d0fd8 x18: 1fffe00036804396
|
|
x17: ffff80008ec9d000 x16: ffff8000802d089c x15: 0000000000000001
|
|
---truncated---(CVE-2024-40981)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ssb: Fix potential NULL pointer dereference in ssb_device_uevent()
|
|
|
|
The ssb_device_uevent() function first attempts to convert the 'dev' pointer
|
|
to 'struct ssb_device *'. However, it mistakenly dereferences 'dev' before
|
|
performing the NULL check, potentially leading to a NULL pointer
|
|
dereference if 'dev' is NULL.
|
|
|
|
To fix this issue, move the NULL check before dereferencing the 'dev' pointer,
|
|
ensuring that the pointer is valid before attempting to use it.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-40982)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc()
|
|
|
|
syzbot found hanging tasks waiting on rtnl_lock [1]
|
|
|
|
A reproducer is available in the syzbot bug.
|
|
|
|
When a request to add multiple actions with the same index is sent, the
|
|
second request will block forever on the first request. This holds
|
|
rtnl_lock, and causes tasks to hang.
|
|
|
|
Return -EAGAIN to prevent infinite looping, while keeping documented
|
|
behavior.
|
|
|
|
[1]
|
|
|
|
INFO: task kworker/1:0:5088 blocked for more than 143 seconds.
|
|
Not tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0
|
|
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
|
|
task:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000
|
|
Workqueue: events_power_efficient reg_check_chans_work
|
|
Call Trace:
|
|
<TASK>
|
|
context_switch kernel/sched/core.c:5409 [inline]
|
|
__schedule+0xf15/0x5d00 kernel/sched/core.c:6746
|
|
__schedule_loop kernel/sched/core.c:6823 [inline]
|
|
schedule+0xe7/0x350 kernel/sched/core.c:6838
|
|
schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6895
|
|
__mutex_lock_common kernel/locking/mutex.c:684 [inline]
|
|
__mutex_lock+0x5b8/0x9c0 kernel/locking/mutex.c:752
|
|
wiphy_lock include/net/cfg80211.h:5953 [inline]
|
|
reg_leave_invalid_chans net/wireless/reg.c:2466 [inline]
|
|
reg_check_chans_work+0x10a/0x10e0 net/wireless/reg.c:2481(CVE-2024-40995)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amdkfd: don't allow mapping the MMIO HDP page with large pages
|
|
|
|
We don't get the right offset in that case. The GPU has
|
|
an unused 4K area of the register BAR space into which you can
|
|
remap registers. We remap the HDP flush registers into this
|
|
space to allow userspace (CPU or GPU) to flush the HDP when it
|
|
updates VRAM. However, on systems with >4K pages, we end up
|
|
exposing PAGE_SIZE of MMIO space.(CVE-2024-41011)</Note>
|
|
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP3.
|
|
|
|
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/security-bulletins/detail?id=openEuler-SA-2024-1942</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2021-47205</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48703</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48859</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-52679</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-52764</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-26988</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-27012</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-27032</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-27038</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-27047</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-27052</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-27065</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-27412</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-27416</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-34777</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-35837</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-35931</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-36923</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-37078</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38548</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38567</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38607</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38611</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39471</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39475</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39476</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39484</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39506</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39508</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40915</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40945</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40947</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40956</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40960</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40963</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40967</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40972</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40980</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40981</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40982</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40995</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41011</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47205</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48703</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48859</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52679</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52764</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26988</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27012</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27032</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27038</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27047</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27052</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27065</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27412</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27416</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-34777</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35837</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35931</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36923</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-37078</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38548</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38567</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38607</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38611</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39471</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39475</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39476</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39484</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39506</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39508</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40915</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40945</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40947</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40956</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40960</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40963</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40967</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40972</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40980</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40981</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40982</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40995</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41011</URL>
|
|
</Reference>
|
|
</DocumentReferences>
|
|
<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
|
|
<Branch Type="Product Name" Name="openEuler">
|
|
<FullProductName ProductID="openEuler-22.03-LTS-SP3" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">openEuler-22.03-LTS-SP3</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-221.0.0.124" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debuginfo-5.10.0-221.0.0.124.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-221.0.0.124" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-5.10.0-221.0.0.124.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-221.0.0.124" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-devel-5.10.0-221.0.0.124.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-221.0.0.124" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-devel-5.10.0-221.0.0.124.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-221.0.0.124" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-debuginfo-5.10.0-221.0.0.124.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-5.10.0-221.0.0.124" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-221.0.0.124.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-221.0.0.124" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-source-5.10.0-221.0.0.124.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-221.0.0.124" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-debuginfo-5.10.0-221.0.0.124.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-221.0.0.124" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debugsource-5.10.0-221.0.0.124.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-221.0.0.124" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-5.10.0-221.0.0.124.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-221.0.0.124" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-debuginfo-5.10.0-221.0.0.124.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-221.0.0.124" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-headers-5.10.0-221.0.0.124.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-221.0.0.124" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-5.10.0-221.0.0.124.oe2203sp3.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-5.10.0-221.0.0.124" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-221.0.0.124.oe2203sp3.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-221.0.0.124" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-devel-5.10.0-221.0.0.124.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-221.0.0.124" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-debuginfo-5.10.0-221.0.0.124.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-221.0.0.124" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debugsource-5.10.0-221.0.0.124.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-221.0.0.124" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-debuginfo-5.10.0-221.0.0.124.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-221.0.0.124" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-devel-5.10.0-221.0.0.124.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-5.10.0-221.0.0.124" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-221.0.0.124.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-221.0.0.124" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-5.10.0-221.0.0.124.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-221.0.0.124" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-headers-5.10.0-221.0.0.124.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-221.0.0.124" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-5.10.0-221.0.0.124.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-221.0.0.124" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debuginfo-5.10.0-221.0.0.124.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-221.0.0.124" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-5.10.0-221.0.0.124.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-221.0.0.124" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-debuginfo-5.10.0-221.0.0.124.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-221.0.0.124" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-source-5.10.0-221.0.0.124.oe2203sp3.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:
|
|
|
|
clk: sunxi-ng: Unregister clocks/resets when unbinding
|
|
|
|
Currently, unbinding a CCU driver unmaps the device's MMIO region, while
|
|
leaving its clocks/resets and their providers registered. This can cause
|
|
a page fault later when some clock operation tries to perform MMIO. Fix
|
|
this by separating the CCU initialization from the memory allocation,
|
|
and then using a devres callback to unregister the clocks and resets.
|
|
|
|
This also fixes a memory leak of the `struct ccu_reset`, and uses the
|
|
correct owner (the specific platform driver) for the clocks and resets.
|
|
|
|
Early OF clock providers are never unregistered, and limited error
|
|
handling is possible, so they are mostly unchanged. The error reporting
|
|
is made more consistent by moving the message inside of_sunxi_ccu_probe.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2021-47205</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
thermal/int340x_thermal: handle data_vault when the value is ZERO_SIZE_PTR
|
|
|
|
In some case, the GDDV returns a package with a buffer which has
|
|
zero length. It causes that kmemdup() returns ZERO_SIZE_PTR (0x10).
|
|
|
|
Then the data_vault_read() got NULL point dereference problem when
|
|
accessing the 0x10 value in data_vault.
|
|
|
|
[ 71.024560] BUG: kernel NULL pointer dereference, address:
|
|
0000000000000010
|
|
|
|
This patch uses ZERO_OR_NULL_PTR() for checking ZERO_SIZE_PTR or
|
|
NULL value in data_vault.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2022-48703</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
net: marvell: prestera: Add missing of_node_put() in prestera_switch_set_base_mac_addr
|
|
|
|
This node pointer is returned by of_find_compatible_node() with
|
|
refcount incremented. Calling of_node_put() to aovid the refcount leak.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2022-48859</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
of: Fix double free in of_parse_phandle_with_args_map
|
|
|
|
In of_parse_phandle_with_args_map() the inner loop that
|
|
iterates through the map entries calls of_node_put(new)
|
|
to free the reference acquired by the previous iteration
|
|
of the inner loop. This assumes that the value of "new" is
|
|
NULL on the first iteration of the inner loop.
|
|
|
|
Make sure that this is true in all iterations of the outer
|
|
loop by setting "new" to NULL after its value is assigned to "cur".
|
|
|
|
Extend the unittest to detect the double free and add an additional
|
|
test case that actually triggers this path.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2023-52679</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
media: gspca: cpia1: shift-out-of-bounds in set_flicker
|
|
|
|
Syzkaller reported the following issue:
|
|
UBSAN: shift-out-of-bounds in drivers/media/usb/gspca/cpia1.c:1031:27
|
|
shift exponent 245 is too large for 32-bit type 'int'
|
|
|
|
When the value of the variable "sd->params.exposure.gain" exceeds the
|
|
number of bits in an integer, a shift-out-of-bounds error is reported. It
|
|
is triggered because the variable "currentexp" cannot be left-shifted by
|
|
more than the number of bits in an integer. In order to avoid invalid
|
|
range during left-shift, the conditional expression is added.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2023-52764</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
init/main.c: Fix potential static_command_line memory overflow
|
|
|
|
We allocate memory of size 'xlen + strlen(boot_command_line) + 1' for
|
|
static_command_line, but the strings copied into static_command_line are
|
|
extra_command_line and command_line, rather than extra_command_line and
|
|
boot_command_line.
|
|
|
|
When strlen(command_line) > strlen(boot_command_line), static_command_line
|
|
will overflow.
|
|
|
|
This patch just recovers strlen(command_line) which was miss-consolidated
|
|
with strlen(boot_command_line) in the commit f5c7310ac73e ("init/main: add
|
|
checks for the return value of memblock_alloc*()")</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-26988</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.3</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
netfilter: nf_tables: restore set elements when delete set fails
|
|
|
|
From abort path, nft_mapelem_activate() needs to restore refcounters to
|
|
the original state. Currently, it uses the set->ops->walk() to iterate
|
|
over these set elements. The existing set iterator skips inactive
|
|
elements in the next generation, this does not work from the abort path
|
|
to restore the original state since it has to skip active elements
|
|
instead (not inactive ones).
|
|
|
|
This patch moves the check for inactive elements to the set iterator
|
|
callback, then it reverses the logic for the .activate case which
|
|
needs to skip active elements.
|
|
|
|
Toggle next generation bit for elements when delete set command is
|
|
invoked and call nft_clear() from .activate (abort) path to restore the
|
|
next generation bit.
|
|
|
|
The splat below shows an object in mappings memleak:
|
|
|
|
[43929.457523] ------------[ cut here ]------------
|
|
[43929.457532] WARNING: CPU: 0 PID: 1139 at include/net/netfilter/nf_tables.h:1237 nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]
|
|
[...]
|
|
[43929.458014] RIP: 0010:nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]
|
|
[43929.458076] Code: 83 f8 01 77 ab 49 8d 7c 24 08 e8 37 5e d0 de 49 8b 6c 24 08 48 8d 7d 50 e8 e9 5c d0 de 8b 45 50 8d 50 ff 89 55 50 85 c0 75 86 <0f> 0b eb 82 0f 0b eb b3 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90
|
|
[43929.458081] RSP: 0018:ffff888140f9f4b0 EFLAGS: 00010246
|
|
[43929.458086] RAX: 0000000000000000 RBX: ffff8881434f5288 RCX: dffffc0000000000
|
|
[43929.458090] RDX: 00000000ffffffff RSI: ffffffffa26d28a7 RDI: ffff88810ecc9550
|
|
[43929.458093] RBP: ffff88810ecc9500 R08: 0000000000000001 R09: ffffed10281f3e8f
|
|
[43929.458096] R10: 0000000000000003 R11: ffff0000ffff0000 R12: ffff8881434f52a0
|
|
[43929.458100] R13: ffff888140f9f5f4 R14: ffff888151c7a800 R15: 0000000000000002
|
|
[43929.458103] FS: 00007f0c687c4740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000
|
|
[43929.458107] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[43929.458111] CR2: 00007f58dbe5b008 CR3: 0000000123602005 CR4: 00000000001706f0
|
|
[43929.458114] Call Trace:
|
|
[43929.458118] <TASK>
|
|
[43929.458121] ? __warn+0x9f/0x1a0
|
|
[43929.458127] ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]
|
|
[43929.458188] ? report_bug+0x1b1/0x1e0
|
|
[43929.458196] ? handle_bug+0x3c/0x70
|
|
[43929.458200] ? exc_invalid_op+0x17/0x40
|
|
[43929.458211] ? nft_setelem_data_deactivate+0xd7/0xf0 [nf_tables]
|
|
[43929.458271] ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]
|
|
[43929.458332] nft_mapelem_deactivate+0x24/0x30 [nf_tables]
|
|
[43929.458392] nft_rhash_walk+0xdd/0x180 [nf_tables]
|
|
[43929.458453] ? __pfx_nft_rhash_walk+0x10/0x10 [nf_tables]
|
|
[43929.458512] ? rb_insert_color+0x2e/0x280
|
|
[43929.458520] nft_map_deactivate+0xdc/0x1e0 [nf_tables]
|
|
[43929.458582] ? __pfx_nft_map_deactivate+0x10/0x10 [nf_tables]
|
|
[43929.458642] ? __pfx_nft_mapelem_deactivate+0x10/0x10 [nf_tables]
|
|
[43929.458701] ? __rcu_read_unlock+0x46/0x70
|
|
[43929.458709] nft_delset+0xff/0x110 [nf_tables]
|
|
[43929.458769] nft_flush_table+0x16f/0x460 [nf_tables]
|
|
[43929.458830] nf_tables_deltable+0x501/0x580 [nf_tables]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-27012</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
f2fs: fix to avoid potential panic during recovery
|
|
|
|
During recovery, if FAULT_BLOCK is on, it is possible that
|
|
f2fs_reserve_new_block() will return -ENOSPC during recovery,
|
|
then it may trigger panic.
|
|
|
|
Also, if fault injection rate is 1 and only FAULT_BLOCK fault
|
|
type is on, it may encounter deadloop in loop of block reservation.
|
|
|
|
Let's change as below to fix these issues:
|
|
- remove bug_on() to avoid panic.
|
|
- limit the loop count of block reservation to avoid potential
|
|
deadloop.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-27032</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
clk: Fix clk_core_get NULL dereference
|
|
|
|
It is possible for clk_core_get to dereference a NULL in the following
|
|
sequence:
|
|
|
|
clk_core_get()
|
|
of_clk_get_hw_from_clkspec()
|
|
__of_clk_get_hw_from_provider()
|
|
__clk_get_hw()
|
|
|
|
__clk_get_hw() can return NULL which is dereferenced by clk_core_get() at
|
|
hw->core.
|
|
|
|
Prior to commit dde4eff47c82 ("clk: Look for parents with clkdev based
|
|
clk_lookups") the check IS_ERR_OR_NULL() was performed which would have
|
|
caught the NULL.
|
|
|
|
Reading the description of this function it talks about returning NULL but
|
|
that cannot be so at the moment.
|
|
|
|
Update the function to check for hw before dereferencing it and return NULL
|
|
if hw is NULL.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-27038</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
net: phy: fix phy_get_internal_delay accessing an empty array
|
|
|
|
The phy_get_internal_delay function could try to access to an empty
|
|
array in the case that the driver is calling phy_get_internal_delay
|
|
without defining delay_values and rx-internal-delay-ps or
|
|
tx-internal-delay-ps is defined to 0 in the device-tree.
|
|
This will lead to "unable to handle kernel NULL pointer dereference at
|
|
virtual address 0". To avoid this kernel oops, the test should be delay
|
|
>= 0. As there is already delay < 0 test just before, the test could
|
|
only be size == 0.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-27047</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
wifi: rtl8xxxu: add cancel_work_sync() for c2hcmd_work
|
|
|
|
The workqueue might still be running, when the driver is stopped. To
|
|
avoid a use-after-free, call cancel_work_sync() in rtl8xxxu_stop().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-27052</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.7</BaseScore>
|
|
<Vector>AV:L/AC:L/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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
netfilter: nf_tables: do not compare internal table flags on updates
|
|
|
|
Restore skipping transaction if table update does not modify flags.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-27065</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
power: supply: bq27xxx-i2c: Do not free non existing IRQ
|
|
|
|
The bq27xxx i2c-client may not have an IRQ, in which case
|
|
client->irq will be 0. bq27xxx_battery_i2c_probe() already has
|
|
an if (client->irq) check wrapping the request_threaded_irq().
|
|
|
|
But bq27xxx_battery_i2c_remove() unconditionally calls
|
|
free_irq(client->irq) leading to:
|
|
|
|
[ 190.310742] ------------[ cut here ]------------
|
|
[ 190.310843] Trying to free already-free IRQ 0
|
|
[ 190.310861] WARNING: CPU: 2 PID: 1304 at kernel/irq/manage.c:1893 free_irq+0x1b8/0x310
|
|
|
|
Followed by a backtrace when unbinding the driver. Add
|
|
an if (client->irq) to bq27xxx_battery_i2c_remove() mirroring
|
|
probe() to fix this.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-27412</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
Bluetooth: hci_event: Fix handling of HCI_EV_IO_CAPA_REQUEST
|
|
|
|
If we received HCI_EV_IO_CAPA_REQUEST while
|
|
HCI_OP_READ_REMOTE_EXT_FEATURES is yet to be responded assume the remote
|
|
does support SSP since otherwise this event shouldn't be generated.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-27416</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
dma-mapping: benchmark: fix node id validation
|
|
|
|
While validating node ids in map_benchmark_ioctl(), node_possible() may
|
|
be provided with invalid argument outside of [0,MAX_NUMNODES-1] range
|
|
leading to:
|
|
|
|
BUG: KASAN: wild-memory-access in map_benchmark_ioctl (kernel/dma/map_benchmark.c:214)
|
|
Read of size 8 at addr 1fffffff8ccb6398 by task dma_map_benchma/971
|
|
CPU: 7 PID: 971 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #37
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
|
|
Call Trace:
|
|
<TASK>
|
|
dump_stack_lvl (lib/dump_stack.c:117)
|
|
kasan_report (mm/kasan/report.c:603)
|
|
kasan_check_range (mm/kasan/generic.c:189)
|
|
variable_test_bit (arch/x86/include/asm/bitops.h:227) [inline]
|
|
arch_test_bit (arch/x86/include/asm/bitops.h:239) [inline]
|
|
_test_bit at (include/asm-generic/bitops/instrumented-non-atomic.h:142) [inline]
|
|
node_state (include/linux/nodemask.h:423) [inline]
|
|
map_benchmark_ioctl (kernel/dma/map_benchmark.c:214)
|
|
full_proxy_unlocked_ioctl (fs/debugfs/file.c:333)
|
|
__x64_sys_ioctl (fs/ioctl.c:890)
|
|
do_syscall_64 (arch/x86/entry/common.c:83)
|
|
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
|
|
|
|
Compare node ids with sane bounds first. NUMA_NO_NODE is considered a
|
|
special valid case meaning that benchmarking kthreads won't be bound to a
|
|
cpuset of a given node.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org).</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-34777</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.1</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
net: mvpp2: clear BM pool before initialization
|
|
|
|
Register value persist after booting the kernel using
|
|
kexec which results in kernel panic. Thus clear the
|
|
BM pool registers before initialisation to fix the issue.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-35837</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="17" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="17" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amdgpu: Skip do PCI error slot reset during RAS recovery
|
|
|
|
Why:
|
|
The PCI error slot reset maybe triggered after inject ue to UMC multi times, this
|
|
caused system hang.
|
|
[ 557.371857] amdgpu 0000:af:00.0: amdgpu: GPU reset succeeded, trying to resume
|
|
[ 557.373718] [drm] PCIE GART of 512M enabled.
|
|
[ 557.373722] [drm] PTB located at 0x0000031FED700000
|
|
[ 557.373788] [drm] VRAM is lost due to GPU reset!
|
|
[ 557.373789] [drm] PSP is resuming...
|
|
[ 557.547012] mlx5_core 0000:55:00.0: mlx5_pci_err_detected Device state = 1 pci_status: 0. Exit, result = 3, need reset
|
|
[ 557.547067] [drm] PCI error: detected callback, state(1)!!
|
|
[ 557.547069] [drm] No support for XGMI hive yet...
|
|
[ 557.548125] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 0. Enter
|
|
[ 557.607763] mlx5_core 0000:55:00.0: wait vital counter value 0x16b5b after 1 iterations
|
|
[ 557.607777] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 1. Exit, err = 0, result = 5, recovered
|
|
[ 557.610492] [drm] PCI error: slot reset callback!!
|
|
...
|
|
[ 560.689382] amdgpu 0000:3f:00.0: amdgpu: GPU reset(2) succeeded!
|
|
[ 560.689546] amdgpu 0000:5a:00.0: amdgpu: GPU reset(2) succeeded!
|
|
[ 560.689562] general protection fault, probably for non-canonical address 0x5f080b54534f611f: 0000 [#1] SMP NOPTI
|
|
[ 560.701008] CPU: 16 PID: 2361 Comm: kworker/u448:9 Tainted: G OE 5.15.0-91-generic #101-Ubuntu
|
|
[ 560.712057] Hardware name: Microsoft C278A/C278A, BIOS C2789.5.BS.1C11.AG.1 11/08/2023
|
|
[ 560.720959] Workqueue: amdgpu-reset-hive amdgpu_ras_do_recovery [amdgpu]
|
|
[ 560.728887] RIP: 0010:amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu]
|
|
[ 560.736891] Code: ff 41 89 c6 e9 1b ff ff ff 44 0f b6 45 b0 e9 4f ff ff ff be 01 00 00 00 4c 89 e7 e8 76 c9 8b ff 44 0f b6 45 b0 e9 3c fd ff ff <48> 83 ba 18 02 00 00 00 0f 84 6a f8 ff ff 48 8d 7a 78 be 01 00 00
|
|
[ 560.757967] RSP: 0018:ffa0000032e53d80 EFLAGS: 00010202
|
|
[ 560.763848] RAX: ffa00000001dfd10 RBX: ffa0000000197090 RCX: ffa0000032e53db0
|
|
[ 560.771856] RDX: 5f080b54534f5f07 RSI: 0000000000000000 RDI: ff11000128100010
|
|
[ 560.779867] RBP: ffa0000032e53df0 R08: 0000000000000000 R09: ffffffffffe77f08
|
|
[ 560.787879] R10: 0000000000ffff0a R11: 0000000000000001 R12: 0000000000000000
|
|
[ 560.795889] R13: ffa0000032e53e00 R14: 0000000000000000 R15: 0000000000000000
|
|
[ 560.803889] FS: 0000000000000000(0000) GS:ff11007e7e800000(0000) knlGS:0000000000000000
|
|
[ 560.812973] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 560.819422] CR2: 000055a04c118e68 CR3: 0000000007410005 CR4: 0000000000771ee0
|
|
[ 560.827433] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
[ 560.835433] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
|
|
[ 560.843444] PKRU: 55555554
|
|
[ 560.846480] Call Trace:
|
|
[ 560.849225] <TASK>
|
|
[ 560.851580] ? show_trace_log_lvl+0x1d6/0x2ea
|
|
[ 560.856488] ? show_trace_log_lvl+0x1d6/0x2ea
|
|
[ 560.861379] ? amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu]
|
|
[ 560.867778] ? show_regs.part.0+0x23/0x29
|
|
[ 560.872293] ? __die_body.cold+0x8/0xd
|
|
[ 560.876502] ? die_addr+0x3e/0x60
|
|
[ 560.880238] ? exc_general_protection+0x1c5/0x410
|
|
[ 560.885532] ? asm_exc_general_protection+0x27/0x30
|
|
[ 560.891025] ? amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu]
|
|
[ 560.898323] amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu]
|
|
[ 560.904520] process_one_work+0x228/0x3d0
|
|
How:
|
|
In RAS recovery, mode-1 reset is issued from RAS fatal error handling and expected
|
|
all the nodes in a hive to be reset. no need to issue another mode-1 during this procedure.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-35931</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
fs/9p: fix uninitialized values during inode evict
|
|
|
|
If an iget fails due to not being able to retrieve information
|
|
from the server then the inode structure is only partially
|
|
initialized. When the inode gets evicted, references to
|
|
uninitialized structures (like fscache cookies) were being
|
|
made.
|
|
|
|
This patch checks for a bad_inode before doing anything other
|
|
than clearing the inode from the cache. Since the inode is
|
|
bad, it shouldn't have any state associated with it that needs
|
|
to be written back (and there really isn't a way to complete
|
|
those anyways).</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-36923</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
nilfs2: fix potential kernel bug due to lack of writeback flag waiting
|
|
|
|
Destructive writes to a block device on which nilfs2 is mounted can cause
|
|
a kernel bug in the folio/page writeback start routine or writeback end
|
|
routine (__folio_start_writeback in the log below):
|
|
|
|
kernel BUG at mm/page-writeback.c:3070!
|
|
Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
|
|
...
|
|
RIP: 0010:__folio_start_writeback+0xbaa/0x10e0
|
|
Code: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff
|
|
e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 <0f>
|
|
0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00
|
|
...
|
|
Call Trace:
|
|
<TASK>
|
|
nilfs_segctor_do_construct+0x4654/0x69d0 [nilfs2]
|
|
nilfs_segctor_construct+0x181/0x6b0 [nilfs2]
|
|
nilfs_segctor_thread+0x548/0x11c0 [nilfs2]
|
|
kthread+0x2f0/0x390
|
|
ret_from_fork+0x4b/0x80
|
|
ret_from_fork_asm+0x1a/0x30
|
|
</TASK>
|
|
|
|
This is because when the log writer starts a writeback for segment summary
|
|
blocks or a super root block that use the backing device's page cache, it
|
|
does not wait for the ongoing folio/page writeback, resulting in an
|
|
inconsistent writeback state.
|
|
|
|
Fix this issue by waiting for ongoing writebacks when putting
|
|
folios/pages on the backing device into writeback state.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-37078</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.9</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference
|
|
|
|
In cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() is
|
|
assigned to mhdp_state->current_mode, and there is a dereference of it in
|
|
drm_mode_set_name(), which will lead to a NULL pointer dereference on
|
|
failure of drm_mode_duplicate().
|
|
|
|
Fix this bug add a check of mhdp_state->current_mode.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-38548</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
wifi: carl9170: add a proper sanity check for endpoints
|
|
|
|
Syzkaller reports [1] hitting a warning which is caused by presence
|
|
of a wrong endpoint type at the URB sumbitting stage. While there
|
|
was a check for a specific 4th endpoint, since it can switch types
|
|
between bulk and interrupt, other endpoints are trusted implicitly.
|
|
Similar warning is triggered in a couple of other syzbot issues [2].
|
|
|
|
Fix the issue by doing a comprehensive check of all endpoints
|
|
taking into account difference between high- and full-speed
|
|
configuration.
|
|
|
|
[1] Syzkaller report:
|
|
...
|
|
WARNING: CPU: 0 PID: 4721 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504
|
|
...
|
|
Call Trace:
|
|
<TASK>
|
|
carl9170_usb_send_rx_irq_urb+0x273/0x340 drivers/net/wireless/ath/carl9170/usb.c:504
|
|
carl9170_usb_init_device drivers/net/wireless/ath/carl9170/usb.c:939 [inline]
|
|
carl9170_usb_firmware_finish drivers/net/wireless/ath/carl9170/usb.c:999 [inline]
|
|
carl9170_usb_firmware_step2+0x175/0x240 drivers/net/wireless/ath/carl9170/usb.c:1028
|
|
request_firmware_work_func+0x130/0x240 drivers/base/firmware_loader/main.c:1107
|
|
process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289
|
|
worker_thread+0x669/0x1090 kernel/workqueue.c:2436
|
|
kthread+0x2e8/0x3a0 kernel/kthread.c:376
|
|
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
|
|
</TASK>
|
|
|
|
[2] Related syzkaller crashes:</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-38567</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
macintosh/via-macii: Fix "BUG: sleeping function called from invalid context"
|
|
|
|
The via-macii ADB driver calls request_irq() after disabling hard
|
|
interrupts. But disabling interrupts isn't necessary here because the
|
|
VIA shift register interrupt was masked during VIA1 initialization.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-38607</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
media: i2c: et8ek8: Don't strip remove function when driver is builtin
|
|
|
|
Using __exit for the remove function results in the remove callback
|
|
being discarded with CONFIG_VIDEO_ET8EK8=y. When such a device gets
|
|
unbound (e.g. using sysfs or hotplug), the driver is just removed
|
|
without the cleanup being performed. This results in resource leaks. Fix
|
|
it by compiling in the remove callback unconditionally.
|
|
|
|
This also fixes a W=1 modpost warning:
|
|
|
|
WARNING: modpost: drivers/media/i2c/et8ek8/et8ek8: section mismatch in reference: et8ek8_i2c_driver+0x10 (section: .data) -> et8ek8_remove (section: .exit.text)</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-38611</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</BaseScore>
|
|
<Vector>AV:L/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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
drm/amdgpu: add error handle to avoid out-of-bounds
|
|
|
|
if the sdma_v4_0_irq_id_to_seq return -EINVAL, the process should
|
|
be stop to avoid out-of-bounds read, so directly return -EINVAL.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-39471</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:fbdev: savage: Handle err return when savagefb_check_var failedThe commit 04e5eac8f3ab( fbdev: savage: Error out if pixclock equals zero )checks the value of pixclock to avoid divide-by-zero error. Howeverthe function savagefb_probe doesn t handle the error return ofsavagefb_check_var. When pixclock is 0, it will cause divide-by-zero error.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-39475</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING
|
|
|
|
Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with
|
|
small possibility, the root cause is exactly the same as commit
|
|
bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"")
|
|
|
|
However, Dan reported another hang after that, and junxiao investigated
|
|
the problem and found out that this is caused by plugged bio can't issue
|
|
from raid5d().
|
|
|
|
Current implementation in raid5d() has a weird dependence:
|
|
|
|
1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear
|
|
MD_SB_CHANGE_PENDING;
|
|
2) raid5d() handles IO in a deadloop, until all IO are issued;
|
|
3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;
|
|
|
|
This behaviour is introduce before v2.6, and for consequence, if other
|
|
context hold 'reconfig_mutex', and md_check_recovery() can't update
|
|
super_block, then raid5d() will waste one cpu 100% by the deadloop, until
|
|
'reconfig_mutex' is released.
|
|
|
|
Refer to the implementation from raid1 and raid10, fix this problem by
|
|
skipping issue IO if MD_SB_CHANGE_PENDING is still set after
|
|
md_check_recovery(), daemon thread will be woken up when 'reconfig_mutex'
|
|
is released. Meanwhile, the hang problem will be fixed as well.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-39476</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:mmc: davinci: Don t strip remove function when driver is builtinUsing __exit for the remove function results in the remove callback beingdiscarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g.using sysfs or hotplug), the driver is just removed without the cleanupbeing performed. This results in resource leaks. Fix it by compiling in theremove callback unconditionally.This also fixes a W=1 modpost warning:WARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch inreference: davinci_mmcsd_driver+0x10 (section: .data) ->davinci_mmcsd_remove (section: .exit.text)</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-39484</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet
|
|
|
|
In lio_vf_rep_copy_packet() pg_info->page is compared to a NULL value,
|
|
but then it is unconditionally passed to skb_add_rx_frag() which looks
|
|
strange and could lead to null pointer dereference.
|
|
|
|
lio_vf_rep_copy_packet() call trace looks like:
|
|
octeon_droq_process_packets
|
|
octeon_droq_fast_process_packets
|
|
octeon_droq_dispatch_pkt
|
|
octeon_create_recv_info
|
|
...search in the dispatch_list...
|
|
->disp_fn(rdisp->rinfo, ...)
|
|
lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...)
|
|
In this path there is no code which sets pg_info->page to NULL.
|
|
So this check looks unneeded and doesn't solve potential problem.
|
|
But I guess the author had reason to add a check and I have no such card
|
|
and can't do real test.
|
|
In addition, the code in the function liquidio_push_packet() in
|
|
liquidio/lio_core.c does exactly the same.
|
|
|
|
Based on this, I consider the most acceptable compromise solution to
|
|
adjust this issue by moving skb_add_rx_frag() into conditional scope.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-39506</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
io_uring/io-wq: Use set_bit() and test_bit() at worker->flags
|
|
|
|
Utilize set_bit() and test_bit() on worker->flags within io_uring/io-wq
|
|
to address potential data races.
|
|
|
|
The structure io_worker->flags may be accessed through various data
|
|
paths, leading to concurrency issues. When KCSAN is enabled, it reveals
|
|
data races occurring in io_worker_handle_work and
|
|
io_wq_activate_free_worker functions.
|
|
|
|
BUG: KCSAN: data-race in io_worker_handle_work / io_wq_activate_free_worker
|
|
write to 0xffff8885c4246404 of 4 bytes by task 49071 on cpu 28:
|
|
io_worker_handle_work (io_uring/io-wq.c:434 io_uring/io-wq.c:569)
|
|
io_wq_worker (io_uring/io-wq.c:?)
|
|
<snip>
|
|
|
|
read to 0xffff8885c4246404 of 4 bytes by task 49024 on cpu 5:
|
|
io_wq_activate_free_worker (io_uring/io-wq.c:? io_uring/io-wq.c:285)
|
|
io_wq_enqueue (io_uring/io-wq.c:947)
|
|
io_queue_iowq (io_uring/io_uring.c:524)
|
|
io_req_task_submit (io_uring/io_uring.c:1511)
|
|
io_handle_tw_list (io_uring/io_uring.c:1198)
|
|
<snip>
|
|
|
|
Line numbers against commit 18daea77cca6 ("Merge tag 'for-linus' of
|
|
git://git.kernel.org/pub/scm/virt/kvm/kvm").
|
|
|
|
These races involve writes and reads to the same memory location by
|
|
different tasks running on different CPUs. To mitigate this, refactor
|
|
the code to use atomic operations such as set_bit(), test_bit(), and
|
|
clear_bit() instead of basic "and" and "or" operations. This ensures
|
|
thread-safe manipulation of worker flags.
|
|
|
|
Also, move `create_index` to avoid holes in the structure.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-39508</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.3</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
riscv: rewrite __kernel_map_pages() to fix sleeping in invalid context
|
|
|
|
__kernel_map_pages() is a debug function which clears the valid bit in page
|
|
table entry for deallocated pages to detect illegal memory accesses to
|
|
freed pages.
|
|
|
|
This function set/clear the valid bit using __set_memory(). __set_memory()
|
|
acquires init_mm's semaphore, and this operation may sleep. This is
|
|
problematic, because __kernel_map_pages() can be called in atomic context,
|
|
and thus is illegal to sleep. An example warning that this causes:
|
|
|
|
BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1578
|
|
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2, name: kthreadd
|
|
preempt_count: 2, expected: 0
|
|
CPU: 0 PID: 2 Comm: kthreadd Not tainted 6.9.0-g1d4c6d784ef6 #37
|
|
Hardware name: riscv-virtio,qemu (DT)
|
|
Call Trace:
|
|
[<ffffffff800060dc>] dump_backtrace+0x1c/0x24
|
|
[<ffffffff8091ef6e>] show_stack+0x2c/0x38
|
|
[<ffffffff8092baf8>] dump_stack_lvl+0x5a/0x72
|
|
[<ffffffff8092bb24>] dump_stack+0x14/0x1c
|
|
[<ffffffff8003b7ac>] __might_resched+0x104/0x10e
|
|
[<ffffffff8003b7f4>] __might_sleep+0x3e/0x62
|
|
[<ffffffff8093276a>] down_write+0x20/0x72
|
|
[<ffffffff8000cf00>] __set_memory+0x82/0x2fa
|
|
[<ffffffff8000d324>] __kernel_map_pages+0x5a/0xd4
|
|
[<ffffffff80196cca>] __alloc_pages_bulk+0x3b2/0x43a
|
|
[<ffffffff8018ee82>] __vmalloc_node_range+0x196/0x6ba
|
|
[<ffffffff80011904>] copy_process+0x72c/0x17ec
|
|
[<ffffffff80012ab4>] kernel_clone+0x60/0x2fe
|
|
[<ffffffff80012f62>] kernel_thread+0x82/0xa0
|
|
[<ffffffff8003552c>] kthreadd+0x14a/0x1be
|
|
[<ffffffff809357de>] ret_from_fork+0xe/0x1c
|
|
|
|
Rewrite this function with apply_to_existing_page_range(). It is fine to
|
|
not have any locking, because __kernel_map_pages() works with pages being
|
|
allocated/deallocated and those pages are not changed by anyone else in the
|
|
meantime.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-40915</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
iommu: Return right value in iommu_sva_bind_device()
|
|
|
|
iommu_sva_bind_device() should return either a sva bond handle or an
|
|
ERR_PTR value in error cases. Existing drivers (idxd and uacce) only
|
|
check the return value with IS_ERR(). This could potentially lead to
|
|
a kernel NULL pointer dereference issue if the function returns NULL
|
|
instead of an error pointer.
|
|
|
|
In reality, this doesn't cause any problems because iommu_sva_bind_device()
|
|
only returns NULL when the kernel is not configured with CONFIG_IOMMU_SVA.
|
|
In this case, iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_SVA) will
|
|
return an error, and the device drivers won't call iommu_sva_bind_device()
|
|
at all.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-40945</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
ima: Avoid blocking in RCU read-side critical section
|
|
|
|
A panic happens in ima_match_policy:
|
|
|
|
BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
|
|
PGD 42f873067 P4D 0
|
|
Oops: 0000 [#1] SMP NOPTI
|
|
CPU: 5 PID: 1286325 Comm: kubeletmonit.sh
|
|
Kdump: loaded Tainted: P
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
|
|
BIOS 0.0.0 02/06/2015
|
|
RIP: 0010:ima_match_policy+0x84/0x450
|
|
Code: 49 89 fc 41 89 cf 31 ed 89 44 24 14 eb 1c 44 39
|
|
7b 18 74 26 41 83 ff 05 74 20 48 8b 1b 48 3b 1d
|
|
f2 b9 f4 00 0f 84 9c 01 00 00 <44> 85 73 10 74 ea
|
|
44 8b 6b 14 41 f6 c5 01 75 d4 41 f6 c5 02 74 0f
|
|
RSP: 0018:ff71570009e07a80 EFLAGS: 00010207
|
|
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000200
|
|
RDX: ffffffffad8dc7c0 RSI: 0000000024924925 RDI: ff3e27850dea2000
|
|
RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffffabfce739
|
|
R10: ff3e27810cc42400 R11: 0000000000000000 R12: ff3e2781825ef970
|
|
R13: 00000000ff3e2785 R14: 000000000000000c R15: 0000000000000001
|
|
FS: 00007f5195b51740(0000)
|
|
GS:ff3e278b12d40000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000000000000010 CR3: 0000000626d24002 CR4: 0000000000361ee0
|
|
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
Call Trace:
|
|
ima_get_action+0x22/0x30
|
|
process_measurement+0xb0/0x830
|
|
? page_add_file_rmap+0x15/0x170
|
|
? alloc_set_pte+0x269/0x4c0
|
|
? prep_new_page+0x81/0x140
|
|
? simple_xattr_get+0x75/0xa0
|
|
? selinux_file_open+0x9d/0xf0
|
|
ima_file_check+0x64/0x90
|
|
path_openat+0x571/0x1720
|
|
do_filp_open+0x9b/0x110
|
|
? page_counter_try_charge+0x57/0xc0
|
|
? files_cgroup_alloc_fd+0x38/0x60
|
|
? __alloc_fd+0xd4/0x250
|
|
? do_sys_open+0x1bd/0x250
|
|
do_sys_open+0x1bd/0x250
|
|
do_syscall_64+0x5d/0x1d0
|
|
entry_SYSCALL_64_after_hwframe+0x65/0xca
|
|
|
|
Commit c7423dbdbc9e ("ima: Handle -ESTALE returned by
|
|
ima_filter_rule_match()") introduced call to ima_lsm_copy_rule within a
|
|
RCU read-side critical section which contains kmalloc with GFP_KERNEL.
|
|
This implies a possible sleep and violates limitations of RCU read-side
|
|
critical sections on non-PREEMPT systems.
|
|
|
|
Sleeping within RCU read-side critical section might cause
|
|
synchronize_rcu() returning early and break RCU protection, allowing a
|
|
UAF to happen.
|
|
|
|
The root cause of this issue could be described as follows:
|
|
| Thread A | Thread B |
|
|
| |ima_match_policy |
|
|
| | rcu_read_lock |
|
|
|ima_lsm_update_rule | |
|
|
| synchronize_rcu | |
|
|
| | kmalloc(GFP_KERNEL)|
|
|
| | sleep |
|
|
==> synchronize_rcu returns early
|
|
| kfree(entry) | |
|
|
| | entry = entry->next|
|
|
==> UAF happens and entry now becomes NULL (or could be anything).
|
|
| | entry->action |
|
|
==> Accessing entry might cause panic.
|
|
|
|
To fix this issue, we are converting all kmalloc that is called within
|
|
RCU read-side critical section to use GFP_ATOMIC.
|
|
|
|
[PM: fixed missing comment, long lines, !CONFIG_IMA_LSM_RULES case]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-40947</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.9</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
dmaengine: idxd: Fix possible Use-After-Free in irq_process_work_list
|
|
|
|
Use list_for_each_entry_safe() to allow iterating through the list and
|
|
deleting the entry in the iteration process. The descriptor is freed via
|
|
idxd_desc_complete() and there's a slight chance may cause issue for
|
|
the list iterator when the descriptor is reused by another thread
|
|
without it being deleted from the list.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-40956</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
ipv6: prevent possible NULL dereference in rt6_probe()
|
|
|
|
syzbot caught a NULL dereference in rt6_probe() [1]
|
|
|
|
Bail out if __in6_dev_get() returns NULL.
|
|
|
|
[1]
|
|
Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cb: 0000 [#1] PREEMPT SMP KASAN PTI
|
|
KASAN: null-ptr-deref in range [0x0000000000000658-0x000000000000065f]
|
|
CPU: 1 PID: 22444 Comm: syz-executor.0 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
|
|
RIP: 0010:rt6_probe net/ipv6/route.c:656 [inline]
|
|
RIP: 0010:find_match+0x8c4/0xf50 net/ipv6/route.c:758
|
|
Code: 14 fd f7 48 8b 85 38 ff ff ff 48 c7 45 b0 00 00 00 00 48 8d b8 5c 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 19
|
|
RSP: 0018:ffffc900034af070 EFLAGS: 00010203
|
|
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004521000
|
|
RDX: 00000000000000cb RSI: ffffffff8990d0cd RDI: 000000000000065c
|
|
RBP: ffffc900034af150 R08: 0000000000000005 R09: 0000000000000000
|
|
R10: 0000000000000001 R11: 0000000000000002 R12: 000000000000000a
|
|
R13: 1ffff92000695e18 R14: ffff8880244a1d20 R15: 0000000000000000
|
|
FS: 00007f4844a5a6c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000001b31b27000 CR3: 000000002d42c000 CR4: 00000000003506f0
|
|
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
Call Trace:
|
|
<TASK>
|
|
rt6_nh_find_match+0xfa/0x1a0 net/ipv6/route.c:784
|
|
nexthop_for_each_fib6_nh+0x26d/0x4a0 net/ipv4/nexthop.c:1496
|
|
__find_rr_leaf+0x6e7/0xe00 net/ipv6/route.c:825
|
|
find_rr_leaf net/ipv6/route.c:853 [inline]
|
|
rt6_select net/ipv6/route.c:897 [inline]
|
|
fib6_table_lookup+0x57e/0xa30 net/ipv6/route.c:2195
|
|
ip6_pol_route+0x1cd/0x1150 net/ipv6/route.c:2231
|
|
pol_lookup_func include/net/ip6_fib.h:616 [inline]
|
|
fib6_rule_lookup+0x386/0x720 net/ipv6/fib6_rules.c:121
|
|
ip6_route_output_flags_noref net/ipv6/route.c:2639 [inline]
|
|
ip6_route_output_flags+0x1d0/0x640 net/ipv6/route.c:2651
|
|
ip6_dst_lookup_tail.constprop.0+0x961/0x1760 net/ipv6/ip6_output.c:1147
|
|
ip6_dst_lookup_flow+0x99/0x1d0 net/ipv6/ip6_output.c:1250
|
|
rawv6_sendmsg+0xdab/0x4340 net/ipv6/raw.c:898
|
|
inet_sendmsg+0x119/0x140 net/ipv4/af_inet.c:853
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg net/socket.c:745 [inline]
|
|
sock_write_iter+0x4b8/0x5c0 net/socket.c:1160
|
|
new_sync_write fs/read_write.c:497 [inline]
|
|
vfs_write+0x6b6/0x1140 fs/read_write.c:590
|
|
ksys_write+0x1f8/0x260 fs/read_write.c:643
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-40960</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
mips: bmips: BCM6358: make sure CBR is correctly set
|
|
|
|
It was discovered that some device have CBR address set to 0 causing
|
|
kernel panic when arch_sync_dma_for_cpu_all is called.
|
|
|
|
This was notice in situation where the system is booted from TP1 and
|
|
BMIPS_GET_CBR() returns 0 instead of a valid address and
|
|
!!(read_c0_brcm_cmt_local() & (1 << 31)); not failing.
|
|
|
|
The current check whether RAC flush should be disabled or not are not
|
|
enough hence lets check if CBR is a valid address or not.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-40963</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.9</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
serial: imx: Introduce timeout when waiting on transmitter empty
|
|
|
|
By waiting at most 1 second for USR2_TXDC to be set, we avoid a potential
|
|
deadlock.
|
|
|
|
In case of the timeout, there is not much we can do, so we simply ignore
|
|
the transmitter state and optimistically try to continue.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-40967</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.9</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
ext4: do not create EA inode under buffer lock
|
|
|
|
ext4_xattr_set_entry() creates new EA inodes while holding buffer lock
|
|
on the external xattr block. This is problematic as it nests all the
|
|
allocation locking (which acquires locks on other buffers) under the
|
|
buffer lock. This can even deadlock when the filesystem is corrupted and
|
|
e.g. quota file is setup to contain xattr block as data block. Move the
|
|
allocation of EA inode out of ext4_xattr_set_entry() into the callers.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-40972</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.7</BaseScore>
|
|
<Vector></Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
drop_monitor: replace spin_lock by raw_spin_lock
|
|
|
|
trace_drop_common() is called with preemption disabled, and it acquires
|
|
a spin_lock. This is problematic for RT kernels because spin_locks are
|
|
sleeping locks in this configuration, which causes the following splat:
|
|
|
|
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
|
|
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 449, name: rcuc/47
|
|
preempt_count: 1, expected: 0
|
|
RCU nest depth: 2, expected: 2
|
|
5 locks held by rcuc/47/449:
|
|
#0: ff1100086ec30a60 ((softirq_ctrl.lock)){+.+.}-{2:2}, at: __local_bh_disable_ip+0x105/0x210
|
|
#1: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: rt_spin_lock+0xbf/0x130
|
|
#2: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: __local_bh_disable_ip+0x11c/0x210
|
|
#3: ffffffffb394a160 (rcu_callback){....}-{0:0}, at: rcu_do_batch+0x360/0xc70
|
|
#4: ff1100086ee07520 (&data->lock){+.+.}-{2:2}, at: trace_drop_common.constprop.0+0xb5/0x290
|
|
irq event stamp: 139909
|
|
hardirqs last enabled at (139908): [<ffffffffb1df2b33>] _raw_spin_unlock_irqrestore+0x63/0x80
|
|
hardirqs last disabled at (139909): [<ffffffffb19bd03d>] trace_drop_common.constprop.0+0x26d/0x290
|
|
softirqs last enabled at (139892): [<ffffffffb07a1083>] __local_bh_enable_ip+0x103/0x170
|
|
softirqs last disabled at (139898): [<ffffffffb0909b33>] rcu_cpu_kthread+0x93/0x1f0
|
|
Preemption disabled at:
|
|
[<ffffffffb1de786b>] rt_mutex_slowunlock+0xab/0x2e0
|
|
CPU: 47 PID: 449 Comm: rcuc/47 Not tainted 6.9.0-rc2-rt1+ #7
|
|
Hardware name: Dell Inc. PowerEdge R650/0Y2G81, BIOS 1.6.5 04/15/2022
|
|
Call Trace:
|
|
<TASK>
|
|
dump_stack_lvl+0x8c/0xd0
|
|
dump_stack+0x14/0x20
|
|
__might_resched+0x21e/0x2f0
|
|
rt_spin_lock+0x5e/0x130
|
|
? trace_drop_common.constprop.0+0xb5/0x290
|
|
? skb_queue_purge_reason.part.0+0x1bf/0x230
|
|
trace_drop_common.constprop.0+0xb5/0x290
|
|
? preempt_count_sub+0x1c/0xd0
|
|
? _raw_spin_unlock_irqrestore+0x4a/0x80
|
|
? __pfx_trace_drop_common.constprop.0+0x10/0x10
|
|
? rt_mutex_slowunlock+0x26a/0x2e0
|
|
? skb_queue_purge_reason.part.0+0x1bf/0x230
|
|
? __pfx_rt_mutex_slowunlock+0x10/0x10
|
|
? skb_queue_purge_reason.part.0+0x1bf/0x230
|
|
trace_kfree_skb_hit+0x15/0x20
|
|
trace_kfree_skb+0xe9/0x150
|
|
kfree_skb_reason+0x7b/0x110
|
|
skb_queue_purge_reason.part.0+0x1bf/0x230
|
|
? __pfx_skb_queue_purge_reason.part.0+0x10/0x10
|
|
? mark_lock.part.0+0x8a/0x520
|
|
...
|
|
|
|
trace_drop_common() also disables interrupts, but this is a minor issue
|
|
because we could easily replace it with a local_lock.
|
|
|
|
Replace the spin_lock with raw_spin_lock to avoid sleeping in atomic
|
|
context.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-40980</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.7</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
batman-adv: bypass empty buckets in batadv_purge_orig_ref()
|
|
|
|
Many syzbot reports are pointing to soft lockups in
|
|
batadv_purge_orig_ref() [1]
|
|
|
|
Root cause is unknown, but we can avoid spending too much
|
|
time there and perhaps get more interesting reports.
|
|
|
|
[1]
|
|
|
|
watchdog: BUG: soft lockup - CPU#0 stuck for 27s! [kworker/u4:6:621]
|
|
Modules linked in:
|
|
irq event stamp: 6182794
|
|
hardirqs last enabled at (6182793): [<ffff8000801dae10>] __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386
|
|
hardirqs last disabled at (6182794): [<ffff80008ad66a78>] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]
|
|
hardirqs last disabled at (6182794): [<ffff80008ad66a78>] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551
|
|
softirqs last enabled at (6182792): [<ffff80008aab71c4>] spin_unlock_bh include/linux/spinlock.h:396 [inline]
|
|
softirqs last enabled at (6182792): [<ffff80008aab71c4>] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287
|
|
softirqs last disabled at (6182790): [<ffff80008aab61dc>] spin_lock_bh include/linux/spinlock.h:356 [inline]
|
|
softirqs last disabled at (6182790): [<ffff80008aab61dc>] batadv_purge_orig_ref+0x164/0x1228 net/batman-adv/originator.c:1271
|
|
CPU: 0 PID: 621 Comm: kworker/u4:6 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
|
|
Workqueue: bat_events batadv_purge_orig
|
|
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
|
pc : should_resched arch/arm64/include/asm/preempt.h:79 [inline]
|
|
pc : __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:388
|
|
lr : __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386
|
|
sp : ffff800099007970
|
|
x29: ffff800099007980 x28: 1fffe00018fce1bd x27: dfff800000000000
|
|
x26: ffff0000d2620008 x25: ffff0000c7e70de8 x24: 0000000000000001
|
|
x23: 1fffe00018e57781 x22: dfff800000000000 x21: ffff80008aab71c4
|
|
x20: ffff0001b40136c0 x19: ffff0000c72bbc08 x18: 1fffe0001a817bb0
|
|
x17: ffff800125414000 x16: ffff80008032116c x15: 0000000000000001
|
|
x14: 1fffe0001ee9d610 x13: 0000000000000000 x12: 0000000000000003
|
|
x11: 0000000000000000 x10: 0000000000ff0100 x9 : 0000000000000000
|
|
x8 : 00000000005e5789 x7 : ffff80008aab61dc x6 : 0000000000000000
|
|
x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000
|
|
x2 : 0000000000000006 x1 : 0000000000000080 x0 : ffff800125414000
|
|
Call trace:
|
|
__daif_local_irq_enable arch/arm64/include/asm/irqflags.h:27 [inline]
|
|
arch_local_irq_enable arch/arm64/include/asm/irqflags.h:49 [inline]
|
|
__local_bh_enable_ip+0x228/0x44c kernel/softirq.c:386
|
|
__raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline]
|
|
_raw_spin_unlock_bh+0x3c/0x4c kernel/locking/spinlock.c:210
|
|
spin_unlock_bh include/linux/spinlock.h:396 [inline]
|
|
batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287
|
|
batadv_purge_orig+0x20/0x70 net/batman-adv/originator.c:1300
|
|
process_one_work+0x694/0x1204 kernel/workqueue.c:2633
|
|
process_scheduled_works kernel/workqueue.c:2706 [inline]
|
|
worker_thread+0x938/0xef4 kernel/workqueue.c:2787
|
|
kthread+0x288/0x310 kernel/kthread.c:388
|
|
ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860
|
|
Sending NMI from CPU 0 to CPUs 1:
|
|
NMI backtrace for cpu 1
|
|
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
|
|
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
|
pc : arch_local_irq_enable+0x8/0xc arch/arm64/include/asm/irqflags.h:51
|
|
lr : default_idle_call+0xf8/0x128 kernel/sched/idle.c:103
|
|
sp : ffff800093a17d30
|
|
x29: ffff800093a17d30 x28: dfff800000000000 x27: 1ffff00012742fb4
|
|
x26: ffff80008ec9d000 x25: 0000000000000000 x24: 0000000000000002
|
|
x23: 1ffff00011d93a74 x22: ffff80008ec9d3a0 x21: 0000000000000000
|
|
x20: ffff0000c19dbc00 x19: ffff8000802d0fd8 x18: 1fffe00036804396
|
|
x17: ffff80008ec9d000 x16: ffff8000802d089c x15: 0000000000000001
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-40981</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
ssb: Fix potential NULL pointer dereference in ssb_device_uevent()
|
|
|
|
The ssb_device_uevent() function first attempts to convert the 'dev' pointer
|
|
to 'struct ssb_device *'. However, it mistakenly dereferences 'dev' before
|
|
performing the NULL check, potentially leading to a NULL pointer
|
|
dereference if 'dev' is NULL.
|
|
|
|
To fix this issue, move the NULL check before dereferencing the 'dev' pointer,
|
|
ensuring that the pointer is valid before attempting to use it.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-40982</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc()
|
|
|
|
syzbot found hanging tasks waiting on rtnl_lock [1]
|
|
|
|
A reproducer is available in the syzbot bug.
|
|
|
|
When a request to add multiple actions with the same index is sent, the
|
|
second request will block forever on the first request. This holds
|
|
rtnl_lock, and causes tasks to hang.
|
|
|
|
Return -EAGAIN to prevent infinite looping, while keeping documented
|
|
behavior.
|
|
|
|
[1]
|
|
|
|
INFO: task kworker/1:0:5088 blocked for more than 143 seconds.
|
|
Not tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0
|
|
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
|
|
task:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000
|
|
Workqueue: events_power_efficient reg_check_chans_work
|
|
Call Trace:
|
|
<TASK>
|
|
context_switch kernel/sched/core.c:5409 [inline]
|
|
__schedule+0xf15/0x5d00 kernel/sched/core.c:6746
|
|
__schedule_loop kernel/sched/core.c:6823 [inline]
|
|
schedule+0xe7/0x350 kernel/sched/core.c:6838
|
|
schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6895
|
|
__mutex_lock_common kernel/locking/mutex.c:684 [inline]
|
|
__mutex_lock+0x5b8/0x9c0 kernel/locking/mutex.c:752
|
|
wiphy_lock include/net/cfg80211.h:5953 [inline]
|
|
reg_leave_invalid_chans net/wireless/reg.c:2466 [inline]
|
|
reg_check_chans_work+0x10a/0x10e0 net/wireless/reg.c:2481</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-40995</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</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:
|
|
|
|
drm/amdkfd: don't allow mapping the MMIO HDP page with large pages
|
|
|
|
We don't get the right offset in that case. The GPU has
|
|
an unused 4K area of the register BAR space into which you can
|
|
remap registers. We remap the HDP flush registers into this
|
|
space to allow userspace (CPU or GPU) to flush the HDP when it
|
|
updates VRAM. However, on systems with >4K pages, we end up
|
|
exposing PAGE_SIZE of MMIO space.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-08-02</ReleaseDate>
|
|
<CVE>CVE-2024-41011</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.8</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-08-02</DATE>
|
|
<URL>https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-1942</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |