3539 lines
158 KiB
XML
3539 lines
158 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-1738</ID>
|
||
</Identification>
|
||
<Status>Final</Status>
|
||
<Version>1.0</Version>
|
||
<RevisionHistory>
|
||
<Revision>
|
||
<Number>1.0</Number>
|
||
<Date>2024-06-21</Date>
|
||
<Description>Initial</Description>
|
||
</Revision>
|
||
</RevisionHistory>
|
||
<InitialReleaseDate>2024-06-21</InitialReleaseDate>
|
||
<CurrentReleaseDate>2024-06-21</CurrentReleaseDate>
|
||
<Generator>
|
||
<Engine>openEuler SA Tool V1.0</Engine>
|
||
<Date>2024-06-21</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:
|
||
|
||
afs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server
|
||
|
||
AFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, and
|
||
Linux's afs client switches between them when talking to a non-YFS server
|
||
if the read size, the file position or the sum of the two have the upper 32
|
||
bits set of the 64-bit value.
|
||
|
||
This is a problem, however, since the file position and length fields of
|
||
FS.FetchData are *signed* 32-bit values.
|
||
|
||
Fix this by capturing the capability bits obtained from the fileserver when
|
||
it's sent an FS.GetCapabilities RPC, rather than just discarding them, and
|
||
then picking out the VICED_CAPABILITY_64BITFILES flag. This can then be
|
||
used to decide whether to use FS.FetchData or FS.FetchData64 - and also
|
||
FS.StoreData or FS.StoreData64 - rather than using upper_32_bits() to
|
||
switch on the parameter values.
|
||
|
||
This capabilities flag could also be used to limit the maximum size of the
|
||
file, but all servers must be checked for that.
|
||
|
||
Note that the issue does not exist with FS.StoreData - that uses *unsigned*
|
||
32-bit values. It's also not a problem with Auristor servers as its
|
||
YFS.FetchData64 op uses unsigned 64-bit values.
|
||
|
||
This can be tested by cloning a git repo through an OpenAFS client to an
|
||
OpenAFS server and then doing "git status" on it from a Linux afs
|
||
client[1]. Provided the clone has a pack file that's in the 2G-4G range,
|
||
the git status will show errors like:
|
||
|
||
error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index
|
||
error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index
|
||
|
||
This can be observed in the server's FileLog with something like the
|
||
following appearing:
|
||
|
||
Sun Aug 29 19:31:39 2021 SRXAFS_FetchData, Fid = 2303380852.491776.3263114, Host 192.168.11.201:7001, Id 1001
|
||
Sun Aug 29 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001
|
||
Sun Aug 29 19:31:39 2021 FetchData_RXStyle: Pos 18446744071815340032, Len 3154
|
||
Sun Aug 29 19:31:39 2021 FetchData_RXStyle: file size 2400758866
|
||
...
|
||
Sun Aug 29 19:31:40 2021 SRXAFS_FetchData returns 5
|
||
|
||
Note the file position of 18446744071815340032. This is the requested file
|
||
position sign-extended.(CVE-2021-47366)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
net/smc: Fix possible access to freed memory in link clear
|
||
|
||
After modifying the QP to the Error state, all RX WR would be completed
|
||
with WC in IB_WC_WR_FLUSH_ERR status. Current implementation does not
|
||
wait for it is done, but destroy the QP and free the link group directly.
|
||
So there is a risk that accessing the freed memory in tasklet context.
|
||
|
||
Here is a crash example:
|
||
|
||
BUG: unable to handle page fault for address: ffffffff8f220860
|
||
#PF: supervisor write access in kernel mode
|
||
#PF: error_code(0x0002) - not-present page
|
||
PGD f7300e067 P4D f7300e067 PUD f7300f063 PMD 8c4e45063 PTE 800ffff08c9df060
|
||
Oops: 0002 [#1] SMP PTI
|
||
CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: G S OE 5.10.0-0607+ #23
|
||
Hardware name: Inspur NF5280M4/YZMB-00689-101, BIOS 4.1.20 07/09/2018
|
||
RIP: 0010:native_queued_spin_lock_slowpath+0x176/0x1b0
|
||
Code: f3 90 48 8b 32 48 85 f6 74 f6 eb d5 c1 ee 12 83 e0 03 83 ee 01 48 c1 e0 05 48 63 f6 48 05 00 c8 02 00 48 03 04 f5 00 09 98 8e <48> 89 10 8b 42 08 85 c0 75 09 f3 90 8b 42 08 85 c0 74 f7 48 8b 32
|
||
RSP: 0018:ffffb3b6c001ebd8 EFLAGS: 00010086
|
||
RAX: ffffffff8f220860 RBX: 0000000000000246 RCX: 0000000000080000
|
||
RDX: ffff91db1f86c800 RSI: 000000000000173c RDI: ffff91db62bace00
|
||
RBP: ffff91db62bacc00 R08: 0000000000000000 R09: c00000010000028b
|
||
R10: 0000000000055198 R11: ffffb3b6c001ea58 R12: ffff91db80e05010
|
||
R13: 000000000000000a R14: 0000000000000006 R15: 0000000000000040
|
||
FS: 0000000000000000(0000) GS:ffff91db1f840000(0000) knlGS:0000000000000000
|
||
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
||
CR2: ffffffff8f220860 CR3: 00000001f9580004 CR4: 00000000003706e0
|
||
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
||
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
||
Call Trace:
|
||
<IRQ>
|
||
_raw_spin_lock_irqsave+0x30/0x40
|
||
mlx5_ib_poll_cq+0x4c/0xc50 [mlx5_ib]
|
||
smc_wr_rx_tasklet_fn+0x56/0xa0 [smc]
|
||
tasklet_action_common.isra.21+0x66/0x100
|
||
__do_softirq+0xd5/0x29c
|
||
asm_call_irq_on_stack+0x12/0x20
|
||
</IRQ>
|
||
do_softirq_own_stack+0x37/0x40
|
||
irq_exit_rcu+0x9d/0xa0
|
||
sysvec_call_function_single+0x34/0x80
|
||
asm_sysvec_call_function_single+0x12/0x20(CVE-2022-48673)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
RDMA/srp: Set scmnd->result only when scmnd is not NULL
|
||
|
||
This change fixes the following kernel NULL pointer dereference
|
||
which is reproduced by blktests srp/007 occasionally.
|
||
|
||
BUG: kernel NULL pointer dereference, address: 0000000000000170
|
||
PGD 0 P4D 0
|
||
Oops: 0002 [#1] PREEMPT SMP NOPTI
|
||
CPU: 0 PID: 9 Comm: kworker/0:1H Kdump: loaded Not tainted 6.0.0-rc1+ #37
|
||
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.15.0-29-g6a62e0cb0dfe-prebuilt.qemu.org 04/01/2014
|
||
Workqueue: 0x0 (kblockd)
|
||
RIP: 0010:srp_recv_done+0x176/0x500 [ib_srp]
|
||
Code: 00 4d 85 ff 0f 84 52 02 00 00 48 c7 82 80 02 00 00 00 00 00 00 4c 89 df 4c 89 14 24 e8 53 d3 4a f6 4c 8b 14 24 41 0f b6 42 13 <41> 89 87 70 01 00 00 41 0f b6 52 12 f6 c2 02 74 44 41 8b 42 1c b9
|
||
RSP: 0018:ffffaef7c0003e28 EFLAGS: 00000282
|
||
RAX: 0000000000000000 RBX: ffff9bc9486dea60 RCX: 0000000000000000
|
||
RDX: 0000000000000102 RSI: ffffffffb76bbd0e RDI: 00000000ffffffff
|
||
RBP: ffff9bc980099a00 R08: 0000000000000001 R09: 0000000000000001
|
||
R10: ffff9bca53ef0000 R11: ffff9bc980099a10 R12: ffff9bc956e14000
|
||
R13: ffff9bc9836b9cb0 R14: ffff9bc9557b4480 R15: 0000000000000000
|
||
FS: 0000000000000000(0000) GS:ffff9bc97ec00000(0000) knlGS:0000000000000000
|
||
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
||
CR2: 0000000000000170 CR3: 0000000007e04000 CR4: 00000000000006f0
|
||
Call Trace:
|
||
<IRQ>
|
||
__ib_process_cq+0xb7/0x280 [ib_core]
|
||
ib_poll_handler+0x2b/0x130 [ib_core]
|
||
irq_poll_softirq+0x93/0x150
|
||
__do_softirq+0xee/0x4b8
|
||
irq_exit_rcu+0xf7/0x130
|
||
sysvec_apic_timer_interrupt+0x8e/0xc0
|
||
</IRQ>(CVE-2022-48692)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
rpmsg: virtio: Free driver_override when rpmsg_remove()
|
||
|
||
Free driver_override when rpmsg_remove(), otherwise
|
||
the following memory leak will occur:
|
||
|
||
unreferenced object 0xffff0000d55d7080 (size 128):
|
||
comm "kworker/u8:2", pid 56, jiffies 4294893188 (age 214.272s)
|
||
hex dump (first 32 bytes):
|
||
72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00 rpmsg_ns........
|
||
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||
backtrace:
|
||
[<000000009c94c9c1>] __kmem_cache_alloc_node+0x1f8/0x320
|
||
[<000000002300d89b>] __kmalloc_node_track_caller+0x44/0x70
|
||
[<00000000228a60c3>] kstrndup+0x4c/0x90
|
||
[<0000000077158695>] driver_set_override+0xd0/0x164
|
||
[<000000003e9c4ea5>] rpmsg_register_device_override+0x98/0x170
|
||
[<000000001c0c89a8>] rpmsg_ns_register_device+0x24/0x30
|
||
[<000000008bbf8fa2>] rpmsg_probe+0x2e0/0x3ec
|
||
[<00000000e65a68df>] virtio_dev_probe+0x1c0/0x280
|
||
[<00000000443331cc>] really_probe+0xbc/0x2dc
|
||
[<00000000391064b1>] __driver_probe_device+0x78/0xe0
|
||
[<00000000a41c9a5b>] driver_probe_device+0xd8/0x160
|
||
[<000000009c3bd5df>] __device_attach_driver+0xb8/0x140
|
||
[<0000000043cd7614>] bus_for_each_drv+0x7c/0xd4
|
||
[<000000003b929a36>] __device_attach+0x9c/0x19c
|
||
[<00000000a94e0ba8>] device_initial_probe+0x14/0x20
|
||
[<000000003c999637>] bus_probe_device+0xa0/0xac(CVE-2023-52670)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
f2fs: avoid format-overflow warning
|
||
|
||
With gcc and W=1 option, there's a warning like this:
|
||
|
||
fs/f2fs/compress.c: In function ‘f2fs_init_page_array_cache’:
|
||
fs/f2fs/compress.c:1984:47: error: ‘%u’ directive writing between
|
||
1 and 7 bytes into a region of size between 5 and 8
|
||
[-Werror=format-overflow=]
|
||
1984 | sprintf(slab_name, "f2fs_page_array_entry-%u:%u", MAJOR(dev),
|
||
MINOR(dev));
|
||
| ^~
|
||
|
||
String "f2fs_page_array_entry-%u:%u" can up to 35. The first "%u" can up
|
||
to 4 and the second "%u" can up to 7, so total size is "24 + 4 + 7 = 35".
|
||
slab_name's size should be 35 rather than 32.(CVE-2023-52748)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
i2c: core: Run atomic i2c xfer when !preemptible
|
||
|
||
Since bae1d3a05a8b, i2c transfers are non-atomic if preemption is
|
||
disabled. However, non-atomic i2c transfers require preemption (e.g. in
|
||
wait_for_completion() while waiting for the DMA).
|
||
|
||
panic() calls preempt_disable_notrace() before calling
|
||
emergency_restart(). Therefore, if an i2c device is used for the
|
||
restart, the xfer should be atomic. This avoids warnings like:
|
||
|
||
[ 12.667612] WARNING: CPU: 1 PID: 1 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x33c/0x6b0
|
||
[ 12.676926] Voluntary context switch within RCU read-side critical section!
|
||
...
|
||
[ 12.742376] schedule_timeout from wait_for_completion_timeout+0x90/0x114
|
||
[ 12.749179] wait_for_completion_timeout from tegra_i2c_wait_completion+0x40/0x70
|
||
...
|
||
[ 12.994527] atomic_notifier_call_chain from machine_restart+0x34/0x58
|
||
[ 13.001050] machine_restart from panic+0x2a8/0x32c
|
||
|
||
Use !preemptible() instead, which is basically the same check as
|
||
pre-v5.2.(CVE-2023-52791)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
drm/panel: fix a possible null pointer dereference
|
||
|
||
In versatile_panel_get_modes(), the return value of drm_mode_duplicate()
|
||
is assigned to mode, which will lead to a NULL pointer dereference
|
||
on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2023-52821)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
media: vidtv: mux: Add check and kfree for kstrdup
|
||
|
||
Add check for the return value of kstrdup() and return the error
|
||
if it fails in order to avoid NULL pointer dereference.
|
||
Moreover, use kfree() in the later error handling in order to avoid
|
||
memory leak.(CVE-2023-52841)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
clk: mediatek: clk-mt6779: Add check for mtk_alloc_clk_data
|
||
|
||
Add the check for the return value of mtk_alloc_clk_data() in order to
|
||
avoid NULL pointer dereference.(CVE-2023-52873)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
clk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate change
|
||
|
||
While PLL CPUX clock rate change when CPU is running from it works in
|
||
vast majority of cases, now and then it causes instability. This leads
|
||
to system crashes and other undefined behaviour. After a lot of testing
|
||
(30+ hours) while also doing a lot of frequency switches, we can't
|
||
observe any instability issues anymore when doing reparenting to stable
|
||
clock like 24 MHz oscillator.(CVE-2023-52882)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
netfilter: nft_set_pipapo: do not free live element
|
||
|
||
Pablo reports a crash with large batches of elements with a
|
||
back-to-back add/remove pattern. Quoting Pablo:
|
||
|
||
add_elem("00000000") timeout 100 ms
|
||
...
|
||
add_elem("0000000X") timeout 100 ms
|
||
del_elem("0000000X") <---------------- delete one that was just added
|
||
...
|
||
add_elem("00005000") timeout 100 ms
|
||
|
||
1) nft_pipapo_remove() removes element 0000000X
|
||
Then, KASAN shows a splat.
|
||
|
||
Looking at the remove function there is a chance that we will drop a
|
||
rule that maps to a non-deactivated element.
|
||
|
||
Removal happens in two steps, first we do a lookup for key k and return the
|
||
to-be-removed element and mark it as inactive in the next generation.
|
||
Then, in a second step, the element gets removed from the set/map.
|
||
|
||
The _remove function does not work correctly if we have more than one
|
||
element that share the same key.
|
||
|
||
This can happen if we insert an element into a set when the set already
|
||
holds an element with same key, but the element mapping to the existing
|
||
key has timed out or is not active in the next generation.
|
||
|
||
In such case its possible that removal will unmap the wrong element.
|
||
If this happens, we will leak the non-deactivated element, it becomes
|
||
unreachable.
|
||
|
||
The element that got deactivated (and will be freed later) will
|
||
remain reachable in the set data structure, this can result in
|
||
a crash when such an element is retrieved during lookup (stale
|
||
pointer).
|
||
|
||
Add a check that the fully matching key does in fact map to the element
|
||
that we have marked as inactive in the deactivation step.
|
||
If not, we need to continue searching.
|
||
|
||
Add a bug/warn trap at the end of the function as well, the remove
|
||
function must not ever be called with an invisible/unreachable/non-existent
|
||
element.
|
||
|
||
v2: avoid uneeded temporary variable (Stefano)(CVE-2024-26924)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
scsi: core: Fix unremoved procfs host directory regression
|
||
|
||
Commit fc663711b944 ("scsi: core: Remove the /proc/scsi/${proc_name}
|
||
directory earlier") fixed a bug related to modules loading/unloading, by
|
||
adding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led
|
||
to a potential duplicate call to the hostdir_rm() routine, since it's also
|
||
called from scsi_host_dev_release(). That triggered a regression report,
|
||
which was then fixed by commit be03df3d4bfe ("scsi: core: Fix a procfs host
|
||
directory removal regression"). The fix just dropped the hostdir_rm() call
|
||
from dev_release().
|
||
|
||
But it happens that this proc directory is created on scsi_host_alloc(),
|
||
and that function "pairs" with scsi_host_dev_release(), while
|
||
scsi_remove_host() pairs with scsi_add_host(). In other words, it seems the
|
||
reason for removing the proc directory on dev_release() was meant to cover
|
||
cases in which a SCSI host structure was allocated, but the call to
|
||
scsi_add_host() didn't happen. And that pattern happens to exist in some
|
||
error paths, for example.
|
||
|
||
Syzkaller causes that by using USB raw gadget device, error'ing on
|
||
usb-storage driver, at usb_stor_probe2(). By checking that path, we can see
|
||
that the BadDevice label leads to a scsi_host_put() after a SCSI host
|
||
allocation, but there's no call to scsi_add_host() in such path. That leads
|
||
to messages like this in dmesg (and a leak of the SCSI host proc
|
||
structure):
|
||
|
||
usb-storage 4-1:87.51: USB Mass Storage device detected
|
||
proc_dir_entry 'scsi/usb-storage' already registered
|
||
WARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376
|
||
|
||
The proper fix seems to still call scsi_proc_hostdir_rm() on dev_release(),
|
||
but guard that with the state check for SHOST_CREATED; there is even a
|
||
comment in scsi_host_dev_release() detailing that: such conditional is
|
||
meant for cases where the SCSI host was allocated but there was no calls to
|
||
{add,remove}_host(), like the usb-storage case.
|
||
|
||
This is what we propose here and with that, the error path of usb-storage
|
||
does not trigger the warning anymore.(CVE-2024-26935)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
ksmbd: validate request buffer size in smb2_allocate_rsp_buf()
|
||
|
||
The response buffer should be allocated in smb2_allocate_rsp_buf
|
||
before validating request. But the fields in payload as well as smb2 header
|
||
is used in smb2_allocate_rsp_buf(). This patch add simple buffer size
|
||
validation to avoid potencial out-of-bounds in request buffer.(CVE-2024-26936)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
ARM: 9359/1: flush: check if the folio is reserved for no-mapping addresses
|
||
|
||
Since commit a4d5613c4dc6 ("arm: extend pfn_valid to take into account
|
||
freed memory map alignment") changes the semantics of pfn_valid() to check
|
||
presence of the memory map for a PFN. A valid page for an address which
|
||
is reserved but not mapped by the kernel[1], the system crashed during
|
||
some uio test with the following memory layout:
|
||
|
||
node 0: [mem 0x00000000c0a00000-0x00000000cc8fffff]
|
||
node 0: [mem 0x00000000d0000000-0x00000000da1fffff]
|
||
the uio layout is：0xc0900000, 0x100000
|
||
|
||
the crash backtrace like:
|
||
|
||
Unable to handle kernel paging request at virtual address bff00000
|
||
[...]
|
||
CPU: 1 PID: 465 Comm: startapp.bin Tainted: G O 5.10.0 #1
|
||
Hardware name: Generic DT based system
|
||
PC is at b15_flush_kern_dcache_area+0x24/0x3c
|
||
LR is at __sync_icache_dcache+0x6c/0x98
|
||
[...]
|
||
(b15_flush_kern_dcache_area) from (__sync_icache_dcache+0x6c/0x98)
|
||
(__sync_icache_dcache) from (set_pte_at+0x28/0x54)
|
||
(set_pte_at) from (remap_pfn_range+0x1a0/0x274)
|
||
(remap_pfn_range) from (uio_mmap+0x184/0x1b8 [uio])
|
||
(uio_mmap [uio]) from (__mmap_region+0x264/0x5f4)
|
||
(__mmap_region) from (__do_mmap_mm+0x3ec/0x440)
|
||
(__do_mmap_mm) from (do_mmap+0x50/0x58)
|
||
(do_mmap) from (vm_mmap_pgoff+0xfc/0x188)
|
||
(vm_mmap_pgoff) from (ksys_mmap_pgoff+0xac/0xc4)
|
||
(ksys_mmap_pgoff) from (ret_fast_syscall+0x0/0x5c)
|
||
Code: e0801001 e2423001 e1c00003 f57ff04f (ee070f3e)
|
||
---[ end trace 09cf0734c3805d52 ]---
|
||
Kernel panic - not syncing: Fatal exception
|
||
|
||
So check if PG_reserved was set to solve this issue.
|
||
|
||
[1]: https://lore.kernel.org/lkml/Zbtdue57RO0QScJM@linux.ibm.com/(CVE-2024-26947)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
ksmbd: fix slab-out-of-bounds in smb_strndup_from_utf16()
|
||
|
||
If ->NameOffset of smb2_create_req is smaller than Buffer offset of
|
||
smb2_create_req, slab-out-of-bounds read can happen from smb2_open.
|
||
This patch set the minimum value of the name offset to the buffer offset
|
||
to validate name length of smb2_create_req().(CVE-2024-26954)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
mm: swap: fix race between free_swap_and_cache() and swapoff()
|
||
|
||
There was previously a theoretical window where swapoff() could run and
|
||
teardown a swap_info_struct while a call to free_swap_and_cache() was
|
||
running in another thread. This could cause, amongst other bad
|
||
possibilities, swap_page_trans_huge_swapped() (called by
|
||
free_swap_and_cache()) to access the freed memory for swap_map.
|
||
|
||
This is a theoretical problem and I haven't been able to provoke it from a
|
||
test case. But there has been agreement based on code review that this is
|
||
possible (see link below).
|
||
|
||
Fix it by using get_swap_device()/put_swap_device(), which will stall
|
||
swapoff(). There was an extra check in _swap_info_get() to confirm that
|
||
the swap entry was not free. This isn't present in get_swap_device()
|
||
because it doesn't make sense in general due to the race between getting
|
||
the reference and swapoff. So I've added an equivalent check directly in
|
||
free_swap_and_cache().
|
||
|
||
Details of how to provoke one possible issue (thanks to David Hildenbrand
|
||
for deriving this):
|
||
|
||
--8<-----
|
||
|
||
__swap_entry_free() might be the last user and result in
|
||
"count == SWAP_HAS_CACHE".
|
||
|
||
swapoff->try_to_unuse() will stop as soon as soon as si->inuse_pages==0.
|
||
|
||
So the question is: could someone reclaim the folio and turn
|
||
si->inuse_pages==0, before we completed swap_page_trans_huge_swapped().
|
||
|
||
Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages are
|
||
still references by swap entries.
|
||
|
||
Process 1 still references subpage 0 via swap entry.
|
||
Process 2 still references subpage 1 via swap entry.
|
||
|
||
Process 1 quits. Calls free_swap_and_cache().
|
||
-> count == SWAP_HAS_CACHE
|
||
[then, preempted in the hypervisor etc.]
|
||
|
||
Process 2 quits. Calls free_swap_and_cache().
|
||
-> count == SWAP_HAS_CACHE
|
||
|
||
Process 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls
|
||
__try_to_reclaim_swap().
|
||
|
||
__try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()->
|
||
put_swap_folio()->free_swap_slot()->swapcache_free_entries()->
|
||
swap_entry_free()->swap_range_free()->
|
||
...
|
||
WRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries);
|
||
|
||
What stops swapoff to succeed after process 2 reclaimed the swap cache
|
||
but before process1 finished its call to swap_page_trans_huge_swapped()?
|
||
|
||
--8<-----(CVE-2024-26960)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
net/mlx5e: Prevent deadlock while disabling aRFS
|
||
|
||
When disabling aRFS under the `priv->state_lock`, any scheduled
|
||
aRFS works are canceled using the `cancel_work_sync` function,
|
||
which waits for the work to end if it has already started.
|
||
However, while waiting for the work handler, the handler will
|
||
try to acquire the `state_lock` which is already acquired.
|
||
|
||
The worker acquires the lock to delete the rules if the state
|
||
is down, which is not the worker's responsibility since
|
||
disabling aRFS deletes the rules.
|
||
|
||
Add an aRFS state variable, which indicates whether the aRFS is
|
||
enabled and prevent adding rules when the aRFS is disabled.
|
||
|
||
Kernel log:
|
||
|
||
======================================================
|
||
WARNING: possible circular locking dependency detected
|
||
6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G I
|
||
------------------------------------------------------
|
||
ethtool/386089 is trying to acquire lock:
|
||
ffff88810f21ce68 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0
|
||
|
||
but task is already holding lock:
|
||
ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]
|
||
|
||
which lock already depends on the new lock.
|
||
|
||
the existing dependency chain (in reverse order) is:
|
||
|
||
-> #1 (&priv->state_lock){+.+.}-{3:3}:
|
||
__mutex_lock+0x80/0xc90
|
||
arfs_handle_work+0x4b/0x3b0 [mlx5_core]
|
||
process_one_work+0x1dc/0x4a0
|
||
worker_thread+0x1bf/0x3c0
|
||
kthread+0xd7/0x100
|
||
ret_from_fork+0x2d/0x50
|
||
ret_from_fork_asm+0x11/0x20
|
||
|
||
-> #0 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}:
|
||
__lock_acquire+0x17b4/0x2c80
|
||
lock_acquire+0xd0/0x2b0
|
||
__flush_work+0x7a/0x4e0
|
||
__cancel_work_timer+0x131/0x1c0
|
||
arfs_del_rules+0x143/0x1e0 [mlx5_core]
|
||
mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]
|
||
mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]
|
||
ethnl_set_channels+0x28f/0x3b0
|
||
ethnl_default_set_doit+0xec/0x240
|
||
genl_family_rcv_msg_doit+0xd0/0x120
|
||
genl_rcv_msg+0x188/0x2c0
|
||
netlink_rcv_skb+0x54/0x100
|
||
genl_rcv+0x24/0x40
|
||
netlink_unicast+0x1a1/0x270
|
||
netlink_sendmsg+0x214/0x460
|
||
__sock_sendmsg+0x38/0x60
|
||
__sys_sendto+0x113/0x170
|
||
__x64_sys_sendto+0x20/0x30
|
||
do_syscall_64+0x40/0xe0
|
||
entry_SYSCALL_64_after_hwframe+0x46/0x4e
|
||
|
||
other info that might help us debug this:
|
||
|
||
Possible unsafe locking scenario:
|
||
|
||
CPU0 CPU1
|
||
---- ----
|
||
lock(&priv->state_lock);
|
||
lock((work_completion)(&rule->arfs_work));
|
||
lock(&priv->state_lock);
|
||
lock((work_completion)(&rule->arfs_work));
|
||
|
||
*** DEADLOCK ***
|
||
|
||
3 locks held by ethtool/386089:
|
||
#0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40
|
||
#1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240
|
||
#2: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]
|
||
|
||
stack backtrace:
|
||
CPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4_net_next_mlx5_5483eb2 #1
|
||
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
|
||
Call Trace:
|
||
<TASK>
|
||
dump_stack_lvl+0x60/0xa0
|
||
check_noncircular+0x144/0x160
|
||
__lock_acquire+0x17b4/0x2c80
|
||
lock_acquire+0xd0/0x2b0
|
||
? __flush_work+0x74/0x4e0
|
||
? save_trace+0x3e/0x360
|
||
? __flush_work+0x74/0x4e0
|
||
__flush_work+0x7a/0x4e0
|
||
? __flush_work+0x74/0x4e0
|
||
? __lock_acquire+0xa78/0x2c80
|
||
? lock_acquire+0xd0/0x2b0
|
||
? mark_held_locks+0x49/0x70
|
||
__cancel_work_timer+0x131/0x1c0
|
||
? mark_held_locks+0x49/0x70
|
||
arfs_del_rules+0x143/0x1e0 [mlx5_core]
|
||
mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]
|
||
mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]
|
||
ethnl_set_channels+0x28f/0x3b0
|
||
ethnl_default_set_doit+0xec/0x240
|
||
genl_family_rcv_msg_doit+0xd0/0x120
|
||
genl_rcv_msg+0x188/0x2c0
|
||
? ethn
|
||
---truncated---(CVE-2024-27014)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
netfilter: nft_set_pipapo: walk over current view on netlink dump
|
||
|
||
The generation mask can be updated while netlink dump is in progress.
|
||
The pipapo set backend walk iterator cannot rely on it to infer what
|
||
view of the datastructure is to be used. Add notation to specify if user
|
||
wants to read/update the set.
|
||
|
||
Based on patch from Florian Westphal.(CVE-2024-27017)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()
|
||
|
||
nft_unregister_obj() can concurrent with __nft_obj_type_get(),
|
||
and there is not any protection when iterate over nf_tables_objects
|
||
list in __nft_obj_type_get(). Therefore, there is potential data-race
|
||
of nf_tables_objects list entry.
|
||
|
||
Use list_for_each_entry_rcu() to iterate over nf_tables_objects
|
||
list in __nft_obj_type_get(), and use rcu_read_lock() in the caller
|
||
nft_obj_type_get() to protect the entire type query process.(CVE-2024-27019)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
drm/amd/display: Fix potential NULL pointer dereferences in 'dcn10_set_output_transfer_func()'
|
||
|
||
The 'stream' pointer is used in dcn10_set_output_transfer_func() before
|
||
the check if 'stream' is NULL.
|
||
|
||
Fixes the below:
|
||
drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn10/dcn10_hwseq.c:1892 dcn10_set_output_transfer_func() warn: variable dereferenced before check 'stream' (see line 1875)(CVE-2024-27044)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
net: ll_temac: platform_get_resource replaced by wrong function
|
||
|
||
The function platform_get_resource was replaced with
|
||
devm_platform_ioremap_resource_byname and is called using 0 as name.
|
||
|
||
This eventually ends up in platform_get_resource_byname in the call
|
||
stack, where it causes a null pointer in strcmp.
|
||
|
||
if (type == resource_type(r) && !strcmp(r->name, name))
|
||
|
||
It should have been replaced with devm_platform_ioremap_resource.(CVE-2024-35796)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
soc: fsl: qbman: Use raw spinlock for cgr_lock
|
||
|
||
smp_call_function always runs its callback in hard IRQ context, even on
|
||
PREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlock
|
||
for cgr_lock to ensure we aren't waiting on a sleeping task.
|
||
|
||
Although this bug has existed for a while, it was not apparent until
|
||
commit ef2a8d5478b9 ("net: dpaa: Adjust queue depth on rate change")
|
||
which invokes smp_call_function_single via qman_update_cgr_safe every
|
||
time a link goes up or down.(CVE-2024-35819)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
ubifs: Set page uptodate in the correct place
|
||
|
||
Page cache reads are lockless, so setting the freshly allocated page
|
||
uptodate before we've overwritten it with the data it's supposed to have
|
||
in it will allow a simultaneous reader to see old data. Move the call
|
||
to SetPageUptodate into ubifs_write_end(), which is after we copied the
|
||
new data into the page.(CVE-2024-35821)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
wifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer()
|
||
|
||
In the for statement of lbs_allocate_cmd_buffer(), if the allocation of
|
||
cmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to
|
||
be freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer().(CVE-2024-35828)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
smb: client: fix UAF in smb2_reconnect_server()
|
||
|
||
The UAF bug is due to smb2_reconnect_server() accessing a session that
|
||
is already being teared down by another thread that is executing
|
||
__cifs_put_smb_ses(). This can happen when (a) the client has
|
||
connection to the server but no session or (b) another thread ends up
|
||
setting @ses->ses_status again to something different than
|
||
SES_EXITING.
|
||
|
||
To fix this, we need to make sure to unconditionally set
|
||
@ses->ses_status to SES_EXITING and prevent any other threads from
|
||
setting a new status while we're still tearing it down.
|
||
|
||
The following can be reproduced by adding some delay to right after
|
||
the ipc is freed in __cifs_put_smb_ses() - which will give
|
||
smb2_reconnect_server() worker a chance to run and then accessing
|
||
@ses->ipc:
|
||
|
||
kinit ...
|
||
mount.cifs //srv/share /mnt/1 -o sec=krb5,nohandlecache,echo_interval=10
|
||
[disconnect srv]
|
||
ls /mnt/1 &>/dev/null
|
||
sleep 30
|
||
kdestroy
|
||
[reconnect srv]
|
||
sleep 10
|
||
umount /mnt/1
|
||
...
|
||
CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed
|
||
CIFS: VFS: \\srv Send error in SessSetup = -126
|
||
CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed
|
||
CIFS: VFS: \\srv Send error in SessSetup = -126
|
||
general protection fault, probably for non-canonical address
|
||
0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI
|
||
CPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc2 #1
|
||
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39
|
||
04/01/2014
|
||
Workqueue: cifsiod smb2_reconnect_server [cifs]
|
||
RIP: 0010:__list_del_entry_valid_or_report+0x33/0xf0
|
||
Code: 4f 08 48 85 d2 74 42 48 85 c9 74 59 48 b8 00 01 00 00 00 00 ad
|
||
de 48 39 c2 74 61 48 b8 22 01 00 00 00 00 74 69 <48> 8b 01 48 39 f8 75
|
||
7b 48 8b 72 08 48 39 c6 0f 85 88 00 00 00 b8
|
||
RSP: 0018:ffffc900001bfd70 EFLAGS: 00010a83
|
||
RAX: dead000000000122 RBX: ffff88810da53838 RCX: 6b6b6b6b6b6b6b6b
|
||
RDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc02f6878 RDI: ffff88810da53800
|
||
RBP: ffff88810da53800 R08: 0000000000000001 R09: 0000000000000000
|
||
R10: 0000000000000000 R11: 0000000000000001 R12: ffff88810c064000
|
||
R13: 0000000000000001 R14: ffff88810c064000 R15: ffff8881039cc000
|
||
FS: 0000000000000000(0000) GS:ffff888157c00000(0000)
|
||
knlGS:0000000000000000
|
||
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
||
CR2: 00007fe3728b1000 CR3: 000000010caa4000 CR4: 0000000000750ef0
|
||
PKRU: 55555554
|
||
Call Trace:
|
||
<TASK>
|
||
? die_addr+0x36/0x90
|
||
? exc_general_protection+0x1c1/0x3f0
|
||
? asm_exc_general_protection+0x26/0x30
|
||
? __list_del_entry_valid_or_report+0x33/0xf0
|
||
__cifs_put_smb_ses+0x1ae/0x500 [cifs]
|
||
smb2_reconnect_server+0x4ed/0x710 [cifs]
|
||
process_one_work+0x205/0x6b0
|
||
worker_thread+0x191/0x360
|
||
? __pfx_worker_thread+0x10/0x10
|
||
kthread+0xe2/0x110
|
||
? __pfx_kthread+0x10/0x10
|
||
ret_from_fork+0x34/0x50
|
||
? __pfx_kthread+0x10/0x10
|
||
ret_from_fork_asm+0x1a/0x30
|
||
</TASK>(CVE-2024-35870)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
ax25: fix use-after-free bugs caused by ax25_ds_del_timer
|
||
|
||
When the ax25 device is detaching, the ax25_dev_device_down()
|
||
calls ax25_ds_del_timer() to cleanup the slave_timer. When
|
||
the timer handler is running, the ax25_ds_del_timer() that
|
||
calls del_timer() in it will return directly. As a result,
|
||
the use-after-free bugs could happen, one of the scenarios
|
||
is shown below:
|
||
|
||
(Thread 1) | (Thread 2)
|
||
| ax25_ds_timeout()
|
||
ax25_dev_device_down() |
|
||
ax25_ds_del_timer() |
|
||
del_timer() |
|
||
ax25_dev_put() //FREE |
|
||
| ax25_dev-> //USE
|
||
|
||
In order to mitigate bugs, when the device is detaching, use
|
||
timer_shutdown_sync() to stop the timer.(CVE-2024-35887)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
tcp: properly terminate timers for kernel sockets
|
||
|
||
We had various syzbot reports about tcp timers firing after
|
||
the corresponding netns has been dismantled.
|
||
|
||
Fortunately Josef Bacik could trigger the issue more often,
|
||
and could test a patch I wrote two years ago.
|
||
|
||
When TCP sockets are closed, we call inet_csk_clear_xmit_timers()
|
||
to 'stop' the timers.
|
||
|
||
inet_csk_clear_xmit_timers() can be called from any context,
|
||
including when socket lock is held.
|
||
This is the reason it uses sk_stop_timer(), aka del_timer().
|
||
This means that ongoing timers might finish much later.
|
||
|
||
For user sockets, this is fine because each running timer
|
||
holds a reference on the socket, and the user socket holds
|
||
a reference on the netns.
|
||
|
||
For kernel sockets, we risk that the netns is freed before
|
||
timer can complete, because kernel sockets do not hold
|
||
reference on the netns.
|
||
|
||
This patch adds inet_csk_clear_xmit_timers_sync() function
|
||
that using sk_stop_timer_sync() to make sure all timers
|
||
are terminated before the kernel socket is released.
|
||
Modules using kernel sockets close them in their netns exit()
|
||
handler.
|
||
|
||
Also add sock_not_owned_by_me() helper to get LOCKDEP
|
||
support : inet_csk_clear_xmit_timers_sync() must not be called
|
||
while socket lock is held.
|
||
|
||
It is very possible we can revert in the future commit
|
||
3a58f13a881e ("net: rds: acquire refcount on TCP sockets")
|
||
which attempted to solve the issue in rds only.
|
||
(net/smc/af_smc.c and net/mptcp/subflow.c have similar code)
|
||
|
||
We probably can remove the check_net() tests from
|
||
tcp_out_of_resources() and __tcp_close() in the future.(CVE-2024-35910)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet
|
||
|
||
syzbot reported the following uninit-value access issue [1][2]:
|
||
|
||
nci_rx_work() parses and processes received packet. When the payload
|
||
length is zero, each message type handler reads uninitialized payload
|
||
and KMSAN detects this issue. The receipt of a packet with a zero-size
|
||
payload is considered unexpected, and therefore, such packets should be
|
||
silently discarded.
|
||
|
||
This patch resolved this issue by checking payload size before calling
|
||
each message type handler codes.(CVE-2024-35915)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
drm/vc4: don't check if plane->state->fb == state->fb
|
||
|
||
Currently, when using non-blocking commits, we can see the following
|
||
kernel warning:
|
||
|
||
[ 110.908514] ------------[ cut here ]------------
|
||
[ 110.908529] refcount_t: underflow; use-after-free.
|
||
[ 110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87 refcount_dec_not_one+0xb8/0xc0
|
||
[ 110.908664] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash aes_arm64 aes_generic algif_skcipher af_alg bnep hid_logitech_hidpp vc4 brcmfmac hci_uart btbcm brcmutil bluetooth snd_soc_hdmi_codec cfg80211 cec drm_display_helper drm_dma_helper drm_kms_helper snd_soc_core snd_compress snd_pcm_dmaengine fb_sys_fops sysimgblt syscopyarea sysfillrect raspberrypi_hwmon ecdh_generic ecc rfkill libaes i2c_bcm2835 binfmt_misc joydev snd_bcm2835(C) bcm2835_codec(C) bcm2835_isp(C) v4l2_mem2mem videobuf2_dma_contig snd_pcm bcm2835_v4l2(C) raspberrypi_gpiomem bcm2835_mmal_vchiq(C) videobuf2_v4l2 snd_timer videobuf2_vmalloc videobuf2_memops videobuf2_common snd videodev vc_sm_cma(C) mc hid_logitech_dj uio_pdrv_genirq uio i2c_dev drm fuse dm_mod drm_panel_orientation_quirks backlight ip_tables x_tables ipv6
|
||
[ 110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Tainted: G C 6.1.66-v8+ #32
|
||
[ 110.909104] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)
|
||
[ 110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
||
[ 110.909132] pc : refcount_dec_not_one+0xb8/0xc0
|
||
[ 110.909152] lr : refcount_dec_not_one+0xb4/0xc0
|
||
[ 110.909170] sp : ffffffc00913b9c0
|
||
[ 110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60
|
||
[ 110.909205] x26: 0000000000000002 x25: 0000000000000004 x24: ffffff8004448480
|
||
[ 110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: ffffffecfca68c78
|
||
[ 110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000
|
||
[ 110.909283] x17: 0000000000000011 x16: ffffffffffffffff x15: 0000000000000004
|
||
[ 110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003
|
||
[ 110.909333] x11: 0000000000000000 x10: 0000000000000027 x9 : c912d0d083728c00
|
||
[ 110.909359] x8 : c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572
|
||
[ 110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 0000000000000000
|
||
[ 110.909409] x2 : 0000000000000000 x1 : ffffffc00913b750 x0 : 0000000000000001
|
||
[ 110.909434] Call trace:
|
||
[ 110.909441] refcount_dec_not_one+0xb8/0xc0
|
||
[ 110.909461] vc4_bo_dec_usecnt+0x4c/0x1b0 [vc4]
|
||
[ 110.909903] vc4_cleanup_fb+0x44/0x50 [vc4]
|
||
[ 110.910315] drm_atomic_helper_cleanup_planes+0x88/0xa4 [drm_kms_helper]
|
||
[ 110.910669] vc4_atomic_commit_tail+0x390/0x9dc [vc4]
|
||
[ 110.911079] commit_tail+0xb0/0x164 [drm_kms_helper]
|
||
[ 110.911397] drm_atomic_helper_commit+0x1d0/0x1f0 [drm_kms_helper]
|
||
[ 110.911716] drm_atomic_commit+0xb0/0xdc [drm]
|
||
[ 110.912569] drm_mode_atomic_ioctl+0x348/0x4b8 [drm]
|
||
[ 110.913330] drm_ioctl_kernel+0xec/0x15c [drm]
|
||
[ 110.914091] drm_ioctl+0x24c/0x3b0 [drm]
|
||
[ 110.914850] __arm64_sys_ioctl+0x9c/0xd4
|
||
[ 110.914873] invoke_syscall+0x4c/0x114
|
||
[ 110.914897] el0_svc_common+0xd0/0x118
|
||
[ 110.914917] do_el0_svc+0x38/0xd0
|
||
[ 110.914936] el0_svc+0x30/0x8c
|
||
[ 110.914958] el0t_64_sync_handler+0x84/0xf0
|
||
[ 110.914979] el0t_64_sync+0x18c/0x190
|
||
[ 110.914996] ---[ end trace 0000000000000000 ]---
|
||
|
||
This happens because, although `prepare_fb` and `cleanup_fb` are
|
||
perfectly balanced, we cannot guarantee consistency in the check
|
||
plane->state->fb == state->fb. This means that sometimes we can increase
|
||
the refcount in `prepare_fb` and don't decrease it in `cleanup_fb`. The
|
||
opposite can also be true.
|
||
|
||
In fact, the struct drm_plane .state shouldn't be accessed directly
|
||
but instead, the `drm_atomic_get_new_plane_state()` helper function should
|
||
be used. So, we could stick to this check, but using
|
||
`drm_atomic_get_new_plane_state()`. But actually, this check is not re
|
||
---truncated---(CVE-2024-35932)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
btrfs: send: handle path ref underflow in header iterate_inode_ref()
|
||
|
||
Change BUG_ON to proper error handling if building the path buffer
|
||
fails. The pointers are not printed so we don't accidentally leak kernel
|
||
addresses.(CVE-2024-35935)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
wifi: cfg80211: check A-MSDU format more carefully
|
||
|
||
If it looks like there's another subframe in the A-MSDU
|
||
but the header isn't fully there, we can end up reading
|
||
data out of bounds, only to discard later. Make this a
|
||
bit more careful and check if the subframe header can
|
||
even be present.(CVE-2024-35937)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()
|
||
|
||
Subject: [PATCH] drm/panfrost: Fix the error path in
|
||
panfrost_mmu_map_fault_addr()
|
||
|
||
If some the pages or sgt allocation failed, we shouldn't release the
|
||
pages ref we got earlier, otherwise we will end up with unbalanced
|
||
get/put_pages() calls. We should instead leave everything in place
|
||
and let the BO release function deal with extra cleanup when the object
|
||
is destroyed, or let the fault handler try again next time it's called.(CVE-2024-35951)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
Bluetooth: L2CAP: Fix not validating setsockopt user input
|
||
|
||
Check user input length before copying data.(CVE-2024-35965)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
Bluetooth: RFCOMM: Fix not validating setsockopt user input
|
||
|
||
syzbot reported rfcomm_sock_setsockopt_old() is copying data without
|
||
checking user input length.
|
||
|
||
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset
|
||
include/linux/sockptr.h:49 [inline]
|
||
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr
|
||
include/linux/sockptr.h:55 [inline]
|
||
BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old
|
||
net/bluetooth/rfcomm/sock.c:632 [inline]
|
||
BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70
|
||
net/bluetooth/rfcomm/sock.c:673
|
||
Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064(CVE-2024-35966)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
tty: n_gsm: fix possible out-of-bounds in gsm0_receive()
|
||
|
||
Assuming the following:
|
||
- side A configures the n_gsm in basic option mode
|
||
- side B sends the header of a basic option mode frame with data length 1
|
||
- side A switches to advanced option mode
|
||
- side B sends 2 data bytes which exceeds gsm->len
|
||
Reason: gsm->len is not used in advanced option mode.
|
||
- side A switches to basic option mode
|
||
- side B keeps sending until gsm0_receive() writes past gsm->buf
|
||
Reason: Neither gsm->state nor gsm->len have been reset after
|
||
reconfiguration.
|
||
|
||
Fix this by changing gsm->count to gsm->len comparison from equal to less
|
||
than. Also add upper limit checks against the constant MAX_MRU in
|
||
gsm0_receive() and gsm1_receive() to harden against memory corruption of
|
||
gsm->len and gsm->mru.
|
||
|
||
All other checks remain as we still need to limit the data according to the
|
||
user configuration and actual payload size.(CVE-2024-36016)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets
|
||
|
||
TCP_SYN_RECV state is really special, it is only used by
|
||
cross-syn connections, mostly used by fuzzers.
|
||
|
||
In the following crash [1], syzbot managed to trigger a divide
|
||
by zero in tcp_rcv_space_adjust()
|
||
|
||
A socket makes the following state transitions,
|
||
without ever calling tcp_init_transfer(),
|
||
meaning tcp_init_buffer_space() is also not called.
|
||
|
||
TCP_CLOSE
|
||
connect()
|
||
TCP_SYN_SENT
|
||
TCP_SYN_RECV
|
||
shutdown() -> tcp_shutdown(sk, SEND_SHUTDOWN)
|
||
TCP_FIN_WAIT1
|
||
|
||
To fix this issue, change tcp_shutdown() to not
|
||
perform a TCP_SYN_RECV -> TCP_FIN_WAIT1 transition,
|
||
which makes no sense anyway.
|
||
|
||
When tcp_rcv_state_process() later changes socket state
|
||
from TCP_SYN_RECV to TCP_ESTABLISH, then look at
|
||
sk->sk_shutdown to finally enter TCP_FIN_WAIT1 state,
|
||
and send a FIN packet from a sane socket state.
|
||
|
||
This means tcp_send_fin() can now be called from BH
|
||
context, and must use GFP_ATOMIC allocations.
|
||
|
||
[1]
|
||
divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI
|
||
CPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0
|
||
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
|
||
RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767
|
||
Code: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 <48> f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48
|
||
RSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246
|
||
RAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000
|
||
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
|
||
RBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7
|
||
R10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30
|
||
R13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da
|
||
FS: 00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
|
||
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
||
CR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0
|
||
Call Trace:
|
||
<TASK>
|
||
tcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513
|
||
tcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578
|
||
inet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680
|
||
sock_recvmsg_nosec net/socket.c:1046 [inline]
|
||
sock_recvmsg+0x109/0x280 net/socket.c:1068
|
||
____sys_recvmsg+0x1db/0x470 net/socket.c:2803
|
||
___sys_recvmsg net/socket.c:2845 [inline]
|
||
do_recvmmsg+0x474/0xae0 net/socket.c:2939
|
||
__sys_recvmmsg net/socket.c:3018 [inline]
|
||
__do_sys_recvmmsg net/socket.c:3041 [inline]
|
||
__se_sys_recvmmsg net/socket.c:3034 [inline]
|
||
__x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034
|
||
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
||
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
|
||
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
||
RIP: 0033:0x7faeb6363db9
|
||
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
|
||
RSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b
|
||
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9
|
||
RDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005
|
||
RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c
|
||
R10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000
|
||
R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001(CVE-2024-36905)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
blk-iocost: avoid out of bounds shift
|
||
|
||
UBSAN catches undefined behavior in blk-iocost, where sometimes
|
||
iocg->delay is shifted right by a number that is too large,
|
||
resulting in undefined behavior on some architectures.
|
||
|
||
[ 186.556576] ------------[ cut here ]------------
|
||
UBSAN: shift-out-of-bounds in block/blk-iocost.c:1366:23
|
||
shift exponent 64 is too large for 64-bit type 'u64' (aka 'unsigned long long')
|
||
CPU: 16 PID: 0 Comm: swapper/16 Tainted: G S E N 6.9.0-0_fbk700_debug_rc2_kbuilder_0_gc85af715cac0 #1
|
||
Hardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F09_3A23 12/08/2020
|
||
Call Trace:
|
||
<IRQ>
|
||
dump_stack_lvl+0x8f/0xe0
|
||
__ubsan_handle_shift_out_of_bounds+0x22c/0x280
|
||
iocg_kick_delay+0x30b/0x310
|
||
ioc_timer_fn+0x2fb/0x1f80
|
||
__run_timer_base+0x1b6/0x250
|
||
...
|
||
|
||
Avoid that undefined behavior by simply taking the
|
||
"delay = 0" branch if the shift is too large.
|
||
|
||
I am not sure what the symptoms of an undefined value
|
||
delay will be, but I suspect it could be more than a
|
||
little annoying to debug.(CVE-2024-36916)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
scsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload
|
||
|
||
The session resources are used by FW and driver when session is offloaded,
|
||
once session is uploaded these resources are not used. The lock is not
|
||
required as these fields won't be used any longer. The offload and upload
|
||
calls are sequential, hence lock is not required.
|
||
|
||
This will suppress following BUG_ON():
|
||
|
||
[ 449.843143] ------------[ cut here ]------------
|
||
[ 449.848302] kernel BUG at mm/vmalloc.c:2727!
|
||
[ 449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI
|
||
[ 449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x86_64 #1
|
||
Rebooting.
|
||
[ 449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016
|
||
[ 449.876966] Workqueue: fc_rport_eq fc_rport_work [libfc]
|
||
[ 449.882910] RIP: 0010:vunmap+0x2e/0x30
|
||
[ 449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 <0f> 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41
|
||
[ 449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206
|
||
[ 449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005
|
||
[ 449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000
|
||
[ 449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf
|
||
[ 449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000
|
||
[ 449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0
|
||
[ 449.953701] FS: 0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000
|
||
[ 449.962732] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
||
[ 449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0
|
||
[ 449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
||
[ 449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
||
[ 449.993028] Call Trace:
|
||
[ 449.995756] __iommu_dma_free+0x96/0x100
|
||
[ 450.000139] bnx2fc_free_session_resc+0x67/0x240 [bnx2fc]
|
||
[ 450.006171] bnx2fc_upload_session+0xce/0x100 [bnx2fc]
|
||
[ 450.011910] bnx2fc_rport_event_handler+0x9f/0x240 [bnx2fc]
|
||
[ 450.018136] fc_rport_work+0x103/0x5b0 [libfc]
|
||
[ 450.023103] process_one_work+0x1e8/0x3c0
|
||
[ 450.027581] worker_thread+0x50/0x3b0
|
||
[ 450.031669] ? rescuer_thread+0x370/0x370
|
||
[ 450.036143] kthread+0x149/0x170
|
||
[ 450.039744] ? set_kthread_struct+0x40/0x40
|
||
[ 450.044411] ret_from_fork+0x22/0x30
|
||
[ 450.048404] Modules linked in: vfat msdos fat xfs nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver dm_service_time qedf qed crc8 bnx2fc libfcoe libfc scsi_transport_fc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp dcdbas rapl intel_cstate intel_uncore mei_me pcspkr mei ipmi_ssif lpc_ich ipmi_si fuse zram ext4 mbcache jbd2 loop nfsv3 nfs_acl nfs lockd grace fscache netfs irdma ice sd_mod t10_pi sg ib_uverbs ib_core 8021q garp mrp stp llc mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi fb_sys_fops cec crct10dif_pclmul ahci crc32_pclmul bnx2x drm ghash_clmulni_intel libahci rfkill i40e libata megaraid_sas mdio wmi sunrpc lrw dm_crypt dm_round_robin dm_multipath dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_zero dm_mod linear raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid6_pq libcrc32c crc32c_intel raid1 raid0 iscsi_ibft squashfs be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls
|
||
[ 450.048497] libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi edd ipmi_devintf ipmi_msghandler
|
||
[ 450.159753] ---[ end trace 712de2c57c64abc8 ]---(CVE-2024-36919)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
scsi: lpfc: Move NPIV's transport unregistration to after resource clean up
|
||
|
||
There are cases after NPIV deletion where the fabric switch still believes
|
||
the NPIV is logged into the fabric. This occurs when a vport is
|
||
unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the
|
||
fabric.
|
||
|
||
Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including
|
||
the fabric D_ID, removes the last ndlp reference and frees the ndlp rport
|
||
object. This sometimes causes the race condition where the final DA_ID and
|
||
LOGO are skipped from being sent to the fabric switch.
|
||
|
||
Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID
|
||
and LOGO are sent.(CVE-2024-36952)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
drm/vmwgfx: Fix invalid reads in fence signaled events
|
||
|
||
Correctly set the length of the drm_event to the size of the structure
|
||
that's actually used.
|
||
|
||
The length of the drm_event was set to the parent structure instead of
|
||
to the drm_vmw_event_fence which is supposed to be read. drm_read
|
||
uses the length parameter to copy the event to the user space thus
|
||
resuling in oob reads.(CVE-2024-36960)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()
|
||
|
||
l2cap_le_flowctl_init() can cause both div-by-zero and an integer
|
||
overflow since hdev->le_mtu may not fall in the valid range.
|
||
|
||
Move MTU from hci_dev to hci_conn to validate MTU and stop the connection
|
||
process earlier if MTU is invalid.
|
||
Also, add a missing validation in read_buffer_size() and make it return
|
||
an error value if the validation fails.
|
||
Now hci_conn_add() returns ERR_PTR() as it can fail due to the both a
|
||
kzalloc failure and invalid MTU value.
|
||
|
||
divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI
|
||
CPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G W 6.9.0-rc5+ #20
|
||
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
|
||
Workqueue: hci0 hci_rx_work
|
||
RIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547
|
||
Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c
|
||
89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 <66> f7 f3 89 c3 ff c3 4d 8d
|
||
b7 88 00 00 00 4c 89 f0 48 c1 e8 03 42
|
||
RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246
|
||
RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000
|
||
RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f
|
||
RBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa
|
||
R10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084
|
||
R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000
|
||
FS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000
|
||
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
||
CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0
|
||
PKRU: 55555554
|
||
Call Trace:
|
||
<TASK>
|
||
l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline]
|
||
l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline]
|
||
l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline]
|
||
l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809
|
||
l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506
|
||
hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline]
|
||
hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176
|
||
process_one_work kernel/workqueue.c:3254 [inline]
|
||
process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335
|
||
worker_thread+0x926/0xe70 kernel/workqueue.c:3416
|
||
kthread+0x2e3/0x380 kernel/kthread.c:388
|
||
ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147
|
||
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
|
||
</TASK>
|
||
Modules linked in:
|
||
---[ end trace 0000000000000000 ]---(CVE-2024-36968)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
net: fix __dst_negative_advice() race
|
||
|
||
__dst_negative_advice() does not enforce proper RCU rules when
|
||
sk->dst_cache must be cleared, leading to possible UAF.
|
||
|
||
RCU rules are that we must first clear sk->sk_dst_cache,
|
||
then call dst_release(old_dst).
|
||
|
||
Note that sk_dst_reset(sk) is implementing this protocol correctly,
|
||
while __dst_negative_advice() uses the wrong order.
|
||
|
||
Given that ip6_negative_advice() has special logic
|
||
against RTF_CACHE, this means each of the three ->negative_advice()
|
||
existing methods must perform the sk_dst_reset() themselves.
|
||
|
||
Note the check against NULL dst is centralized in
|
||
__dst_negative_advice(), there is no need to duplicate
|
||
it in various callbacks.
|
||
|
||
Many thanks to Clement Lecigne for tracking this issue.
|
||
|
||
This old bug became visible after the blamed commit, using UDP sockets.(CVE-2024-36971)</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/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</URL>
|
||
</Reference>
|
||
<Reference Type="openEuler CVE">
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47366</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2022-48673</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2022-48692</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52670</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52748</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52791</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52821</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52841</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52873</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52882</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26924</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26935</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26936</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26947</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26954</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26960</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27014</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27017</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27019</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27044</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35796</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35819</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35821</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35828</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35870</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35887</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35910</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35915</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35932</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35935</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35937</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35951</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35965</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35966</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36016</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36905</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36916</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36919</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36952</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36960</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36968</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36971</URL>
|
||
</Reference>
|
||
<Reference Type="Other">
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47366</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48673</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48692</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52670</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52748</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52791</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52821</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52841</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52873</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52882</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26924</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26935</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26936</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26947</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26954</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26960</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27014</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27017</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27019</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27044</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35796</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35819</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35821</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35828</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35870</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35887</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35910</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35915</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35932</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35935</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35937</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35951</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35965</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35966</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36016</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36905</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36916</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36919</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36952</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36960</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36968</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36971</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-tools-5.10.0-209.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-headers-5.10.0-209.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-headers-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-5.10.0-209.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-devel-5.10.0-209.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-devel-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-tools-devel-5.10.0-209.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-devel-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="perf-debuginfo-5.10.0-209.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-debuginfo-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-debugsource-5.10.0-209.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debugsource-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-debuginfo-5.10.0-209.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debuginfo-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-209.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-debuginfo-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="perf-5.10.0-209.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-source-5.10.0-209.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-source-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-209.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-debuginfo-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="python3-perf-5.10.0-209.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-5.10.0-209.0.0.117.oe2203sp3.aarch64.rpm</FullProductName>
|
||
</Branch>
|
||
<Branch Type="Package Arch" Name="src">
|
||
<FullProductName ProductID="kernel-5.10.0-209.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-209.0.0.117.oe2203sp3.src.rpm</FullProductName>
|
||
</Branch>
|
||
<Branch Type="Package Arch" Name="x86_64">
|
||
<FullProductName ProductID="kernel-tools-devel-5.10.0-209.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-devel-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-source-5.10.0-209.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-source-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-debugsource-5.10.0-209.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debugsource-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-209.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-debuginfo-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-headers-5.10.0-209.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-headers-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="python3-perf-5.10.0-209.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-tools-5.10.0-209.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="perf-debuginfo-5.10.0-209.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-debuginfo-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-debuginfo-5.10.0-209.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debuginfo-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-devel-5.10.0-209.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-devel-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-5.10.0-209.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="perf-5.10.0-209.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-5.10.0-209.0.0.117.oe2203sp3.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-209.0.0.117" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-debuginfo-5.10.0-209.0.0.117.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:
|
||
|
||
afs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server
|
||
|
||
AFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, and
|
||
Linux's afs client switches between them when talking to a non-YFS server
|
||
if the read size, the file position or the sum of the two have the upper 32
|
||
bits set of the 64-bit value.
|
||
|
||
This is a problem, however, since the file position and length fields of
|
||
FS.FetchData are *signed* 32-bit values.
|
||
|
||
Fix this by capturing the capability bits obtained from the fileserver when
|
||
it's sent an FS.GetCapabilities RPC, rather than just discarding them, and
|
||
then picking out the VICED_CAPABILITY_64BITFILES flag. This can then be
|
||
used to decide whether to use FS.FetchData or FS.FetchData64 - and also
|
||
FS.StoreData or FS.StoreData64 - rather than using upper_32_bits() to
|
||
switch on the parameter values.
|
||
|
||
This capabilities flag could also be used to limit the maximum size of the
|
||
file, but all servers must be checked for that.
|
||
|
||
Note that the issue does not exist with FS.StoreData - that uses *unsigned*
|
||
32-bit values. It's also not a problem with Auristor servers as its
|
||
YFS.FetchData64 op uses unsigned 64-bit values.
|
||
|
||
This can be tested by cloning a git repo through an OpenAFS client to an
|
||
OpenAFS server and then doing "git status" on it from a Linux afs
|
||
client[1]. Provided the clone has a pack file that's in the 2G-4G range,
|
||
the git status will show errors like:
|
||
|
||
error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index
|
||
error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index
|
||
|
||
This can be observed in the server's FileLog with something like the
|
||
following appearing:
|
||
|
||
Sun Aug 29 19:31:39 2021 SRXAFS_FetchData, Fid = 2303380852.491776.3263114, Host 192.168.11.201:7001, Id 1001
|
||
Sun Aug 29 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001
|
||
Sun Aug 29 19:31:39 2021 FetchData_RXStyle: Pos 18446744071815340032, Len 3154
|
||
Sun Aug 29 19:31:39 2021 FetchData_RXStyle: file size 2400758866
|
||
...
|
||
Sun Aug 29 19:31:40 2021 SRXAFS_FetchData returns 5
|
||
|
||
Note the file position of 18446744071815340032. This is the requested file
|
||
position sign-extended.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2021-47366</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.5</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:net/smc: Fix possible access to freed memory in link clearAfter modifying the QP to the Error state, all RX WR would be completedwith WC in IB_WC_WR_FLUSH_ERR status. Current implementation does notwait for it is done, but destroy the QP and free the link group directly.So there is a risk that accessing the freed memory in tasklet context.Here is a crash example: BUG: unable to handle page fault for address: ffffffff8f220860 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD f7300e067 P4D f7300e067 PUD f7300f063 PMD 8c4e45063 PTE 800ffff08c9df060 Oops: 0002 [#1] SMP PTI CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: G S OE 5.10.0-0607+ #23 Hardware name: Inspur NF5280M4/YZMB-00689-101, BIOS 4.1.20 07/09/2018 RIP: 0010:native_queued_spin_lock_slowpath+0x176/0x1b0 Code: f3 90 48 8b 32 48 85 f6 74 f6 eb d5 c1 ee 12 83 e0 03 83 ee 01 48 c1 e0 05 48 63 f6 48 05 00 c8 02 00 48 03 04 f5 00 09 98 8e <48> 89 10 8b 42 08 85 c0 75 09 f3 90 8b 42 08 85 c0 74 f7 48 8b 32 RSP: 0018:ffffb3b6c001ebd8 EFLAGS: 00010086 RAX: ffffffff8f220860 RBX: 0000000000000246 RCX: 0000000000080000 RDX: ffff91db1f86c800 RSI: 000000000000173c RDI: ffff91db62bace00 RBP: ffff91db62bacc00 R08: 0000000000000000 R09: c00000010000028b R10: 0000000000055198 R11: ffffb3b6c001ea58 R12: ffff91db80e05010 R13: 000000000000000a R14: 0000000000000006 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff91db1f840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff8f220860 CR3: 00000001f9580004 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> _raw_spin_lock_irqsave+0x30/0x40 mlx5_ib_poll_cq+0x4c/0xc50 [mlx5_ib] smc_wr_rx_tasklet_fn+0x56/0xa0 [smc] tasklet_action_common.isra.21+0x66/0x100 __do_softirq+0xd5/0x29c asm_call_irq_on_stack+0x12/0x20 </IRQ> do_softirq_own_stack+0x37/0x40 irq_exit_rcu+0x9d/0xa0 sysvec_call_function_single+0x34/0x80 asm_sysvec_call_function_single+0x12/0x20</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2022-48673</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-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
RDMA/srp: Set scmnd->result only when scmnd is not NULL
|
||
|
||
This change fixes the following kernel NULL pointer dereference
|
||
which is reproduced by blktests srp/007 occasionally.
|
||
|
||
BUG: kernel NULL pointer dereference, address: 0000000000000170
|
||
PGD 0 P4D 0
|
||
Oops: 0002 [#1] PREEMPT SMP NOPTI
|
||
CPU: 0 PID: 9 Comm: kworker/0:1H Kdump: loaded Not tainted 6.0.0-rc1+ #37
|
||
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.15.0-29-g6a62e0cb0dfe-prebuilt.qemu.org 04/01/2014
|
||
Workqueue: 0x0 (kblockd)
|
||
RIP: 0010:srp_recv_done+0x176/0x500 [ib_srp]
|
||
Code: 00 4d 85 ff 0f 84 52 02 00 00 48 c7 82 80 02 00 00 00 00 00 00 4c 89 df 4c 89 14 24 e8 53 d3 4a f6 4c 8b 14 24 41 0f b6 42 13 <41> 89 87 70 01 00 00 41 0f b6 52 12 f6 c2 02 74 44 41 8b 42 1c b9
|
||
RSP: 0018:ffffaef7c0003e28 EFLAGS: 00000282
|
||
RAX: 0000000000000000 RBX: ffff9bc9486dea60 RCX: 0000000000000000
|
||
RDX: 0000000000000102 RSI: ffffffffb76bbd0e RDI: 00000000ffffffff
|
||
RBP: ffff9bc980099a00 R08: 0000000000000001 R09: 0000000000000001
|
||
R10: ffff9bca53ef0000 R11: ffff9bc980099a10 R12: ffff9bc956e14000
|
||
R13: ffff9bc9836b9cb0 R14: ffff9bc9557b4480 R15: 0000000000000000
|
||
FS: 0000000000000000(0000) GS:ffff9bc97ec00000(0000) knlGS:0000000000000000
|
||
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
||
CR2: 0000000000000170 CR3: 0000000007e04000 CR4: 00000000000006f0
|
||
Call Trace:
|
||
<IRQ>
|
||
__ib_process_cq+0xb7/0x280 [ib_core]
|
||
ib_poll_handler+0x2b/0x130 [ib_core]
|
||
irq_poll_softirq+0x93/0x150
|
||
__do_softirq+0xee/0x4b8
|
||
irq_exit_rcu+0xf7/0x130
|
||
sysvec_apic_timer_interrupt+0x8e/0xc0
|
||
</IRQ></Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2022-48692</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-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
rpmsg: virtio: Free driver_override when rpmsg_remove()
|
||
|
||
Free driver_override when rpmsg_remove(), otherwise
|
||
the following memory leak will occur:
|
||
|
||
unreferenced object 0xffff0000d55d7080 (size 128):
|
||
comm "kworker/u8:2", pid 56, jiffies 4294893188 (age 214.272s)
|
||
hex dump (first 32 bytes):
|
||
72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00 rpmsg_ns........
|
||
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||
backtrace:
|
||
[<000000009c94c9c1>] __kmem_cache_alloc_node+0x1f8/0x320
|
||
[<000000002300d89b>] __kmalloc_node_track_caller+0x44/0x70
|
||
[<00000000228a60c3>] kstrndup+0x4c/0x90
|
||
[<0000000077158695>] driver_set_override+0xd0/0x164
|
||
[<000000003e9c4ea5>] rpmsg_register_device_override+0x98/0x170
|
||
[<000000001c0c89a8>] rpmsg_ns_register_device+0x24/0x30
|
||
[<000000008bbf8fa2>] rpmsg_probe+0x2e0/0x3ec
|
||
[<00000000e65a68df>] virtio_dev_probe+0x1c0/0x280
|
||
[<00000000443331cc>] really_probe+0xbc/0x2dc
|
||
[<00000000391064b1>] __driver_probe_device+0x78/0xe0
|
||
[<00000000a41c9a5b>] driver_probe_device+0xd8/0x160
|
||
[<000000009c3bd5df>] __device_attach_driver+0xb8/0x140
|
||
[<0000000043cd7614>] bus_for_each_drv+0x7c/0xd4
|
||
[<000000003b929a36>] __device_attach+0x9c/0x19c
|
||
[<00000000a94e0ba8>] device_initial_probe+0x14/0x20
|
||
[<000000003c999637>] bus_probe_device+0xa0/0xac</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2023-52670</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
f2fs: avoid format-overflow warning
|
||
|
||
With gcc and W=1 option, there's a warning like this:
|
||
|
||
fs/f2fs/compress.c: In function ‘f2fs_init_page_array_cache’:
|
||
fs/f2fs/compress.c:1984:47: error: ‘%u’ directive writing between
|
||
1 and 7 bytes into a region of size between 5 and 8
|
||
[-Werror=format-overflow=]
|
||
1984 | sprintf(slab_name, "f2fs_page_array_entry-%u:%u", MAJOR(dev),
|
||
MINOR(dev));
|
||
| ^~
|
||
|
||
String "f2fs_page_array_entry-%u:%u" can up to 35. The first "%u" can up
|
||
to 4 and the second "%u" can up to 7, so total size is "24 + 4 + 7 = 35".
|
||
slab_name's size should be 35 rather than 32.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2023-52748</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.0</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
i2c: core: Run atomic i2c xfer when !preemptible
|
||
|
||
Since bae1d3a05a8b, i2c transfers are non-atomic if preemption is
|
||
disabled. However, non-atomic i2c transfers require preemption (e.g. in
|
||
wait_for_completion() while waiting for the DMA).
|
||
|
||
panic() calls preempt_disable_notrace() before calling
|
||
emergency_restart(). Therefore, if an i2c device is used for the
|
||
restart, the xfer should be atomic. This avoids warnings like:
|
||
|
||
[ 12.667612] WARNING: CPU: 1 PID: 1 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x33c/0x6b0
|
||
[ 12.676926] Voluntary context switch within RCU read-side critical section!
|
||
...
|
||
[ 12.742376] schedule_timeout from wait_for_completion_timeout+0x90/0x114
|
||
[ 12.749179] wait_for_completion_timeout from tegra_i2c_wait_completion+0x40/0x70
|
||
...
|
||
[ 12.994527] atomic_notifier_call_chain from machine_restart+0x34/0x58
|
||
[ 13.001050] machine_restart from panic+0x2a8/0x32c
|
||
|
||
Use !preemptible() instead, which is basically the same check as
|
||
pre-v5.2.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2023-52791</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="7" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
||
<Notes>
|
||
<Note Title="Vulnerability Description" Type="General" Ordinal="7" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:drm/panel: fix a possible null pointer dereferenceIn versatile_panel_get_modes(), the return value of drm_mode_duplicate()is assigned to mode, which will lead to a NULL pointer dereferenceon failure of drm_mode_duplicate(). Add a check to avoid npd.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2023-52821</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-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
media: vidtv: mux: Add check and kfree for kstrdup
|
||
|
||
Add check for the return value of kstrdup() and return the error
|
||
if it fails in order to avoid NULL pointer dereference.
|
||
Moreover, use kfree() in the later error handling in order to avoid
|
||
memory leak.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2023-52841</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-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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: mediatek: clk-mt6779: Add check for mtk_alloc_clk_data
|
||
|
||
Add the check for the return value of mtk_alloc_clk_data() in order to
|
||
avoid NULL pointer dereference.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2023-52873</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-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
clk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate change
|
||
|
||
While PLL CPUX clock rate change when CPU is running from it works in
|
||
vast majority of cases, now and then it causes instability. This leads
|
||
to system crashes and other undefined behaviour. After a lot of testing
|
||
(30+ hours) while also doing a lot of frequency switches, we can't
|
||
observe any instability issues anymore when doing reparenting to stable
|
||
clock like 24 MHz oscillator.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2023-52882</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
netfilter: nft_set_pipapo: do not free live element
|
||
|
||
Pablo reports a crash with large batches of elements with a
|
||
back-to-back add/remove pattern. Quoting Pablo:
|
||
|
||
add_elem("00000000") timeout 100 ms
|
||
...
|
||
add_elem("0000000X") timeout 100 ms
|
||
del_elem("0000000X") <---------------- delete one that was just added
|
||
...
|
||
add_elem("00005000") timeout 100 ms
|
||
|
||
1) nft_pipapo_remove() removes element 0000000X
|
||
Then, KASAN shows a splat.
|
||
|
||
Looking at the remove function there is a chance that we will drop a
|
||
rule that maps to a non-deactivated element.
|
||
|
||
Removal happens in two steps, first we do a lookup for key k and return the
|
||
to-be-removed element and mark it as inactive in the next generation.
|
||
Then, in a second step, the element gets removed from the set/map.
|
||
|
||
The _remove function does not work correctly if we have more than one
|
||
element that share the same key.
|
||
|
||
This can happen if we insert an element into a set when the set already
|
||
holds an element with same key, but the element mapping to the existing
|
||
key has timed out or is not active in the next generation.
|
||
|
||
In such case its possible that removal will unmap the wrong element.
|
||
If this happens, we will leak the non-deactivated element, it becomes
|
||
unreachable.
|
||
|
||
The element that got deactivated (and will be freed later) will
|
||
remain reachable in the set data structure, this can result in
|
||
a crash when such an element is retrieved during lookup (stale
|
||
pointer).
|
||
|
||
Add a check that the fully matching key does in fact map to the element
|
||
that we have marked as inactive in the deactivation step.
|
||
If not, we need to continue searching.
|
||
|
||
Add a bug/warn trap at the end of the function as well, the remove
|
||
function must not ever be called with an invisible/unreachable/non-existent
|
||
element.
|
||
|
||
v2: avoid uneeded temporary variable (Stefano)</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-26924</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-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
scsi: core: Fix unremoved procfs host directory regression
|
||
|
||
Commit fc663711b944 ("scsi: core: Remove the /proc/scsi/${proc_name}
|
||
directory earlier") fixed a bug related to modules loading/unloading, by
|
||
adding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led
|
||
to a potential duplicate call to the hostdir_rm() routine, since it's also
|
||
called from scsi_host_dev_release(). That triggered a regression report,
|
||
which was then fixed by commit be03df3d4bfe ("scsi: core: Fix a procfs host
|
||
directory removal regression"). The fix just dropped the hostdir_rm() call
|
||
from dev_release().
|
||
|
||
But it happens that this proc directory is created on scsi_host_alloc(),
|
||
and that function "pairs" with scsi_host_dev_release(), while
|
||
scsi_remove_host() pairs with scsi_add_host(). In other words, it seems the
|
||
reason for removing the proc directory on dev_release() was meant to cover
|
||
cases in which a SCSI host structure was allocated, but the call to
|
||
scsi_add_host() didn't happen. And that pattern happens to exist in some
|
||
error paths, for example.
|
||
|
||
Syzkaller causes that by using USB raw gadget device, error'ing on
|
||
usb-storage driver, at usb_stor_probe2(). By checking that path, we can see
|
||
that the BadDevice label leads to a scsi_host_put() after a SCSI host
|
||
allocation, but there's no call to scsi_add_host() in such path. That leads
|
||
to messages like this in dmesg (and a leak of the SCSI host proc
|
||
structure):
|
||
|
||
usb-storage 4-1:87.51: USB Mass Storage device detected
|
||
proc_dir_entry 'scsi/usb-storage' already registered
|
||
WARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376
|
||
|
||
The proper fix seems to still call scsi_proc_hostdir_rm() on dev_release(),
|
||
but guard that with the state check for SHOST_CREATED; there is even a
|
||
comment in scsi_host_dev_release() detailing that: such conditional is
|
||
meant for cases where the SCSI host was allocated but there was no calls to
|
||
{add,remove}_host(), like the usb-storage case.
|
||
|
||
This is what we propose here and with that, the error path of usb-storage
|
||
does not trigger the warning anymore.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-26935</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.3</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
ksmbd: validate request buffer size in smb2_allocate_rsp_buf()
|
||
|
||
The response buffer should be allocated in smb2_allocate_rsp_buf
|
||
before validating request. But the fields in payload as well as smb2 header
|
||
is used in smb2_allocate_rsp_buf(). This patch add simple buffer size
|
||
validation to avoid potencial out-of-bounds in request buffer.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-26936</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-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
ARM: 9359/1: flush: check if the folio is reserved for no-mapping addresses
|
||
|
||
Since commit a4d5613c4dc6 ("arm: extend pfn_valid to take into account
|
||
freed memory map alignment") changes the semantics of pfn_valid() to check
|
||
presence of the memory map for a PFN. A valid page for an address which
|
||
is reserved but not mapped by the kernel[1], the system crashed during
|
||
some uio test with the following memory layout:
|
||
|
||
node 0: [mem 0x00000000c0a00000-0x00000000cc8fffff]
|
||
node 0: [mem 0x00000000d0000000-0x00000000da1fffff]
|
||
the uio layout is：0xc0900000, 0x100000
|
||
|
||
the crash backtrace like:
|
||
|
||
Unable to handle kernel paging request at virtual address bff00000
|
||
[...]
|
||
CPU: 1 PID: 465 Comm: startapp.bin Tainted: G O 5.10.0 #1
|
||
Hardware name: Generic DT based system
|
||
PC is at b15_flush_kern_dcache_area+0x24/0x3c
|
||
LR is at __sync_icache_dcache+0x6c/0x98
|
||
[...]
|
||
(b15_flush_kern_dcache_area) from (__sync_icache_dcache+0x6c/0x98)
|
||
(__sync_icache_dcache) from (set_pte_at+0x28/0x54)
|
||
(set_pte_at) from (remap_pfn_range+0x1a0/0x274)
|
||
(remap_pfn_range) from (uio_mmap+0x184/0x1b8 [uio])
|
||
(uio_mmap [uio]) from (__mmap_region+0x264/0x5f4)
|
||
(__mmap_region) from (__do_mmap_mm+0x3ec/0x440)
|
||
(__do_mmap_mm) from (do_mmap+0x50/0x58)
|
||
(do_mmap) from (vm_mmap_pgoff+0xfc/0x188)
|
||
(vm_mmap_pgoff) from (ksys_mmap_pgoff+0xac/0xc4)
|
||
(ksys_mmap_pgoff) from (ret_fast_syscall+0x0/0x5c)
|
||
Code: e0801001 e2423001 e1c00003 f57ff04f (ee070f3e)
|
||
---[ end trace 09cf0734c3805d52 ]---
|
||
Kernel panic - not syncing: Fatal exception
|
||
|
||
So check if PG_reserved was set to solve this issue.
|
||
|
||
[1]: https://lore.kernel.org/lkml/Zbtdue57RO0QScJM@linux.ibm.com/</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-26947</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-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
ksmbd: fix slab-out-of-bounds in smb_strndup_from_utf16()
|
||
|
||
If ->NameOffset of smb2_create_req is smaller than Buffer offset of
|
||
smb2_create_req, slab-out-of-bounds read can happen from smb2_open.
|
||
This patch set the minimum value of the name offset to the buffer offset
|
||
to validate name length of smb2_create_req().</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-26954</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-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
mm: swap: fix race between free_swap_and_cache() and swapoff()
|
||
|
||
There was previously a theoretical window where swapoff() could run and
|
||
teardown a swap_info_struct while a call to free_swap_and_cache() was
|
||
running in another thread. This could cause, amongst other bad
|
||
possibilities, swap_page_trans_huge_swapped() (called by
|
||
free_swap_and_cache()) to access the freed memory for swap_map.
|
||
|
||
This is a theoretical problem and I haven't been able to provoke it from a
|
||
test case. But there has been agreement based on code review that this is
|
||
possible (see link below).
|
||
|
||
Fix it by using get_swap_device()/put_swap_device(), which will stall
|
||
swapoff(). There was an extra check in _swap_info_get() to confirm that
|
||
the swap entry was not free. This isn't present in get_swap_device()
|
||
because it doesn't make sense in general due to the race between getting
|
||
the reference and swapoff. So I've added an equivalent check directly in
|
||
free_swap_and_cache().
|
||
|
||
Details of how to provoke one possible issue (thanks to David Hildenbrand
|
||
for deriving this):
|
||
|
||
--8<-----
|
||
|
||
__swap_entry_free() might be the last user and result in
|
||
"count == SWAP_HAS_CACHE".
|
||
|
||
swapoff->try_to_unuse() will stop as soon as soon as si->inuse_pages==0.
|
||
|
||
So the question is: could someone reclaim the folio and turn
|
||
si->inuse_pages==0, before we completed swap_page_trans_huge_swapped().
|
||
|
||
Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages are
|
||
still references by swap entries.
|
||
|
||
Process 1 still references subpage 0 via swap entry.
|
||
Process 2 still references subpage 1 via swap entry.
|
||
|
||
Process 1 quits. Calls free_swap_and_cache().
|
||
-> count == SWAP_HAS_CACHE
|
||
[then, preempted in the hypervisor etc.]
|
||
|
||
Process 2 quits. Calls free_swap_and_cache().
|
||
-> count == SWAP_HAS_CACHE
|
||
|
||
Process 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls
|
||
__try_to_reclaim_swap().
|
||
|
||
__try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()->
|
||
put_swap_folio()->free_swap_slot()->swapcache_free_entries()->
|
||
swap_entry_free()->swap_range_free()->
|
||
...
|
||
WRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries);
|
||
|
||
What stops swapoff to succeed after process 2 reclaimed the swap cache
|
||
but before process1 finished its call to swap_page_trans_huge_swapped()?
|
||
|
||
--8<-----</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-26960</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></Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:net/mlx5e: Prevent deadlock while disabling aRFSWhen disabling aRFS under the `priv->state_lock`, any scheduledaRFS works are canceled using the `cancel_work_sync` function,which waits for the work to end if it has already started.However, while waiting for the work handler, the handler willtry to acquire the `state_lock` which is already acquired.The worker acquires the lock to delete the rules if the stateis down, which is not the worker s responsibility sincedisabling aRFS deletes the rules.Add an aRFS state variable, which indicates whether the aRFS isenabled and prevent adding rules when the aRFS is disabled.Kernel log:======================================================WARNING: possible circular locking dependency detected6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G I------------------------------------------------------ethtool/386089 is trying to acquire lock:ffff88810f21ce68 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0but task is already holding lock:ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]which lock already depends on the new lock.the existing dependency chain (in reverse order) is:-> #1 (&priv->state_lock){+.+.}-{3:3}: __mutex_lock+0x80/0xc90 arfs_handle_work+0x4b/0x3b0 [mlx5_core] process_one_work+0x1dc/0x4a0 worker_thread+0x1bf/0x3c0 kthread+0xd7/0x100 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20-> #0 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}: __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 __flush_work+0x7a/0x4e0 __cancel_work_timer+0x131/0x1c0 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1a1/0x270 netlink_sendmsg+0x214/0x460 __sock_sendmsg+0x38/0x60 __sys_sendto+0x113/0x170 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x46/0x4eother info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); *** DEADLOCK ***3 locks held by ethtool/386089: #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40 #1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240 #2: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]stack backtrace:CPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4_net_next_mlx5_5483eb2 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014Call Trace: <TASK> dump_stack_lvl+0x60/0xa0 check_noncircular+0x144/0x160 __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 ? __flush_work+0x74/0x4e0 ? save_trace+0x3e/0x360 ? __flush_work+0x74/0x4e0 __flush_work+0x7a/0x4e0 ? __flush_work+0x74/0x4e0 ? __lock_acquire+0xa78/0x2c80 ? lock_acquire+0xd0/0x2b0 ? mark_held_locks+0x49/0x70 __cancel_work_timer+0x131/0x1c0 ? mark_held_locks+0x49/0x70 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 ? ethn---truncated---</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-27014</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-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
netfilter: nft_set_pipapo: walk over current view on netlink dump
|
||
|
||
The generation mask can be updated while netlink dump is in progress.
|
||
The pipapo set backend walk iterator cannot rely on it to infer what
|
||
view of the datastructure is to be used. Add notation to specify if user
|
||
wants to read/update the set.
|
||
|
||
Based on patch from Florian Westphal.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-27017</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:H/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()nft_unregister_obj() can concurrent with __nft_obj_type_get(),and there is not any protection when iterate over nf_tables_objectslist in __nft_obj_type_get(). Therefore, there is potential data-raceof nf_tables_objects list entry.Use list_for_each_entry_rcu() to iterate over nf_tables_objectslist in __nft_obj_type_get(), and use rcu_read_lock() in the callernft_obj_type_get() to protect the entire type query process.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-27019</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:H/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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/amd/display: Fix potential NULL pointer dereferences in 'dcn10_set_output_transfer_func()'
|
||
|
||
The 'stream' pointer is used in dcn10_set_output_transfer_func() before
|
||
the check if 'stream' is NULL.
|
||
|
||
Fixes the below:
|
||
drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn10/dcn10_hwseq.c:1892 dcn10_set_output_transfer_func() warn: variable dereferenced before check 'stream' (see line 1875)</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-27044</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-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
net: ll_temac: platform_get_resource replaced by wrong function
|
||
|
||
The function platform_get_resource was replaced with
|
||
devm_platform_ioremap_resource_byname and is called using 0 as name.
|
||
|
||
This eventually ends up in platform_get_resource_byname in the call
|
||
stack, where it causes a null pointer in strcmp.
|
||
|
||
if (type == resource_type(r) && !strcmp(r->name, name))
|
||
|
||
It should have been replaced with devm_platform_ioremap_resource.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-35796</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.0</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
soc: fsl: qbman: Use raw spinlock for cgr_lock
|
||
|
||
smp_call_function always runs its callback in hard IRQ context, even on
|
||
PREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlock
|
||
for cgr_lock to ensure we aren't waiting on a sleeping task.
|
||
|
||
Although this bug has existed for a while, it was not apparent until
|
||
commit ef2a8d5478b9 ("net: dpaa: Adjust queue depth on rate change")
|
||
which invokes smp_call_function_single via qman_update_cgr_safe every
|
||
time a link goes up or down.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-35819</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
ubifs: Set page uptodate in the correct place
|
||
|
||
Page cache reads are lockless, so setting the freshly allocated page
|
||
uptodate before we've overwritten it with the data it's supposed to have
|
||
in it will allow a simultaneous reader to see old data. Move the call
|
||
to SetPageUptodate into ubifs_write_end(), which is after we copied the
|
||
new data into the page.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-35821</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
wifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer()
|
||
|
||
In the for statement of lbs_allocate_cmd_buffer(), if the allocation of
|
||
cmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to
|
||
be freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer().</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-35828</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-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
smb: client: fix UAF in smb2_reconnect_server()
|
||
|
||
The UAF bug is due to smb2_reconnect_server() accessing a session that
|
||
is already being teared down by another thread that is executing
|
||
__cifs_put_smb_ses(). This can happen when (a) the client has
|
||
connection to the server but no session or (b) another thread ends up
|
||
setting @ses->ses_status again to something different than
|
||
SES_EXITING.
|
||
|
||
To fix this, we need to make sure to unconditionally set
|
||
@ses->ses_status to SES_EXITING and prevent any other threads from
|
||
setting a new status while we're still tearing it down.
|
||
|
||
The following can be reproduced by adding some delay to right after
|
||
the ipc is freed in __cifs_put_smb_ses() - which will give
|
||
smb2_reconnect_server() worker a chance to run and then accessing
|
||
@ses->ipc:
|
||
|
||
kinit ...
|
||
mount.cifs //srv/share /mnt/1 -o sec=krb5,nohandlecache,echo_interval=10
|
||
[disconnect srv]
|
||
ls /mnt/1 &>/dev/null
|
||
sleep 30
|
||
kdestroy
|
||
[reconnect srv]
|
||
sleep 10
|
||
umount /mnt/1
|
||
...
|
||
CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed
|
||
CIFS: VFS: \\srv Send error in SessSetup = -126
|
||
CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed
|
||
CIFS: VFS: \\srv Send error in SessSetup = -126
|
||
general protection fault, probably for non-canonical address
|
||
0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI
|
||
CPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc2 #1
|
||
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39
|
||
04/01/2014
|
||
Workqueue: cifsiod smb2_reconnect_server [cifs]
|
||
RIP: 0010:__list_del_entry_valid_or_report+0x33/0xf0
|
||
Code: 4f 08 48 85 d2 74 42 48 85 c9 74 59 48 b8 00 01 00 00 00 00 ad
|
||
de 48 39 c2 74 61 48 b8 22 01 00 00 00 00 74 69 <48> 8b 01 48 39 f8 75
|
||
7b 48 8b 72 08 48 39 c6 0f 85 88 00 00 00 b8
|
||
RSP: 0018:ffffc900001bfd70 EFLAGS: 00010a83
|
||
RAX: dead000000000122 RBX: ffff88810da53838 RCX: 6b6b6b6b6b6b6b6b
|
||
RDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc02f6878 RDI: ffff88810da53800
|
||
RBP: ffff88810da53800 R08: 0000000000000001 R09: 0000000000000000
|
||
R10: 0000000000000000 R11: 0000000000000001 R12: ffff88810c064000
|
||
R13: 0000000000000001 R14: ffff88810c064000 R15: ffff8881039cc000
|
||
FS: 0000000000000000(0000) GS:ffff888157c00000(0000)
|
||
knlGS:0000000000000000
|
||
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
||
CR2: 00007fe3728b1000 CR3: 000000010caa4000 CR4: 0000000000750ef0
|
||
PKRU: 55555554
|
||
Call Trace:
|
||
<TASK>
|
||
? die_addr+0x36/0x90
|
||
? exc_general_protection+0x1c1/0x3f0
|
||
? asm_exc_general_protection+0x26/0x30
|
||
? __list_del_entry_valid_or_report+0x33/0xf0
|
||
__cifs_put_smb_ses+0x1ae/0x500 [cifs]
|
||
smb2_reconnect_server+0x4ed/0x710 [cifs]
|
||
process_one_work+0x205/0x6b0
|
||
worker_thread+0x191/0x360
|
||
? __pfx_worker_thread+0x10/0x10
|
||
kthread+0xe2/0x110
|
||
? __pfx_kthread+0x10/0x10
|
||
ret_from_fork+0x34/0x50
|
||
? __pfx_kthread+0x10/0x10
|
||
ret_from_fork_asm+0x1a/0x30
|
||
</TASK></Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-35870</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-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
ax25: fix use-after-free bugs caused by ax25_ds_del_timer
|
||
|
||
When the ax25 device is detaching, the ax25_dev_device_down()
|
||
calls ax25_ds_del_timer() to cleanup the slave_timer. When
|
||
the timer handler is running, the ax25_ds_del_timer() that
|
||
calls del_timer() in it will return directly. As a result,
|
||
the use-after-free bugs could happen, one of the scenarios
|
||
is shown below:
|
||
|
||
(Thread 1) | (Thread 2)
|
||
| ax25_ds_timeout()
|
||
ax25_dev_device_down() |
|
||
ax25_ds_del_timer() |
|
||
del_timer() |
|
||
ax25_dev_put() //FREE |
|
||
| ax25_dev-> //USE
|
||
|
||
In order to mitigate bugs, when the device is detaching, use
|
||
timer_shutdown_sync() to stop the timer.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-35887</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
tcp: properly terminate timers for kernel sockets
|
||
|
||
We had various syzbot reports about tcp timers firing after
|
||
the corresponding netns has been dismantled.
|
||
|
||
Fortunately Josef Bacik could trigger the issue more often,
|
||
and could test a patch I wrote two years ago.
|
||
|
||
When TCP sockets are closed, we call inet_csk_clear_xmit_timers()
|
||
to 'stop' the timers.
|
||
|
||
inet_csk_clear_xmit_timers() can be called from any context,
|
||
including when socket lock is held.
|
||
This is the reason it uses sk_stop_timer(), aka del_timer().
|
||
This means that ongoing timers might finish much later.
|
||
|
||
For user sockets, this is fine because each running timer
|
||
holds a reference on the socket, and the user socket holds
|
||
a reference on the netns.
|
||
|
||
For kernel sockets, we risk that the netns is freed before
|
||
timer can complete, because kernel sockets do not hold
|
||
reference on the netns.
|
||
|
||
This patch adds inet_csk_clear_xmit_timers_sync() function
|
||
that using sk_stop_timer_sync() to make sure all timers
|
||
are terminated before the kernel socket is released.
|
||
Modules using kernel sockets close them in their netns exit()
|
||
handler.
|
||
|
||
Also add sock_not_owned_by_me() helper to get LOCKDEP
|
||
support : inet_csk_clear_xmit_timers_sync() must not be called
|
||
while socket lock is held.
|
||
|
||
It is very possible we can revert in the future commit
|
||
3a58f13a881e ("net: rds: acquire refcount on TCP sockets")
|
||
which attempted to solve the issue in rds only.
|
||
(net/smc/af_smc.c and net/mptcp/subflow.c have similar code)
|
||
|
||
We probably can remove the check_net() tests from
|
||
tcp_out_of_resources() and __tcp_close() in the future.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-35910</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.8</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet
|
||
|
||
syzbot reported the following uninit-value access issue [1][2]:
|
||
|
||
nci_rx_work() parses and processes received packet. When the payload
|
||
length is zero, each message type handler reads uninitialized payload
|
||
and KMSAN detects this issue. The receipt of a packet with a zero-size
|
||
payload is considered unexpected, and therefore, such packets should be
|
||
silently discarded.
|
||
|
||
This patch resolved this issue by checking payload size before calling
|
||
each message type handler codes.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-35915</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>0.0</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
drm/vc4: don't check if plane->state->fb == state->fb
|
||
|
||
Currently, when using non-blocking commits, we can see the following
|
||
kernel warning:
|
||
|
||
[ 110.908514] ------------[ cut here ]------------
|
||
[ 110.908529] refcount_t: underflow; use-after-free.
|
||
[ 110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87 refcount_dec_not_one+0xb8/0xc0
|
||
[ 110.908664] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash aes_arm64 aes_generic algif_skcipher af_alg bnep hid_logitech_hidpp vc4 brcmfmac hci_uart btbcm brcmutil bluetooth snd_soc_hdmi_codec cfg80211 cec drm_display_helper drm_dma_helper drm_kms_helper snd_soc_core snd_compress snd_pcm_dmaengine fb_sys_fops sysimgblt syscopyarea sysfillrect raspberrypi_hwmon ecdh_generic ecc rfkill libaes i2c_bcm2835 binfmt_misc joydev snd_bcm2835(C) bcm2835_codec(C) bcm2835_isp(C) v4l2_mem2mem videobuf2_dma_contig snd_pcm bcm2835_v4l2(C) raspberrypi_gpiomem bcm2835_mmal_vchiq(C) videobuf2_v4l2 snd_timer videobuf2_vmalloc videobuf2_memops videobuf2_common snd videodev vc_sm_cma(C) mc hid_logitech_dj uio_pdrv_genirq uio i2c_dev drm fuse dm_mod drm_panel_orientation_quirks backlight ip_tables x_tables ipv6
|
||
[ 110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Tainted: G C 6.1.66-v8+ #32
|
||
[ 110.909104] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)
|
||
[ 110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
||
[ 110.909132] pc : refcount_dec_not_one+0xb8/0xc0
|
||
[ 110.909152] lr : refcount_dec_not_one+0xb4/0xc0
|
||
[ 110.909170] sp : ffffffc00913b9c0
|
||
[ 110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60
|
||
[ 110.909205] x26: 0000000000000002 x25: 0000000000000004 x24: ffffff8004448480
|
||
[ 110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: ffffffecfca68c78
|
||
[ 110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000
|
||
[ 110.909283] x17: 0000000000000011 x16: ffffffffffffffff x15: 0000000000000004
|
||
[ 110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003
|
||
[ 110.909333] x11: 0000000000000000 x10: 0000000000000027 x9 : c912d0d083728c00
|
||
[ 110.909359] x8 : c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572
|
||
[ 110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 0000000000000000
|
||
[ 110.909409] x2 : 0000000000000000 x1 : ffffffc00913b750 x0 : 0000000000000001
|
||
[ 110.909434] Call trace:
|
||
[ 110.909441] refcount_dec_not_one+0xb8/0xc0
|
||
[ 110.909461] vc4_bo_dec_usecnt+0x4c/0x1b0 [vc4]
|
||
[ 110.909903] vc4_cleanup_fb+0x44/0x50 [vc4]
|
||
[ 110.910315] drm_atomic_helper_cleanup_planes+0x88/0xa4 [drm_kms_helper]
|
||
[ 110.910669] vc4_atomic_commit_tail+0x390/0x9dc [vc4]
|
||
[ 110.911079] commit_tail+0xb0/0x164 [drm_kms_helper]
|
||
[ 110.911397] drm_atomic_helper_commit+0x1d0/0x1f0 [drm_kms_helper]
|
||
[ 110.911716] drm_atomic_commit+0xb0/0xdc [drm]
|
||
[ 110.912569] drm_mode_atomic_ioctl+0x348/0x4b8 [drm]
|
||
[ 110.913330] drm_ioctl_kernel+0xec/0x15c [drm]
|
||
[ 110.914091] drm_ioctl+0x24c/0x3b0 [drm]
|
||
[ 110.914850] __arm64_sys_ioctl+0x9c/0xd4
|
||
[ 110.914873] invoke_syscall+0x4c/0x114
|
||
[ 110.914897] el0_svc_common+0xd0/0x118
|
||
[ 110.914917] do_el0_svc+0x38/0xd0
|
||
[ 110.914936] el0_svc+0x30/0x8c
|
||
[ 110.914958] el0t_64_sync_handler+0x84/0xf0
|
||
[ 110.914979] el0t_64_sync+0x18c/0x190
|
||
[ 110.914996] ---[ end trace 0000000000000000 ]---
|
||
|
||
This happens because, although `prepare_fb` and `cleanup_fb` are
|
||
perfectly balanced, we cannot guarantee consistency in the check
|
||
plane->state->fb == state->fb. This means that sometimes we can increase
|
||
the refcount in `prepare_fb` and don't decrease it in `cleanup_fb`. The
|
||
opposite can also be true.
|
||
|
||
In fact, the struct drm_plane .state shouldn't be accessed directly
|
||
but instead, the `drm_atomic_get_new_plane_state()` helper function should
|
||
be used. So, we could stick to this check, but using
|
||
`drm_atomic_get_new_plane_state()`. But actually, this check is not re
|
||
---truncated---</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-35932</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-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
btrfs: send: handle path ref underflow in header iterate_inode_ref()
|
||
|
||
Change BUG_ON to proper error handling if building the path buffer
|
||
fails. The pointers are not printed so we don't accidentally leak kernel
|
||
addresses.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-35935</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-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
wifi: cfg80211: check A-MSDU format more carefully
|
||
|
||
If it looks like there's another subframe in the A-MSDU
|
||
but the header isn't fully there, we can end up reading
|
||
data out of bounds, only to discard later. Make this a
|
||
bit more careful and check if the subframe header can
|
||
even be present.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-35937</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.3</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()
|
||
|
||
Subject: [PATCH] drm/panfrost: Fix the error path in
|
||
panfrost_mmu_map_fault_addr()
|
||
|
||
If some the pages or sgt allocation failed, we shouldn't release the
|
||
pages ref we got earlier, otherwise we will end up with unbalanced
|
||
get/put_pages() calls. We should instead leave everything in place
|
||
and let the BO release function deal with extra cleanup when the object
|
||
is destroyed, or let the fault handler try again next time it's called.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-35951</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-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
Bluetooth: L2CAP: Fix not validating setsockopt user input
|
||
|
||
Check user input length before copying data.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-35965</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
Bluetooth: RFCOMM: Fix not validating setsockopt user input
|
||
|
||
syzbot reported rfcomm_sock_setsockopt_old() is copying data without
|
||
checking user input length.
|
||
|
||
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset
|
||
include/linux/sockptr.h:49 [inline]
|
||
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr
|
||
include/linux/sockptr.h:55 [inline]
|
||
BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old
|
||
net/bluetooth/rfcomm/sock.c:632 [inline]
|
||
BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70
|
||
net/bluetooth/rfcomm/sock.c:673
|
||
Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-35966</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
tty: n_gsm: fix possible out-of-bounds in gsm0_receive()
|
||
|
||
Assuming the following:
|
||
- side A configures the n_gsm in basic option mode
|
||
- side B sends the header of a basic option mode frame with data length 1
|
||
- side A switches to advanced option mode
|
||
- side B sends 2 data bytes which exceeds gsm->len
|
||
Reason: gsm->len is not used in advanced option mode.
|
||
- side A switches to basic option mode
|
||
- side B keeps sending until gsm0_receive() writes past gsm->buf
|
||
Reason: Neither gsm->state nor gsm->len have been reset after
|
||
reconfiguration.
|
||
|
||
Fix this by changing gsm->count to gsm->len comparison from equal to less
|
||
than. Also add upper limit checks against the constant MAX_MRU in
|
||
gsm0_receive() and gsm1_receive() to harden against memory corruption of
|
||
gsm->len and gsm->mru.
|
||
|
||
All other checks remain as we still need to limit the data according to the
|
||
user configuration and actual payload size.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-36016</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets
|
||
|
||
TCP_SYN_RECV state is really special, it is only used by
|
||
cross-syn connections, mostly used by fuzzers.
|
||
|
||
In the following crash [1], syzbot managed to trigger a divide
|
||
by zero in tcp_rcv_space_adjust()
|
||
|
||
A socket makes the following state transitions,
|
||
without ever calling tcp_init_transfer(),
|
||
meaning tcp_init_buffer_space() is also not called.
|
||
|
||
TCP_CLOSE
|
||
connect()
|
||
TCP_SYN_SENT
|
||
TCP_SYN_RECV
|
||
shutdown() -> tcp_shutdown(sk, SEND_SHUTDOWN)
|
||
TCP_FIN_WAIT1
|
||
|
||
To fix this issue, change tcp_shutdown() to not
|
||
perform a TCP_SYN_RECV -> TCP_FIN_WAIT1 transition,
|
||
which makes no sense anyway.
|
||
|
||
When tcp_rcv_state_process() later changes socket state
|
||
from TCP_SYN_RECV to TCP_ESTABLISH, then look at
|
||
sk->sk_shutdown to finally enter TCP_FIN_WAIT1 state,
|
||
and send a FIN packet from a sane socket state.
|
||
|
||
This means tcp_send_fin() can now be called from BH
|
||
context, and must use GFP_ATOMIC allocations.
|
||
|
||
[1]
|
||
divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI
|
||
CPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0
|
||
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
|
||
RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767
|
||
Code: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 <48> f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48
|
||
RSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246
|
||
RAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000
|
||
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
|
||
RBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7
|
||
R10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30
|
||
R13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da
|
||
FS: 00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
|
||
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
||
CR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0
|
||
Call Trace:
|
||
<TASK>
|
||
tcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513
|
||
tcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578
|
||
inet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680
|
||
sock_recvmsg_nosec net/socket.c:1046 [inline]
|
||
sock_recvmsg+0x109/0x280 net/socket.c:1068
|
||
____sys_recvmsg+0x1db/0x470 net/socket.c:2803
|
||
___sys_recvmsg net/socket.c:2845 [inline]
|
||
do_recvmmsg+0x474/0xae0 net/socket.c:2939
|
||
__sys_recvmmsg net/socket.c:3018 [inline]
|
||
__do_sys_recvmmsg net/socket.c:3041 [inline]
|
||
__se_sys_recvmmsg net/socket.c:3034 [inline]
|
||
__x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034
|
||
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
||
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
|
||
entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
||
RIP: 0033:0x7faeb6363db9
|
||
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
|
||
RSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b
|
||
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9
|
||
RDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005
|
||
RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c
|
||
R10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000
|
||
R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-36905</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
blk-iocost: avoid out of bounds shift
|
||
|
||
UBSAN catches undefined behavior in blk-iocost, where sometimes
|
||
iocg->delay is shifted right by a number that is too large,
|
||
resulting in undefined behavior on some architectures.
|
||
|
||
[ 186.556576] ------------[ cut here ]------------
|
||
UBSAN: shift-out-of-bounds in block/blk-iocost.c:1366:23
|
||
shift exponent 64 is too large for 64-bit type 'u64' (aka 'unsigned long long')
|
||
CPU: 16 PID: 0 Comm: swapper/16 Tainted: G S E N 6.9.0-0_fbk700_debug_rc2_kbuilder_0_gc85af715cac0 #1
|
||
Hardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F09_3A23 12/08/2020
|
||
Call Trace:
|
||
<IRQ>
|
||
dump_stack_lvl+0x8f/0xe0
|
||
__ubsan_handle_shift_out_of_bounds+0x22c/0x280
|
||
iocg_kick_delay+0x30b/0x310
|
||
ioc_timer_fn+0x2fb/0x1f80
|
||
__run_timer_base+0x1b6/0x250
|
||
...
|
||
|
||
Avoid that undefined behavior by simply taking the
|
||
"delay = 0" branch if the shift is too large.
|
||
|
||
I am not sure what the symptoms of an undefined value
|
||
delay will be, but I suspect it could be more than a
|
||
little annoying to debug.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-36916</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
scsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload
|
||
|
||
The session resources are used by FW and driver when session is offloaded,
|
||
once session is uploaded these resources are not used. The lock is not
|
||
required as these fields won't be used any longer. The offload and upload
|
||
calls are sequential, hence lock is not required.
|
||
|
||
This will suppress following BUG_ON():
|
||
|
||
[ 449.843143] ------------[ cut here ]------------
|
||
[ 449.848302] kernel BUG at mm/vmalloc.c:2727!
|
||
[ 449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI
|
||
[ 449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x86_64 #1
|
||
Rebooting.
|
||
[ 449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016
|
||
[ 449.876966] Workqueue: fc_rport_eq fc_rport_work [libfc]
|
||
[ 449.882910] RIP: 0010:vunmap+0x2e/0x30
|
||
[ 449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 <0f> 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41
|
||
[ 449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206
|
||
[ 449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005
|
||
[ 449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000
|
||
[ 449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf
|
||
[ 449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000
|
||
[ 449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0
|
||
[ 449.953701] FS: 0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000
|
||
[ 449.962732] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
||
[ 449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0
|
||
[ 449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
||
[ 449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
||
[ 449.993028] Call Trace:
|
||
[ 449.995756] __iommu_dma_free+0x96/0x100
|
||
[ 450.000139] bnx2fc_free_session_resc+0x67/0x240 [bnx2fc]
|
||
[ 450.006171] bnx2fc_upload_session+0xce/0x100 [bnx2fc]
|
||
[ 450.011910] bnx2fc_rport_event_handler+0x9f/0x240 [bnx2fc]
|
||
[ 450.018136] fc_rport_work+0x103/0x5b0 [libfc]
|
||
[ 450.023103] process_one_work+0x1e8/0x3c0
|
||
[ 450.027581] worker_thread+0x50/0x3b0
|
||
[ 450.031669] ? rescuer_thread+0x370/0x370
|
||
[ 450.036143] kthread+0x149/0x170
|
||
[ 450.039744] ? set_kthread_struct+0x40/0x40
|
||
[ 450.044411] ret_from_fork+0x22/0x30
|
||
[ 450.048404] Modules linked in: vfat msdos fat xfs nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver dm_service_time qedf qed crc8 bnx2fc libfcoe libfc scsi_transport_fc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp dcdbas rapl intel_cstate intel_uncore mei_me pcspkr mei ipmi_ssif lpc_ich ipmi_si fuse zram ext4 mbcache jbd2 loop nfsv3 nfs_acl nfs lockd grace fscache netfs irdma ice sd_mod t10_pi sg ib_uverbs ib_core 8021q garp mrp stp llc mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi fb_sys_fops cec crct10dif_pclmul ahci crc32_pclmul bnx2x drm ghash_clmulni_intel libahci rfkill i40e libata megaraid_sas mdio wmi sunrpc lrw dm_crypt dm_round_robin dm_multipath dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_zero dm_mod linear raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid6_pq libcrc32c crc32c_intel raid1 raid0 iscsi_ibft squashfs be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls
|
||
[ 450.048497] libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi edd ipmi_devintf ipmi_msghandler
|
||
[ 450.159753] ---[ end trace 712de2c57c64abc8 ]---</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-36919</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
scsi: lpfc: Move NPIV's transport unregistration to after resource clean up
|
||
|
||
There are cases after NPIV deletion where the fabric switch still believes
|
||
the NPIV is logged into the fabric. This occurs when a vport is
|
||
unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the
|
||
fabric.
|
||
|
||
Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including
|
||
the fabric D_ID, removes the last ndlp reference and frees the ndlp rport
|
||
object. This sometimes causes the race condition where the final DA_ID and
|
||
LOGO are skipped from being sent to the fabric switch.
|
||
|
||
Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID
|
||
and LOGO are sent.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-36952</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:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
drm/vmwgfx: Fix invalid reads in fence signaled events
|
||
|
||
Correctly set the length of the drm_event to the size of the structure
|
||
that's actually used.
|
||
|
||
The length of the drm_event was set to the parent structure instead of
|
||
to the drm_vmw_event_fence which is supposed to be read. drm_read
|
||
uses the length parameter to copy the event to the user space thus
|
||
resuling in oob reads.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-36960</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.1</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</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:
|
||
|
||
Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()
|
||
|
||
l2cap_le_flowctl_init() can cause both div-by-zero and an integer
|
||
overflow since hdev->le_mtu may not fall in the valid range.
|
||
|
||
Move MTU from hci_dev to hci_conn to validate MTU and stop the connection
|
||
process earlier if MTU is invalid.
|
||
Also, add a missing validation in read_buffer_size() and make it return
|
||
an error value if the validation fails.
|
||
Now hci_conn_add() returns ERR_PTR() as it can fail due to the both a
|
||
kzalloc failure and invalid MTU value.
|
||
|
||
divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI
|
||
CPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G W 6.9.0-rc5+ #20
|
||
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
|
||
Workqueue: hci0 hci_rx_work
|
||
RIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547
|
||
Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c
|
||
89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 <66> f7 f3 89 c3 ff c3 4d 8d
|
||
b7 88 00 00 00 4c 89 f0 48 c1 e8 03 42
|
||
RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246
|
||
RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000
|
||
RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f
|
||
RBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa
|
||
R10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084
|
||
R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000
|
||
FS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000
|
||
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
||
CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0
|
||
PKRU: 55555554
|
||
Call Trace:
|
||
<TASK>
|
||
l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline]
|
||
l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline]
|
||
l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline]
|
||
l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809
|
||
l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506
|
||
hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline]
|
||
hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176
|
||
process_one_work kernel/workqueue.c:3254 [inline]
|
||
process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335
|
||
worker_thread+0x926/0xe70 kernel/workqueue.c:3416
|
||
kthread+0x2e3/0x380 kernel/kthread.c:388
|
||
ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147
|
||
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
|
||
</TASK>
|
||
Modules linked in:
|
||
---[ end trace 0000000000000000 ]---</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-36968</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:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="42" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
||
<Notes>
|
||
<Note Title="Vulnerability Description" Type="General" Ordinal="42" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
net: fix __dst_negative_advice() race
|
||
|
||
__dst_negative_advice() does not enforce proper RCU rules when
|
||
sk->dst_cache must be cleared, leading to possible UAF.
|
||
|
||
RCU rules are that we must first clear sk->sk_dst_cache,
|
||
then call dst_release(old_dst).
|
||
|
||
Note that sk_dst_reset(sk) is implementing this protocol correctly,
|
||
while __dst_negative_advice() uses the wrong order.
|
||
|
||
Given that ip6_negative_advice() has special logic
|
||
against RTF_CACHE, this means each of the three ->negative_advice()
|
||
existing methods must perform the sk_dst_reset() themselves.
|
||
|
||
Note the check against NULL dst is centralized in
|
||
__dst_negative_advice(), there is no need to duplicate
|
||
it in various callbacks.
|
||
|
||
Many thanks to Clement Lecigne for tracking this issue.
|
||
|
||
This old bug became visible after the blamed commit, using UDP sockets.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-36971</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-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1738</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
</cvrfdoc> |