3740 lines
167 KiB
XML
3740 lines
167 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
||
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
|
||
<DocumentTitle xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP1</DocumentTitle>
|
||
<DocumentType>Security Advisory</DocumentType>
|
||
<DocumentPublisher Type="Vendor">
|
||
<ContactDetails>openeuler-security@openeuler.org</ContactDetails>
|
||
<IssuingAuthority>openEuler security committee</IssuingAuthority>
|
||
</DocumentPublisher>
|
||
<DocumentTracking>
|
||
<Identification>
|
||
<ID>openEuler-SA-2024-1737</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-SP1.</Note>
|
||
<Note Title="Description" Type="General" Ordinal="3" xml:lang="en">The Linux Kernel, the operating system core itself.
|
||
|
||
Security Fix(es):
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
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:
|
||
|
||
soc: brcmstb: pm-arm: Fix refcount leak and __iomem leak bugs
|
||
|
||
In brcmstb_pm_probe(), there are two kinds of leak bugs:
|
||
|
||
(1) we need to add of_node_put() when for_each__matching_node() breaks
|
||
(2) we need to add iounmap() for each iomap in fail path(CVE-2022-48693)
|
||
|
||
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:
|
||
|
||
pipe: wakeup wr_wait after setting max_usage
|
||
|
||
Commit c73be61cede5 ("pipe: Add general notification queue support") a
|
||
regression was introduced that would lock up resized pipes under certain
|
||
conditions. See the reproducer in [1].
|
||
|
||
The commit resizing the pipe ring size was moved to a different
|
||
function, doing that moved the wakeup for pipe->wr_wait before actually
|
||
raising pipe->max_usage. If a pipe was full before the resize occured it
|
||
would result in the wakeup never actually triggering pipe_write.
|
||
|
||
Set @max_usage and @nr_accounted before waking writers if this isn't a
|
||
watch queue.
|
||
|
||
[Christian Brauner <brauner@kernel.org>: rewrite to account for watch queues](CVE-2023-52672)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
ACPI: video: check for error while searching for backlight device parent
|
||
|
||
If acpi_get_parent() called in acpi_video_dev_register_backlight()
|
||
fails, for example, because acpi_ut_acquire_mutex() fails inside
|
||
acpi_get_parent), this can lead to incorrect (uninitialized)
|
||
acpi_parent handle being passed to acpi_get_pci_dev() for detecting
|
||
the parent pci device.
|
||
|
||
Check acpi_get_parent() result and set parent device only in case of success.
|
||
|
||
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52693)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
mmc: mmc_spi: fix error handling in mmc_spi_probe()
|
||
|
||
If mmc_add_host() fails, it doesn't need to call mmc_remove_host(),
|
||
or it will cause null-ptr-deref, because of deleting a not added
|
||
device in mmc_remove_host().
|
||
|
||
To fix this, goto label 'fail_glue_init', if mmc_add_host() fails,
|
||
and change the label 'fail_add_host' to 'fail_gpiod_request'.(CVE-2023-52708)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
ceph: blocklist the kclient when receiving corrupted snap trace
|
||
|
||
When received corrupted snap trace we don't know what exactly has
|
||
happened in MDS side. And we shouldn't continue IOs and metadatas
|
||
access to MDS, which may corrupt or get incorrect contents.
|
||
|
||
This patch will just block all the further IO/MDS requests
|
||
immediately and then evict the kclient itself.
|
||
|
||
The reason why we still need to evict the kclient just after
|
||
blocking all the further IOs is that the MDS could revoke the caps
|
||
faster.(CVE-2023-52732)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
Fix page corruption caused by racy check in __free_pages
|
||
|
||
When we upgraded our kernel, we started seeing some page corruption like
|
||
the following consistently:
|
||
|
||
BUG: Bad page state in process ganesha.nfsd pfn:1304ca
|
||
page:0000000022261c55 refcount:0 mapcount:-128 mapping:0000000000000000 index:0x0 pfn:0x1304ca
|
||
flags: 0x17ffffc0000000()
|
||
raw: 0017ffffc0000000 ffff8a513ffd4c98 ffffeee24b35ec08 0000000000000000
|
||
raw: 0000000000000000 0000000000000001 00000000ffffff7f 0000000000000000
|
||
page dumped because: nonzero mapcount
|
||
CPU: 0 PID: 15567 Comm: ganesha.nfsd Kdump: loaded Tainted: P B O 5.10.158-1.nutanix.20221209.el7.x86_64 #1
|
||
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/05/2016
|
||
Call Trace:
|
||
dump_stack+0x74/0x96
|
||
bad_page.cold+0x63/0x94
|
||
check_new_page_bad+0x6d/0x80
|
||
rmqueue+0x46e/0x970
|
||
get_page_from_freelist+0xcb/0x3f0
|
||
? _cond_resched+0x19/0x40
|
||
__alloc_pages_nodemask+0x164/0x300
|
||
alloc_pages_current+0x87/0xf0
|
||
skb_page_frag_refill+0x84/0x110
|
||
...
|
||
|
||
Sometimes, it would also show up as corruption in the free list pointer
|
||
and cause crashes.
|
||
|
||
After bisecting the issue, we found the issue started from commit
|
||
e320d3012d25 ("mm/page_alloc.c: fix freeing non-compound pages"):
|
||
|
||
if (put_page_testzero(page))
|
||
free_the_page(page, order);
|
||
else if (!PageHead(page))
|
||
while (order-- > 0)
|
||
free_the_page(page + (1 << order), order);
|
||
|
||
So the problem is the check PageHead is racy because at this point we
|
||
already dropped our reference to the page. So even if we came in with
|
||
compound page, the page can already be freed and PageHead can return
|
||
false and we will end up freeing all the tail pages causing double free.(CVE-2023-52739)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
IB/hfi1: Restore allocated resources on failed copyout
|
||
|
||
Fix a resource leak if an error occurs.(CVE-2023-52747)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
virtio-blk: fix implicit overflow on virtio_max_dma_size
|
||
|
||
The following codes have an implicit conversion from size_t to u32:
|
||
(u32)max_size = (size_t)virtio_max_dma_size(vdev);
|
||
|
||
This may lead overflow, Ex (size_t)4G -> (u32)0. Once
|
||
virtio_max_dma_size() has a larger size than U32_MAX, use U32_MAX
|
||
instead.(CVE-2023-52762)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
fs/jfs: Add check for negative db_l2nbperpage
|
||
|
||
l2nbperpage is log2(number of blks per page), and the minimum legal
|
||
value should be 0, not negative.
|
||
|
||
In the case of l2nbperpage being negative, an error will occur
|
||
when subsequently used as shift exponent.
|
||
|
||
Syzbot reported this bug:
|
||
|
||
UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:799:12
|
||
shift exponent -16777216 is negative(CVE-2023-52810)
|
||
|
||
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:
|
||
|
||
hsr: Prevent use after free in prp_create_tagged_frame()
|
||
|
||
The prp_fill_rct() function can fail. In that situation, it frees the
|
||
skb and returns NULL. Meanwhile on the success path, it returns the
|
||
original skb. So it's straight forward to fix bug by using the returned
|
||
value.(CVE-2023-52846)
|
||
|
||
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:
|
||
|
||
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: 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:
|
||
|
||
fs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversion
|
||
|
||
The first kiocb_set_cancel_fn() argument may point at a struct kiocb
|
||
that is not embedded inside struct aio_kiocb. With the current code,
|
||
depending on the compiler, the req->ki_ctx read happens either before
|
||
the IOCB_AIO_RW test or after that test. Move the req->ki_ctx read such
|
||
that it is guaranteed that the IOCB_AIO_RW test happens first.(CVE-2024-35815)
|
||
|
||
In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
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:
|
||
|
||
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:
|
||
|
||
netfilter: bridge: replace physindev with physinif in nf_bridge_info
|
||
|
||
An skb can be added to a neigh->arp_queue while waiting for an arp
|
||
reply. Where original skb's skb->dev can be different to neigh's
|
||
neigh->dev. For instance in case of bridging dnated skb from one veth to
|
||
another, the skb would be added to a neigh->arp_queue of the bridge.
|
||
|
||
As skb->dev can be reset back to nf_bridge->physindev and used, and as
|
||
there is no explicit mechanism that prevents this physindev from been
|
||
freed under us (for instance neigh_flush_dev doesn't cleanup skbs from
|
||
different device's neigh queue) we can crash on e.g. this stack:
|
||
|
||
arp_process
|
||
neigh_update
|
||
skb = __skb_dequeue(&neigh->arp_queue)
|
||
neigh_resolve_output(..., skb)
|
||
...
|
||
br_nf_dev_xmit
|
||
br_nf_pre_routing_finish_bridge_slow
|
||
skb->dev = nf_bridge->physindev
|
||
br_handle_frame_finish
|
||
|
||
Let's use plain ifindex instead of net_device link. To peek into the
|
||
original net_device we will use dev_get_by_index_rcu(). Thus either we
|
||
get device and are safe to use it or we don't get it and drop skb.(CVE-2024-35839)
|
||
|
||
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:
|
||
|
||
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:
|
||
|
||
batman-adv: Avoid infinite loop trying to resize local TT
|
||
|
||
If the MTU of one of an attached interface becomes too small to transmit
|
||
the local translation table then it must be resized to fit inside all
|
||
fragments (when enabled) or a single packet.
|
||
|
||
But if the MTU becomes too low to transmit even the header + the VLAN
|
||
specific part then the resizing of the local TT will never succeed. This
|
||
can for example happen when the usable space is 110 bytes and 11 VLANs are
|
||
on top of batman-adv. In this case, at least 116 byte would be needed.
|
||
There will just be an endless spam of
|
||
|
||
batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110)
|
||
|
||
in the log but the function will never finish. Problem here is that the
|
||
timeout will be halved all the time and will then stagnate at 0 and
|
||
therefore never be able to reduce the table even more.
|
||
|
||
There are other scenarios possible with a similar result. The number of
|
||
BATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too
|
||
high to fit inside a packet. Such a scenario can therefore happen also with
|
||
only a single VLAN + 7 non-purgable addresses - requiring at least 120
|
||
bytes.
|
||
|
||
While this should be handled proactively when:
|
||
|
||
* interface with too low MTU is added
|
||
* VLAN is added
|
||
* non-purgeable local mac is added
|
||
* MTU of an attached interface is reduced
|
||
* fragmentation setting gets disabled (which most likely requires dropping
|
||
attached interfaces)
|
||
|
||
not all of these scenarios can be prevented because batman-adv is only
|
||
consuming events without the the possibility to prevent these actions
|
||
(non-purgable MAC address added, MTU of an attached interface is reduced).
|
||
It is therefore necessary to also make sure that the code is able to handle
|
||
also the situations when there were already incompatible system
|
||
configuration are present.(CVE-2024-35982)
|
||
|
||
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:
|
||
|
||
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:
|
||
|
||
block: fix overflow in blk_ioctl_discard()
|
||
|
||
There is no check for overflow of 'start + len' in blk_ioctl_discard().
|
||
Hung task occurs if submit an discard ioctl with the following param:
|
||
start = 0x80000000000ff000, len = 0x8000000000fff000;
|
||
Add the overflow validation now.(CVE-2024-36917)
|
||
|
||
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:
|
||
|
||
s390/qeth: Fix kernel panic after setting hsuid
|
||
|
||
Symptom:
|
||
When the hsuid attribute is set for the first time on an IQD Layer3
|
||
device while the corresponding network interface is already UP,
|
||
the kernel will try to execute a napi function pointer that is NULL.
|
||
|
||
Example:
|
||
---------------------------------------------------------------------------
|
||
[ 2057.572696] illegal operation: 0001 ilc:1 [#1] SMP
|
||
[ 2057.572702] Modules linked in: af_iucv qeth_l3 zfcp scsi_transport_fc sunrpc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6
|
||
nft_reject nft_ct nf_tables_set nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink ghash_s390 prng xts aes_s390 des_s390 de
|
||
s_generic sha3_512_s390 sha3_256_s390 sha512_s390 vfio_ccw vfio_mdev mdev vfio_iommu_type1 eadm_sch vfio ext4 mbcache jbd2 qeth_l2 bridge stp llc dasd_eckd_mod qeth dasd_mod
|
||
qdio ccwgroup pkey zcrypt
|
||
[ 2057.572739] CPU: 6 PID: 60182 Comm: stress_client Kdump: loaded Not tainted 4.18.0-541.el8.s390x #1
|
||
[ 2057.572742] Hardware name: IBM 3931 A01 704 (LPAR)
|
||
[ 2057.572744] Krnl PSW : 0704f00180000000 0000000000000002 (0x2)
|
||
[ 2057.572748] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3
|
||
[ 2057.572751] Krnl GPRS: 0000000000000004 0000000000000000 00000000a3b008d8 0000000000000000
|
||
[ 2057.572754] 00000000a3b008d8 cb923a29c779abc5 0000000000000000 00000000814cfd80
|
||
[ 2057.572756] 000000000000012c 0000000000000000 00000000a3b008d8 00000000a3b008d8
|
||
[ 2057.572758] 00000000bab6d500 00000000814cfd80 0000000091317e46 00000000814cfc68
|
||
[ 2057.572762] Krnl Code:#0000000000000000: 0000 illegal
|
||
>0000000000000002: 0000 illegal
|
||
0000000000000004: 0000 illegal
|
||
0000000000000006: 0000 illegal
|
||
0000000000000008: 0000 illegal
|
||
000000000000000a: 0000 illegal
|
||
000000000000000c: 0000 illegal
|
||
000000000000000e: 0000 illegal
|
||
[ 2057.572800] Call Trace:
|
||
[ 2057.572801] ([<00000000ec639700>] 0xec639700)
|
||
[ 2057.572803] [<00000000913183e2>] net_rx_action+0x2ba/0x398
|
||
[ 2057.572809] [<0000000091515f76>] __do_softirq+0x11e/0x3a0
|
||
[ 2057.572813] [<0000000090ce160c>] do_softirq_own_stack+0x3c/0x58
|
||
[ 2057.572817] ([<0000000090d2cbd6>] do_softirq.part.1+0x56/0x60)
|
||
[ 2057.572822] [<0000000090d2cc60>] __local_bh_enable_ip+0x80/0x98
|
||
[ 2057.572825] [<0000000091314706>] __dev_queue_xmit+0x2be/0xd70
|
||
[ 2057.572827] [<000003ff803dd6d6>] afiucv_hs_send+0x24e/0x300 [af_iucv]
|
||
[ 2057.572830] [<000003ff803dd88a>] iucv_send_ctrl+0x102/0x138 [af_iucv]
|
||
[ 2057.572833] [<000003ff803de72a>] iucv_sock_connect+0x37a/0x468 [af_iucv]
|
||
[ 2057.572835] [<00000000912e7e90>] __sys_connect+0xa0/0xd8
|
||
[ 2057.572839] [<00000000912e9580>] sys_socketcall+0x228/0x348
|
||
[ 2057.572841] [<0000000091514e1a>] system_call+0x2a6/0x2c8
|
||
[ 2057.572843] Last Breaking-Event-Address:
|
||
[ 2057.572844] [<0000000091317e44>] __napi_poll+0x4c/0x1d8
|
||
[ 2057.572846]
|
||
[ 2057.572847] Kernel panic - not syncing: Fatal exception in interrupt
|
||
-------------------------------------------------------------------------------------------
|
||
|
||
Analysis:
|
||
There is one napi structure per out_q: card->qdio.out_qs[i].napi
|
||
The napi.poll functions are set during qeth_open().
|
||
|
||
Since
|
||
commit 1cfef80d4c2b ("s390/qeth: Don't call dev_close/dev_open (DOWN/UP)")
|
||
qeth_set_offline()/qeth_set_online() no longer call dev_close()/
|
||
dev_open(). So if qeth_free_qdio_queues() cleared
|
||
card->qdio.out_qs[i].napi.poll while the network interface was UP and the
|
||
card was offline, they are not set again.
|
||
|
||
Reproduction:
|
||
chzdev -e $devno layer2=0
|
||
ip link set dev $network_interface up
|
||
echo 0 > /sys/bus/ccw
|
||
---truncated---(CVE-2024-36928)
|
||
|
||
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:
|
||
|
||
tipc: fix a possible memleak in tipc_buf_append
|
||
|
||
__skb_linearize() doesn't free the skb when it fails, so move
|
||
'*buf = NULL' after __skb_linearize(), so that the skb can be
|
||
freed on the err path.(CVE-2024-36954)
|
||
|
||
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-SP1.
|
||
|
||
openEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.</Note>
|
||
<Note Title="Severity" Type="General" Ordinal="5" xml:lang="en">High</Note>
|
||
<Note Title="Affected Component" Type="General" Ordinal="6" xml:lang="en">kernel</Note>
|
||
</DocumentNotes>
|
||
<DocumentReferences>
|
||
<Reference Type="Self">
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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-48693</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-52672</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52693</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52708</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52732</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52739</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52747</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52762</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52810</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-52846</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-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-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-35815</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-35828</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35839</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-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-35982</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-36916</URL>
|
||
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36917</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-36928</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-36954</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-48693</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52670</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52672</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52693</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52708</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52732</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52739</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52747</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52762</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52810</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-52846</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52882</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-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-35815</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35819</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35828</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35839</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-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-35982</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36016</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36916</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36917</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36919</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36928</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36952</URL>
|
||
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36954</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-SP1" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">openEuler-22.03-LTS-SP1</FullProductName>
|
||
</Branch>
|
||
<Branch Type="Package Arch" Name="aarch64">
|
||
<FullProductName ProductID="kernel-source-5.10.0-136.80.0.160" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-source-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-tools-devel-5.10.0-136.80.0.160" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-devel-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="perf-5.10.0-136.80.0.160" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-debugsource-5.10.0-136.80.0.160" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debugsource-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-136.80.0.160" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-debuginfo-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-tools-5.10.0-136.80.0.160" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-devel-5.10.0-136.80.0.160" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-devel-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-5.10.0-136.80.0.160" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="perf-debuginfo-5.10.0-136.80.0.160" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-debuginfo-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-headers-5.10.0-136.80.0.160" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-headers-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-debuginfo-5.10.0-136.80.0.160" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debuginfo-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="python3-perf-5.10.0-136.80.0.160" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-136.80.0.160" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-debuginfo-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</FullProductName>
|
||
</Branch>
|
||
<Branch Type="Package Arch" Name="src">
|
||
<FullProductName ProductID="kernel-5.10.0-136.80.0.160" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-5.10.0-136.80.0.160.oe2203sp1.src.rpm</FullProductName>
|
||
</Branch>
|
||
<Branch Type="Package Arch" Name="x86_64">
|
||
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-136.80.0.160" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-debuginfo-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="python3-perf-5.10.0-136.80.0.160" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-debugsource-5.10.0-136.80.0.160" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debugsource-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-tools-devel-5.10.0-136.80.0.160" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-devel-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-devel-5.10.0-136.80.0.160" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-devel-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-headers-5.10.0-136.80.0.160" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-headers-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-tools-5.10.0-136.80.0.160" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-5.10.0-136.80.0.160" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-debuginfo-5.10.0-136.80.0.160" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debuginfo-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="kernel-source-5.10.0-136.80.0.160" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-source-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-136.80.0.160" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-debuginfo-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="perf-debuginfo-5.10.0-136.80.0.160" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-debuginfo-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</FullProductName>
|
||
<FullProductName ProductID="perf-5.10.0-136.80.0.160" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</FullProductName>
|
||
</Branch>
|
||
</ProductTree>
|
||
<Vulnerability Ordinal="1" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
||
<Notes>
|
||
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
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-SP1</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-1737</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-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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:soc: brcmstb: pm-arm: Fix refcount leak and __iomem leak bugsIn brcmstb_pm_probe(), there are two kinds of leak bugs:(1) we need to add of_node_put() when for_each__matching_node() breaks(2) we need to add iounmap() for each iomap in fail path</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2022-48693</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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:
|
||
|
||
pipe: wakeup wr_wait after setting max_usage
|
||
|
||
Commit c73be61cede5 ("pipe: Add general notification queue support") a
|
||
regression was introduced that would lock up resized pipes under certain
|
||
conditions. See the reproducer in [1].
|
||
|
||
The commit resizing the pipe ring size was moved to a different
|
||
function, doing that moved the wakeup for pipe->wr_wait before actually
|
||
raising pipe->max_usage. If a pipe was full before the resize occured it
|
||
would result in the wakeup never actually triggering pipe_write.
|
||
|
||
Set @max_usage and @nr_accounted before waking writers if this isn't a
|
||
watch queue.
|
||
|
||
[Christian Brauner <brauner@kernel.org>: rewrite to account for watch queues]</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2023-52672</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Low</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>0.0</BaseScore>
|
||
<Vector></Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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:
|
||
|
||
ACPI: video: check for error while searching for backlight device parent
|
||
|
||
If acpi_get_parent() called in acpi_video_dev_register_backlight()
|
||
fails, for example, because acpi_ut_acquire_mutex() fails inside
|
||
acpi_get_parent), this can lead to incorrect (uninitialized)
|
||
acpi_parent handle being passed to acpi_get_pci_dev() for detecting
|
||
the parent pci device.
|
||
|
||
Check acpi_get_parent() result and set parent device only in case of success.
|
||
|
||
Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2023-52693</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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:
|
||
|
||
mmc: mmc_spi: fix error handling in mmc_spi_probe()
|
||
|
||
If mmc_add_host() fails, it doesn't need to call mmc_remove_host(),
|
||
or it will cause null-ptr-deref, because of deleting a not added
|
||
device in mmc_remove_host().
|
||
|
||
To fix this, goto label 'fail_glue_init', if mmc_add_host() fails,
|
||
and change the label 'fail_add_host' to 'fail_gpiod_request'.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2023-52708</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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:
|
||
|
||
ceph: blocklist the kclient when receiving corrupted snap trace
|
||
|
||
When received corrupted snap trace we don't know what exactly has
|
||
happened in MDS side. And we shouldn't continue IOs and metadatas
|
||
access to MDS, which may corrupt or get incorrect contents.
|
||
|
||
This patch will just block all the further IO/MDS requests
|
||
immediately and then evict the kclient itself.
|
||
|
||
The reason why we still need to evict the kclient just after
|
||
blocking all the further IOs is that the MDS could revoke the caps
|
||
faster.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2023-52732</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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:
|
||
|
||
Fix page corruption caused by racy check in __free_pages
|
||
|
||
When we upgraded our kernel, we started seeing some page corruption like
|
||
the following consistently:
|
||
|
||
BUG: Bad page state in process ganesha.nfsd pfn:1304ca
|
||
page:0000000022261c55 refcount:0 mapcount:-128 mapping:0000000000000000 index:0x0 pfn:0x1304ca
|
||
flags: 0x17ffffc0000000()
|
||
raw: 0017ffffc0000000 ffff8a513ffd4c98 ffffeee24b35ec08 0000000000000000
|
||
raw: 0000000000000000 0000000000000001 00000000ffffff7f 0000000000000000
|
||
page dumped because: nonzero mapcount
|
||
CPU: 0 PID: 15567 Comm: ganesha.nfsd Kdump: loaded Tainted: P B O 5.10.158-1.nutanix.20221209.el7.x86_64 #1
|
||
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/05/2016
|
||
Call Trace:
|
||
dump_stack+0x74/0x96
|
||
bad_page.cold+0x63/0x94
|
||
check_new_page_bad+0x6d/0x80
|
||
rmqueue+0x46e/0x970
|
||
get_page_from_freelist+0xcb/0x3f0
|
||
? _cond_resched+0x19/0x40
|
||
__alloc_pages_nodemask+0x164/0x300
|
||
alloc_pages_current+0x87/0xf0
|
||
skb_page_frag_refill+0x84/0x110
|
||
...
|
||
|
||
Sometimes, it would also show up as corruption in the free list pointer
|
||
and cause crashes.
|
||
|
||
After bisecting the issue, we found the issue started from commit
|
||
e320d3012d25 ("mm/page_alloc.c: fix freeing non-compound pages"):
|
||
|
||
if (put_page_testzero(page))
|
||
free_the_page(page, order);
|
||
else if (!PageHead(page))
|
||
while (order-- > 0)
|
||
free_the_page(page + (1 << order), order);
|
||
|
||
So the problem is the check PageHead is racy because at this point we
|
||
already dropped our reference to the page. So even if we came in with
|
||
compound page, the page can already be freed and PageHead can return
|
||
false and we will end up freeing all the tail pages causing double free.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2023-52739</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>High</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>7.0</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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:
|
||
|
||
IB/hfi1: Restore allocated resources on failed copyout
|
||
|
||
Fix a resource leak if an error occurs.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2023-52747</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>4.7</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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:
|
||
|
||
virtio-blk: fix implicit overflow on virtio_max_dma_size
|
||
|
||
The following codes have an implicit conversion from size_t to u32:
|
||
(u32)max_size = (size_t)virtio_max_dma_size(vdev);
|
||
|
||
This may lead overflow, Ex (size_t)4G -> (u32)0. Once
|
||
virtio_max_dma_size() has a larger size than U32_MAX, use U32_MAX
|
||
instead.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2023-52762</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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:
|
||
|
||
fs/jfs: Add check for negative db_l2nbperpage
|
||
|
||
l2nbperpage is log2(number of blks per page), and the minimum legal
|
||
value should be 0, not negative.
|
||
|
||
In the case of l2nbperpage being negative, an error will occur
|
||
when subsequently used as shift exponent.
|
||
|
||
Syzbot reported this bug:
|
||
|
||
UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:799:12
|
||
shift exponent -16777216 is negative</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2023-52810</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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: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-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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:
|
||
|
||
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-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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:
|
||
|
||
hsr: Prevent use after free in prp_create_tagged_frame()
|
||
|
||
The prp_fill_rct() function can fail. In that situation, it frees the
|
||
skb and returns NULL. Meanwhile on the success path, it returns the
|
||
original skb. So it's straight forward to fix bug by using the returned
|
||
value.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2023-52846</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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:
|
||
|
||
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-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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:
|
||
|
||
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-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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:
|
||
|
||
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-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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:
|
||
|
||
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-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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:
|
||
|
||
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-SP1</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-1737</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: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-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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: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-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>4.7</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C: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-1737</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="24" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
||
<Notes>
|
||
<Note Title="Vulnerability Description" Type="General" Ordinal="24" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
drm/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-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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:
|
||
|
||
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-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>4.0</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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:
|
||
|
||
fs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversion
|
||
|
||
The first kiocb_set_cancel_fn() argument may point at a struct kiocb
|
||
that is not embedded inside struct aio_kiocb. With the current code,
|
||
depending on the compiler, the req->ki_ctx read happens either before
|
||
the IOCB_AIO_RW test or after that test. Move the req->ki_ctx read such
|
||
that it is guaranteed that the IOCB_AIO_RW test happens first.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-35815</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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:
|
||
|
||
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-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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:
|
||
|
||
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-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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:
|
||
|
||
netfilter: bridge: replace physindev with physinif in nf_bridge_info
|
||
|
||
An skb can be added to a neigh->arp_queue while waiting for an arp
|
||
reply. Where original skb's skb->dev can be different to neigh's
|
||
neigh->dev. For instance in case of bridging dnated skb from one veth to
|
||
another, the skb would be added to a neigh->arp_queue of the bridge.
|
||
|
||
As skb->dev can be reset back to nf_bridge->physindev and used, and as
|
||
there is no explicit mechanism that prevents this physindev from been
|
||
freed under us (for instance neigh_flush_dev doesn't cleanup skbs from
|
||
different device's neigh queue) we can crash on e.g. this stack:
|
||
|
||
arp_process
|
||
neigh_update
|
||
skb = __skb_dequeue(&neigh->arp_queue)
|
||
neigh_resolve_output(..., skb)
|
||
...
|
||
br_nf_dev_xmit
|
||
br_nf_pre_routing_finish_bridge_slow
|
||
skb->dev = nf_bridge->physindev
|
||
br_handle_frame_finish
|
||
|
||
Let's use plain ifindex instead of net_device link. To peek into the
|
||
original net_device we will use dev_get_by_index_rcu(). Thus either we
|
||
get device and are safe to use it or we don't get it and drop skb.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-35839</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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:
|
||
|
||
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-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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:
|
||
|
||
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-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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:
|
||
|
||
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-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.8</BaseScore>
|
||
<Vector>AV:L/AC:H/PR: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-1737</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:
|
||
|
||
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-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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:
|
||
|
||
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-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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:
|
||
|
||
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-SP1</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-1737</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="36" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
||
<Notes>
|
||
<Note Title="Vulnerability Description" Type="General" Ordinal="36" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
drm/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-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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:
|
||
|
||
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-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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:
|
||
|
||
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-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="39" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
||
<Notes>
|
||
<Note Title="Vulnerability Description" Type="General" Ordinal="39" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:batman-adv: Avoid infinite loop trying to resize local TTIf the MTU of one of an attached interface becomes too small to transmitthe local translation table then it must be resized to fit inside allfragments (when enabled) or a single packet.But if the MTU becomes too low to transmit even the header + the VLANspecific part then the resizing of the local TT will never succeed. Thiscan for example happen when the usable space is 110 bytes and 11 VLANs areon top of batman-adv. In this case, at least 116 byte would be needed.There will just be an endless spam of batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110)in the log but the function will never finish. Problem here is that thetimeout will be halved all the time and will then stagnate at 0 andtherefore never be able to reduce the table even more.There are other scenarios possible with a similar result. The number ofBATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be toohigh to fit inside a packet. Such a scenario can therefore happen also withonly a single VLAN + 7 non-purgable addresses - requiring at least 120bytes.While this should be handled proactively when:* interface with too low MTU is added* VLAN is added* non-purgeable local mac is added* MTU of an attached interface is reduced* fragmentation setting gets disabled (which most likely requires dropping attached interfaces)not all of these scenarios can be prevented because batman-adv is onlyconsuming events without the the possibility to prevent these actions(non-purgable MAC address added, MTU of an attached interface is reduced).It is therefore necessary to also make sure that the code is able to handlealso the situations when there were already incompatible systemconfiguration are present.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-35982</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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:
|
||
|
||
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-SP1</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-1737</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:
|
||
|
||
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-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</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:
|
||
|
||
block: fix overflow in blk_ioctl_discard()
|
||
|
||
There is no check for overflow of 'start + len' in blk_ioctl_discard().
|
||
Hung task occurs if submit an discard ioctl with the following param:
|
||
start = 0x80000000000ff000, len = 0x8000000000fff000;
|
||
Add the overflow validation now.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-36917</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Low</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>0.0</BaseScore>
|
||
<Vector></Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="43" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
||
<Notes>
|
||
<Note Title="Vulnerability Description" Type="General" Ordinal="43" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
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-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="44" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
||
<Notes>
|
||
<Note Title="Vulnerability Description" Type="General" Ordinal="44" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
s390/qeth: Fix kernel panic after setting hsuid
|
||
|
||
Symptom:
|
||
When the hsuid attribute is set for the first time on an IQD Layer3
|
||
device while the corresponding network interface is already UP,
|
||
the kernel will try to execute a napi function pointer that is NULL.
|
||
|
||
Example:
|
||
---------------------------------------------------------------------------
|
||
[ 2057.572696] illegal operation: 0001 ilc:1 [#1] SMP
|
||
[ 2057.572702] Modules linked in: af_iucv qeth_l3 zfcp scsi_transport_fc sunrpc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6
|
||
nft_reject nft_ct nf_tables_set nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink ghash_s390 prng xts aes_s390 des_s390 de
|
||
s_generic sha3_512_s390 sha3_256_s390 sha512_s390 vfio_ccw vfio_mdev mdev vfio_iommu_type1 eadm_sch vfio ext4 mbcache jbd2 qeth_l2 bridge stp llc dasd_eckd_mod qeth dasd_mod
|
||
qdio ccwgroup pkey zcrypt
|
||
[ 2057.572739] CPU: 6 PID: 60182 Comm: stress_client Kdump: loaded Not tainted 4.18.0-541.el8.s390x #1
|
||
[ 2057.572742] Hardware name: IBM 3931 A01 704 (LPAR)
|
||
[ 2057.572744] Krnl PSW : 0704f00180000000 0000000000000002 (0x2)
|
||
[ 2057.572748] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3
|
||
[ 2057.572751] Krnl GPRS: 0000000000000004 0000000000000000 00000000a3b008d8 0000000000000000
|
||
[ 2057.572754] 00000000a3b008d8 cb923a29c779abc5 0000000000000000 00000000814cfd80
|
||
[ 2057.572756] 000000000000012c 0000000000000000 00000000a3b008d8 00000000a3b008d8
|
||
[ 2057.572758] 00000000bab6d500 00000000814cfd80 0000000091317e46 00000000814cfc68
|
||
[ 2057.572762] Krnl Code:#0000000000000000: 0000 illegal
|
||
>0000000000000002: 0000 illegal
|
||
0000000000000004: 0000 illegal
|
||
0000000000000006: 0000 illegal
|
||
0000000000000008: 0000 illegal
|
||
000000000000000a: 0000 illegal
|
||
000000000000000c: 0000 illegal
|
||
000000000000000e: 0000 illegal
|
||
[ 2057.572800] Call Trace:
|
||
[ 2057.572801] ([<00000000ec639700>] 0xec639700)
|
||
[ 2057.572803] [<00000000913183e2>] net_rx_action+0x2ba/0x398
|
||
[ 2057.572809] [<0000000091515f76>] __do_softirq+0x11e/0x3a0
|
||
[ 2057.572813] [<0000000090ce160c>] do_softirq_own_stack+0x3c/0x58
|
||
[ 2057.572817] ([<0000000090d2cbd6>] do_softirq.part.1+0x56/0x60)
|
||
[ 2057.572822] [<0000000090d2cc60>] __local_bh_enable_ip+0x80/0x98
|
||
[ 2057.572825] [<0000000091314706>] __dev_queue_xmit+0x2be/0xd70
|
||
[ 2057.572827] [<000003ff803dd6d6>] afiucv_hs_send+0x24e/0x300 [af_iucv]
|
||
[ 2057.572830] [<000003ff803dd88a>] iucv_send_ctrl+0x102/0x138 [af_iucv]
|
||
[ 2057.572833] [<000003ff803de72a>] iucv_sock_connect+0x37a/0x468 [af_iucv]
|
||
[ 2057.572835] [<00000000912e7e90>] __sys_connect+0xa0/0xd8
|
||
[ 2057.572839] [<00000000912e9580>] sys_socketcall+0x228/0x348
|
||
[ 2057.572841] [<0000000091514e1a>] system_call+0x2a6/0x2c8
|
||
[ 2057.572843] Last Breaking-Event-Address:
|
||
[ 2057.572844] [<0000000091317e44>] __napi_poll+0x4c/0x1d8
|
||
[ 2057.572846]
|
||
[ 2057.572847] Kernel panic - not syncing: Fatal exception in interrupt
|
||
-------------------------------------------------------------------------------------------
|
||
|
||
Analysis:
|
||
There is one napi structure per out_q: card->qdio.out_qs[i].napi
|
||
The napi.poll functions are set during qeth_open().
|
||
|
||
Since
|
||
commit 1cfef80d4c2b ("s390/qeth: Don't call dev_close/dev_open (DOWN/UP)")
|
||
qeth_set_offline()/qeth_set_online() no longer call dev_close()/
|
||
dev_open(). So if qeth_free_qdio_queues() cleared
|
||
card->qdio.out_qs[i].napi.poll while the network interface was UP and the
|
||
card was offline, they are not set again.
|
||
|
||
Reproduction:
|
||
chzdev -e $devno layer2=0
|
||
ip link set dev $network_interface up
|
||
echo 0 > /sys/bus/ccw
|
||
---truncated---</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-36928</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>4.4</BaseScore>
|
||
<Vector>AV:L/AC: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-1737</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="45" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
||
<Notes>
|
||
<Note Title="Vulnerability Description" Type="General" Ordinal="45" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
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-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>4.7</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="46" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
||
<Notes>
|
||
<Note Title="Vulnerability Description" Type="General" Ordinal="46" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
tipc: fix a possible memleak in tipc_buf_append
|
||
|
||
__skb_linearize() doesn't free the skb when it fails, so move
|
||
'*buf = NULL' after __skb_linearize(), so that the skb can be
|
||
freed on the err path.</Note>
|
||
</Notes>
|
||
<ReleaseDate>2024-06-21</ReleaseDate>
|
||
<CVE>CVE-2024-36954</CVE>
|
||
<ProductStatuses>
|
||
<Status Type="Fixed">
|
||
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="47" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
||
<Notes>
|
||
<Note Title="Vulnerability Description" Type="General" Ordinal="47" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
drm/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-SP1</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-1737</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="48" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
||
<Notes>
|
||
<Note Title="Vulnerability Description" Type="General" Ordinal="48" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
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-SP1</ProductID>
|
||
</Status>
|
||
</ProductStatuses>
|
||
<Threats>
|
||
<Threat Type="Impact">
|
||
<Description>Medium</Description>
|
||
</Threat>
|
||
</Threats>
|
||
<CVSSScoreSets>
|
||
<ScoreSet>
|
||
<BaseScore>5.5</BaseScore>
|
||
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
||
</ScoreSet>
|
||
</CVSSScoreSets>
|
||
<Remediations>
|
||
<Remediation Type="Vendor Fix">
|
||
<Description>kernel security update</Description>
|
||
<DATE>2024-06-21</DATE>
|
||
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1737</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
<Vulnerability Ordinal="49" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
||
<Notes>
|
||
<Note Title="Vulnerability Description" Type="General" Ordinal="49" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
||
|
||
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-SP1</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-1737</URL>
|
||
</Remediation>
|
||
</Remediations>
|
||
</Vulnerability>
|
||
</cvrfdoc> |