3451 lines
146 KiB
XML
3451 lines
146 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
|
|
<DocumentTitle xml:lang="en">An update for kernel is now available for openEuler-20.03-LTS-SP4</DocumentTitle>
|
|
<DocumentType>Security Advisory</DocumentType>
|
|
<DocumentPublisher Type="Vendor">
|
|
<ContactDetails>openeuler-security@openeuler.org</ContactDetails>
|
|
<IssuingAuthority>openEuler security committee</IssuingAuthority>
|
|
</DocumentPublisher>
|
|
<DocumentTracking>
|
|
<Identification>
|
|
<ID>openEuler-SA-2024-1705</ID>
|
|
</Identification>
|
|
<Status>Final</Status>
|
|
<Version>1.0</Version>
|
|
<RevisionHistory>
|
|
<Revision>
|
|
<Number>1.0</Number>
|
|
<Date>2024-06-14</Date>
|
|
<Description>Initial</Description>
|
|
</Revision>
|
|
</RevisionHistory>
|
|
<InitialReleaseDate>2024-06-14</InitialReleaseDate>
|
|
<CurrentReleaseDate>2024-06-14</CurrentReleaseDate>
|
|
<Generator>
|
|
<Engine>openEuler SA Tool V1.0</Engine>
|
|
<Date>2024-06-14</Date>
|
|
</Generator>
|
|
</DocumentTracking>
|
|
<DocumentNotes>
|
|
<Note Title="Synopsis" Type="General" Ordinal="1" xml:lang="en">kernel security update</Note>
|
|
<Note Title="Summary" Type="General" Ordinal="2" xml:lang="en">An update for kernel is now available for openEuler-20.03-LTS-SP4.</Note>
|
|
<Note Title="Description" Type="General" Ordinal="3" xml:lang="en">The Linux Kernel, the operating system core itself.
|
|
|
|
Security Fix(es):
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: cdc_eem: fix tx fixup skb leak
|
|
|
|
when usbnet transmit a skb, eem fixup it in eem_tx_fixup(),
|
|
if skb_copy_expand() failed, it return NULL,
|
|
usbnet_start_xmit() will have no chance to free original skb.
|
|
|
|
fix it by free orginal skb in eem_tx_fixup() first,
|
|
then check skb clone status, if failed, return NULL to usbnet.(CVE-2021-47236)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
gfs2: Fix use-after-free in gfs2_glock_shrink_scan
|
|
|
|
The GLF_LRU flag is checked under lru_lock in gfs2_glock_remove_from_lru() to
|
|
remove the glock from the lru list in __gfs2_glock_put().
|
|
|
|
On the shrink scan path, the same flag is cleared under lru_lock but because
|
|
of cond_resched_lock(&lru_lock) in gfs2_dispose_glock_lru(), progress on the
|
|
put side can be made without deleting the glock from the lru list.
|
|
|
|
Keep GLF_LRU across the race window opened by cond_resched_lock(&lru_lock) to
|
|
ensure correct behavior on both sides - clear GLF_LRU after list_del under
|
|
lru_lock.(CVE-2021-47254)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netrom: Decrease sock refcount when sock timers expire
|
|
|
|
Commit 63346650c1a9 ("netrom: switch to sock timer API") switched to use
|
|
sock timer API. It replaces mod_timer() by sk_reset_timer(), and
|
|
del_timer() by sk_stop_timer().
|
|
|
|
Function sk_reset_timer() will increase the refcount of sock if it is
|
|
called on an inactive timer, hence, in case the timer expires, we need to
|
|
decrease the refcount ourselves in the handler, otherwise, the sock
|
|
refcount will be unbalanced and the sock will never be freed.(CVE-2021-47294)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
memory: fsl_ifc: fix leak of IO mapping on probe failure
|
|
|
|
On probe error the driver should unmap the IO memory. Smatch reports:
|
|
|
|
drivers/memory/fsl_ifc.c:298 fsl_ifc_ctrl_probe() warn: 'fsl_ifc_ctrl_dev->gregs' not released on lines: 298.(CVE-2021-47315)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
watchdog: Fix possible use-after-free in wdt_startup()
|
|
|
|
This module's remove path calls del_timer(). However, that function
|
|
does not wait until the timer handler finishes. This means that the
|
|
timer handler may still be running after the driver's remove function
|
|
has finished, which would result in a use-after-free.
|
|
|
|
Fix by calling del_timer_sync(), which makes sure the timer handler
|
|
has finished, and unable to re-schedule itself.(CVE-2021-47324)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: megaraid_sas: Fix resource leak in case of probe failure
|
|
|
|
The driver doesn't clean up all the allocated resources properly when
|
|
scsi_add_host(), megasas_start_aen() function fails during the PCI device
|
|
probe.
|
|
|
|
Clean up all those resources.(CVE-2021-47329)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ipack: ipoctal: fix module reference leak
|
|
|
|
A reference to the carrier module was taken on every open but was only
|
|
released once when the final reference to the tty struct was dropped.
|
|
|
|
Fix this by taking the module reference and initialising the tty driver
|
|
data when installing the tty.(CVE-2021-47403)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
usb: dwc2: check return value after calling platform_get_resource()
|
|
|
|
It will cause null-ptr-deref if platform_get_resource() returns NULL,
|
|
we need check the return value.(CVE-2021-47409)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
i40e: Fix freeing of uninitialized misc IRQ vector
|
|
|
|
When VSI set up failed in i40e_probe() as part of PF switch set up
|
|
driver was trying to free misc IRQ vectors in
|
|
i40e_clear_interrupt_scheme and produced a kernel Oops:
|
|
|
|
Trying to free already-free IRQ 266
|
|
WARNING: CPU: 0 PID: 5 at kernel/irq/manage.c:1731 __free_irq+0x9a/0x300
|
|
Workqueue: events work_for_cpu_fn
|
|
RIP: 0010:__free_irq+0x9a/0x300
|
|
Call Trace:
|
|
? synchronize_irq+0x3a/0xa0
|
|
free_irq+0x2e/0x60
|
|
i40e_clear_interrupt_scheme+0x53/0x190 [i40e]
|
|
i40e_probe.part.108+0x134b/0x1a40 [i40e]
|
|
? kmem_cache_alloc+0x158/0x1c0
|
|
? acpi_ut_update_ref_count.part.1+0x8e/0x345
|
|
? acpi_ut_update_object_reference+0x15e/0x1e2
|
|
? strstr+0x21/0x70
|
|
? irq_get_irq_data+0xa/0x20
|
|
? mp_check_pin_attr+0x13/0xc0
|
|
? irq_get_irq_data+0xa/0x20
|
|
? mp_map_pin_to_irq+0xd3/0x2f0
|
|
? acpi_register_gsi_ioapic+0x93/0x170
|
|
? pci_conf1_read+0xa4/0x100
|
|
? pci_bus_read_config_word+0x49/0x70
|
|
? do_pci_enable_device+0xcc/0x100
|
|
local_pci_probe+0x41/0x90
|
|
work_for_cpu_fn+0x16/0x20
|
|
process_one_work+0x1a7/0x360
|
|
worker_thread+0x1cf/0x390
|
|
? create_worker+0x1a0/0x1a0
|
|
kthread+0x112/0x130
|
|
? kthread_flush_work_fn+0x10/0x10
|
|
ret_from_fork+0x1f/0x40
|
|
|
|
The problem is that at that point misc IRQ vectors
|
|
were not allocated yet and we get a call trace
|
|
that driver is trying to free already free IRQ vectors.
|
|
|
|
Add a check in i40e_clear_interrupt_scheme for __I40E_MISC_IRQ_REQUESTED
|
|
PF state before calling i40e_free_misc_vector. This state is set only if
|
|
misc IRQ vectors were properly initialized.(CVE-2021-47424)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ocfs2: fix data corruption after conversion from inline format
|
|
|
|
Commit 6dbf7bb55598 ("fs: Don't invalidate page buffers in
|
|
block_write_full_page()") uncovered a latent bug in ocfs2 conversion
|
|
from inline inode format to a normal inode format.
|
|
|
|
The code in ocfs2_convert_inline_data_to_extents() attempts to zero out
|
|
the whole cluster allocated for file data by grabbing, zeroing, and
|
|
dirtying all pages covering this cluster. However these pages are
|
|
beyond i_size, thus writeback code generally ignores these dirty pages
|
|
and no blocks were ever actually zeroed on the disk.
|
|
|
|
This oversight was fixed by commit 693c241a5f6a ("ocfs2: No need to zero
|
|
pages past i_size.") for standard ocfs2 write path, inline conversion
|
|
path was apparently forgotten; the commit log also has a reasoning why
|
|
the zeroing actually is not needed.
|
|
|
|
After commit 6dbf7bb55598, things became worse as writeback code stopped
|
|
invalidating buffers on pages beyond i_size and thus these pages end up
|
|
with clean PageDirty bit but with buffers attached to these pages being
|
|
still dirty. So when a file is converted from inline format, then
|
|
writeback triggers, and then the file is grown so that these pages
|
|
become valid, the invalid dirtiness state is preserved,
|
|
mark_buffer_dirty() does nothing on these pages (buffers are already
|
|
dirty) but page is never written back because it is clean. So data
|
|
written to these pages is lost once pages are reclaimed.
|
|
|
|
Simple reproducer for the problem is:
|
|
|
|
xfs_io -f -c "pwrite 0 2000" -c "pwrite 2000 2000" -c "fsync" \
|
|
-c "pwrite 4000 2000" ocfs2_file
|
|
|
|
After unmounting and mounting the fs again, you can observe that end of
|
|
'ocfs2_file' has lost its contents.
|
|
|
|
Fix the problem by not doing the pointless zeroing during conversion
|
|
from inline format similarly as in the standard write path.
|
|
|
|
[akpm@linux-foundation.org: fix whitespace, per Joseph](CVE-2021-47460)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
comedi: ni_usb6501: fix NULL-deref in command paths
|
|
|
|
The driver uses endpoint-sized USB transfer buffers but had no sanity
|
|
checks on the sizes. This can lead to zero-size-pointer dereferences or
|
|
overflowed transfer buffers in ni6501_port_command() and
|
|
ni6501_counter_command() if a (malicious) device has smaller max-packet
|
|
sizes than expected (or when doing descriptor fuzz testing).
|
|
|
|
Add the missing sanity checks to probe().(CVE-2021-47476)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
isofs: Fix out of bound access for corrupted isofs image
|
|
|
|
When isofs image is suitably corrupted isofs_read_inode() can read data
|
|
beyond the end of buffer. Sanity-check the directory entry length before
|
|
using it.(CVE-2021-47478)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
staging: rtl8712: fix use-after-free in rtl8712_dl_fw
|
|
|
|
Syzbot reported use-after-free in rtl8712_dl_fw(). The problem was in
|
|
race condition between r871xu_dev_remove() ->ndo_open() callback.
|
|
|
|
It's easy to see from crash log, that driver accesses released firmware
|
|
in ->ndo_open() callback. It may happen, since driver was releasing
|
|
firmware _before_ unregistering netdev. Fix it by moving
|
|
unregister_netdev() before cleaning up resources.
|
|
|
|
Call Trace:
|
|
...
|
|
rtl871x_open_fw drivers/staging/rtl8712/hal_init.c:83 [inline]
|
|
rtl8712_dl_fw+0xd95/0xe10 drivers/staging/rtl8712/hal_init.c:170
|
|
rtl8712_hal_init drivers/staging/rtl8712/hal_init.c:330 [inline]
|
|
rtl871x_hal_init+0xae/0x180 drivers/staging/rtl8712/hal_init.c:394
|
|
netdev_open+0xe6/0x6c0 drivers/staging/rtl8712/os_intfs.c:380
|
|
__dev_open+0x2bc/0x4d0 net/core/dev.c:1484
|
|
|
|
Freed by task 1306:
|
|
...
|
|
release_firmware+0x1b/0x30 drivers/base/firmware_loader/main.c:1053
|
|
r871xu_dev_remove+0xcc/0x2c0 drivers/staging/rtl8712/usb_intf.c:599
|
|
usb_unbind_interface+0x1d8/0x8d0 drivers/usb/core/driver.c:458(CVE-2021-47479)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
iio: accel: kxcjk-1013: Fix possible memory leak in probe and remove
|
|
|
|
When ACPI type is ACPI_SMO8500, the data->dready_trig will not be set, the
|
|
memory allocated by iio_triggered_buffer_setup() will not be freed, and cause
|
|
memory leak as follows:
|
|
|
|
unreferenced object 0xffff888009551400 (size 512):
|
|
comm "i2c-SMO8500-125", pid 911, jiffies 4294911787 (age 83.852s)
|
|
hex dump (first 32 bytes):
|
|
02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
00 00 00 00 00 00 00 00 20 e2 e5 c0 ff ff ff ff ........ .......
|
|
backtrace:
|
|
[<0000000041ce75ee>] kmem_cache_alloc_trace+0x16d/0x360
|
|
[<000000000aeb17b0>] iio_kfifo_allocate+0x41/0x130 [kfifo_buf]
|
|
[<000000004b40c1f5>] iio_triggered_buffer_setup_ext+0x2c/0x210 [industrialio_triggered_buffer]
|
|
[<000000004375b15f>] kxcjk1013_probe+0x10c3/0x1d81 [kxcjk_1013]
|
|
|
|
Fix it by remove data->dready_trig condition in probe and remove.(CVE-2021-47499)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ALSA: pcm: oss: Fix negative period/buffer sizes
|
|
|
|
The period size calculation in OSS layer may receive a negative value
|
|
as an error, but the code there assumes only the positive values and
|
|
handle them with size_t. Due to that, a too big value may be passed
|
|
to the lower layers.
|
|
|
|
This patch changes the code to handle with ssize_t and adds the proper
|
|
error checks appropriately.(CVE-2021-47511)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nfc: fix potential NULL pointer deref in nfc_genl_dump_ses_done
|
|
|
|
The done() netlink callback nfc_genl_dump_ses_done() should check if
|
|
received argument is non-NULL, because its allocation could fail earlier
|
|
in dumpit() (nfc_genl_dump_ses()).(CVE-2021-47518)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
rxrpc: Fix rxrpc_local leak in rxrpc_lookup_peer()
|
|
|
|
Need to call rxrpc_put_local() for peer candidate before kfree() as it
|
|
holds a ref to rxrpc_local.
|
|
|
|
[DH: v2: Changed to abstract the peer freeing code out into a function](CVE-2021-47538)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/mlx4_en: Fix an use-after-free bug in mlx4_en_try_alloc_resources()
|
|
|
|
In mlx4_en_try_alloc_resources(), mlx4_en_copy_priv() is called and
|
|
tmp->tx_cq will be freed on the error path of mlx4_en_copy_priv().
|
|
After that mlx4_en_alloc_resources() is called and there is a dereference
|
|
of &tmp->tx_cq[t][i] in mlx4_en_alloc_resources(), which could lead to
|
|
a use after free problem on failure of mlx4_en_copy_priv().
|
|
|
|
Fix this bug by adding a check of mlx4_en_copy_priv()
|
|
|
|
This bug was found by a static analyzer. The analysis employs
|
|
differential checking to identify inconsistent security operations
|
|
(e.g., checks or kfrees) between two code paths and confirms that the
|
|
inconsistent operations are not recovered in the current function or
|
|
the callers, so they constitute bugs.
|
|
|
|
Note that, as a bug found by static analysis, it can be a false
|
|
positive or hard to trigger. Multiple researchers have cross-reviewed
|
|
the bug.
|
|
|
|
Builds with CONFIG_MLX4_EN=m show no new warnings,
|
|
and our static analyzer no longer warns about this code.(CVE-2021-47541)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: qlogic: qlcnic: Fix a NULL pointer dereference in qlcnic_83xx_add_rings()
|
|
|
|
In qlcnic_83xx_add_rings(), the indirect function of
|
|
ahw->hw_ops->alloc_mbx_args will be called to allocate memory for
|
|
cmd.req.arg, and there is a dereference of it in qlcnic_83xx_add_rings(),
|
|
which could lead to a NULL pointer dereference on failure of the
|
|
indirect function like qlcnic_83xx_alloc_mbx_args().
|
|
|
|
Fix this bug by adding a check of alloc_mbx_args(), this patch
|
|
imitates the logic of mbx_cmd()'s failure handling.
|
|
|
|
This bug was found by a static analyzer. The analysis employs
|
|
differential checking to identify inconsistent security operations
|
|
(e.g., checks or kfrees) between two code paths and confirms that the
|
|
inconsistent operations are not recovered in the current function or
|
|
the callers, so they constitute bugs.
|
|
|
|
Note that, as a bug found by static analysis, it can be a false
|
|
positive or hard to trigger. Multiple researchers have cross-reviewed
|
|
the bug.
|
|
|
|
Builds with CONFIG_QLCNIC=m show no new warnings, and our
|
|
static analyzer no longer warns about this code.(CVE-2021-47542)
|
|
|
|
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2021-47543)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tcp: fix page frag corruption on page fault
|
|
|
|
Steffen reported a TCP stream corruption for HTTP requests
|
|
served by the apache web-server using a cifs mount-point
|
|
and memory mapping the relevant file.
|
|
|
|
The root cause is quite similar to the one addressed by
|
|
commit 20eb4f29b602 ("net: fix sk_page_frag() recursion from
|
|
memory reclaim"). Here the nested access to the task page frag
|
|
is caused by a page fault on the (mmapped) user-space memory
|
|
buffer coming from the cifs file.
|
|
|
|
The page fault handler performs an smb transaction on a different
|
|
socket, inside the same process context. Since sk->sk_allaction
|
|
for such socket does not prevent the usage for the task_frag,
|
|
the nested allocation modify "under the hood" the page frag
|
|
in use by the outer sendmsg call, corrupting the stream.
|
|
|
|
The overall relevant stack trace looks like the following:
|
|
|
|
httpd 78268 [001] 3461630.850950: probe:tcp_sendmsg_locked:
|
|
ffffffff91461d91 tcp_sendmsg_locked+0x1
|
|
ffffffff91462b57 tcp_sendmsg+0x27
|
|
ffffffff9139814e sock_sendmsg+0x3e
|
|
ffffffffc06dfe1d smb_send_kvec+0x28
|
|
[...]
|
|
ffffffffc06cfaf8 cifs_readpages+0x213
|
|
ffffffff90e83c4b read_pages+0x6b
|
|
ffffffff90e83f31 __do_page_cache_readahead+0x1c1
|
|
ffffffff90e79e98 filemap_fault+0x788
|
|
ffffffff90eb0458 __do_fault+0x38
|
|
ffffffff90eb5280 do_fault+0x1a0
|
|
ffffffff90eb7c84 __handle_mm_fault+0x4d4
|
|
ffffffff90eb8093 handle_mm_fault+0xc3
|
|
ffffffff90c74f6d __do_page_fault+0x1ed
|
|
ffffffff90c75277 do_page_fault+0x37
|
|
ffffffff9160111e page_fault+0x1e
|
|
ffffffff9109e7b5 copyin+0x25
|
|
ffffffff9109eb40 _copy_from_iter_full+0xe0
|
|
ffffffff91462370 tcp_sendmsg_locked+0x5e0
|
|
ffffffff91462370 tcp_sendmsg_locked+0x5e0
|
|
ffffffff91462b57 tcp_sendmsg+0x27
|
|
ffffffff9139815c sock_sendmsg+0x4c
|
|
ffffffff913981f7 sock_write_iter+0x97
|
|
ffffffff90f2cc56 do_iter_readv_writev+0x156
|
|
ffffffff90f2dff0 do_iter_write+0x80
|
|
ffffffff90f2e1c3 vfs_writev+0xa3
|
|
ffffffff90f2e27c do_writev+0x5c
|
|
ffffffff90c042bb do_syscall_64+0x5b
|
|
ffffffff916000ad entry_SYSCALL_64_after_hwframe+0x65
|
|
|
|
The cifs filesystem rightfully sets sk_allocations to GFP_NOFS,
|
|
we can avoid the nesting using the sk page frag for allocation
|
|
lacking the __GFP_FS flag. Do not define an additional mm-helper
|
|
for that, as this is strictly tied to the sk page frag usage.
|
|
|
|
v1 -> v2:
|
|
- use a stricted sk_page_frag() check instead of reordering the
|
|
code (Eric)(CVE-2021-47544)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: tulip: de4x5: fix the problem that the array 'lp->phy[8]' may be out of bound
|
|
|
|
In line 5001, if all id in the array 'lp->phy[8]' is not 0, when the
|
|
'for' end, the 'k' is 8.
|
|
|
|
At this time, the array 'lp->phy[8]' may be out of bound.(CVE-2021-47547)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
powerpc/powernv: Add a null pointer check in opal_event_init()
|
|
|
|
kasprintf() returns a pointer to dynamically allocated memory
|
|
which can be NULL upon failure.(CVE-2023-52686)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nilfs2: fix underflow in second superblock position calculations
|
|
|
|
Macro NILFS_SB2_OFFSET_BYTES, which computes the position of the second
|
|
superblock, underflows when the argument device size is less than 4096
|
|
bytes. Therefore, when using this macro, it is necessary to check in
|
|
advance that the device size is not less than a lower limit, or at least
|
|
that underflow does not occur.
|
|
|
|
The current nilfs2 implementation lacks this check, causing out-of-bound
|
|
block access when mounting devices smaller than 4096 bytes:
|
|
|
|
I/O error, dev loop0, sector 36028797018963960 op 0x0:(READ) flags 0x0
|
|
phys_seg 1 prio class 2
|
|
NILFS (loop0): unable to read secondary superblock (blocksize = 1024)
|
|
|
|
In addition, when trying to resize the filesystem to a size below 4096
|
|
bytes, this underflow occurs in nilfs_resize_fs(), passing a huge number
|
|
of segments to nilfs_sufile_resize(), corrupting parameters such as the
|
|
number of segments in superblocks. This causes excessive loop iterations
|
|
in nilfs_sufile_resize() during a subsequent resize ioctl, causing
|
|
semaphore ns_segctor_sem to block for a long time and hang the writer
|
|
thread:
|
|
|
|
INFO: task segctord:5067 blocked for more than 143 seconds.
|
|
Not tainted 6.2.0-rc8-syzkaller-00015-gf6feea56f66d #0
|
|
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
|
|
task:segctord state:D stack:23456 pid:5067 ppid:2
|
|
flags:0x00004000
|
|
Call Trace:
|
|
<TASK>
|
|
context_switch kernel/sched/core.c:5293 [inline]
|
|
__schedule+0x1409/0x43f0 kernel/sched/core.c:6606
|
|
schedule+0xc3/0x190 kernel/sched/core.c:6682
|
|
rwsem_down_write_slowpath+0xfcf/0x14a0 kernel/locking/rwsem.c:1190
|
|
nilfs_transaction_lock+0x25c/0x4f0 fs/nilfs2/segment.c:357
|
|
nilfs_segctor_thread_construct fs/nilfs2/segment.c:2486 [inline]
|
|
nilfs_segctor_thread+0x52f/0x1140 fs/nilfs2/segment.c:2570
|
|
kthread+0x270/0x300 kernel/kthread.c:376
|
|
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
|
|
</TASK>
|
|
...
|
|
Call Trace:
|
|
<TASK>
|
|
folio_mark_accessed+0x51c/0xf00 mm/swap.c:515
|
|
__nilfs_get_page_block fs/nilfs2/page.c:42 [inline]
|
|
nilfs_grab_buffer+0x3d3/0x540 fs/nilfs2/page.c:61
|
|
nilfs_mdt_submit_block+0xd7/0x8f0 fs/nilfs2/mdt.c:121
|
|
nilfs_mdt_read_block+0xeb/0x430 fs/nilfs2/mdt.c:176
|
|
nilfs_mdt_get_block+0x12d/0xbb0 fs/nilfs2/mdt.c:251
|
|
nilfs_sufile_get_segment_usage_block fs/nilfs2/sufile.c:92 [inline]
|
|
nilfs_sufile_truncate_range fs/nilfs2/sufile.c:679 [inline]
|
|
nilfs_sufile_resize+0x7a3/0x12b0 fs/nilfs2/sufile.c:777
|
|
nilfs_resize_fs+0x20c/0xed0 fs/nilfs2/super.c:422
|
|
nilfs_ioctl_resize fs/nilfs2/ioctl.c:1033 [inline]
|
|
nilfs_ioctl+0x137c/0x2440 fs/nilfs2/ioctl.c:1301
|
|
...
|
|
|
|
This fixes these issues by inserting appropriate minimum device size
|
|
checks or anti-underflow checks, depending on where the macro is used.(CVE-2023-52705)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amd/display: Avoid NULL dereference of timing generator
|
|
|
|
[Why & How]
|
|
Check whether assigned timing generator is NULL or not before
|
|
accessing its funcs to prevent NULL dereference.(CVE-2023-52753)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: imon: fix access to invalid resource for the second interface
|
|
|
|
imon driver probes two USB interfaces, and at the probe of the second
|
|
interface, the driver assumes blindly that the first interface got
|
|
bound with the same imon driver. It's usually true, but it's still
|
|
possible that the first interface is bound with another driver via a
|
|
malformed descriptor. Then it may lead to a memory corruption, as
|
|
spotted by syzkaller; imon driver accesses the data from drvdata as
|
|
struct imon_context object although it's a completely different one
|
|
that was assigned by another driver.
|
|
|
|
This patch adds a sanity check -- whether the first interface is
|
|
really bound with the imon driver or not -- for avoiding the problem
|
|
above at the probe time.(CVE-2023-52754)
|
|
|
|
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2023-52756)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
s390/dasd: protect device queue against concurrent access
|
|
|
|
In dasd_profile_start() the amount of requests on the device queue are
|
|
counted. The access to the device queue is unprotected against
|
|
concurrent access. With a lot of parallel I/O, especially with alias
|
|
devices enabled, the device queue can change while dasd_profile_start()
|
|
is accessing the queue. In the worst case this leads to a kernel panic
|
|
due to incorrect pointer accesses.
|
|
|
|
Fix this by taking the device lock before accessing the queue and
|
|
counting the requests. Additionally the check for a valid profile data
|
|
pointer can be done earlier to avoid unnecessary locking in a hot path.(CVE-2023-52774)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
SUNRPC: Fix RPC client cleaned up the freed pipefs dentries
|
|
|
|
RPC client pipefs dentries cleanup is in separated rpc_remove_pipedir()
|
|
workqueue,which takes care about pipefs superblock locking.
|
|
In some special scenarios, when kernel frees the pipefs sb of the
|
|
current client and immediately alloctes a new pipefs sb,
|
|
rpc_remove_pipedir function would misjudge the existence of pipefs
|
|
sb which is not the one it used to hold. As a result,
|
|
the rpc_remove_pipedir would clean the released freed pipefs dentries.
|
|
|
|
To fix this issue, rpc_remove_pipedir should check whether the
|
|
current pipefs sb is consistent with the original pipefs sb.
|
|
|
|
This error can be catched by KASAN:
|
|
=========================================================
|
|
[ 250.497700] BUG: KASAN: slab-use-after-free in dget_parent+0x195/0x200
|
|
[ 250.498315] Read of size 4 at addr ffff88800a2ab804 by task kworker/0:18/106503
|
|
[ 250.500549] Workqueue: events rpc_free_client_work
|
|
[ 250.501001] Call Trace:
|
|
[ 250.502880] kasan_report+0xb6/0xf0
|
|
[ 250.503209] ? dget_parent+0x195/0x200
|
|
[ 250.503561] dget_parent+0x195/0x200
|
|
[ 250.503897] ? __pfx_rpc_clntdir_depopulate+0x10/0x10
|
|
[ 250.504384] rpc_rmdir_depopulate+0x1b/0x90
|
|
[ 250.504781] rpc_remove_client_dir+0xf5/0x150
|
|
[ 250.505195] rpc_free_client_work+0xe4/0x230
|
|
[ 250.505598] process_one_work+0x8ee/0x13b0
|
|
...
|
|
[ 22.039056] Allocated by task 244:
|
|
[ 22.039390] kasan_save_stack+0x22/0x50
|
|
[ 22.039758] kasan_set_track+0x25/0x30
|
|
[ 22.040109] __kasan_slab_alloc+0x59/0x70
|
|
[ 22.040487] kmem_cache_alloc_lru+0xf0/0x240
|
|
[ 22.040889] __d_alloc+0x31/0x8e0
|
|
[ 22.041207] d_alloc+0x44/0x1f0
|
|
[ 22.041514] __rpc_lookup_create_exclusive+0x11c/0x140
|
|
[ 22.041987] rpc_mkdir_populate.constprop.0+0x5f/0x110
|
|
[ 22.042459] rpc_create_client_dir+0x34/0x150
|
|
[ 22.042874] rpc_setup_pipedir_sb+0x102/0x1c0
|
|
[ 22.043284] rpc_client_register+0x136/0x4e0
|
|
[ 22.043689] rpc_new_client+0x911/0x1020
|
|
[ 22.044057] rpc_create_xprt+0xcb/0x370
|
|
[ 22.044417] rpc_create+0x36b/0x6c0
|
|
...
|
|
[ 22.049524] Freed by task 0:
|
|
[ 22.049803] kasan_save_stack+0x22/0x50
|
|
[ 22.050165] kasan_set_track+0x25/0x30
|
|
[ 22.050520] kasan_save_free_info+0x2b/0x50
|
|
[ 22.050921] __kasan_slab_free+0x10e/0x1a0
|
|
[ 22.051306] kmem_cache_free+0xa5/0x390
|
|
[ 22.051667] rcu_core+0x62c/0x1930
|
|
[ 22.051995] __do_softirq+0x165/0x52a
|
|
[ 22.052347]
|
|
[ 22.052503] Last potentially related work creation:
|
|
[ 22.052952] kasan_save_stack+0x22/0x50
|
|
[ 22.053313] __kasan_record_aux_stack+0x8e/0xa0
|
|
[ 22.053739] __call_rcu_common.constprop.0+0x6b/0x8b0
|
|
[ 22.054209] dentry_free+0xb2/0x140
|
|
[ 22.054540] __dentry_kill+0x3be/0x540
|
|
[ 22.054900] shrink_dentry_list+0x199/0x510
|
|
[ 22.055293] shrink_dcache_parent+0x190/0x240
|
|
[ 22.055703] do_one_tree+0x11/0x40
|
|
[ 22.056028] shrink_dcache_for_umount+0x61/0x140
|
|
[ 22.056461] generic_shutdown_super+0x70/0x590
|
|
[ 22.056879] kill_anon_super+0x3a/0x60
|
|
[ 22.057234] rpc_kill_sb+0x121/0x200(CVE-2023-52803)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
platform/x86: wmi: Fix opening of char device
|
|
|
|
Since commit fa1f68db6ca7 ("drivers: misc: pass miscdevice pointer via
|
|
file private data"), the miscdevice stores a pointer to itself inside
|
|
filp->private_data, which means that private_data will not be NULL when
|
|
wmi_char_open() is called. This might cause memory corruption should
|
|
wmi_char_open() be unable to find its driver, something which can
|
|
happen when the associated WMI device is deleted in wmi_free_devices().
|
|
|
|
Fix the problem by using the miscdevice pointer to retrieve the WMI
|
|
device data associated with a char device using container_of(). This
|
|
also avoids wmi_char_open() picking a wrong WMI device bound to a
|
|
driver with the same name as the original driver.(CVE-2023-52864)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
clk: mediatek: clk-mt6797: Add check for mtk_alloc_clk_data
|
|
|
|
Add the check for the return value of mtk_alloc_clk_data() in order to
|
|
avoid NULL pointer dereference.(CVE-2023-52865)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
soc: qcom: llcc: Handle a second device without data corruption
|
|
|
|
Usually there is only one llcc device. But if there were a second, even
|
|
a failed probe call would modify the global drv_data pointer. So check
|
|
if drv_data is valid before overwriting it.(CVE-2023-52871)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
efi/capsule-loader: fix incorrect allocation size
|
|
|
|
gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures
|
|
is not enough for a 64-bit phys_addr_t:
|
|
|
|
drivers/firmware/efi/capsule-loader.c: In function 'efi_capsule_open':
|
|
drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size '4' for type 'phys_addr_t' {aka 'long long unsigned int'} with size '8' [-Werror=alloc-size]
|
|
295 | cap_info->phys = kzalloc(sizeof(void *), GFP_KERNEL);
|
|
| ^
|
|
|
|
Use the correct type instead here.(CVE-2024-27413)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
PCI/PM: Drain runtime-idle callbacks before driver removal
|
|
|
|
A race condition between the .runtime_idle() callback and the .remove()
|
|
callback in the rtsx_pcr PCI driver leads to a kernel crash due to an
|
|
unhandled page fault [1].
|
|
|
|
The problem is that rtsx_pci_runtime_idle() is not expected to be running
|
|
after pm_runtime_get_sync() has been called, but the latter doesn't really
|
|
guarantee that. It only guarantees that the suspend and resume callbacks
|
|
will not be running when it returns.
|
|
|
|
However, if a .runtime_idle() callback is already running when
|
|
pm_runtime_get_sync() is called, the latter will notice that the runtime PM
|
|
status of the device is RPM_ACTIVE and it will return right away without
|
|
waiting for the former to complete. In fact, it cannot wait for
|
|
.runtime_idle() to complete because it may be called from that callback (it
|
|
arguably does not make much sense to do that, but it is not strictly
|
|
prohibited).
|
|
|
|
Thus in general, whoever is providing a .runtime_idle() callback needs
|
|
to protect it from running in parallel with whatever code runs after
|
|
pm_runtime_get_sync(). [Note that .runtime_idle() will not start after
|
|
pm_runtime_get_sync() has returned, but it may continue running then if it
|
|
has started earlier.]
|
|
|
|
One way to address that race condition is to call pm_runtime_barrier()
|
|
after pm_runtime_get_sync() (not before it, because a nonzero value of the
|
|
runtime PM usage counter is necessary to prevent runtime PM callbacks from
|
|
being invoked) to wait for the .runtime_idle() callback to complete should
|
|
it be running at that point. A suitable place for doing that is in
|
|
pci_device_remove() which calls pm_runtime_get_sync() before removing the
|
|
driver, so it may as well call pm_runtime_barrier() subsequently, which
|
|
will prevent the race in question from occurring, not just in the rtsx_pcr
|
|
driver, but in any PCI drivers providing .runtime_idle() callbacks.(CVE-2024-35809)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach
|
|
|
|
This is the candidate patch of CVE-2023-47233 :
|
|
https://nvd.nist.gov/vuln/detail/CVE-2023-47233
|
|
|
|
In brcm80211 driver,it starts with the following invoking chain
|
|
to start init a timeout worker:
|
|
|
|
->brcmf_usb_probe
|
|
->brcmf_usb_probe_cb
|
|
->brcmf_attach
|
|
->brcmf_bus_started
|
|
->brcmf_cfg80211_attach
|
|
->wl_init_priv
|
|
->brcmf_init_escan
|
|
->INIT_WORK(&cfg->escan_timeout_work,
|
|
brcmf_cfg80211_escan_timeout_worker);
|
|
|
|
If we disconnect the USB by hotplug, it will call
|
|
brcmf_usb_disconnect to make cleanup. The invoking chain is :
|
|
|
|
brcmf_usb_disconnect
|
|
->brcmf_usb_disconnect_cb
|
|
->brcmf_detach
|
|
->brcmf_cfg80211_detach
|
|
->kfree(cfg);
|
|
|
|
While the timeout woker may still be running. This will cause
|
|
a use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker.
|
|
|
|
Fix it by deleting the timer and canceling the worker in
|
|
brcmf_cfg80211_detach.
|
|
|
|
[arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free](CVE-2024-35811)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
erspan: make sure erspan_base_hdr is present in skb->head
|
|
|
|
syzbot reported a problem in ip6erspan_rcv() [1]
|
|
|
|
Issue is that ip6erspan_rcv() (and erspan_rcv()) no longer make
|
|
sure erspan_base_hdr is present in skb linear part (skb->head)
|
|
before getting @ver field from it.
|
|
|
|
Add the missing pskb_may_pull() calls.
|
|
|
|
v2: Reload iph pointer in erspan_rcv() after pskb_may_pull()
|
|
because skb->head might have changed.
|
|
|
|
[1]
|
|
|
|
BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2742 [inline]
|
|
BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2756 [inline]
|
|
BUG: KMSAN: uninit-value in ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline]
|
|
BUG: KMSAN: uninit-value in gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610
|
|
pskb_may_pull_reason include/linux/skbuff.h:2742 [inline]
|
|
pskb_may_pull include/linux/skbuff.h:2756 [inline]
|
|
ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline]
|
|
gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610
|
|
ip6_protocol_deliver_rcu+0x1d4c/0x2ca0 net/ipv6/ip6_input.c:438
|
|
ip6_input_finish net/ipv6/ip6_input.c:483 [inline]
|
|
NF_HOOK include/linux/netfilter.h:314 [inline]
|
|
ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492
|
|
ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586
|
|
dst_input include/net/dst.h:460 [inline]
|
|
ip6_rcv_finish+0x955/0x970 net/ipv6/ip6_input.c:79
|
|
NF_HOOK include/linux/netfilter.h:314 [inline]
|
|
ipv6_rcv+0xde/0x390 net/ipv6/ip6_input.c:310
|
|
__netif_receive_skb_one_core net/core/dev.c:5538 [inline]
|
|
__netif_receive_skb+0x1da/0xa00 net/core/dev.c:5652
|
|
netif_receive_skb_internal net/core/dev.c:5738 [inline]
|
|
netif_receive_skb+0x58/0x660 net/core/dev.c:5798
|
|
tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1549
|
|
tun_get_user+0x5566/0x69e0 drivers/net/tun.c:2002
|
|
tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
|
|
call_write_iter include/linux/fs.h:2108 [inline]
|
|
new_sync_write fs/read_write.c:497 [inline]
|
|
vfs_write+0xb63/0x1520 fs/read_write.c:590
|
|
ksys_write+0x20f/0x4c0 fs/read_write.c:643
|
|
__do_sys_write fs/read_write.c:655 [inline]
|
|
__se_sys_write fs/read_write.c:652 [inline]
|
|
__x64_sys_write+0x93/0xe0 fs/read_write.c:652
|
|
do_syscall_64+0xd5/0x1f0
|
|
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
|
|
|
Uninit was created at:
|
|
slab_post_alloc_hook mm/slub.c:3804 [inline]
|
|
slab_alloc_node mm/slub.c:3845 [inline]
|
|
kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888
|
|
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577
|
|
__alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668
|
|
alloc_skb include/linux/skbuff.h:1318 [inline]
|
|
alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504
|
|
sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795
|
|
tun_alloc_skb drivers/net/tun.c:1525 [inline]
|
|
tun_get_user+0x209a/0x69e0 drivers/net/tun.c:1846
|
|
tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
|
|
call_write_iter include/linux/fs.h:2108 [inline]
|
|
new_sync_write fs/read_write.c:497 [inline]
|
|
vfs_write+0xb63/0x1520 fs/read_write.c:590
|
|
ksys_write+0x20f/0x4c0 fs/read_write.c:643
|
|
__do_sys_write fs/read_write.c:655 [inline]
|
|
__se_sys_write fs/read_write.c:652 [inline]
|
|
__x64_sys_write+0x93/0xe0 fs/read_write.c:652
|
|
do_syscall_64+0xd5/0x1f0
|
|
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
|
|
|
CPU: 1 PID: 5045 Comm: syz-executor114 Not tainted 6.9.0-rc1-syzkaller-00021-g962490525cff #0(CVE-2024-35888)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: validate user input for expected length
|
|
|
|
I got multiple syzbot reports showing old bugs exposed
|
|
by BPF after commit 20f2505fb436 ("bpf: Try to avoid kzalloc
|
|
in cgroup/{s,g}etsockopt")
|
|
|
|
setsockopt() @optlen argument should be taken into account
|
|
before copying data.
|
|
|
|
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 do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline]
|
|
BUG: KASAN: slab-out-of-bounds in do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627
|
|
Read of size 96 at addr ffff88802cd73da0 by task syz-executor.4/7238
|
|
|
|
CPU: 1 PID: 7238 Comm: syz-executor.4 Not tainted 6.9.0-rc2-next-20240403-syzkaller #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
|
|
print_address_description mm/kasan/report.c:377 [inline]
|
|
print_report+0x169/0x550 mm/kasan/report.c:488
|
|
kasan_report+0x143/0x180 mm/kasan/report.c:601
|
|
kasan_check_range+0x282/0x290 mm/kasan/generic.c:189
|
|
__asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105
|
|
copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
|
|
copy_from_sockptr include/linux/sockptr.h:55 [inline]
|
|
do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline]
|
|
do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627
|
|
nf_setsockopt+0x295/0x2c0 net/netfilter/nf_sockopt.c:101
|
|
do_sock_setsockopt+0x3af/0x720 net/socket.c:2311
|
|
__sys_setsockopt+0x1ae/0x250 net/socket.c:2334
|
|
__do_sys_setsockopt net/socket.c:2343 [inline]
|
|
__se_sys_setsockopt net/socket.c:2340 [inline]
|
|
__x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
|
|
do_syscall_64+0xfb/0x240
|
|
entry_SYSCALL_64_after_hwframe+0x72/0x7a
|
|
RIP: 0033:0x7fd22067dde9
|
|
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
|
|
RSP: 002b:00007fd21f9ff0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
|
|
RAX: ffffffffffffffda RBX: 00007fd2207abf80 RCX: 00007fd22067dde9
|
|
RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003
|
|
RBP: 00007fd2206ca47a R08: 0000000000000001 R09: 0000000000000000
|
|
R10: 0000000020000880 R11: 0000000000000246 R12: 0000000000000000
|
|
R13: 000000000000000b R14: 00007fd2207abf80 R15: 00007ffd2d0170d8
|
|
</TASK>
|
|
|
|
Allocated by task 7238:
|
|
kasan_save_stack mm/kasan/common.c:47 [inline]
|
|
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
|
|
poison_kmalloc_redzone mm/kasan/common.c:370 [inline]
|
|
__kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387
|
|
kasan_kmalloc include/linux/kasan.h:211 [inline]
|
|
__do_kmalloc_node mm/slub.c:4069 [inline]
|
|
__kmalloc_noprof+0x200/0x410 mm/slub.c:4082
|
|
kmalloc_noprof include/linux/slab.h:664 [inline]
|
|
__cgroup_bpf_run_filter_setsockopt+0xd47/0x1050 kernel/bpf/cgroup.c:1869
|
|
do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293
|
|
__sys_setsockopt+0x1ae/0x250 net/socket.c:2334
|
|
__do_sys_setsockopt net/socket.c:2343 [inline]
|
|
__se_sys_setsockopt net/socket.c:2340 [inline]
|
|
__x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
|
|
do_syscall_64+0xfb/0x240
|
|
entry_SYSCALL_64_after_hwframe+0x72/0x7a
|
|
|
|
The buggy address belongs to the object at ffff88802cd73da0
|
|
which belongs to the cache kmalloc-8 of size 8
|
|
The buggy address is located 0 bytes inside of
|
|
allocated 1-byte region [ffff88802cd73da0, ffff88802cd73da1)
|
|
|
|
The buggy address belongs to the physical page:
|
|
page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88802cd73020 pfn:0x2cd73
|
|
flags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff)
|
|
page_type: 0xffffefff(slab)
|
|
raw: 00fff80000000000 ffff888015041280 dead000000000100 dead000000000122
|
|
raw: ffff88802cd73020 000000008080007f 00000001ffffefff 00
|
|
---truncated---(CVE-2024-35896)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
i2c: smbus: fix NULL function pointer dereference
|
|
|
|
Baruch reported an OOPS when using the designware controller as target
|
|
only. Target-only modes break the assumption of one transfer function
|
|
always being available. Fix this by always checking the pointer in
|
|
__i2c_transfer.
|
|
|
|
[wsa: dropped the simplification in core-smbus to avoid theoretical regressions](CVE-2024-35984)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
rtnetlink: Correct nested IFLA_VF_VLAN_LIST attribute validation
|
|
|
|
Each attribute inside a nested IFLA_VF_VLAN_LIST is assumed to be a
|
|
struct ifla_vf_vlan_info so the size of such attribute needs to be at least
|
|
of sizeof(struct ifla_vf_vlan_info) which is 14 bytes.
|
|
The current size validation in do_setvfinfo is against NLA_HDRLEN (4 bytes)
|
|
which is less than sizeof(struct ifla_vf_vlan_info) so this validation
|
|
is not enough and a too small attribute might be cast to a
|
|
struct ifla_vf_vlan_info, this might result in an out of bands
|
|
read access when accessing the saved (casted) entry in ivvl.(CVE-2024-36017)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mmc: sdhci-msm: pervent access to suspended controller
|
|
|
|
Generic sdhci code registers LED device and uses host->runtime_suspended
|
|
flag to protect access to it. The sdhci-msm driver doesn't set this flag,
|
|
which causes a crash when LED is accessed while controller is runtime
|
|
suspended. Fix this by setting the flag correctly.(CVE-2024-36029)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: fix out-of-bounds access in ops_init
|
|
|
|
net_alloc_generic is called by net_alloc, which is called without any
|
|
locking. It reads max_gen_ptrs, which is changed under pernet_ops_rwsem. It
|
|
is read twice, first to allocate an array, then to set s.len, which is
|
|
later used to limit the bounds of the array access.
|
|
|
|
It is possible that the array is allocated and another thread is
|
|
registering a new pernet ops, increments max_gen_ptrs, which is then used
|
|
to set s.len with a larger than allocated length for the variable array.
|
|
|
|
Fix it by reading max_gen_ptrs only once in net_alloc_generic. If
|
|
max_gen_ptrs is later incremented, it will be caught in net_assign_generic.(CVE-2024-36883)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action()
|
|
|
|
syzbot is able to trigger the following crash [1],
|
|
caused by unsafe ip6_dst_idev() use.
|
|
|
|
Indeed ip6_dst_idev() can return NULL, and must always be checked.
|
|
|
|
[1]
|
|
|
|
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI
|
|
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
|
|
CPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
|
|
RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c:237 [inline]
|
|
RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267
|
|
Code: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 <42> 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c
|
|
RSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246
|
|
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700
|
|
RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760
|
|
RBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd
|
|
R10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000
|
|
R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00
|
|
FS: 00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0
|
|
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
Call Trace:
|
|
<TASK>
|
|
fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317
|
|
fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108
|
|
ip6_route_output_flags_noref net/ipv6/route.c:2637 [inline]
|
|
ip6_route_output_flags+0x38e/0x610 net/ipv6/route.c:2649
|
|
ip6_route_output include/net/ip6_route.h:93 [inline]
|
|
ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120
|
|
ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250
|
|
sctp_v6_get_dst+0x792/0x1e20 net/sctp/ipv6.c:326
|
|
sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455
|
|
sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662
|
|
sctp_connect_new_asoc+0x31d/0x6c0 net/sctp/socket.c:1099
|
|
__sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197
|
|
sctp_connect net/sctp/socket.c:4819 [inline]
|
|
sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834
|
|
__sys_connect_file net/socket.c:2048 [inline]
|
|
__sys_connect+0x2df/0x310 net/socket.c:2065
|
|
__do_sys_connect net/socket.c:2075 [inline]
|
|
__se_sys_connect net/socket.c:2072 [inline]
|
|
__x64_sys_connect+0x7a/0x90 net/socket.c:2072
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-36902)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ipv6: Fix potential uninit-value access in __ip6_make_skb()
|
|
|
|
As it was done in commit fc1092f51567 ("ipv4: Fix uninit-value access in
|
|
__ip_make_skb()") for IPv4, check FLOWI_FLAG_KNOWN_NH on fl6->flowi6_flags
|
|
instead of testing HDRINCL on the socket to avoid a race condition which
|
|
causes uninit-value access.(CVE-2024-36903)
|
|
|
|
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: lpfc: Release hbalock before calling lpfc_worker_wake_up()
|
|
|
|
lpfc_worker_wake_up() calls the lpfc_work_done() routine, which takes the
|
|
hbalock. Thus, lpfc_worker_wake_up() should not be called while holding the
|
|
hbalock to avoid potential deadlock.(CVE-2024-36924)
|
|
|
|
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:
|
|
|
|
fs/9p: only translate RWX permissions for plain 9P2000
|
|
|
|
Garbage in plain 9P2000's perm bits is allowed through, which causes it
|
|
to be able to set (among others) the suid bit. This was presumably not
|
|
the intent since the unix extended bits are handled explicitly and
|
|
conditionally on .u.(CVE-2024-36964)</Note>
|
|
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-20.03-LTS-SP4.
|
|
|
|
openEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.</Note>
|
|
<Note Title="Severity" Type="General" Ordinal="5" xml:lang="en">High</Note>
|
|
<Note Title="Affected Component" Type="General" Ordinal="6" xml:lang="en">kernel</Note>
|
|
</DocumentNotes>
|
|
<DocumentReferences>
|
|
<Reference Type="Self">
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47236</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47254</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47294</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47315</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47324</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47329</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47403</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47409</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47424</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47460</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47476</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47478</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47479</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47499</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47511</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47518</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47538</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47541</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47542</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47543</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47544</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47547</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52686</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52705</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52753</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52754</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52756</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52774</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52803</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52864</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52865</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52871</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27413</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35809</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35811</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35888</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35896</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35984</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36017</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36029</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36883</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36902</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36903</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-36924</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-36964</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47236</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47254</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47294</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47315</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47324</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47329</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47403</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47409</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47424</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47460</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47476</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47478</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47479</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47499</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47511</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47518</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47538</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47541</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47542</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47543</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47544</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47547</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52686</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52705</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52753</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52754</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52756</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52774</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52803</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52864</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52865</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52871</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27413</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35809</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35811</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35888</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35896</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35984</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36017</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36029</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36883</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36902</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36903</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36917</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36924</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36954</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36964</URL>
|
|
</Reference>
|
|
</DocumentReferences>
|
|
<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
|
|
<Branch Type="Product Name" Name="openEuler">
|
|
<FullProductName ProductID="openEuler-20.03-LTS-SP4" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">openEuler-20.03-LTS-SP4</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="python2-perf-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-devel-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-devel-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debugsource-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-source-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2406.2.0.0281.oe2003sp4.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="bpftool-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-source-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-devel-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-devel-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debugsource-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2406.2.0.0281" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm</FullProductName>
|
|
</Branch>
|
|
</ProductTree>
|
|
<Vulnerability Ordinal="1" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: cdc_eem: fix tx fixup skb leak
|
|
|
|
when usbnet transmit a skb, eem fixup it in eem_tx_fixup(),
|
|
if skb_copy_expand() failed, it return NULL,
|
|
usbnet_start_xmit() will have no chance to free original skb.
|
|
|
|
fix it by free orginal skb in eem_tx_fixup() first,
|
|
then check skb clone status, if failed, return NULL to usbnet.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2021-47236</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
gfs2: Fix use-after-free in gfs2_glock_shrink_scan
|
|
|
|
The GLF_LRU flag is checked under lru_lock in gfs2_glock_remove_from_lru() to
|
|
remove the glock from the lru list in __gfs2_glock_put().
|
|
|
|
On the shrink scan path, the same flag is cleared under lru_lock but because
|
|
of cond_resched_lock(&lru_lock) in gfs2_dispose_glock_lru(), progress on the
|
|
put side can be made without deleting the glock from the lru list.
|
|
|
|
Keep GLF_LRU across the race window opened by cond_resched_lock(&lru_lock) to
|
|
ensure correct behavior on both sides - clear GLF_LRU after list_del under
|
|
lru_lock.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2021-47254</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
netrom: Decrease sock refcount when sock timers expire
|
|
|
|
Commit 63346650c1a9 ("netrom: switch to sock timer API") switched to use
|
|
sock timer API. It replaces mod_timer() by sk_reset_timer(), and
|
|
del_timer() by sk_stop_timer().
|
|
|
|
Function sk_reset_timer() will increase the refcount of sock if it is
|
|
called on an inactive timer, hence, in case the timer expires, we need to
|
|
decrease the refcount ourselves in the handler, otherwise, the sock
|
|
refcount will be unbalanced and the sock will never be freed.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2021-47294</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
memory: fsl_ifc: fix leak of IO mapping on probe failure
|
|
|
|
On probe error the driver should unmap the IO memory. Smatch reports:
|
|
|
|
drivers/memory/fsl_ifc.c:298 fsl_ifc_ctrl_probe() warn: 'fsl_ifc_ctrl_dev->gregs' not released on lines: 298.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2021-47315</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.3</BaseScore>
|
|
<Vector>AV:L/AC: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-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
watchdog: Fix possible use-after-free in wdt_startup()
|
|
|
|
This module's remove path calls del_timer(). However, that function
|
|
does not wait until the timer handler finishes. This means that the
|
|
timer handler may still be running after the driver's remove function
|
|
has finished, which would result in a use-after-free.
|
|
|
|
Fix by calling del_timer_sync(), which makes sure the timer handler
|
|
has finished, and unable to re-schedule itself.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2021-47324</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="6" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="6" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: megaraid_sas: Fix resource leak in case of probe failure
|
|
|
|
The driver doesn't clean up all the allocated resources properly when
|
|
scsi_add_host(), megasas_start_aen() function fails during the PCI device
|
|
probe.
|
|
|
|
Clean up all those resources.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2021-47329</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.3</BaseScore>
|
|
<Vector>AV:L/AC: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-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
ipack: ipoctal: fix module reference leak
|
|
|
|
A reference to the carrier module was taken on every open but was only
|
|
released once when the final reference to the tty struct was dropped.
|
|
|
|
Fix this by taking the module reference and initialising the tty driver
|
|
data when installing the tty.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2021-47403</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
usb: dwc2: check return value after calling platform_get_resource()
|
|
|
|
It will cause null-ptr-deref if platform_get_resource() returns NULL,
|
|
we need check the return value.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2021-47409</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
i40e: Fix freeing of uninitialized misc IRQ vector
|
|
|
|
When VSI set up failed in i40e_probe() as part of PF switch set up
|
|
driver was trying to free misc IRQ vectors in
|
|
i40e_clear_interrupt_scheme and produced a kernel Oops:
|
|
|
|
Trying to free already-free IRQ 266
|
|
WARNING: CPU: 0 PID: 5 at kernel/irq/manage.c:1731 __free_irq+0x9a/0x300
|
|
Workqueue: events work_for_cpu_fn
|
|
RIP: 0010:__free_irq+0x9a/0x300
|
|
Call Trace:
|
|
? synchronize_irq+0x3a/0xa0
|
|
free_irq+0x2e/0x60
|
|
i40e_clear_interrupt_scheme+0x53/0x190 [i40e]
|
|
i40e_probe.part.108+0x134b/0x1a40 [i40e]
|
|
? kmem_cache_alloc+0x158/0x1c0
|
|
? acpi_ut_update_ref_count.part.1+0x8e/0x345
|
|
? acpi_ut_update_object_reference+0x15e/0x1e2
|
|
? strstr+0x21/0x70
|
|
? irq_get_irq_data+0xa/0x20
|
|
? mp_check_pin_attr+0x13/0xc0
|
|
? irq_get_irq_data+0xa/0x20
|
|
? mp_map_pin_to_irq+0xd3/0x2f0
|
|
? acpi_register_gsi_ioapic+0x93/0x170
|
|
? pci_conf1_read+0xa4/0x100
|
|
? pci_bus_read_config_word+0x49/0x70
|
|
? do_pci_enable_device+0xcc/0x100
|
|
local_pci_probe+0x41/0x90
|
|
work_for_cpu_fn+0x16/0x20
|
|
process_one_work+0x1a7/0x360
|
|
worker_thread+0x1cf/0x390
|
|
? create_worker+0x1a0/0x1a0
|
|
kthread+0x112/0x130
|
|
? kthread_flush_work_fn+0x10/0x10
|
|
ret_from_fork+0x1f/0x40
|
|
|
|
The problem is that at that point misc IRQ vectors
|
|
were not allocated yet and we get a call trace
|
|
that driver is trying to free already free IRQ vectors.
|
|
|
|
Add a check in i40e_clear_interrupt_scheme for __I40E_MISC_IRQ_REQUESTED
|
|
PF state before calling i40e_free_misc_vector. This state is set only if
|
|
misc IRQ vectors were properly initialized.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2021-47424</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
ocfs2: fix data corruption after conversion from inline format
|
|
|
|
Commit 6dbf7bb55598 ("fs: Don't invalidate page buffers in
|
|
block_write_full_page()") uncovered a latent bug in ocfs2 conversion
|
|
from inline inode format to a normal inode format.
|
|
|
|
The code in ocfs2_convert_inline_data_to_extents() attempts to zero out
|
|
the whole cluster allocated for file data by grabbing, zeroing, and
|
|
dirtying all pages covering this cluster. However these pages are
|
|
beyond i_size, thus writeback code generally ignores these dirty pages
|
|
and no blocks were ever actually zeroed on the disk.
|
|
|
|
This oversight was fixed by commit 693c241a5f6a ("ocfs2: No need to zero
|
|
pages past i_size.") for standard ocfs2 write path, inline conversion
|
|
path was apparently forgotten; the commit log also has a reasoning why
|
|
the zeroing actually is not needed.
|
|
|
|
After commit 6dbf7bb55598, things became worse as writeback code stopped
|
|
invalidating buffers on pages beyond i_size and thus these pages end up
|
|
with clean PageDirty bit but with buffers attached to these pages being
|
|
still dirty. So when a file is converted from inline format, then
|
|
writeback triggers, and then the file is grown so that these pages
|
|
become valid, the invalid dirtiness state is preserved,
|
|
mark_buffer_dirty() does nothing on these pages (buffers are already
|
|
dirty) but page is never written back because it is clean. So data
|
|
written to these pages is lost once pages are reclaimed.
|
|
|
|
Simple reproducer for the problem is:
|
|
|
|
xfs_io -f -c "pwrite 0 2000" -c "pwrite 2000 2000" -c "fsync" \
|
|
-c "pwrite 4000 2000" ocfs2_file
|
|
|
|
After unmounting and mounting the fs again, you can observe that end of
|
|
'ocfs2_file' has lost its contents.
|
|
|
|
Fix the problem by not doing the pointless zeroing during conversion
|
|
from inline format similarly as in the standard write path.
|
|
|
|
[akpm@linux-foundation.org: fix whitespace, per Joseph]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2021-47460</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
comedi: ni_usb6501: fix NULL-deref in command paths
|
|
|
|
The driver uses endpoint-sized USB transfer buffers but had no sanity
|
|
checks on the sizes. This can lead to zero-size-pointer dereferences or
|
|
overflowed transfer buffers in ni6501_port_command() and
|
|
ni6501_counter_command() if a (malicious) device has smaller max-packet
|
|
sizes than expected (or when doing descriptor fuzz testing).
|
|
|
|
Add the missing sanity checks to probe().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2021-47476</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="12" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="12" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
isofs: Fix out of bound access for corrupted isofs image
|
|
|
|
When isofs image is suitably corrupted isofs_read_inode() can read data
|
|
beyond the end of buffer. Sanity-check the directory entry length before
|
|
using it.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2021-47478</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
staging: rtl8712: fix use-after-free in rtl8712_dl_fw
|
|
|
|
Syzbot reported use-after-free in rtl8712_dl_fw(). The problem was in
|
|
race condition between r871xu_dev_remove() ->ndo_open() callback.
|
|
|
|
It's easy to see from crash log, that driver accesses released firmware
|
|
in ->ndo_open() callback. It may happen, since driver was releasing
|
|
firmware _before_ unregistering netdev. Fix it by moving
|
|
unregister_netdev() before cleaning up resources.
|
|
|
|
Call Trace:
|
|
...
|
|
rtl871x_open_fw drivers/staging/rtl8712/hal_init.c:83 [inline]
|
|
rtl8712_dl_fw+0xd95/0xe10 drivers/staging/rtl8712/hal_init.c:170
|
|
rtl8712_hal_init drivers/staging/rtl8712/hal_init.c:330 [inline]
|
|
rtl871x_hal_init+0xae/0x180 drivers/staging/rtl8712/hal_init.c:394
|
|
netdev_open+0xe6/0x6c0 drivers/staging/rtl8712/os_intfs.c:380
|
|
__dev_open+0x2bc/0x4d0 net/core/dev.c:1484
|
|
|
|
Freed by task 1306:
|
|
...
|
|
release_firmware+0x1b/0x30 drivers/base/firmware_loader/main.c:1053
|
|
r871xu_dev_remove+0xcc/0x2c0 drivers/staging/rtl8712/usb_intf.c:599
|
|
usb_unbind_interface+0x1d8/0x8d0 drivers/usb/core/driver.c:458</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2021-47479</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.4</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
iio: accel: kxcjk-1013: Fix possible memory leak in probe and remove
|
|
|
|
When ACPI type is ACPI_SMO8500, the data->dready_trig will not be set, the
|
|
memory allocated by iio_triggered_buffer_setup() will not be freed, and cause
|
|
memory leak as follows:
|
|
|
|
unreferenced object 0xffff888009551400 (size 512):
|
|
comm "i2c-SMO8500-125", pid 911, jiffies 4294911787 (age 83.852s)
|
|
hex dump (first 32 bytes):
|
|
02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
00 00 00 00 00 00 00 00 20 e2 e5 c0 ff ff ff ff ........ .......
|
|
backtrace:
|
|
[<0000000041ce75ee>] kmem_cache_alloc_trace+0x16d/0x360
|
|
[<000000000aeb17b0>] iio_kfifo_allocate+0x41/0x130 [kfifo_buf]
|
|
[<000000004b40c1f5>] iio_triggered_buffer_setup_ext+0x2c/0x210 [industrialio_triggered_buffer]
|
|
[<000000004375b15f>] kxcjk1013_probe+0x10c3/0x1d81 [kxcjk_1013]
|
|
|
|
Fix it by remove data->dready_trig condition in probe and remove.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2021-47499</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
ALSA: pcm: oss: Fix negative period/buffer sizes
|
|
|
|
The period size calculation in OSS layer may receive a negative value
|
|
as an error, but the code there assumes only the positive values and
|
|
handle them with size_t. Due to that, a too big value may be passed
|
|
to the lower layers.
|
|
|
|
This patch changes the code to handle with ssize_t and adds the proper
|
|
error checks appropriately.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2021-47511</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:nfc: fix potential NULL pointer deref in nfc_genl_dump_ses_doneThe done() netlink callback nfc_genl_dump_ses_done() should check ifreceived argument is non-NULL, because its allocation could fail earlierin dumpit() (nfc_genl_dump_ses()).</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2021-47518</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
rxrpc: Fix rxrpc_local leak in rxrpc_lookup_peer()
|
|
|
|
Need to call rxrpc_put_local() for peer candidate before kfree() as it
|
|
holds a ref to rxrpc_local.
|
|
|
|
[DH: v2: Changed to abstract the peer freeing code out into a function]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2021-47538</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector></Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
net/mlx4_en: Fix an use-after-free bug in mlx4_en_try_alloc_resources()
|
|
|
|
In mlx4_en_try_alloc_resources(), mlx4_en_copy_priv() is called and
|
|
tmp->tx_cq will be freed on the error path of mlx4_en_copy_priv().
|
|
After that mlx4_en_alloc_resources() is called and there is a dereference
|
|
of &tmp->tx_cq[t][i] in mlx4_en_alloc_resources(), which could lead to
|
|
a use after free problem on failure of mlx4_en_copy_priv().
|
|
|
|
Fix this bug by adding a check of mlx4_en_copy_priv()
|
|
|
|
This bug was found by a static analyzer. The analysis employs
|
|
differential checking to identify inconsistent security operations
|
|
(e.g., checks or kfrees) between two code paths and confirms that the
|
|
inconsistent operations are not recovered in the current function or
|
|
the callers, so they constitute bugs.
|
|
|
|
Note that, as a bug found by static analysis, it can be a false
|
|
positive or hard to trigger. Multiple researchers have cross-reviewed
|
|
the bug.
|
|
|
|
Builds with CONFIG_MLX4_EN=m show no new warnings,
|
|
and our static analyzer no longer warns about this code.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2021-47541</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:net: qlogic: qlcnic: Fix a NULL pointer dereference in qlcnic_83xx_add_rings()In qlcnic_83xx_add_rings(), the indirect function ofahw->hw_ops->alloc_mbx_args will be called to allocate memory forcmd.req.arg, and there is a dereference of it in qlcnic_83xx_add_rings(),which could lead to a NULL pointer dereference on failure of theindirect function like qlcnic_83xx_alloc_mbx_args().Fix this bug by adding a check of alloc_mbx_args(), this patchimitates the logic of mbx_cmd() s failure handling.This bug was found by a static analyzer. The analysis employsdifferential checking to identify inconsistent security operations(e.g., checks or kfrees) between two code paths and confirms that theinconsistent operations are not recovered in the current function orthe callers, so they constitute bugs.Note that, as a bug found by static analysis, it can be a falsepositive or hard to trigger. Multiple researchers have cross-reviewedthe bug.Builds with CONFIG_QLCNIC=m show no new warnings, and ourstatic analyzer no longer warns about this code.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2021-47542</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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">Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2021-47543</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
tcp: fix page frag corruption on page fault
|
|
|
|
Steffen reported a TCP stream corruption for HTTP requests
|
|
served by the apache web-server using a cifs mount-point
|
|
and memory mapping the relevant file.
|
|
|
|
The root cause is quite similar to the one addressed by
|
|
commit 20eb4f29b602 ("net: fix sk_page_frag() recursion from
|
|
memory reclaim"). Here the nested access to the task page frag
|
|
is caused by a page fault on the (mmapped) user-space memory
|
|
buffer coming from the cifs file.
|
|
|
|
The page fault handler performs an smb transaction on a different
|
|
socket, inside the same process context. Since sk->sk_allaction
|
|
for such socket does not prevent the usage for the task_frag,
|
|
the nested allocation modify "under the hood" the page frag
|
|
in use by the outer sendmsg call, corrupting the stream.
|
|
|
|
The overall relevant stack trace looks like the following:
|
|
|
|
httpd 78268 [001] 3461630.850950: probe:tcp_sendmsg_locked:
|
|
ffffffff91461d91 tcp_sendmsg_locked+0x1
|
|
ffffffff91462b57 tcp_sendmsg+0x27
|
|
ffffffff9139814e sock_sendmsg+0x3e
|
|
ffffffffc06dfe1d smb_send_kvec+0x28
|
|
[...]
|
|
ffffffffc06cfaf8 cifs_readpages+0x213
|
|
ffffffff90e83c4b read_pages+0x6b
|
|
ffffffff90e83f31 __do_page_cache_readahead+0x1c1
|
|
ffffffff90e79e98 filemap_fault+0x788
|
|
ffffffff90eb0458 __do_fault+0x38
|
|
ffffffff90eb5280 do_fault+0x1a0
|
|
ffffffff90eb7c84 __handle_mm_fault+0x4d4
|
|
ffffffff90eb8093 handle_mm_fault+0xc3
|
|
ffffffff90c74f6d __do_page_fault+0x1ed
|
|
ffffffff90c75277 do_page_fault+0x37
|
|
ffffffff9160111e page_fault+0x1e
|
|
ffffffff9109e7b5 copyin+0x25
|
|
ffffffff9109eb40 _copy_from_iter_full+0xe0
|
|
ffffffff91462370 tcp_sendmsg_locked+0x5e0
|
|
ffffffff91462370 tcp_sendmsg_locked+0x5e0
|
|
ffffffff91462b57 tcp_sendmsg+0x27
|
|
ffffffff9139815c sock_sendmsg+0x4c
|
|
ffffffff913981f7 sock_write_iter+0x97
|
|
ffffffff90f2cc56 do_iter_readv_writev+0x156
|
|
ffffffff90f2dff0 do_iter_write+0x80
|
|
ffffffff90f2e1c3 vfs_writev+0xa3
|
|
ffffffff90f2e27c do_writev+0x5c
|
|
ffffffff90c042bb do_syscall_64+0x5b
|
|
ffffffff916000ad entry_SYSCALL_64_after_hwframe+0x65
|
|
|
|
The cifs filesystem rightfully sets sk_allocations to GFP_NOFS,
|
|
we can avoid the nesting using the sk page frag for allocation
|
|
lacking the __GFP_FS flag. Do not define an additional mm-helper
|
|
for that, as this is strictly tied to the sk page frag usage.
|
|
|
|
v1 -> v2:
|
|
- use a stricted sk_page_frag() check instead of reordering the
|
|
code (Eric)</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2021-47544</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.1</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-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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: tulip: de4x5: fix the problem that the array 'lp->phy[8]' may be out of bound
|
|
|
|
In line 5001, if all id in the array 'lp->phy[8]' is not 0, when the
|
|
'for' end, the 'k' is 8.
|
|
|
|
At this time, the array 'lp->phy[8]' may be out of bound.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2021-47547</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector></Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
powerpc/powernv: Add a null pointer check in opal_event_init()
|
|
|
|
kasprintf() returns a pointer to dynamically allocated memory
|
|
which can be NULL upon failure.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2023-52686</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
nilfs2: fix underflow in second superblock position calculations
|
|
|
|
Macro NILFS_SB2_OFFSET_BYTES, which computes the position of the second
|
|
superblock, underflows when the argument device size is less than 4096
|
|
bytes. Therefore, when using this macro, it is necessary to check in
|
|
advance that the device size is not less than a lower limit, or at least
|
|
that underflow does not occur.
|
|
|
|
The current nilfs2 implementation lacks this check, causing out-of-bound
|
|
block access when mounting devices smaller than 4096 bytes:
|
|
|
|
I/O error, dev loop0, sector 36028797018963960 op 0x0:(READ) flags 0x0
|
|
phys_seg 1 prio class 2
|
|
NILFS (loop0): unable to read secondary superblock (blocksize = 1024)
|
|
|
|
In addition, when trying to resize the filesystem to a size below 4096
|
|
bytes, this underflow occurs in nilfs_resize_fs(), passing a huge number
|
|
of segments to nilfs_sufile_resize(), corrupting parameters such as the
|
|
number of segments in superblocks. This causes excessive loop iterations
|
|
in nilfs_sufile_resize() during a subsequent resize ioctl, causing
|
|
semaphore ns_segctor_sem to block for a long time and hang the writer
|
|
thread:
|
|
|
|
INFO: task segctord:5067 blocked for more than 143 seconds.
|
|
Not tainted 6.2.0-rc8-syzkaller-00015-gf6feea56f66d #0
|
|
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
|
|
task:segctord state:D stack:23456 pid:5067 ppid:2
|
|
flags:0x00004000
|
|
Call Trace:
|
|
<TASK>
|
|
context_switch kernel/sched/core.c:5293 [inline]
|
|
__schedule+0x1409/0x43f0 kernel/sched/core.c:6606
|
|
schedule+0xc3/0x190 kernel/sched/core.c:6682
|
|
rwsem_down_write_slowpath+0xfcf/0x14a0 kernel/locking/rwsem.c:1190
|
|
nilfs_transaction_lock+0x25c/0x4f0 fs/nilfs2/segment.c:357
|
|
nilfs_segctor_thread_construct fs/nilfs2/segment.c:2486 [inline]
|
|
nilfs_segctor_thread+0x52f/0x1140 fs/nilfs2/segment.c:2570
|
|
kthread+0x270/0x300 kernel/kthread.c:376
|
|
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
|
|
</TASK>
|
|
...
|
|
Call Trace:
|
|
<TASK>
|
|
folio_mark_accessed+0x51c/0xf00 mm/swap.c:515
|
|
__nilfs_get_page_block fs/nilfs2/page.c:42 [inline]
|
|
nilfs_grab_buffer+0x3d3/0x540 fs/nilfs2/page.c:61
|
|
nilfs_mdt_submit_block+0xd7/0x8f0 fs/nilfs2/mdt.c:121
|
|
nilfs_mdt_read_block+0xeb/0x430 fs/nilfs2/mdt.c:176
|
|
nilfs_mdt_get_block+0x12d/0xbb0 fs/nilfs2/mdt.c:251
|
|
nilfs_sufile_get_segment_usage_block fs/nilfs2/sufile.c:92 [inline]
|
|
nilfs_sufile_truncate_range fs/nilfs2/sufile.c:679 [inline]
|
|
nilfs_sufile_resize+0x7a3/0x12b0 fs/nilfs2/sufile.c:777
|
|
nilfs_resize_fs+0x20c/0xed0 fs/nilfs2/super.c:422
|
|
nilfs_ioctl_resize fs/nilfs2/ioctl.c:1033 [inline]
|
|
nilfs_ioctl+0x137c/0x2440 fs/nilfs2/ioctl.c:1301
|
|
...
|
|
|
|
This fixes these issues by inserting appropriate minimum device size
|
|
checks or anti-underflow checks, depending on where the macro is used.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2023-52705</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:drm/amd/display: Avoid NULL dereference of timing generator[Why & How]Check whether assigned timing generator is NULL or not beforeaccessing its funcs to prevent NULL dereference.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2023-52753</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
media: imon: fix access to invalid resource for the second interface
|
|
|
|
imon driver probes two USB interfaces, and at the probe of the second
|
|
interface, the driver assumes blindly that the first interface got
|
|
bound with the same imon driver. It's usually true, but it's still
|
|
possible that the first interface is bound with another driver via a
|
|
malformed descriptor. Then it may lead to a memory corruption, as
|
|
spotted by syzkaller; imon driver accesses the data from drvdata as
|
|
struct imon_context object although it's a completely different one
|
|
that was assigned by another driver.
|
|
|
|
This patch adds a sanity check -- whether the first interface is
|
|
really bound with the imon driver or not -- for avoiding the problem
|
|
above at the probe time.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2023-52754</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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">Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2023-52756</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
s390/dasd: protect device queue against concurrent access
|
|
|
|
In dasd_profile_start() the amount of requests on the device queue are
|
|
counted. The access to the device queue is unprotected against
|
|
concurrent access. With a lot of parallel I/O, especially with alias
|
|
devices enabled, the device queue can change while dasd_profile_start()
|
|
is accessing the queue. In the worst case this leads to a kernel panic
|
|
due to incorrect pointer accesses.
|
|
|
|
Fix this by taking the device lock before accessing the queue and
|
|
counting the requests. Additionally the check for a valid profile data
|
|
pointer can be done earlier to avoid unnecessary locking in a hot path.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2023-52774</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
SUNRPC: Fix RPC client cleaned up the freed pipefs dentries
|
|
|
|
RPC client pipefs dentries cleanup is in separated rpc_remove_pipedir()
|
|
workqueue,which takes care about pipefs superblock locking.
|
|
In some special scenarios, when kernel frees the pipefs sb of the
|
|
current client and immediately alloctes a new pipefs sb,
|
|
rpc_remove_pipedir function would misjudge the existence of pipefs
|
|
sb which is not the one it used to hold. As a result,
|
|
the rpc_remove_pipedir would clean the released freed pipefs dentries.
|
|
|
|
To fix this issue, rpc_remove_pipedir should check whether the
|
|
current pipefs sb is consistent with the original pipefs sb.
|
|
|
|
This error can be catched by KASAN:
|
|
=========================================================
|
|
[ 250.497700] BUG: KASAN: slab-use-after-free in dget_parent+0x195/0x200
|
|
[ 250.498315] Read of size 4 at addr ffff88800a2ab804 by task kworker/0:18/106503
|
|
[ 250.500549] Workqueue: events rpc_free_client_work
|
|
[ 250.501001] Call Trace:
|
|
[ 250.502880] kasan_report+0xb6/0xf0
|
|
[ 250.503209] ? dget_parent+0x195/0x200
|
|
[ 250.503561] dget_parent+0x195/0x200
|
|
[ 250.503897] ? __pfx_rpc_clntdir_depopulate+0x10/0x10
|
|
[ 250.504384] rpc_rmdir_depopulate+0x1b/0x90
|
|
[ 250.504781] rpc_remove_client_dir+0xf5/0x150
|
|
[ 250.505195] rpc_free_client_work+0xe4/0x230
|
|
[ 250.505598] process_one_work+0x8ee/0x13b0
|
|
...
|
|
[ 22.039056] Allocated by task 244:
|
|
[ 22.039390] kasan_save_stack+0x22/0x50
|
|
[ 22.039758] kasan_set_track+0x25/0x30
|
|
[ 22.040109] __kasan_slab_alloc+0x59/0x70
|
|
[ 22.040487] kmem_cache_alloc_lru+0xf0/0x240
|
|
[ 22.040889] __d_alloc+0x31/0x8e0
|
|
[ 22.041207] d_alloc+0x44/0x1f0
|
|
[ 22.041514] __rpc_lookup_create_exclusive+0x11c/0x140
|
|
[ 22.041987] rpc_mkdir_populate.constprop.0+0x5f/0x110
|
|
[ 22.042459] rpc_create_client_dir+0x34/0x150
|
|
[ 22.042874] rpc_setup_pipedir_sb+0x102/0x1c0
|
|
[ 22.043284] rpc_client_register+0x136/0x4e0
|
|
[ 22.043689] rpc_new_client+0x911/0x1020
|
|
[ 22.044057] rpc_create_xprt+0xcb/0x370
|
|
[ 22.044417] rpc_create+0x36b/0x6c0
|
|
...
|
|
[ 22.049524] Freed by task 0:
|
|
[ 22.049803] kasan_save_stack+0x22/0x50
|
|
[ 22.050165] kasan_set_track+0x25/0x30
|
|
[ 22.050520] kasan_save_free_info+0x2b/0x50
|
|
[ 22.050921] __kasan_slab_free+0x10e/0x1a0
|
|
[ 22.051306] kmem_cache_free+0xa5/0x390
|
|
[ 22.051667] rcu_core+0x62c/0x1930
|
|
[ 22.051995] __do_softirq+0x165/0x52a
|
|
[ 22.052347]
|
|
[ 22.052503] Last potentially related work creation:
|
|
[ 22.052952] kasan_save_stack+0x22/0x50
|
|
[ 22.053313] __kasan_record_aux_stack+0x8e/0xa0
|
|
[ 22.053739] __call_rcu_common.constprop.0+0x6b/0x8b0
|
|
[ 22.054209] dentry_free+0xb2/0x140
|
|
[ 22.054540] __dentry_kill+0x3be/0x540
|
|
[ 22.054900] shrink_dentry_list+0x199/0x510
|
|
[ 22.055293] shrink_dcache_parent+0x190/0x240
|
|
[ 22.055703] do_one_tree+0x11/0x40
|
|
[ 22.056028] shrink_dcache_for_umount+0x61/0x140
|
|
[ 22.056461] generic_shutdown_super+0x70/0x590
|
|
[ 22.056879] kill_anon_super+0x3a/0x60
|
|
[ 22.057234] rpc_kill_sb+0x121/0x200</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2023-52803</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
platform/x86: wmi: Fix opening of char device
|
|
|
|
Since commit fa1f68db6ca7 ("drivers: misc: pass miscdevice pointer via
|
|
file private data"), the miscdevice stores a pointer to itself inside
|
|
filp->private_data, which means that private_data will not be NULL when
|
|
wmi_char_open() is called. This might cause memory corruption should
|
|
wmi_char_open() be unable to find its driver, something which can
|
|
happen when the associated WMI device is deleted in wmi_free_devices().
|
|
|
|
Fix the problem by using the miscdevice pointer to retrieve the WMI
|
|
device data associated with a char device using container_of(). This
|
|
also avoids wmi_char_open() picking a wrong WMI device bound to a
|
|
driver with the same name as the original driver.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2023-52864</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
clk: mediatek: clk-mt6797: Add check for mtk_alloc_clk_data
|
|
|
|
Add the check for the return value of mtk_alloc_clk_data() in order to
|
|
avoid NULL pointer dereference.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2023-52865</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.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-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
soc: qcom: llcc: Handle a second device without data corruption
|
|
|
|
Usually there is only one llcc device. But if there were a second, even
|
|
a failed probe call would modify the global drv_data pointer. So check
|
|
if drv_data is valid before overwriting it.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2023-52871</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
efi/capsule-loader: fix incorrect allocation size
|
|
|
|
gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures
|
|
is not enough for a 64-bit phys_addr_t:
|
|
|
|
drivers/firmware/efi/capsule-loader.c: In function 'efi_capsule_open':
|
|
drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size '4' for type 'phys_addr_t' {aka 'long long unsigned int'} with size '8' [-Werror=alloc-size]
|
|
295 | cap_info->phys = kzalloc(sizeof(void *), GFP_KERNEL);
|
|
| ^
|
|
|
|
Use the correct type instead here.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-27413</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
PCI/PM: Drain runtime-idle callbacks before driver removal
|
|
|
|
A race condition between the .runtime_idle() callback and the .remove()
|
|
callback in the rtsx_pcr PCI driver leads to a kernel crash due to an
|
|
unhandled page fault [1].
|
|
|
|
The problem is that rtsx_pci_runtime_idle() is not expected to be running
|
|
after pm_runtime_get_sync() has been called, but the latter doesn't really
|
|
guarantee that. It only guarantees that the suspend and resume callbacks
|
|
will not be running when it returns.
|
|
|
|
However, if a .runtime_idle() callback is already running when
|
|
pm_runtime_get_sync() is called, the latter will notice that the runtime PM
|
|
status of the device is RPM_ACTIVE and it will return right away without
|
|
waiting for the former to complete. In fact, it cannot wait for
|
|
.runtime_idle() to complete because it may be called from that callback (it
|
|
arguably does not make much sense to do that, but it is not strictly
|
|
prohibited).
|
|
|
|
Thus in general, whoever is providing a .runtime_idle() callback needs
|
|
to protect it from running in parallel with whatever code runs after
|
|
pm_runtime_get_sync(). [Note that .runtime_idle() will not start after
|
|
pm_runtime_get_sync() has returned, but it may continue running then if it
|
|
has started earlier.]
|
|
|
|
One way to address that race condition is to call pm_runtime_barrier()
|
|
after pm_runtime_get_sync() (not before it, because a nonzero value of the
|
|
runtime PM usage counter is necessary to prevent runtime PM callbacks from
|
|
being invoked) to wait for the .runtime_idle() callback to complete should
|
|
it be running at that point. A suitable place for doing that is in
|
|
pci_device_remove() which calls pm_runtime_get_sync() before removing the
|
|
driver, so it may as well call pm_runtime_barrier() subsequently, which
|
|
will prevent the race in question from occurring, not just in the rtsx_pcr
|
|
driver, but in any PCI drivers providing .runtime_idle() callbacks.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-35809</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.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-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach
|
|
|
|
This is the candidate patch of CVE-2023-47233 :
|
|
https://nvd.nist.gov/vuln/detail/CVE-2023-47233
|
|
|
|
In brcm80211 driver,it starts with the following invoking chain
|
|
to start init a timeout worker:
|
|
|
|
->brcmf_usb_probe
|
|
->brcmf_usb_probe_cb
|
|
->brcmf_attach
|
|
->brcmf_bus_started
|
|
->brcmf_cfg80211_attach
|
|
->wl_init_priv
|
|
->brcmf_init_escan
|
|
->INIT_WORK(&cfg->escan_timeout_work,
|
|
brcmf_cfg80211_escan_timeout_worker);
|
|
|
|
If we disconnect the USB by hotplug, it will call
|
|
brcmf_usb_disconnect to make cleanup. The invoking chain is :
|
|
|
|
brcmf_usb_disconnect
|
|
->brcmf_usb_disconnect_cb
|
|
->brcmf_detach
|
|
->brcmf_cfg80211_detach
|
|
->kfree(cfg);
|
|
|
|
While the timeout woker may still be running. This will cause
|
|
a use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker.
|
|
|
|
Fix it by deleting the timer and canceling the worker in
|
|
brcmf_cfg80211_detach.
|
|
|
|
[arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-35811</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
erspan: make sure erspan_base_hdr is present in skb->head
|
|
|
|
syzbot reported a problem in ip6erspan_rcv() [1]
|
|
|
|
Issue is that ip6erspan_rcv() (and erspan_rcv()) no longer make
|
|
sure erspan_base_hdr is present in skb linear part (skb->head)
|
|
before getting @ver field from it.
|
|
|
|
Add the missing pskb_may_pull() calls.
|
|
|
|
v2: Reload iph pointer in erspan_rcv() after pskb_may_pull()
|
|
because skb->head might have changed.
|
|
|
|
[1]
|
|
|
|
BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2742 [inline]
|
|
BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2756 [inline]
|
|
BUG: KMSAN: uninit-value in ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline]
|
|
BUG: KMSAN: uninit-value in gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610
|
|
pskb_may_pull_reason include/linux/skbuff.h:2742 [inline]
|
|
pskb_may_pull include/linux/skbuff.h:2756 [inline]
|
|
ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline]
|
|
gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610
|
|
ip6_protocol_deliver_rcu+0x1d4c/0x2ca0 net/ipv6/ip6_input.c:438
|
|
ip6_input_finish net/ipv6/ip6_input.c:483 [inline]
|
|
NF_HOOK include/linux/netfilter.h:314 [inline]
|
|
ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492
|
|
ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586
|
|
dst_input include/net/dst.h:460 [inline]
|
|
ip6_rcv_finish+0x955/0x970 net/ipv6/ip6_input.c:79
|
|
NF_HOOK include/linux/netfilter.h:314 [inline]
|
|
ipv6_rcv+0xde/0x390 net/ipv6/ip6_input.c:310
|
|
__netif_receive_skb_one_core net/core/dev.c:5538 [inline]
|
|
__netif_receive_skb+0x1da/0xa00 net/core/dev.c:5652
|
|
netif_receive_skb_internal net/core/dev.c:5738 [inline]
|
|
netif_receive_skb+0x58/0x660 net/core/dev.c:5798
|
|
tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1549
|
|
tun_get_user+0x5566/0x69e0 drivers/net/tun.c:2002
|
|
tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
|
|
call_write_iter include/linux/fs.h:2108 [inline]
|
|
new_sync_write fs/read_write.c:497 [inline]
|
|
vfs_write+0xb63/0x1520 fs/read_write.c:590
|
|
ksys_write+0x20f/0x4c0 fs/read_write.c:643
|
|
__do_sys_write fs/read_write.c:655 [inline]
|
|
__se_sys_write fs/read_write.c:652 [inline]
|
|
__x64_sys_write+0x93/0xe0 fs/read_write.c:652
|
|
do_syscall_64+0xd5/0x1f0
|
|
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
|
|
|
Uninit was created at:
|
|
slab_post_alloc_hook mm/slub.c:3804 [inline]
|
|
slab_alloc_node mm/slub.c:3845 [inline]
|
|
kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888
|
|
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577
|
|
__alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668
|
|
alloc_skb include/linux/skbuff.h:1318 [inline]
|
|
alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504
|
|
sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795
|
|
tun_alloc_skb drivers/net/tun.c:1525 [inline]
|
|
tun_get_user+0x209a/0x69e0 drivers/net/tun.c:1846
|
|
tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
|
|
call_write_iter include/linux/fs.h:2108 [inline]
|
|
new_sync_write fs/read_write.c:497 [inline]
|
|
vfs_write+0xb63/0x1520 fs/read_write.c:590
|
|
ksys_write+0x20f/0x4c0 fs/read_write.c:643
|
|
__do_sys_write fs/read_write.c:655 [inline]
|
|
__se_sys_write fs/read_write.c:652 [inline]
|
|
__x64_sys_write+0x93/0xe0 fs/read_write.c:652
|
|
do_syscall_64+0xd5/0x1f0
|
|
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
|
|
|
CPU: 1 PID: 5045 Comm: syz-executor114 Not tainted 6.9.0-rc1-syzkaller-00021-g962490525cff #0</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-35888</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
netfilter: validate user input for expected length
|
|
|
|
I got multiple syzbot reports showing old bugs exposed
|
|
by BPF after commit 20f2505fb436 ("bpf: Try to avoid kzalloc
|
|
in cgroup/{s,g}etsockopt")
|
|
|
|
setsockopt() @optlen argument should be taken into account
|
|
before copying data.
|
|
|
|
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 do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline]
|
|
BUG: KASAN: slab-out-of-bounds in do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627
|
|
Read of size 96 at addr ffff88802cd73da0 by task syz-executor.4/7238
|
|
|
|
CPU: 1 PID: 7238 Comm: syz-executor.4 Not tainted 6.9.0-rc2-next-20240403-syzkaller #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
|
|
Call Trace:
|
|
<TASK>
|
|
__dump_stack lib/dump_stack.c:88 [inline]
|
|
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
|
|
print_address_description mm/kasan/report.c:377 [inline]
|
|
print_report+0x169/0x550 mm/kasan/report.c:488
|
|
kasan_report+0x143/0x180 mm/kasan/report.c:601
|
|
kasan_check_range+0x282/0x290 mm/kasan/generic.c:189
|
|
__asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105
|
|
copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
|
|
copy_from_sockptr include/linux/sockptr.h:55 [inline]
|
|
do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline]
|
|
do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627
|
|
nf_setsockopt+0x295/0x2c0 net/netfilter/nf_sockopt.c:101
|
|
do_sock_setsockopt+0x3af/0x720 net/socket.c:2311
|
|
__sys_setsockopt+0x1ae/0x250 net/socket.c:2334
|
|
__do_sys_setsockopt net/socket.c:2343 [inline]
|
|
__se_sys_setsockopt net/socket.c:2340 [inline]
|
|
__x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
|
|
do_syscall_64+0xfb/0x240
|
|
entry_SYSCALL_64_after_hwframe+0x72/0x7a
|
|
RIP: 0033:0x7fd22067dde9
|
|
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
|
|
RSP: 002b:00007fd21f9ff0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
|
|
RAX: ffffffffffffffda RBX: 00007fd2207abf80 RCX: 00007fd22067dde9
|
|
RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003
|
|
RBP: 00007fd2206ca47a R08: 0000000000000001 R09: 0000000000000000
|
|
R10: 0000000020000880 R11: 0000000000000246 R12: 0000000000000000
|
|
R13: 000000000000000b R14: 00007fd2207abf80 R15: 00007ffd2d0170d8
|
|
</TASK>
|
|
|
|
Allocated by task 7238:
|
|
kasan_save_stack mm/kasan/common.c:47 [inline]
|
|
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
|
|
poison_kmalloc_redzone mm/kasan/common.c:370 [inline]
|
|
__kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387
|
|
kasan_kmalloc include/linux/kasan.h:211 [inline]
|
|
__do_kmalloc_node mm/slub.c:4069 [inline]
|
|
__kmalloc_noprof+0x200/0x410 mm/slub.c:4082
|
|
kmalloc_noprof include/linux/slab.h:664 [inline]
|
|
__cgroup_bpf_run_filter_setsockopt+0xd47/0x1050 kernel/bpf/cgroup.c:1869
|
|
do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293
|
|
__sys_setsockopt+0x1ae/0x250 net/socket.c:2334
|
|
__do_sys_setsockopt net/socket.c:2343 [inline]
|
|
__se_sys_setsockopt net/socket.c:2340 [inline]
|
|
__x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
|
|
do_syscall_64+0xfb/0x240
|
|
entry_SYSCALL_64_after_hwframe+0x72/0x7a
|
|
|
|
The buggy address belongs to the object at ffff88802cd73da0
|
|
which belongs to the cache kmalloc-8 of size 8
|
|
The buggy address is located 0 bytes inside of
|
|
allocated 1-byte region [ffff88802cd73da0, ffff88802cd73da1)
|
|
|
|
The buggy address belongs to the physical page:
|
|
page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88802cd73020 pfn:0x2cd73
|
|
flags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff)
|
|
page_type: 0xffffefff(slab)
|
|
raw: 00fff80000000000 ffff888015041280 dead000000000100 dead000000000122
|
|
raw: ffff88802cd73020 000000008080007f 00000001ffffefff 00
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-35896</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:i2c: smbus: fix NULL function pointer dereferenceBaruch reported an OOPS when using the designware controller as targetonly. Target-only modes break the assumption of one transfer functionalways being available. Fix this by always checking the pointer in__i2c_transfer.[wsa: dropped the simplification in core-smbus to avoid theoretical regressions]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-35984</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
rtnetlink: Correct nested IFLA_VF_VLAN_LIST attribute validation
|
|
|
|
Each attribute inside a nested IFLA_VF_VLAN_LIST is assumed to be a
|
|
struct ifla_vf_vlan_info so the size of such attribute needs to be at least
|
|
of sizeof(struct ifla_vf_vlan_info) which is 14 bytes.
|
|
The current size validation in do_setvfinfo is against NLA_HDRLEN (4 bytes)
|
|
which is less than sizeof(struct ifla_vf_vlan_info) so this validation
|
|
is not enough and a too small attribute might be cast to a
|
|
struct ifla_vf_vlan_info, this might result in an out of bands
|
|
read access when accessing the saved (casted) entry in ivvl.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-36017</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
mmc: sdhci-msm: pervent access to suspended controller
|
|
|
|
Generic sdhci code registers LED device and uses host->runtime_suspended
|
|
flag to protect access to it. The sdhci-msm driver doesn't set this flag,
|
|
which causes a crash when LED is accessed while controller is runtime
|
|
suspended. Fix this by setting the flag correctly.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-36029</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="41" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="41" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: fix out-of-bounds access in ops_init
|
|
|
|
net_alloc_generic is called by net_alloc, which is called without any
|
|
locking. It reads max_gen_ptrs, which is changed under pernet_ops_rwsem. It
|
|
is read twice, first to allocate an array, then to set s.len, which is
|
|
later used to limit the bounds of the array access.
|
|
|
|
It is possible that the array is allocated and another thread is
|
|
registering a new pernet ops, increments max_gen_ptrs, which is then used
|
|
to set s.len with a larger than allocated length for the variable array.
|
|
|
|
Fix it by reading max_gen_ptrs only once in net_alloc_generic. If
|
|
max_gen_ptrs is later incremented, it will be caught in net_assign_generic.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-36883</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
ipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action()
|
|
|
|
syzbot is able to trigger the following crash [1],
|
|
caused by unsafe ip6_dst_idev() use.
|
|
|
|
Indeed ip6_dst_idev() can return NULL, and must always be checked.
|
|
|
|
[1]
|
|
|
|
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI
|
|
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
|
|
CPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
|
|
RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c:237 [inline]
|
|
RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267
|
|
Code: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 <42> 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c
|
|
RSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246
|
|
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700
|
|
RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760
|
|
RBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd
|
|
R10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000
|
|
R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00
|
|
FS: 00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0
|
|
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
Call Trace:
|
|
<TASK>
|
|
fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317
|
|
fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108
|
|
ip6_route_output_flags_noref net/ipv6/route.c:2637 [inline]
|
|
ip6_route_output_flags+0x38e/0x610 net/ipv6/route.c:2649
|
|
ip6_route_output include/net/ip6_route.h:93 [inline]
|
|
ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120
|
|
ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250
|
|
sctp_v6_get_dst+0x792/0x1e20 net/sctp/ipv6.c:326
|
|
sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455
|
|
sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662
|
|
sctp_connect_new_asoc+0x31d/0x6c0 net/sctp/socket.c:1099
|
|
__sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197
|
|
sctp_connect net/sctp/socket.c:4819 [inline]
|
|
sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834
|
|
__sys_connect_file net/socket.c:2048 [inline]
|
|
__sys_connect+0x2df/0x310 net/socket.c:2065
|
|
__do_sys_connect net/socket.c:2075 [inline]
|
|
__se_sys_connect net/socket.c:2072 [inline]
|
|
__x64_sys_connect+0x7a/0x90 net/socket.c:2072
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-36902</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
ipv6: Fix potential uninit-value access in __ip6_make_skb()
|
|
|
|
As it was done in commit fc1092f51567 ("ipv4: Fix uninit-value access in
|
|
__ip_make_skb()") for IPv4, check FLOWI_FLAG_KNOWN_NH on fl6->flowi6_flags
|
|
instead of testing HDRINCL on the socket to avoid a race condition which
|
|
causes uninit-value access.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-36903</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
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-14</ReleaseDate>
|
|
<CVE>CVE-2024-36917</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector></Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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: Release hbalock before calling lpfc_worker_wake_up()
|
|
|
|
lpfc_worker_wake_up() calls the lpfc_work_done() routine, which takes the
|
|
hbalock. Thus, lpfc_worker_wake_up() should not be called while holding the
|
|
hbalock to avoid potential deadlock.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-36924</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.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-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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-14</ReleaseDate>
|
|
<CVE>CVE-2024-36954</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</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:
|
|
|
|
fs/9p: only translate RWX permissions for plain 9P2000
|
|
|
|
Garbage in plain 9P2000's perm bits is allowed through, which causes it
|
|
to be able to set (among others) the suid bit. This was presumably not
|
|
the intent since the unix extended bits are handled explicitly and
|
|
conditionally on .u.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-36964</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |