5169 lines
218 KiB
XML
5169 lines
218 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
|
|
<DocumentTitle xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP3</DocumentTitle>
|
|
<DocumentType>Security Advisory</DocumentType>
|
|
<DocumentPublisher Type="Vendor">
|
|
<ContactDetails>openeuler-security@openeuler.org</ContactDetails>
|
|
<IssuingAuthority>openEuler security committee</IssuingAuthority>
|
|
</DocumentPublisher>
|
|
<DocumentTracking>
|
|
<Identification>
|
|
<ID>openEuler-SA-2024-1707</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-22.03-LTS-SP3.</Note>
|
|
<Note Title="Description" Type="General" Ordinal="3" xml:lang="en">The Linux Kernel, the operating system core itself.
|
|
|
|
Security Fix(es):
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/mlx5e: Fix use-after-free of encap entry in neigh update handler
|
|
|
|
Function mlx5e_rep_neigh_update() wasn't updated to accommodate rtnl lock
|
|
removal from TC filter update path and properly handle concurrent encap
|
|
entry insertion/deletion which can lead to following use-after-free:
|
|
|
|
[23827.464923] ==================================================================
|
|
[23827.469446] BUG: KASAN: use-after-free in mlx5e_encap_take+0x72/0x140 [mlx5_core]
|
|
[23827.470971] Read of size 4 at addr ffff8881d132228c by task kworker/u20:6/21635
|
|
[23827.472251]
|
|
[23827.472615] CPU: 9 PID: 21635 Comm: kworker/u20:6 Not tainted 5.13.0-rc3+ #5
|
|
[23827.473788] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
|
|
[23827.475639] Workqueue: mlx5e mlx5e_rep_neigh_update [mlx5_core]
|
|
[23827.476731] Call Trace:
|
|
[23827.477260] dump_stack+0xbb/0x107
|
|
[23827.477906] print_address_description.constprop.0+0x18/0x140
|
|
[23827.478896] ? mlx5e_encap_take+0x72/0x140 [mlx5_core]
|
|
[23827.479879] ? mlx5e_encap_take+0x72/0x140 [mlx5_core]
|
|
[23827.480905] kasan_report.cold+0x7c/0xd8
|
|
[23827.481701] ? mlx5e_encap_take+0x72/0x140 [mlx5_core]
|
|
[23827.482744] kasan_check_range+0x145/0x1a0
|
|
[23827.493112] mlx5e_encap_take+0x72/0x140 [mlx5_core]
|
|
[23827.494054] ? mlx5e_tc_tun_encap_info_equal_generic+0x140/0x140 [mlx5_core]
|
|
[23827.495296] mlx5e_rep_neigh_update+0x41e/0x5e0 [mlx5_core]
|
|
[23827.496338] ? mlx5e_rep_neigh_entry_release+0xb80/0xb80 [mlx5_core]
|
|
[23827.497486] ? read_word_at_a_time+0xe/0x20
|
|
[23827.498250] ? strscpy+0xa0/0x2a0
|
|
[23827.498889] process_one_work+0x8ac/0x14e0
|
|
[23827.499638] ? lockdep_hardirqs_on_prepare+0x400/0x400
|
|
[23827.500537] ? pwq_dec_nr_in_flight+0x2c0/0x2c0
|
|
[23827.501359] ? rwlock_bug.part.0+0x90/0x90
|
|
[23827.502116] worker_thread+0x53b/0x1220
|
|
[23827.502831] ? process_one_work+0x14e0/0x14e0
|
|
[23827.503627] kthread+0x328/0x3f0
|
|
[23827.504254] ? _raw_spin_unlock_irq+0x24/0x40
|
|
[23827.505065] ? __kthread_bind_mask+0x90/0x90
|
|
[23827.505912] ret_from_fork+0x1f/0x30
|
|
[23827.506621]
|
|
[23827.506987] Allocated by task 28248:
|
|
[23827.507694] kasan_save_stack+0x1b/0x40
|
|
[23827.508476] __kasan_kmalloc+0x7c/0x90
|
|
[23827.509197] mlx5e_attach_encap+0xde1/0x1d40 [mlx5_core]
|
|
[23827.510194] mlx5e_tc_add_fdb_flow+0x397/0xc40 [mlx5_core]
|
|
[23827.511218] __mlx5e_add_fdb_flow+0x519/0xb30 [mlx5_core]
|
|
[23827.512234] mlx5e_configure_flower+0x191c/0x4870 [mlx5_core]
|
|
[23827.513298] tc_setup_cb_add+0x1d5/0x420
|
|
[23827.514023] fl_hw_replace_filter+0x382/0x6a0 [cls_flower]
|
|
[23827.514975] fl_change+0x2ceb/0x4a51 [cls_flower]
|
|
[23827.515821] tc_new_tfilter+0x89a/0x2070
|
|
[23827.516548] rtnetlink_rcv_msg+0x644/0x8c0
|
|
[23827.517300] netlink_rcv_skb+0x11d/0x340
|
|
[23827.518021] netlink_unicast+0x42b/0x700
|
|
[23827.518742] netlink_sendmsg+0x743/0xc20
|
|
[23827.519467] sock_sendmsg+0xb2/0xe0
|
|
[23827.520131] ____sys_sendmsg+0x590/0x770
|
|
[23827.520851] ___sys_sendmsg+0xd8/0x160
|
|
[23827.521552] __sys_sendmsg+0xb7/0x140
|
|
[23827.522238] do_syscall_64+0x3a/0x70
|
|
[23827.522907] entry_SYSCALL_64_after_hwframe+0x44/0xae
|
|
[23827.523797]
|
|
[23827.524163] Freed by task 25948:
|
|
[23827.524780] kasan_save_stack+0x1b/0x40
|
|
[23827.525488] kasan_set_track+0x1c/0x30
|
|
[23827.526187] kasan_set_free_info+0x20/0x30
|
|
[23827.526968] __kasan_slab_free+0xed/0x130
|
|
[23827.527709] slab_free_freelist_hook+0xcf/0x1d0
|
|
[23827.528528] kmem_cache_free_bulk+0x33a/0x6e0
|
|
[23827.529317] kfree_rcu_work+0x55f/0xb70
|
|
[23827.530024] process_one_work+0x8ac/0x14e0
|
|
[23827.530770] worker_thread+0x53b/0x1220
|
|
[23827.531480] kthread+0x328/0x3f0
|
|
[23827.532114] ret_from_fork+0x1f/0x30
|
|
[23827.532785]
|
|
[23827.533147] Last potentially related work creation:
|
|
[23827.534007] kasan_save_stack+0x1b/0x40
|
|
[23827.534710] kasan_record_aux_stack+0xab/0xc0
|
|
[23827.535492] kvfree_call_rcu+0x31/0x7b0
|
|
[23827.536206] mlx5e_tc_del
|
|
---truncated---(CVE-2021-47247)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
octeontx2-af: Fix possible null pointer dereference.
|
|
|
|
This patch fixes possible null pointer dereference in files
|
|
"rvu_debugfs.c" and "rvu_nix.c"(CVE-2021-47484)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: stmmac: Disable Tx queues when reconfiguring the interface
|
|
|
|
The Tx queues were not disabled in situations where the driver needed to
|
|
stop the interface to apply a new configuration. This could result in a
|
|
kernel panic when doing any of the 3 following actions:
|
|
* reconfiguring the number of queues (ethtool -L)
|
|
* reconfiguring the size of the ring buffers (ethtool -G)
|
|
* installing/removing an XDP program (ip l set dev ethX xdp)
|
|
|
|
Prevent the panic by making sure netif_tx_disable is called when stopping
|
|
an interface.
|
|
|
|
Without this patch, the following kernel panic can be observed when doing
|
|
any of the actions above:
|
|
|
|
Unable to handle kernel paging request at virtual address ffff80001238d040
|
|
[....]
|
|
Call trace:
|
|
dwmac4_set_addr+0x8/0x10
|
|
dev_hard_start_xmit+0xe4/0x1ac
|
|
sch_direct_xmit+0xe8/0x39c
|
|
__dev_queue_xmit+0x3ec/0xaf0
|
|
dev_queue_xmit+0x14/0x20
|
|
[...]
|
|
[ end trace 0000000000000002 ]---(CVE-2021-47558)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ice: Fix crash by keep old cfg when update TCs more than queues
|
|
|
|
There are problems if allocated queues less than Traffic Classes.
|
|
|
|
Commit a632b2a4c920 ("ice: ethtool: Prohibit improper channel config
|
|
for DCB") already disallow setting less queues than TCs.
|
|
|
|
Another case is if we first set less queues, and later update more TCs
|
|
config due to LLDP, ice_vsi_cfg_tc() will failed but left dirty
|
|
num_txq/rxq and tc_cfg in vsi, that will cause invalid pointer access.
|
|
|
|
[ 95.968089] ice 0000:3b:00.1: More TCs defined than queues/rings allocated.
|
|
[ 95.968092] ice 0000:3b:00.1: Trying to use more Rx queues (8), than were allocated (1)!
|
|
[ 95.968093] ice 0000:3b:00.1: Failed to config TC for VSI index: 0
|
|
[ 95.969621] general protection fault: 0000 [#1] SMP NOPTI
|
|
[ 95.969705] CPU: 1 PID: 58405 Comm: lldpad Kdump: loaded Tainted: G U W O --------- -t - 4.18.0 #1
|
|
[ 95.969867] Hardware name: O.E.M/BC11SPSCB10, BIOS 8.23 12/30/2021
|
|
[ 95.969992] RIP: 0010:devm_kmalloc+0xa/0x60
|
|
[ 95.970052] Code: 5c ff ff ff 31 c0 5b 5d 41 5c c3 b8 f4 ff ff ff eb f4 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 89 d1 <8b> 97 60 02 00 00 48 8d 7e 18 48 39 f7 72 3f 55 89 ce 53 48 8b 4c
|
|
[ 95.970344] RSP: 0018:ffffc9003f553888 EFLAGS: 00010206
|
|
[ 95.970425] RAX: dead000000000200 RBX: ffffea003c425b00 RCX: 00000000006080c0
|
|
[ 95.970536] RDX: 00000000006080c0 RSI: 0000000000000200 RDI: dead000000000200
|
|
[ 95.970648] RBP: dead000000000200 R08: 00000000000463c0 R09: ffff888ffa900000
|
|
[ 95.970760] R10: 0000000000000000 R11: 0000000000000002 R12: ffff888ff6b40100
|
|
[ 95.970870] R13: ffff888ff6a55018 R14: 0000000000000000 R15: ffff888ff6a55460
|
|
[ 95.970981] FS: 00007f51b7d24700(0000) GS:ffff88903ee80000(0000) knlGS:0000000000000000
|
|
[ 95.971108] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 95.971197] CR2: 00007fac5410d710 CR3: 0000000f2c1de002 CR4: 00000000007606e0
|
|
[ 95.971309] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
[ 95.971419] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
[ 95.971530] PKRU: 55555554
|
|
[ 95.971573] Call Trace:
|
|
[ 95.971622] ice_setup_rx_ring+0x39/0x110 [ice]
|
|
[ 95.971695] ice_vsi_setup_rx_rings+0x54/0x90 [ice]
|
|
[ 95.971774] ice_vsi_open+0x25/0x120 [ice]
|
|
[ 95.971843] ice_open_internal+0xb8/0x1f0 [ice]
|
|
[ 95.971919] ice_ena_vsi+0x4f/0xd0 [ice]
|
|
[ 95.971987] ice_dcb_ena_dis_vsi.constprop.5+0x29/0x90 [ice]
|
|
[ 95.972082] ice_pf_dcb_cfg+0x29a/0x380 [ice]
|
|
[ 95.972154] ice_dcbnl_setets+0x174/0x1b0 [ice]
|
|
[ 95.972220] dcbnl_ieee_set+0x89/0x230
|
|
[ 95.972279] ? dcbnl_ieee_del+0x150/0x150
|
|
[ 95.972341] dcb_doit+0x124/0x1b0
|
|
[ 95.972392] rtnetlink_rcv_msg+0x243/0x2f0
|
|
[ 95.972457] ? dcb_doit+0x14d/0x1b0
|
|
[ 95.972510] ? __kmalloc_node_track_caller+0x1d3/0x280
|
|
[ 95.972591] ? rtnl_calcit.isra.31+0x100/0x100
|
|
[ 95.972661] netlink_rcv_skb+0xcf/0xf0
|
|
[ 95.972720] netlink_unicast+0x16d/0x220
|
|
[ 95.972781] netlink_sendmsg+0x2ba/0x3a0
|
|
[ 95.975891] sock_sendmsg+0x4c/0x50
|
|
[ 95.979032] ___sys_sendmsg+0x2e4/0x300
|
|
[ 95.982147] ? kmem_cache_alloc+0x13e/0x190
|
|
[ 95.985242] ? __wake_up_common_lock+0x79/0x90
|
|
[ 95.988338] ? __check_object_size+0xac/0x1b0
|
|
[ 95.991440] ? _copy_to_user+0x22/0x30
|
|
[ 95.994539] ? move_addr_to_user+0xbb/0xd0
|
|
[ 95.997619] ? __sys_sendmsg+0x53/0x80
|
|
[ 96.000664] __sys_sendmsg+0x53/0x80
|
|
[ 96.003747] do_syscall_64+0x5b/0x1d0
|
|
[ 96.006862] entry_SYSCALL_64_after_hwframe+0x65/0xca
|
|
|
|
Only update num_txq/rxq when passed check, and restore tc_cfg if setup
|
|
queue map failed.(CVE-2022-48652)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
pipe: wakeup wr_wait after setting max_usage
|
|
|
|
Commit c73be61cede5 ("pipe: Add general notification queue support") a
|
|
regression was introduced that would lock up resized pipes under certain
|
|
conditions. See the reproducer in [1].
|
|
|
|
The commit resizing the pipe ring size was moved to a different
|
|
function, doing that moved the wakeup for pipe->wr_wait before actually
|
|
raising pipe->max_usage. If a pipe was full before the resize occured it
|
|
would result in the wakeup never actually triggering pipe_write.
|
|
|
|
Set @max_usage and @nr_accounted before waking writers if this isn't a
|
|
watch queue.
|
|
|
|
[Christian Brauner <brauner@kernel.org>: rewrite to account for watch queues](CVE-2023-52672)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ALSA: scarlett2: Add missing error checks to *_ctl_get()
|
|
|
|
The *_ctl_get() functions which call scarlett2_update_*() were not
|
|
checking the return value. Fix to check the return value and pass to
|
|
the caller.(CVE-2023-52680)
|
|
|
|
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:
|
|
|
|
ACPI: video: check for error while searching for backlight device parent
|
|
|
|
If acpi_get_parent() called in acpi_video_dev_register_backlight()
|
|
fails, for example, because acpi_ut_acquire_mutex() fails inside
|
|
acpi_get_parent), this can lead to incorrect (uninitialized)
|
|
acpi_parent handle being passed to acpi_get_pci_dev() for detecting
|
|
the parent pci device.
|
|
|
|
Check acpi_get_parent() result and set parent device only in case of success.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52693)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ceph: blocklist the kclient when receiving corrupted snap trace
|
|
|
|
When received corrupted snap trace we don't know what exactly has
|
|
happened in MDS side. And we shouldn't continue IOs and metadatas
|
|
access to MDS, which may corrupt or get incorrect contents.
|
|
|
|
This patch will just block all the further IO/MDS requests
|
|
immediately and then evict the kclient itself.
|
|
|
|
The reason why we still need to evict the kclient just after
|
|
blocking all the further IOs is that the MDS could revoke the caps
|
|
faster.(CVE-2023-52732)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
virtio-blk: fix implicit overflow on virtio_max_dma_size
|
|
|
|
The following codes have an implicit conversion from size_t to u32:
|
|
(u32)max_size = (size_t)virtio_max_dma_size(vdev);
|
|
|
|
This may lead overflow, Ex (size_t)4G -> (u32)0. Once
|
|
virtio_max_dma_size() has a larger size than U32_MAX, use U32_MAX
|
|
instead.(CVE-2023-52762)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/smc: avoid data corruption caused by decline
|
|
|
|
We found a data corruption issue during testing of SMC-R on Redis
|
|
applications.
|
|
|
|
The benchmark has a low probability of reporting a strange error as
|
|
shown below.
|
|
|
|
"Error: Protocol error, got "\xe2" as reply type byte"
|
|
|
|
Finally, we found that the retrieved error data was as follows:
|
|
|
|
0xE2 0xD4 0xC3 0xD9 0x04 0x00 0x2C 0x20 0xA6 0x56 0x00 0x16 0x3E 0x0C
|
|
0xCB 0x04 0x02 0x01 0x00 0x00 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00
|
|
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xE2
|
|
|
|
It is quite obvious that this is a SMC DECLINE message, which means that
|
|
the applications received SMC protocol message.
|
|
We found that this was caused by the following situations:
|
|
|
|
client server
|
|
¦ clc proposal
|
|
------------->
|
|
¦ clc accept
|
|
<-------------
|
|
¦ clc confirm
|
|
------------->
|
|
wait llc confirm
|
|
send llc confirm
|
|
¦failed llc confirm
|
|
¦ x------
|
|
(after 2s)timeout
|
|
wait llc confirm rsp
|
|
|
|
wait decline
|
|
|
|
(after 1s) timeout
|
|
(after 2s) timeout
|
|
¦ decline
|
|
-------------->
|
|
¦ decline
|
|
<--------------
|
|
|
|
As a result, a decline message was sent in the implementation, and this
|
|
message was read from TCP by the already-fallback connection.
|
|
|
|
This patch double the client timeout as 2x of the server value,
|
|
With this simple change, the Decline messages should never cross or
|
|
collide (during Confirm link timeout).
|
|
|
|
This issue requires an immediate solution, since the protocol updates
|
|
involve a more long-term solution.(CVE-2023-52775)
|
|
|
|
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:
|
|
|
|
fs/jfs: Add check for negative db_l2nbperpage
|
|
|
|
l2nbperpage is log2(number of blks per page), and the minimum legal
|
|
value should be 0, not negative.
|
|
|
|
In the case of l2nbperpage being negative, an error will occur
|
|
when subsequently used as shift exponent.
|
|
|
|
Syzbot reported this bug:
|
|
|
|
UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:799:12
|
|
shift exponent -16777216 is negative(CVE-2023-52810)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc
|
|
|
|
Any unprivileged user can attach N_GSM0710 ldisc, but it requires
|
|
CAP_NET_ADMIN to create a GSM network anyway.
|
|
|
|
Require initial namespace CAP_NET_ADMIN to do that.(CVE-2023-52880)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tcp: do not accept ACK of bytes we never sent
|
|
|
|
This patch is based on a detailed report and ideas from Yepeng Pan
|
|
and Christian Rossow.
|
|
|
|
ACK seq validation is currently following RFC 5961 5.2 guidelines:
|
|
|
|
The ACK value is considered acceptable only if
|
|
it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <=
|
|
SND.NXT). All incoming segments whose ACK value doesn't satisfy the
|
|
above condition MUST be discarded and an ACK sent back. It needs to
|
|
be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a
|
|
duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK
|
|
acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an
|
|
ACK, drop the segment, and return". The "ignored" above implies that
|
|
the processing of the incoming data segment continues, which means
|
|
the ACK value is treated as acceptable. This mitigation makes the
|
|
ACK check more stringent since any ACK < SND.UNA wouldn't be
|
|
accepted, instead only ACKs that are in the range ((SND.UNA -
|
|
MAX.SND.WND) <= SEG.ACK <= SND.NXT) get through.
|
|
|
|
This can be refined for new (and possibly spoofed) flows,
|
|
by not accepting ACK for bytes that were never sent.
|
|
|
|
This greatly improves TCP security at a little cost.
|
|
|
|
I added a Fixes: tag to make sure this patch will reach stable trees,
|
|
even if the 'blamed' patch was adhering to the RFC.
|
|
|
|
tp->bytes_acked was added in linux-4.2
|
|
|
|
Following packetdrill test (courtesy of Yepeng Pan) shows
|
|
the issue at hand:
|
|
|
|
0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
|
|
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
|
|
+0 bind(3, ..., ...) = 0
|
|
+0 listen(3, 1024) = 0
|
|
|
|
// ---------------- Handshake ------------------- //
|
|
|
|
// when window scale is set to 14 the window size can be extended to
|
|
// 65535 * (2^14) = 1073725440. Linux would accept an ACK packet
|
|
// with ack number in (Server_ISN+1-1073725440. Server_ISN+1)
|
|
// ,though this ack number acknowledges some data never
|
|
// sent by the server.
|
|
|
|
+0 < S 0:0(0) win 65535 <mss 1400,nop,wscale 14>
|
|
+0 > S. 0:0(0) ack 1 <...>
|
|
+0 < . 1:1(0) ack 1 win 65535
|
|
+0 accept(3, ..., ...) = 4
|
|
|
|
// For the established connection, we send an ACK packet,
|
|
// the ack packet uses ack number 1 - 1073725300 + 2^32,
|
|
// where 2^32 is used to wrap around.
|
|
// Note: we used 1073725300 instead of 1073725440 to avoid possible
|
|
// edge cases.
|
|
// 1 - 1073725300 + 2^32 = 3221241997
|
|
|
|
// Oops, old kernels happily accept this packet.
|
|
+0 < . 1:1001(1000) ack 3221241997 win 65535
|
|
|
|
// After the kernel fix the following will be replaced by a challenge ACK,
|
|
// and prior malicious frame would be dropped.
|
|
+0 > . 1:1(0) ack 1001(CVE-2023-52881)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nf_tables: set dormant flag on hook register failure
|
|
|
|
We need to set the dormant flag again if we fail to register
|
|
the hooks.
|
|
|
|
During memory pressure hook registration can fail and we end up
|
|
with a table marked as active but no registered hooks.
|
|
|
|
On table/base chain deletion, nf_tables will attempt to unregister
|
|
the hook again which yields a warn splat from the nftables core.(CVE-2024-26835)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Bluetooth: hci_core: Fix possible buffer overflow
|
|
|
|
struct hci_dev_info has a fixed size name[8] field so in the event that
|
|
hdev->name is bigger than that strcpy would attempt to write past its
|
|
size, so this fixes this problem by switching to use strscpy.(CVE-2024-26889)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
xen-netfront: Add missing skb_mark_for_recycle
|
|
|
|
Notice that skb_mark_for_recycle() is introduced later than fixes tag in
|
|
commit 6a5bcd84e886 ("page_pool: Allow drivers to hint on SKB recycling").
|
|
|
|
It is believed that fixes tag were missing a call to page_pool_release_page()
|
|
between v5.9 to v5.14, after which is should have used skb_mark_for_recycle().
|
|
Since v6.6 the call page_pool_release_page() were removed (in
|
|
commit 535b9c61bdef ("net: page_pool: hide page_pool_release_page()")
|
|
and remaining callers converted (in commit 6bfef2ec0172 ("Merge branch
|
|
'net-page_pool-remove-page_pool_release_page'")).
|
|
|
|
This leak became visible in v6.8 via commit dba1b8a7ab68 ("mm/page_pool: catch
|
|
page_pool memory leaks").(CVE-2024-27393)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
phonet/pep: fix racy skb_queue_empty() use
|
|
|
|
The receive queues are protected by their respective spin-lock, not
|
|
the socket lock. This could lead to skb_peek() unexpectedly
|
|
returning NULL or a pointer to an already dequeued socket buffer.(CVE-2024-27402)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
dmaengine: dw-edma: eDMA: Add sync read before starting the DMA transfer in remote setup
|
|
|
|
The Linked list element and pointer are not stored in the same memory as
|
|
the eDMA controller register. If the doorbell register is toggled before
|
|
the full write of the linked list a race condition error will occur.
|
|
In remote setup we can only use a readl to the memory to assure the full
|
|
write has occurred.(CVE-2024-27408)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
usb: typec: altmodes/displayport: create sysfs nodes as driver's default device attribute group
|
|
|
|
The DisplayPort driver's sysfs nodes may be present to the userspace before
|
|
typec_altmode_set_drvdata() completes in dp_altmode_probe. This means that
|
|
a sysfs read can trigger a NULL pointer error by deferencing dp->hpd in
|
|
hpd_show or dp->lock in pin_assignment_show, as dev_get_drvdata() returns
|
|
NULL in those cases.
|
|
|
|
Remove manual sysfs node creation in favor of adding attribute group as
|
|
default for devices bound to the driver. The ATTRIBUTE_GROUPS() macro is
|
|
not used here otherwise the path to the sysfs nodes is no longer compliant
|
|
with the ABI.(CVE-2024-35790)
|
|
|
|
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:
|
|
|
|
mlxsw: spectrum_acl_tcam: Fix memory leak during rehash
|
|
|
|
The rehash delayed work migrates filters from one region to another.
|
|
This is done by iterating over all chunks (all the filters with the same
|
|
priority) in the region and in each chunk iterating over all the
|
|
filters.
|
|
|
|
If the migration fails, the code tries to migrate the filters back to
|
|
the old region. However, the rollback itself can also fail in which case
|
|
another migration will be erroneously performed. Besides the fact that
|
|
this ping pong is not a very good idea, it also creates a problem.
|
|
|
|
Each virtual chunk references two chunks: The currently used one
|
|
('vchunk->chunk') and a backup ('vchunk->chunk2'). During migration the
|
|
first holds the chunk we want to migrate filters to and the second holds
|
|
the chunk we are migrating filters from.
|
|
|
|
The code currently assumes - but does not verify - that the backup chunk
|
|
does not exist (NULL) if the currently used chunk does not reference the
|
|
target region. This assumption breaks when we are trying to rollback a
|
|
rollback, resulting in the backup chunk being overwritten and leaked
|
|
[1].
|
|
|
|
Fix by not rolling back a failed rollback and add a warning to avoid
|
|
future cases.
|
|
|
|
[1]
|
|
WARNING: CPU: 5 PID: 1063 at lib/parman.c:291 parman_destroy+0x17/0x20
|
|
Modules linked in:
|
|
CPU: 5 PID: 1063 Comm: kworker/5:11 Tainted: G W 6.9.0-rc2-custom-00784-gc6a05c468a0b #14
|
|
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
|
|
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
|
|
RIP: 0010:parman_destroy+0x17/0x20
|
|
[...]
|
|
Call Trace:
|
|
<TASK>
|
|
mlxsw_sp_acl_atcam_region_fini+0x19/0x60
|
|
mlxsw_sp_acl_tcam_region_destroy+0x49/0xf0
|
|
mlxsw_sp_acl_tcam_vregion_rehash_work+0x1f1/0x470
|
|
process_one_work+0x151/0x370
|
|
worker_thread+0x2cb/0x3e0
|
|
kthread+0xd0/0x100
|
|
ret_from_fork+0x34/0x50
|
|
ret_from_fork_asm+0x1a/0x30
|
|
</TASK>(CVE-2024-35853)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehash
|
|
|
|
The rehash delayed work migrates filters from one region to another
|
|
according to the number of available credits.
|
|
|
|
The migrated from region is destroyed at the end of the work if the
|
|
number of credits is non-negative as the assumption is that this is
|
|
indicative of migration being complete. This assumption is incorrect as
|
|
a non-negative number of credits can also be the result of a failed
|
|
migration.
|
|
|
|
The destruction of a region that still has filters referencing it can
|
|
result in a use-after-free [1].
|
|
|
|
Fix by not destroying the region if migration failed.
|
|
|
|
[1]
|
|
BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230
|
|
Read of size 8 at addr ffff8881735319e8 by task kworker/0:31/3858
|
|
|
|
CPU: 0 PID: 3858 Comm: kworker/0:31 Tainted: G W 6.9.0-rc2-custom-00782-gf2275c2157d8 #5
|
|
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
|
|
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
|
|
Call Trace:
|
|
<TASK>
|
|
dump_stack_lvl+0xc6/0x120
|
|
print_report+0xce/0x670
|
|
kasan_report+0xd7/0x110
|
|
mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230
|
|
mlxsw_sp_acl_ctcam_entry_del+0x2e/0x70
|
|
mlxsw_sp_acl_atcam_entry_del+0x81/0x210
|
|
mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3cd/0xb50
|
|
mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300
|
|
process_one_work+0x8eb/0x19b0
|
|
worker_thread+0x6c9/0xf70
|
|
kthread+0x2c9/0x3b0
|
|
ret_from_fork+0x4d/0x80
|
|
ret_from_fork_asm+0x1a/0x30
|
|
</TASK>
|
|
|
|
Allocated by task 174:
|
|
kasan_save_stack+0x33/0x60
|
|
kasan_save_track+0x14/0x30
|
|
__kasan_kmalloc+0x8f/0xa0
|
|
__kmalloc+0x19c/0x360
|
|
mlxsw_sp_acl_tcam_region_create+0xdf/0x9c0
|
|
mlxsw_sp_acl_tcam_vregion_rehash_work+0x954/0x1300
|
|
process_one_work+0x8eb/0x19b0
|
|
worker_thread+0x6c9/0xf70
|
|
kthread+0x2c9/0x3b0
|
|
ret_from_fork+0x4d/0x80
|
|
ret_from_fork_asm+0x1a/0x30
|
|
|
|
Freed by task 7:
|
|
kasan_save_stack+0x33/0x60
|
|
kasan_save_track+0x14/0x30
|
|
kasan_save_free_info+0x3b/0x60
|
|
poison_slab_object+0x102/0x170
|
|
__kasan_slab_free+0x14/0x30
|
|
kfree+0xc1/0x290
|
|
mlxsw_sp_acl_tcam_region_destroy+0x272/0x310
|
|
mlxsw_sp_acl_tcam_vregion_rehash_work+0x731/0x1300
|
|
process_one_work+0x8eb/0x19b0
|
|
worker_thread+0x6c9/0xf70
|
|
kthread+0x2c9/0x3b0
|
|
ret_from_fork+0x4d/0x80
|
|
ret_from_fork_asm+0x1a/0x30(CVE-2024-35854)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
riscv: process: Fix kernel gp leakage
|
|
|
|
childregs represents the registers which are active for the new thread
|
|
in user context. For a kernel thread, childregs->gp is never used since
|
|
the kernel gp is not touched by switch_to. For a user mode helper, the
|
|
gp value can be observed in user space after execve or possibly by other
|
|
means.
|
|
|
|
[From the email thread]
|
|
|
|
The /* Kernel thread */ comment is somewhat inaccurate in that it is also used
|
|
for user_mode_helper threads, which exec a user process, e.g. /sbin/init or
|
|
when /proc/sys/kernel/core_pattern is a pipe. Such threads do not have
|
|
PF_KTHREAD set and are valid targets for ptrace etc. even before they exec.
|
|
|
|
childregs is the *user* context during syscall execution and it is observable
|
|
from userspace in at least five ways:
|
|
|
|
1. kernel_execve does not currently clear integer registers, so the starting
|
|
register state for PID 1 and other user processes started by the kernel has
|
|
sp = user stack, gp = kernel __global_pointer$, all other integer registers
|
|
zeroed by the memset in the patch comment.
|
|
|
|
This is a bug in its own right, but I'm unwilling to bet that it is the only
|
|
way to exploit the issue addressed by this patch.
|
|
|
|
2. ptrace(PTRACE_GETREGSET): you can PTRACE_ATTACH to a user_mode_helper thread
|
|
before it execs, but ptrace requires SIGSTOP to be delivered which can only
|
|
happen at user/kernel boundaries.
|
|
|
|
3. /proc/*/task/*/syscall: this is perfectly happy to read pt_regs for
|
|
user_mode_helpers before the exec completes, but gp is not one of the
|
|
registers it returns.
|
|
|
|
4. PERF_SAMPLE_REGS_USER: LOCKDOWN_PERF normally prevents access to kernel
|
|
addresses via PERF_SAMPLE_REGS_INTR, but due to this bug kernel addresses
|
|
are also exposed via PERF_SAMPLE_REGS_USER which is permitted under
|
|
LOCKDOWN_PERF. I have not attempted to write exploit code.
|
|
|
|
5. Much of the tracing infrastructure allows access to user registers. I have
|
|
not attempted to determine which forms of tracing allow access to user
|
|
registers without already allowing access to kernel registers.(CVE-2024-35871)
|
|
|
|
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:
|
|
|
|
bpf, sockmap: Prevent lock inversion deadlock in map delete elem
|
|
|
|
syzkaller started using corpuses where a BPF tracing program deletes
|
|
elements from a sockmap/sockhash map. Because BPF tracing programs can be
|
|
invoked from any interrupt context, locks taken during a map_delete_elem
|
|
operation must be hardirq-safe. Otherwise a deadlock due to lock inversion
|
|
is possible, as reported by lockdep:
|
|
|
|
CPU0 CPU1
|
|
---- ----
|
|
lock(&htab->buckets[i].lock);
|
|
local_irq_disable();
|
|
lock(&host->lock);
|
|
lock(&htab->buckets[i].lock);
|
|
<Interrupt>
|
|
lock(&host->lock);
|
|
|
|
Locks in sockmap are hardirq-unsafe by design. We expects elements to be
|
|
deleted from sockmap/sockhash only in task (normal) context with interrupts
|
|
enabled, or in softirq context.
|
|
|
|
Detect when map_delete_elem operation is invoked from a context which is
|
|
_not_ hardirq-unsafe, that is interrupts are disabled, and bail out with an
|
|
error.
|
|
|
|
Note that map updates are not affected by this issue. BPF verifier does not
|
|
allow updating sockmap/sockhash from a BPF tracing program today.(CVE-2024-35895)
|
|
|
|
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:
|
|
|
|
bpf: Protect against int overflow for stack access size
|
|
|
|
This patch re-introduces protection against the size of access to stack
|
|
memory being negative; the access size can appear negative as a result
|
|
of overflowing its signed int representation. This should not actually
|
|
happen, as there are other protections along the way, but we should
|
|
protect against it anyway. One code path was missing such protections
|
|
(fixed in the previous patch in the series), causing out-of-bounds array
|
|
accesses in check_stack_range_initialized(). This patch causes the
|
|
verification of a program with such a non-sensical access size to fail.
|
|
|
|
This check used to exist in a more indirect way, but was inadvertendly
|
|
removed in a833a17aeac7.(CVE-2024-35905)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
usb: typec: ucsi: Limit read size on v1.2
|
|
|
|
Between UCSI 1.2 and UCSI 2.0, the size of the MESSAGE_IN region was
|
|
increased from 16 to 256. In order to avoid overflowing reads for older
|
|
systems, add a mechanism to use the read UCSI version to truncate read
|
|
sizes on UCSI v1.2.(CVE-2024-35924)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Bluetooth: SCO: Fix not validating setsockopt user input
|
|
|
|
syzbot reported sco_sock_setsockopt() is copying data without
|
|
checking user input length.
|
|
|
|
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset
|
|
include/linux/sockptr.h:49 [inline]
|
|
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr
|
|
include/linux/sockptr.h:55 [inline]
|
|
BUG: KASAN: slab-out-of-bounds in sco_sock_setsockopt+0xc0b/0xf90
|
|
net/bluetooth/sco.c:893
|
|
Read of size 4 at addr ffff88805f7b15a3 by task syz-executor.5/12578(CVE-2024-35967)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
geneve: fix header validation in geneve[6]_xmit_skb
|
|
|
|
syzbot is able to trigger an uninit-value in geneve_xmit() [1]
|
|
|
|
Problem : While most ip tunnel helpers (like ip_tunnel_get_dsfield())
|
|
uses skb_protocol(skb, true), pskb_inet_may_pull() is only using
|
|
skb->protocol.
|
|
|
|
If anything else than ETH_P_IPV6 or ETH_P_IP is found in skb->protocol,
|
|
pskb_inet_may_pull() does nothing at all.
|
|
|
|
If a vlan tag was provided by the caller (af_packet in the syzbot case),
|
|
the network header might not point to the correct location, and skb
|
|
linear part could be smaller than expected.
|
|
|
|
Add skb_vlan_inet_prepare() to perform a complete mac validation.
|
|
|
|
Use this in geneve for the moment, I suspect we need to adopt this
|
|
more broadly.
|
|
|
|
v4 - Jakub reported v3 broke l2_tos_ttl_inherit.sh selftest
|
|
- Only call __vlan_get_protocol() for vlan types.
|
|
|
|
v2,v3 - Addressed Sabrina comments on v1 and v2
|
|
|
|
[1]
|
|
|
|
BUG: KMSAN: uninit-value in geneve_xmit_skb drivers/net/geneve.c:910 [inline]
|
|
BUG: KMSAN: uninit-value in geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030
|
|
geneve_xmit_skb drivers/net/geneve.c:910 [inline]
|
|
geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030
|
|
__netdev_start_xmit include/linux/netdevice.h:4903 [inline]
|
|
netdev_start_xmit include/linux/netdevice.h:4917 [inline]
|
|
xmit_one net/core/dev.c:3531 [inline]
|
|
dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547
|
|
__dev_queue_xmit+0x348d/0x52c0 net/core/dev.c:4335
|
|
dev_queue_xmit include/linux/netdevice.h:3091 [inline]
|
|
packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276
|
|
packet_snd net/packet/af_packet.c:3081 [inline]
|
|
packet_sendmsg+0x8bb0/0x9ef0 net/packet/af_packet.c:3113
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg+0x30f/0x380 net/socket.c:745
|
|
__sys_sendto+0x685/0x830 net/socket.c:2191
|
|
__do_sys_sendto net/socket.c:2203 [inline]
|
|
__se_sys_sendto net/socket.c:2199 [inline]
|
|
__x64_sys_sendto+0x125/0x1d0 net/socket.c:2199
|
|
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
|
|
packet_alloc_skb net/packet/af_packet.c:2930 [inline]
|
|
packet_snd net/packet/af_packet.c:3024 [inline]
|
|
packet_sendmsg+0x722d/0x9ef0 net/packet/af_packet.c:3113
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg+0x30f/0x380 net/socket.c:745
|
|
__sys_sendto+0x685/0x830 net/socket.c:2191
|
|
__do_sys_sendto net/socket.c:2203 [inline]
|
|
__se_sys_sendto net/socket.c:2199 [inline]
|
|
__x64_sys_sendto+0x125/0x1d0 net/socket.c:2199
|
|
do_syscall_64+0xd5/0x1f0
|
|
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
|
|
|
CPU: 0 PID: 5033 Comm: syz-executor346 Not tainted 6.9.0-rc1-syzkaller-00005-g928a87efa423 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024(CVE-2024-35973)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
batman-adv: Avoid infinite loop trying to resize local TT
|
|
|
|
If the MTU of one of an attached interface becomes too small to transmit
|
|
the local translation table then it must be resized to fit inside all
|
|
fragments (when enabled) or a single packet.
|
|
|
|
But if the MTU becomes too low to transmit even the header + the VLAN
|
|
specific part then the resizing of the local TT will never succeed. This
|
|
can for example happen when the usable space is 110 bytes and 11 VLANs are
|
|
on top of batman-adv. In this case, at least 116 byte would be needed.
|
|
There will just be an endless spam of
|
|
|
|
batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110)
|
|
|
|
in the log but the function will never finish. Problem here is that the
|
|
timeout will be halved all the time and will then stagnate at 0 and
|
|
therefore never be able to reduce the table even more.
|
|
|
|
There are other scenarios possible with a similar result. The number of
|
|
BATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too
|
|
high to fit inside a packet. Such a scenario can therefore happen also with
|
|
only a single VLAN + 7 non-purgable addresses - requiring at least 120
|
|
bytes.
|
|
|
|
While this should be handled proactively when:
|
|
|
|
* interface with too low MTU is added
|
|
* VLAN is added
|
|
* non-purgeable local mac is added
|
|
* MTU of an attached interface is reduced
|
|
* fragmentation setting gets disabled (which most likely requires dropping
|
|
attached interfaces)
|
|
|
|
not all of these scenarios can be prevented because batman-adv is only
|
|
consuming events without the the possibility to prevent these actions
|
|
(non-purgable MAC address added, MTU of an attached interface is reduced).
|
|
It is therefore necessary to also make sure that the code is able to handle
|
|
also the situations when there were already incompatible system
|
|
configuration are present.(CVE-2024-35982)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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:
|
|
|
|
tipc: fix UAF in error path
|
|
|
|
Sam Page (sam4k) working with Trend Micro Zero Day Initiative reported
|
|
a UAF in the tipc_buf_append() error path:
|
|
|
|
BUG: KASAN: slab-use-after-free in kfree_skb_list_reason+0x47e/0x4c0
|
|
linux/net/core/skbuff.c:1183
|
|
Read of size 8 at addr ffff88804d2a7c80 by task poc/8034
|
|
|
|
CPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
|
|
1.16.0-debian-1.16.0-5 04/01/2014
|
|
Call Trace:
|
|
<IRQ>
|
|
__dump_stack linux/lib/dump_stack.c:88
|
|
dump_stack_lvl+0xd9/0x1b0 linux/lib/dump_stack.c:106
|
|
print_address_description linux/mm/kasan/report.c:377
|
|
print_report+0xc4/0x620 linux/mm/kasan/report.c:488
|
|
kasan_report+0xda/0x110 linux/mm/kasan/report.c:601
|
|
kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183
|
|
skb_release_data+0x5af/0x880 linux/net/core/skbuff.c:1026
|
|
skb_release_all linux/net/core/skbuff.c:1094
|
|
__kfree_skb linux/net/core/skbuff.c:1108
|
|
kfree_skb_reason+0x12d/0x210 linux/net/core/skbuff.c:1144
|
|
kfree_skb linux/./include/linux/skbuff.h:1244
|
|
tipc_buf_append+0x425/0xb50 linux/net/tipc/msg.c:186
|
|
tipc_link_input+0x224/0x7c0 linux/net/tipc/link.c:1324
|
|
tipc_link_rcv+0x76e/0x2d70 linux/net/tipc/link.c:1824
|
|
tipc_rcv+0x45f/0x10f0 linux/net/tipc/node.c:2159
|
|
tipc_udp_recv+0x73b/0x8f0 linux/net/tipc/udp_media.c:390
|
|
udp_queue_rcv_one_skb+0xad2/0x1850 linux/net/ipv4/udp.c:2108
|
|
udp_queue_rcv_skb+0x131/0xb00 linux/net/ipv4/udp.c:2186
|
|
udp_unicast_rcv_skb+0x165/0x3b0 linux/net/ipv4/udp.c:2346
|
|
__udp4_lib_rcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422
|
|
ip_protocol_deliver_rcu+0x30c/0x4e0 linux/net/ipv4/ip_input.c:205
|
|
ip_local_deliver_finish+0x2e4/0x520 linux/net/ipv4/ip_input.c:233
|
|
NF_HOOK linux/./include/linux/netfilter.h:314
|
|
NF_HOOK linux/./include/linux/netfilter.h:308
|
|
ip_local_deliver+0x18e/0x1f0 linux/net/ipv4/ip_input.c:254
|
|
dst_input linux/./include/net/dst.h:461
|
|
ip_rcv_finish linux/net/ipv4/ip_input.c:449
|
|
NF_HOOK linux/./include/linux/netfilter.h:314
|
|
NF_HOOK linux/./include/linux/netfilter.h:308
|
|
ip_rcv+0x2c5/0x5d0 linux/net/ipv4/ip_input.c:569
|
|
__netif_receive_skb_one_core+0x199/0x1e0 linux/net/core/dev.c:5534
|
|
__netif_receive_skb+0x1f/0x1c0 linux/net/core/dev.c:5648
|
|
process_backlog+0x101/0x6b0 linux/net/core/dev.c:5976
|
|
__napi_poll.constprop.0+0xba/0x550 linux/net/core/dev.c:6576
|
|
napi_poll linux/net/core/dev.c:6645
|
|
net_rx_action+0x95a/0xe90 linux/net/core/dev.c:6781
|
|
__do_softirq+0x21f/0x8e7 linux/kernel/softirq.c:553
|
|
do_softirq linux/kernel/softirq.c:454
|
|
do_softirq+0xb2/0xf0 linux/kernel/softirq.c:441
|
|
</IRQ>
|
|
<TASK>
|
|
__local_bh_enable_ip+0x100/0x120 linux/kernel/softirq.c:381
|
|
local_bh_enable linux/./include/linux/bottom_half.h:33
|
|
rcu_read_unlock_bh linux/./include/linux/rcupdate.h:851
|
|
__dev_queue_xmit+0x871/0x3ee0 linux/net/core/dev.c:4378
|
|
dev_queue_xmit linux/./include/linux/netdevice.h:3169
|
|
neigh_hh_output linux/./include/net/neighbour.h:526
|
|
neigh_output linux/./include/net/neighbour.h:540
|
|
ip_finish_output2+0x169f/0x2550 linux/net/ipv4/ip_output.c:235
|
|
__ip_finish_output linux/net/ipv4/ip_output.c:313
|
|
__ip_finish_output+0x49e/0x950 linux/net/ipv4/ip_output.c:295
|
|
ip_finish_output+0x31/0x310 linux/net/ipv4/ip_output.c:323
|
|
NF_HOOK_COND linux/./include/linux/netfilter.h:303
|
|
ip_output+0x13b/0x2a0 linux/net/ipv4/ip_output.c:433
|
|
dst_output linux/./include/net/dst.h:451
|
|
ip_local_out linux/net/ipv4/ip_output.c:129
|
|
ip_send_skb+0x3e5/0x560 linux/net/ipv4/ip_output.c:1492
|
|
udp_send_skb+0x73f/0x1530 linux/net/ipv4/udp.c:963
|
|
udp_sendmsg+0x1a36/0x2b40 linux/net/ipv4/udp.c:1250
|
|
inet_sendmsg+0x105/0x140 linux/net/ipv4/af_inet.c:850
|
|
sock_sendmsg_nosec linux/net/socket.c:730
|
|
__sock_sendmsg linux/net/socket.c:745
|
|
__sys_sendto+0x42c/0x4e0 linux/net/socket.c:2191
|
|
__do_sys_sendto linux/net/socket.c:2203
|
|
__se_sys_sendto linux/net/socket.c:2199
|
|
__x64_sys_sendto+0xe0/0x1c0 linux/net/socket.c:2199
|
|
do_syscall_x64 linux/arch/x86/entry/common.c:52
|
|
do_syscall_
|
|
---truncated---(CVE-2024-36886)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mptcp: ensure snd_nxt is properly initialized on connect
|
|
|
|
Christoph reported a splat hinting at a corrupted snd_una:
|
|
|
|
WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005
|
|
Modules linked in:
|
|
CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 #59
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
|
|
Workqueue: events mptcp_worker
|
|
RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005
|
|
Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8
|
|
8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe
|
|
<0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9
|
|
RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293
|
|
RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4
|
|
RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001
|
|
RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000
|
|
R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000
|
|
FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0
|
|
Call Trace:
|
|
<TASK>
|
|
__mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]
|
|
mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]
|
|
__mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615
|
|
mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767
|
|
process_one_work+0x1e0/0x560 kernel/workqueue.c:3254
|
|
process_scheduled_works kernel/workqueue.c:3335 [inline]
|
|
worker_thread+0x3c7/0x640 kernel/workqueue.c:3416
|
|
kthread+0x121/0x170 kernel/kthread.c:388
|
|
ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147
|
|
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243
|
|
</TASK>
|
|
|
|
When fallback to TCP happens early on a client socket, snd_nxt
|
|
is not yet initialized and any incoming ack will copy such value
|
|
into snd_una. If the mptcp worker (dumbly) tries mptcp-level
|
|
re-injection after such ack, that would unconditionally trigger a send
|
|
buffer cleanup using 'bad' snd_una values.
|
|
|
|
We could easily disable re-injection for fallback sockets, but such
|
|
dumb behavior already helped catching a few subtle issues and a very
|
|
low to zero impact in practice.
|
|
|
|
Instead address the issue always initializing snd_nxt (and write_seq,
|
|
for consistency) at connect time.(CVE-2024-36889)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
gpiolib: cdev: fix uninitialised kfifo
|
|
|
|
If a line is requested with debounce, and that results in debouncing
|
|
in software, and the line is subsequently reconfigured to enable edge
|
|
detection then the allocation of the kfifo to contain edge events is
|
|
overlooked. This results in events being written to and read from an
|
|
uninitialised kfifo. Read events are returned to userspace.
|
|
|
|
Initialise the kfifo in the case where the software debounce is
|
|
already active.(CVE-2024-36898)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
gpiolib: cdev: Fix use after free in lineinfo_changed_notify
|
|
|
|
The use-after-free issue occurs as follows: when the GPIO chip device file
|
|
is being closed by invoking gpio_chrdev_release(), watched_lines is freed
|
|
by bitmap_free(), but the unregistration of lineinfo_changed_nb notifier
|
|
chain failed due to waiting write rwsem. Additionally, one of the GPIO
|
|
chip's lines is also in the release process and holds the notifier chain's
|
|
read rwsem. Consequently, a race condition leads to the use-after-free of
|
|
watched_lines.
|
|
|
|
Here is the typical stack when issue happened:
|
|
|
|
[free]
|
|
gpio_chrdev_release()
|
|
--> bitmap_free(cdev->watched_lines) <-- freed
|
|
--> blocking_notifier_chain_unregister()
|
|
--> down_write(&nh->rwsem) <-- waiting rwsem
|
|
--> __down_write_common()
|
|
--> rwsem_down_write_slowpath()
|
|
--> schedule_preempt_disabled()
|
|
--> schedule()
|
|
|
|
[use]
|
|
st54spi_gpio_dev_release()
|
|
--> gpio_free()
|
|
--> gpiod_free()
|
|
--> gpiod_free_commit()
|
|
--> gpiod_line_state_notify()
|
|
--> blocking_notifier_call_chain()
|
|
--> down_read(&nh->rwsem); <-- held rwsem
|
|
--> notifier_call_chain()
|
|
--> lineinfo_changed_notify()
|
|
--> test_bit(xxxx, cdev->watched_lines) <-- use after free
|
|
|
|
The side effect of the use-after-free issue is that a GPIO line event is
|
|
being generated for userspace where it shouldn't. However, since the chrdev
|
|
is being closed, userspace won't have the chance to read that event anyway.
|
|
|
|
To fix the issue, call the bitmap_free() function after the unregistration
|
|
of lineinfo_changed_nb notifier chain.(CVE-2024-36899)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ipv6: prevent NULL dereference in ip6_output()
|
|
|
|
According to syzbot, there is a chance that ip6_dst_idev()
|
|
returns NULL in ip6_output(). Most places in IPv6 stack
|
|
deal with a NULL idev just fine, but not here.
|
|
|
|
syzbot reported:
|
|
|
|
general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI
|
|
KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7]
|
|
CPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
|
|
RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237
|
|
Code: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff
|
|
RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202
|
|
RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000
|
|
RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48
|
|
RBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad
|
|
R10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0
|
|
R13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000
|
|
FS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0
|
|
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
Call Trace:
|
|
<TASK>
|
|
NF_HOOK include/linux/netfilter.h:314 [inline]
|
|
ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358
|
|
sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248
|
|
sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653
|
|
sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783
|
|
sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline]
|
|
sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212
|
|
sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline]
|
|
sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169
|
|
sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73
|
|
__sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234
|
|
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-36901)
|
|
|
|
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:
|
|
|
|
ARM: 9381/1: kasan: clear stale stack poison
|
|
|
|
We found below OOB crash:
|
|
|
|
[ 33.452494] ==================================================================
|
|
[ 33.453513] BUG: KASAN: stack-out-of-bounds in refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec
|
|
[ 33.454660] Write of size 164 at addr c1d03d30 by task swapper/0/0
|
|
[ 33.455515]
|
|
[ 33.455767] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 6.1.25-mainline #1
|
|
[ 33.456880] Hardware name: Generic DT based system
|
|
[ 33.457555] unwind_backtrace from show_stack+0x18/0x1c
|
|
[ 33.458326] show_stack from dump_stack_lvl+0x40/0x4c
|
|
[ 33.459072] dump_stack_lvl from print_report+0x158/0x4a4
|
|
[ 33.459863] print_report from kasan_report+0x9c/0x148
|
|
[ 33.460616] kasan_report from kasan_check_range+0x94/0x1a0
|
|
[ 33.461424] kasan_check_range from memset+0x20/0x3c
|
|
[ 33.462157] memset from refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec
|
|
[ 33.463064] refresh_cpu_vm_stats.constprop.0 from tick_nohz_idle_stop_tick+0x180/0x53c
|
|
[ 33.464181] tick_nohz_idle_stop_tick from do_idle+0x264/0x354
|
|
[ 33.465029] do_idle from cpu_startup_entry+0x20/0x24
|
|
[ 33.465769] cpu_startup_entry from rest_init+0xf0/0xf4
|
|
[ 33.466528] rest_init from arch_post_acpi_subsys_init+0x0/0x18
|
|
[ 33.467397]
|
|
[ 33.467644] The buggy address belongs to stack of task swapper/0/0
|
|
[ 33.468493] and is located at offset 112 in frame:
|
|
[ 33.469172] refresh_cpu_vm_stats.constprop.0+0x0/0x2ec
|
|
[ 33.469917]
|
|
[ 33.470165] This frame has 2 objects:
|
|
[ 33.470696] [32, 76) 'global_zone_diff'
|
|
[ 33.470729] [112, 276) 'global_node_diff'
|
|
[ 33.471294]
|
|
[ 33.472095] The buggy address belongs to the physical page:
|
|
[ 33.472862] page:3cd72da8 refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x41d03
|
|
[ 33.473944] flags: 0x1000(reserved|zone=0)
|
|
[ 33.474565] raw: 00001000 ed741470 ed741470 00000000 00000000 00000000 ffffffff 00000001
|
|
[ 33.475656] raw: 00000000
|
|
[ 33.476050] page dumped because: kasan: bad access detected
|
|
[ 33.476816]
|
|
[ 33.477061] Memory state around the buggy address:
|
|
[ 33.477732] c1d03c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
|
[ 33.478630] c1d03c80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00
|
|
[ 33.479526] >c1d03d00: 00 04 f2 f2 f2 f2 00 00 00 00 00 00 f1 f1 f1 f1
|
|
[ 33.480415] ^
|
|
[ 33.481195] c1d03d80: 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3 f3 f3
|
|
[ 33.482088] c1d03e00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
|
|
[ 33.482978] ==================================================================
|
|
|
|
We find the root cause of this OOB is that arm does not clear stale stack
|
|
poison in the case of cpuidle.
|
|
|
|
This patch refer to arch/arm64/kernel/sleep.S to resolve this issue.
|
|
|
|
From cited commit [1] that explain the problem
|
|
|
|
Functions which the compiler has instrumented for KASAN place poison on
|
|
the stack shadow upon entry and remove this poison prior to returning.
|
|
|
|
In the case of cpuidle, CPUs exit the kernel a number of levels deep in
|
|
C code. Any instrumented functions on this critical path will leave
|
|
portions of the stack shadow poisoned.
|
|
|
|
If CPUs lose context and return to the kernel via a cold path, we
|
|
restore a prior context saved in __cpu_suspend_enter are forgotten, and
|
|
we never remove the poison they placed in the stack shadow area by
|
|
functions calls between this and the actual exit of the kernel.
|
|
|
|
Thus, (depending on stackframe layout) subsequent calls to instrumented
|
|
functions may hit this stale poison, resulting in (spurious) KASAN
|
|
splats to the console.
|
|
|
|
To avoid this, clear any stale poison from the idle thread for a CPU
|
|
prior to bringing a CPU online.
|
|
|
|
From cited commit [2]
|
|
|
|
Extend to check for CONFIG_KASAN_STACK
|
|
|
|
[1] commit 0d97e6d8024c ("arm64: kasan: clear stale stack poison")
|
|
[2] commit d56a9ef84bd0 ("kasan, arm64: unpoison stack only with CONFIG_KASAN_STACK")(CVE-2024-36906)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
blk-iocost: do not WARN if iocg was already offlined
|
|
|
|
In iocg_pay_debt(), warn is triggered if 'active_list' is empty, which
|
|
is intended to confirm iocg is active when it has debt. However, warn
|
|
can be triggered during a blkcg or disk removal, if iocg_waitq_timer_fn()
|
|
is run at that time:
|
|
|
|
WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocg_pay_debt+0x14c/0x190
|
|
Call trace:
|
|
iocg_pay_debt+0x14c/0x190
|
|
iocg_kick_waitq+0x438/0x4c0
|
|
iocg_waitq_timer_fn+0xd8/0x130
|
|
__run_hrtimer+0x144/0x45c
|
|
__hrtimer_run_queues+0x16c/0x244
|
|
hrtimer_interrupt+0x2cc/0x7b0
|
|
|
|
The warn in this situation is meaningless. Since this iocg is being
|
|
removed, the state of the 'active_list' is irrelevant, and 'waitq_timer'
|
|
is canceled after removing 'active_list' in ioc_pd_free(), which ensures
|
|
iocg is freed after iocg_waitq_timer_fn() returns.
|
|
|
|
Therefore, add the check if iocg was already offlined to avoid warn
|
|
when removing a blkcg or disk.(CVE-2024-36908)
|
|
|
|
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:
|
|
|
|
s390/qeth: Fix kernel panic after setting hsuid
|
|
|
|
Symptom:
|
|
When the hsuid attribute is set for the first time on an IQD Layer3
|
|
device while the corresponding network interface is already UP,
|
|
the kernel will try to execute a napi function pointer that is NULL.
|
|
|
|
Example:
|
|
---------------------------------------------------------------------------
|
|
[ 2057.572696] illegal operation: 0001 ilc:1 [#1] SMP
|
|
[ 2057.572702] Modules linked in: af_iucv qeth_l3 zfcp scsi_transport_fc sunrpc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6
|
|
nft_reject nft_ct nf_tables_set nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink ghash_s390 prng xts aes_s390 des_s390 de
|
|
s_generic sha3_512_s390 sha3_256_s390 sha512_s390 vfio_ccw vfio_mdev mdev vfio_iommu_type1 eadm_sch vfio ext4 mbcache jbd2 qeth_l2 bridge stp llc dasd_eckd_mod qeth dasd_mod
|
|
qdio ccwgroup pkey zcrypt
|
|
[ 2057.572739] CPU: 6 PID: 60182 Comm: stress_client Kdump: loaded Not tainted 4.18.0-541.el8.s390x #1
|
|
[ 2057.572742] Hardware name: IBM 3931 A01 704 (LPAR)
|
|
[ 2057.572744] Krnl PSW : 0704f00180000000 0000000000000002 (0x2)
|
|
[ 2057.572748] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3
|
|
[ 2057.572751] Krnl GPRS: 0000000000000004 0000000000000000 00000000a3b008d8 0000000000000000
|
|
[ 2057.572754] 00000000a3b008d8 cb923a29c779abc5 0000000000000000 00000000814cfd80
|
|
[ 2057.572756] 000000000000012c 0000000000000000 00000000a3b008d8 00000000a3b008d8
|
|
[ 2057.572758] 00000000bab6d500 00000000814cfd80 0000000091317e46 00000000814cfc68
|
|
[ 2057.572762] Krnl Code:#0000000000000000: 0000 illegal
|
|
>0000000000000002: 0000 illegal
|
|
0000000000000004: 0000 illegal
|
|
0000000000000006: 0000 illegal
|
|
0000000000000008: 0000 illegal
|
|
000000000000000a: 0000 illegal
|
|
000000000000000c: 0000 illegal
|
|
000000000000000e: 0000 illegal
|
|
[ 2057.572800] Call Trace:
|
|
[ 2057.572801] ([<00000000ec639700>] 0xec639700)
|
|
[ 2057.572803] [<00000000913183e2>] net_rx_action+0x2ba/0x398
|
|
[ 2057.572809] [<0000000091515f76>] __do_softirq+0x11e/0x3a0
|
|
[ 2057.572813] [<0000000090ce160c>] do_softirq_own_stack+0x3c/0x58
|
|
[ 2057.572817] ([<0000000090d2cbd6>] do_softirq.part.1+0x56/0x60)
|
|
[ 2057.572822] [<0000000090d2cc60>] __local_bh_enable_ip+0x80/0x98
|
|
[ 2057.572825] [<0000000091314706>] __dev_queue_xmit+0x2be/0xd70
|
|
[ 2057.572827] [<000003ff803dd6d6>] afiucv_hs_send+0x24e/0x300 [af_iucv]
|
|
[ 2057.572830] [<000003ff803dd88a>] iucv_send_ctrl+0x102/0x138 [af_iucv]
|
|
[ 2057.572833] [<000003ff803de72a>] iucv_sock_connect+0x37a/0x468 [af_iucv]
|
|
[ 2057.572835] [<00000000912e7e90>] __sys_connect+0xa0/0xd8
|
|
[ 2057.572839] [<00000000912e9580>] sys_socketcall+0x228/0x348
|
|
[ 2057.572841] [<0000000091514e1a>] system_call+0x2a6/0x2c8
|
|
[ 2057.572843] Last Breaking-Event-Address:
|
|
[ 2057.572844] [<0000000091317e44>] __napi_poll+0x4c/0x1d8
|
|
[ 2057.572846]
|
|
[ 2057.572847] Kernel panic - not syncing: Fatal exception in interrupt
|
|
-------------------------------------------------------------------------------------------
|
|
|
|
Analysis:
|
|
There is one napi structure per out_q: card->qdio.out_qs[i].napi
|
|
The napi.poll functions are set during qeth_open().
|
|
|
|
Since
|
|
commit 1cfef80d4c2b ("s390/qeth: Don't call dev_close/dev_open (DOWN/UP)")
|
|
qeth_set_offline()/qeth_set_online() no longer call dev_close()/
|
|
dev_open(). So if qeth_free_qdio_queues() cleared
|
|
card->qdio.out_qs[i].napi.poll while the network interface was UP and the
|
|
card was offline, they are not set again.
|
|
|
|
Reproduction:
|
|
chzdev -e $devno layer2=0
|
|
ip link set dev $network_interface up
|
|
echo 0 > /sys/bus/ccw
|
|
---truncated---(CVE-2024-36928)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: core: reject skb_copy(_expand) for fraglist GSO skbs
|
|
|
|
SKB_GSO_FRAGLIST skbs must not be linearized, otherwise they become
|
|
invalid. Return NULL if such an skb is passed to skb_copy or
|
|
skb_copy_expand, in order to prevent a crash on a potential later
|
|
call to skb_gso_segment.(CVE-2024-36929)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
amd/amdkfd: sync all devices to wait all processes being evicted
|
|
|
|
If there are more than one device doing reset in parallel, the first
|
|
device will call kfd_suspend_all_processes() to evict all processes
|
|
on all devices, this call takes time to finish. other device will
|
|
start reset and recover without waiting. if the process has not been
|
|
evicted before doing recover, it will be restored, then caused page
|
|
fault.(CVE-2024-36949)
|
|
|
|
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:
|
|
|
|
octeontx2-af: avoid off-by-one read from userspace
|
|
|
|
We try to access count + 1 byte from userspace with memdup_user(buffer,
|
|
count + 1). However, the userspace only provides buffer of count bytes and
|
|
only these count bytes are verified to be okay to access. To ensure the
|
|
copied buffer is NUL terminated, we use memdup_user_nul instead.(CVE-2024-36957)
|
|
|
|
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-22.03-LTS-SP3.
|
|
|
|
openEuler Security has rated this update as having a security impact of medium. 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">Medium</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-1707</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47247</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47484</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47558</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2022-48652</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52672</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52680</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-52693</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52732</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52762</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52775</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-52810</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52880</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52881</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26835</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26889</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27393</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27402</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27408</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35790</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-35853</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35854</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35871</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-35895</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-35905</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35924</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35967</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35973</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35982</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-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-36886</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36889</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36898</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36899</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36901</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-36906</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36908</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-36928</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36929</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36949</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-36957</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-47247</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47484</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47558</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48652</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52672</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52680</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52686</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52693</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52732</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52762</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52775</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52803</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52810</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52880</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52881</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26835</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26889</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27393</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27402</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27408</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35790</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-35853</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35854</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35871</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35888</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35895</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35896</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35905</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35924</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35967</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35973</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35982</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-36886</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36889</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36898</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36899</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36901</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-36906</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36908</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-36928</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36929</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36949</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36954</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36957</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-22.03-LTS-SP3" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">openEuler-22.03-LTS-SP3</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-207.0.0.116" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-debuginfo-5.10.0-207.0.0.116.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-207.0.0.116" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debuginfo-5.10.0-207.0.0.116.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-207.0.0.116" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-debuginfo-5.10.0-207.0.0.116.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-207.0.0.116" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-debuginfo-5.10.0-207.0.0.116.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-207.0.0.116" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-5.10.0-207.0.0.116.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-5.10.0-207.0.0.116" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-207.0.0.116.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-207.0.0.116" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-headers-5.10.0-207.0.0.116.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-207.0.0.116" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-devel-5.10.0-207.0.0.116.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-207.0.0.116" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-5.10.0-207.0.0.116.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-207.0.0.116" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-5.10.0-207.0.0.116.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-207.0.0.116" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-devel-5.10.0-207.0.0.116.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-207.0.0.116" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debugsource-5.10.0-207.0.0.116.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-207.0.0.116" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-source-5.10.0-207.0.0.116.oe2203sp3.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-5.10.0-207.0.0.116" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-207.0.0.116.oe2203sp3.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-207.0.0.116" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debuginfo-5.10.0-207.0.0.116.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-207.0.0.116" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-5.10.0-207.0.0.116.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-207.0.0.116" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-5.10.0-207.0.0.116.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-207.0.0.116" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-source-5.10.0-207.0.0.116.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-207.0.0.116" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-headers-5.10.0-207.0.0.116.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-207.0.0.116" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-5.10.0-207.0.0.116.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-207.0.0.116" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-devel-5.10.0-207.0.0.116.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-207.0.0.116" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-devel-5.10.0-207.0.0.116.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-207.0.0.116" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debugsource-5.10.0-207.0.0.116.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-207.0.0.116" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-debuginfo-5.10.0-207.0.0.116.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-5.10.0-207.0.0.116" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-207.0.0.116.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-207.0.0.116" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-debuginfo-5.10.0-207.0.0.116.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-207.0.0.116" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-debuginfo-5.10.0-207.0.0.116.oe2203sp3.x86_64.rpm</FullProductName>
|
|
</Branch>
|
|
</ProductTree>
|
|
<Vulnerability Ordinal="1" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/mlx5e: Fix use-after-free of encap entry in neigh update handler
|
|
|
|
Function mlx5e_rep_neigh_update() wasn't updated to accommodate rtnl lock
|
|
removal from TC filter update path and properly handle concurrent encap
|
|
entry insertion/deletion which can lead to following use-after-free:
|
|
|
|
[23827.464923] ==================================================================
|
|
[23827.469446] BUG: KASAN: use-after-free in mlx5e_encap_take+0x72/0x140 [mlx5_core]
|
|
[23827.470971] Read of size 4 at addr ffff8881d132228c by task kworker/u20:6/21635
|
|
[23827.472251]
|
|
[23827.472615] CPU: 9 PID: 21635 Comm: kworker/u20:6 Not tainted 5.13.0-rc3+ #5
|
|
[23827.473788] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
|
|
[23827.475639] Workqueue: mlx5e mlx5e_rep_neigh_update [mlx5_core]
|
|
[23827.476731] Call Trace:
|
|
[23827.477260] dump_stack+0xbb/0x107
|
|
[23827.477906] print_address_description.constprop.0+0x18/0x140
|
|
[23827.478896] ? mlx5e_encap_take+0x72/0x140 [mlx5_core]
|
|
[23827.479879] ? mlx5e_encap_take+0x72/0x140 [mlx5_core]
|
|
[23827.480905] kasan_report.cold+0x7c/0xd8
|
|
[23827.481701] ? mlx5e_encap_take+0x72/0x140 [mlx5_core]
|
|
[23827.482744] kasan_check_range+0x145/0x1a0
|
|
[23827.493112] mlx5e_encap_take+0x72/0x140 [mlx5_core]
|
|
[23827.494054] ? mlx5e_tc_tun_encap_info_equal_generic+0x140/0x140 [mlx5_core]
|
|
[23827.495296] mlx5e_rep_neigh_update+0x41e/0x5e0 [mlx5_core]
|
|
[23827.496338] ? mlx5e_rep_neigh_entry_release+0xb80/0xb80 [mlx5_core]
|
|
[23827.497486] ? read_word_at_a_time+0xe/0x20
|
|
[23827.498250] ? strscpy+0xa0/0x2a0
|
|
[23827.498889] process_one_work+0x8ac/0x14e0
|
|
[23827.499638] ? lockdep_hardirqs_on_prepare+0x400/0x400
|
|
[23827.500537] ? pwq_dec_nr_in_flight+0x2c0/0x2c0
|
|
[23827.501359] ? rwlock_bug.part.0+0x90/0x90
|
|
[23827.502116] worker_thread+0x53b/0x1220
|
|
[23827.502831] ? process_one_work+0x14e0/0x14e0
|
|
[23827.503627] kthread+0x328/0x3f0
|
|
[23827.504254] ? _raw_spin_unlock_irq+0x24/0x40
|
|
[23827.505065] ? __kthread_bind_mask+0x90/0x90
|
|
[23827.505912] ret_from_fork+0x1f/0x30
|
|
[23827.506621]
|
|
[23827.506987] Allocated by task 28248:
|
|
[23827.507694] kasan_save_stack+0x1b/0x40
|
|
[23827.508476] __kasan_kmalloc+0x7c/0x90
|
|
[23827.509197] mlx5e_attach_encap+0xde1/0x1d40 [mlx5_core]
|
|
[23827.510194] mlx5e_tc_add_fdb_flow+0x397/0xc40 [mlx5_core]
|
|
[23827.511218] __mlx5e_add_fdb_flow+0x519/0xb30 [mlx5_core]
|
|
[23827.512234] mlx5e_configure_flower+0x191c/0x4870 [mlx5_core]
|
|
[23827.513298] tc_setup_cb_add+0x1d5/0x420
|
|
[23827.514023] fl_hw_replace_filter+0x382/0x6a0 [cls_flower]
|
|
[23827.514975] fl_change+0x2ceb/0x4a51 [cls_flower]
|
|
[23827.515821] tc_new_tfilter+0x89a/0x2070
|
|
[23827.516548] rtnetlink_rcv_msg+0x644/0x8c0
|
|
[23827.517300] netlink_rcv_skb+0x11d/0x340
|
|
[23827.518021] netlink_unicast+0x42b/0x700
|
|
[23827.518742] netlink_sendmsg+0x743/0xc20
|
|
[23827.519467] sock_sendmsg+0xb2/0xe0
|
|
[23827.520131] ____sys_sendmsg+0x590/0x770
|
|
[23827.520851] ___sys_sendmsg+0xd8/0x160
|
|
[23827.521552] __sys_sendmsg+0xb7/0x140
|
|
[23827.522238] do_syscall_64+0x3a/0x70
|
|
[23827.522907] entry_SYSCALL_64_after_hwframe+0x44/0xae
|
|
[23827.523797]
|
|
[23827.524163] Freed by task 25948:
|
|
[23827.524780] kasan_save_stack+0x1b/0x40
|
|
[23827.525488] kasan_set_track+0x1c/0x30
|
|
[23827.526187] kasan_set_free_info+0x20/0x30
|
|
[23827.526968] __kasan_slab_free+0xed/0x130
|
|
[23827.527709] slab_free_freelist_hook+0xcf/0x1d0
|
|
[23827.528528] kmem_cache_free_bulk+0x33a/0x6e0
|
|
[23827.529317] kfree_rcu_work+0x55f/0xb70
|
|
[23827.530024] process_one_work+0x8ac/0x14e0
|
|
[23827.530770] worker_thread+0x53b/0x1220
|
|
[23827.531480] kthread+0x328/0x3f0
|
|
[23827.532114] ret_from_fork+0x1f/0x30
|
|
[23827.532785]
|
|
[23827.533147] Last potentially related work creation:
|
|
[23827.534007] kasan_save_stack+0x1b/0x40
|
|
[23827.534710] kasan_record_aux_stack+0xab/0xc0
|
|
[23827.535492] kvfree_call_rcu+0x31/0x7b0
|
|
[23827.536206] mlx5e_tc_del
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2021-47247</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
octeontx2-af: Fix possible null pointer dereference.
|
|
|
|
This patch fixes possible null pointer dereference in files
|
|
"rvu_debugfs.c" and "rvu_nix.c"</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2021-47484</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="3" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="3" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: stmmac: Disable Tx queues when reconfiguring the interface
|
|
|
|
The Tx queues were not disabled in situations where the driver needed to
|
|
stop the interface to apply a new configuration. This could result in a
|
|
kernel panic when doing any of the 3 following actions:
|
|
* reconfiguring the number of queues (ethtool -L)
|
|
* reconfiguring the size of the ring buffers (ethtool -G)
|
|
* installing/removing an XDP program (ip l set dev ethX xdp)
|
|
|
|
Prevent the panic by making sure netif_tx_disable is called when stopping
|
|
an interface.
|
|
|
|
Without this patch, the following kernel panic can be observed when doing
|
|
any of the actions above:
|
|
|
|
Unable to handle kernel paging request at virtual address ffff80001238d040
|
|
[....]
|
|
Call trace:
|
|
dwmac4_set_addr+0x8/0x10
|
|
dev_hard_start_xmit+0xe4/0x1ac
|
|
sch_direct_xmit+0xe8/0x39c
|
|
__dev_queue_xmit+0x3ec/0xaf0
|
|
dev_queue_xmit+0x14/0x20
|
|
[...]
|
|
[ end trace 0000000000000002 ]---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2021-47558</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
ice: Fix crash by keep old cfg when update TCs more than queues
|
|
|
|
There are problems if allocated queues less than Traffic Classes.
|
|
|
|
Commit a632b2a4c920 ("ice: ethtool: Prohibit improper channel config
|
|
for DCB") already disallow setting less queues than TCs.
|
|
|
|
Another case is if we first set less queues, and later update more TCs
|
|
config due to LLDP, ice_vsi_cfg_tc() will failed but left dirty
|
|
num_txq/rxq and tc_cfg in vsi, that will cause invalid pointer access.
|
|
|
|
[ 95.968089] ice 0000:3b:00.1: More TCs defined than queues/rings allocated.
|
|
[ 95.968092] ice 0000:3b:00.1: Trying to use more Rx queues (8), than were allocated (1)!
|
|
[ 95.968093] ice 0000:3b:00.1: Failed to config TC for VSI index: 0
|
|
[ 95.969621] general protection fault: 0000 [#1] SMP NOPTI
|
|
[ 95.969705] CPU: 1 PID: 58405 Comm: lldpad Kdump: loaded Tainted: G U W O --------- -t - 4.18.0 #1
|
|
[ 95.969867] Hardware name: O.E.M/BC11SPSCB10, BIOS 8.23 12/30/2021
|
|
[ 95.969992] RIP: 0010:devm_kmalloc+0xa/0x60
|
|
[ 95.970052] Code: 5c ff ff ff 31 c0 5b 5d 41 5c c3 b8 f4 ff ff ff eb f4 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 89 d1 <8b> 97 60 02 00 00 48 8d 7e 18 48 39 f7 72 3f 55 89 ce 53 48 8b 4c
|
|
[ 95.970344] RSP: 0018:ffffc9003f553888 EFLAGS: 00010206
|
|
[ 95.970425] RAX: dead000000000200 RBX: ffffea003c425b00 RCX: 00000000006080c0
|
|
[ 95.970536] RDX: 00000000006080c0 RSI: 0000000000000200 RDI: dead000000000200
|
|
[ 95.970648] RBP: dead000000000200 R08: 00000000000463c0 R09: ffff888ffa900000
|
|
[ 95.970760] R10: 0000000000000000 R11: 0000000000000002 R12: ffff888ff6b40100
|
|
[ 95.970870] R13: ffff888ff6a55018 R14: 0000000000000000 R15: ffff888ff6a55460
|
|
[ 95.970981] FS: 00007f51b7d24700(0000) GS:ffff88903ee80000(0000) knlGS:0000000000000000
|
|
[ 95.971108] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 95.971197] CR2: 00007fac5410d710 CR3: 0000000f2c1de002 CR4: 00000000007606e0
|
|
[ 95.971309] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
[ 95.971419] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
[ 95.971530] PKRU: 55555554
|
|
[ 95.971573] Call Trace:
|
|
[ 95.971622] ice_setup_rx_ring+0x39/0x110 [ice]
|
|
[ 95.971695] ice_vsi_setup_rx_rings+0x54/0x90 [ice]
|
|
[ 95.971774] ice_vsi_open+0x25/0x120 [ice]
|
|
[ 95.971843] ice_open_internal+0xb8/0x1f0 [ice]
|
|
[ 95.971919] ice_ena_vsi+0x4f/0xd0 [ice]
|
|
[ 95.971987] ice_dcb_ena_dis_vsi.constprop.5+0x29/0x90 [ice]
|
|
[ 95.972082] ice_pf_dcb_cfg+0x29a/0x380 [ice]
|
|
[ 95.972154] ice_dcbnl_setets+0x174/0x1b0 [ice]
|
|
[ 95.972220] dcbnl_ieee_set+0x89/0x230
|
|
[ 95.972279] ? dcbnl_ieee_del+0x150/0x150
|
|
[ 95.972341] dcb_doit+0x124/0x1b0
|
|
[ 95.972392] rtnetlink_rcv_msg+0x243/0x2f0
|
|
[ 95.972457] ? dcb_doit+0x14d/0x1b0
|
|
[ 95.972510] ? __kmalloc_node_track_caller+0x1d3/0x280
|
|
[ 95.972591] ? rtnl_calcit.isra.31+0x100/0x100
|
|
[ 95.972661] netlink_rcv_skb+0xcf/0xf0
|
|
[ 95.972720] netlink_unicast+0x16d/0x220
|
|
[ 95.972781] netlink_sendmsg+0x2ba/0x3a0
|
|
[ 95.975891] sock_sendmsg+0x4c/0x50
|
|
[ 95.979032] ___sys_sendmsg+0x2e4/0x300
|
|
[ 95.982147] ? kmem_cache_alloc+0x13e/0x190
|
|
[ 95.985242] ? __wake_up_common_lock+0x79/0x90
|
|
[ 95.988338] ? __check_object_size+0xac/0x1b0
|
|
[ 95.991440] ? _copy_to_user+0x22/0x30
|
|
[ 95.994539] ? move_addr_to_user+0xbb/0xd0
|
|
[ 95.997619] ? __sys_sendmsg+0x53/0x80
|
|
[ 96.000664] __sys_sendmsg+0x53/0x80
|
|
[ 96.003747] do_syscall_64+0x5b/0x1d0
|
|
[ 96.006862] entry_SYSCALL_64_after_hwframe+0x65/0xca
|
|
|
|
Only update num_txq/rxq when passed check, and restore tc_cfg if setup
|
|
queue map failed.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2022-48652</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="5" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="5" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
pipe: wakeup wr_wait after setting max_usage
|
|
|
|
Commit c73be61cede5 ("pipe: Add general notification queue support") a
|
|
regression was introduced that would lock up resized pipes under certain
|
|
conditions. See the reproducer in [1].
|
|
|
|
The commit resizing the pipe ring size was moved to a different
|
|
function, doing that moved the wakeup for pipe->wr_wait before actually
|
|
raising pipe->max_usage. If a pipe was full before the resize occured it
|
|
would result in the wakeup never actually triggering pipe_write.
|
|
|
|
Set @max_usage and @nr_accounted before waking writers if this isn't a
|
|
watch queue.
|
|
|
|
[Christian Brauner <brauner@kernel.org>: rewrite to account for watch queues]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2023-52672</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
ALSA: scarlett2: Add missing error checks to *_ctl_get()
|
|
|
|
The *_ctl_get() functions which call scarlett2_update_*() were not
|
|
checking the return value. Fix to check the return value and pass to
|
|
the caller.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2023-52680</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
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-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
ACPI: video: check for error while searching for backlight device parent
|
|
|
|
If acpi_get_parent() called in acpi_video_dev_register_backlight()
|
|
fails, for example, because acpi_ut_acquire_mutex() fails inside
|
|
acpi_get_parent), this can lead to incorrect (uninitialized)
|
|
acpi_parent handle being passed to acpi_get_pci_dev() for detecting
|
|
the parent pci device.
|
|
|
|
Check acpi_get_parent() result and set parent device only in case of success.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2023-52693</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
ceph: blocklist the kclient when receiving corrupted snap trace
|
|
|
|
When received corrupted snap trace we don't know what exactly has
|
|
happened in MDS side. And we shouldn't continue IOs and metadatas
|
|
access to MDS, which may corrupt or get incorrect contents.
|
|
|
|
This patch will just block all the further IO/MDS requests
|
|
immediately and then evict the kclient itself.
|
|
|
|
The reason why we still need to evict the kclient just after
|
|
blocking all the further IOs is that the MDS could revoke the caps
|
|
faster.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2023-52732</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
virtio-blk: fix implicit overflow on virtio_max_dma_size
|
|
|
|
The following codes have an implicit conversion from size_t to u32:
|
|
(u32)max_size = (size_t)virtio_max_dma_size(vdev);
|
|
|
|
This may lead overflow, Ex (size_t)4G -> (u32)0. Once
|
|
virtio_max_dma_size() has a larger size than U32_MAX, use U32_MAX
|
|
instead.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2023-52762</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
net/smc: avoid data corruption caused by decline
|
|
|
|
We found a data corruption issue during testing of SMC-R on Redis
|
|
applications.
|
|
|
|
The benchmark has a low probability of reporting a strange error as
|
|
shown below.
|
|
|
|
"Error: Protocol error, got "\xe2" as reply type byte"
|
|
|
|
Finally, we found that the retrieved error data was as follows:
|
|
|
|
0xE2 0xD4 0xC3 0xD9 0x04 0x00 0x2C 0x20 0xA6 0x56 0x00 0x16 0x3E 0x0C
|
|
0xCB 0x04 0x02 0x01 0x00 0x00 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00
|
|
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xE2
|
|
|
|
It is quite obvious that this is a SMC DECLINE message, which means that
|
|
the applications received SMC protocol message.
|
|
We found that this was caused by the following situations:
|
|
|
|
client server
|
|
¦ clc proposal
|
|
------------->
|
|
¦ clc accept
|
|
<-------------
|
|
¦ clc confirm
|
|
------------->
|
|
wait llc confirm
|
|
send llc confirm
|
|
¦failed llc confirm
|
|
¦ x------
|
|
(after 2s)timeout
|
|
wait llc confirm rsp
|
|
|
|
wait decline
|
|
|
|
(after 1s) timeout
|
|
(after 2s) timeout
|
|
¦ decline
|
|
-------------->
|
|
¦ decline
|
|
<--------------
|
|
|
|
As a result, a decline message was sent in the implementation, and this
|
|
message was read from TCP by the already-fallback connection.
|
|
|
|
This patch double the client timeout as 2x of the server value,
|
|
With this simple change, the Decline messages should never cross or
|
|
collide (during Confirm link timeout).
|
|
|
|
This issue requires an immediate solution, since the protocol updates
|
|
involve a more long-term solution.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2023-52775</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.9</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-1707</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:
|
|
|
|
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-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="13" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="13" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fs/jfs: Add check for negative db_l2nbperpage
|
|
|
|
l2nbperpage is log2(number of blks per page), and the minimum legal
|
|
value should be 0, not negative.
|
|
|
|
In the case of l2nbperpage being negative, an error will occur
|
|
when subsequently used as shift exponent.
|
|
|
|
Syzbot reported this bug:
|
|
|
|
UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:799:12
|
|
shift exponent -16777216 is negative</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2023-52810</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc
|
|
|
|
Any unprivileged user can attach N_GSM0710 ldisc, but it requires
|
|
CAP_NET_ADMIN to create a GSM network anyway.
|
|
|
|
Require initial namespace CAP_NET_ADMIN to do that.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2023-52880</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
tcp: do not accept ACK of bytes we never sent
|
|
|
|
This patch is based on a detailed report and ideas from Yepeng Pan
|
|
and Christian Rossow.
|
|
|
|
ACK seq validation is currently following RFC 5961 5.2 guidelines:
|
|
|
|
The ACK value is considered acceptable only if
|
|
it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <=
|
|
SND.NXT). All incoming segments whose ACK value doesn't satisfy the
|
|
above condition MUST be discarded and an ACK sent back. It needs to
|
|
be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a
|
|
duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK
|
|
acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an
|
|
ACK, drop the segment, and return". The "ignored" above implies that
|
|
the processing of the incoming data segment continues, which means
|
|
the ACK value is treated as acceptable. This mitigation makes the
|
|
ACK check more stringent since any ACK < SND.UNA wouldn't be
|
|
accepted, instead only ACKs that are in the range ((SND.UNA -
|
|
MAX.SND.WND) <= SEG.ACK <= SND.NXT) get through.
|
|
|
|
This can be refined for new (and possibly spoofed) flows,
|
|
by not accepting ACK for bytes that were never sent.
|
|
|
|
This greatly improves TCP security at a little cost.
|
|
|
|
I added a Fixes: tag to make sure this patch will reach stable trees,
|
|
even if the 'blamed' patch was adhering to the RFC.
|
|
|
|
tp->bytes_acked was added in linux-4.2
|
|
|
|
Following packetdrill test (courtesy of Yepeng Pan) shows
|
|
the issue at hand:
|
|
|
|
0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
|
|
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
|
|
+0 bind(3, ..., ...) = 0
|
|
+0 listen(3, 1024) = 0
|
|
|
|
// ---------------- Handshake ------------------- //
|
|
|
|
// when window scale is set to 14 the window size can be extended to
|
|
// 65535 * (2^14) = 1073725440. Linux would accept an ACK packet
|
|
// with ack number in (Server_ISN+1-1073725440. Server_ISN+1)
|
|
// ,though this ack number acknowledges some data never
|
|
// sent by the server.
|
|
|
|
+0 < S 0:0(0) win 65535 <mss 1400,nop,wscale 14>
|
|
+0 > S. 0:0(0) ack 1 <...>
|
|
+0 < . 1:1(0) ack 1 win 65535
|
|
+0 accept(3, ..., ...) = 4
|
|
|
|
// For the established connection, we send an ACK packet,
|
|
// the ack packet uses ack number 1 - 1073725300 + 2^32,
|
|
// where 2^32 is used to wrap around.
|
|
// Note: we used 1073725300 instead of 1073725440 to avoid possible
|
|
// edge cases.
|
|
// 1 - 1073725300 + 2^32 = 3221241997
|
|
|
|
// Oops, old kernels happily accept this packet.
|
|
+0 < . 1:1001(1000) ack 3221241997 win 65535
|
|
|
|
// After the kernel fix the following will be replaced by a challenge ACK,
|
|
// and prior malicious frame would be dropped.
|
|
+0 > . 1:1(0) ack 1001</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2023-52881</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.9</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-1707</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:
|
|
|
|
netfilter: nf_tables: set dormant flag on hook register failure
|
|
|
|
We need to set the dormant flag again if we fail to register
|
|
the hooks.
|
|
|
|
During memory pressure hook registration can fail and we end up
|
|
with a table marked as active but no registered hooks.
|
|
|
|
On table/base chain deletion, nf_tables will attempt to unregister
|
|
the hook again which yields a warn splat from the nftables core.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-26835</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.3</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:L/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-1707</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:
|
|
|
|
Bluetooth: hci_core: Fix possible buffer overflow
|
|
|
|
struct hci_dev_info has a fixed size name[8] field so in the event that
|
|
hdev->name is bigger than that strcpy would attempt to write past its
|
|
size, so this fixes this problem by switching to use strscpy.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-26889</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
xen-netfront: Add missing skb_mark_for_recycle
|
|
|
|
Notice that skb_mark_for_recycle() is introduced later than fixes tag in
|
|
commit 6a5bcd84e886 ("page_pool: Allow drivers to hint on SKB recycling").
|
|
|
|
It is believed that fixes tag were missing a call to page_pool_release_page()
|
|
between v5.9 to v5.14, after which is should have used skb_mark_for_recycle().
|
|
Since v6.6 the call page_pool_release_page() were removed (in
|
|
commit 535b9c61bdef ("net: page_pool: hide page_pool_release_page()")
|
|
and remaining callers converted (in commit 6bfef2ec0172 ("Merge branch
|
|
'net-page_pool-remove-page_pool_release_page'")).
|
|
|
|
This leak became visible in v6.8 via commit dba1b8a7ab68 ("mm/page_pool: catch
|
|
page_pool memory leaks").</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-27393</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
phonet/pep: fix racy skb_queue_empty() use
|
|
|
|
The receive queues are protected by their respective spin-lock, not
|
|
the socket lock. This could lead to skb_peek() unexpectedly
|
|
returning NULL or a pointer to an already dequeued socket buffer.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-27402</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="20" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="20" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
dmaengine: dw-edma: eDMA: Add sync read before starting the DMA transfer in remote setup
|
|
|
|
The Linked list element and pointer are not stored in the same memory as
|
|
the eDMA controller register. If the doorbell register is toggled before
|
|
the full write of the linked list a race condition error will occur.
|
|
In remote setup we can only use a readl to the memory to assure the full
|
|
write has occurred.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-27408</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
usb: typec: altmodes/displayport: create sysfs nodes as driver's default device attribute group
|
|
|
|
The DisplayPort driver's sysfs nodes may be present to the userspace before
|
|
typec_altmode_set_drvdata() completes in dp_altmode_probe. This means that
|
|
a sysfs read can trigger a NULL pointer error by deferencing dp->hpd in
|
|
hpd_show or dp->lock in pin_assignment_show, as dev_get_drvdata() returns
|
|
NULL in those cases.
|
|
|
|
Remove manual sysfs node creation in favor of adding attribute group as
|
|
default for devices bound to the driver. The ATTRIBUTE_GROUPS() macro is
|
|
not used here otherwise the path to the sysfs nodes is no longer compliant
|
|
with the ABI.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-35790</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
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-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.7</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
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-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
mlxsw: spectrum_acl_tcam: Fix memory leak during rehash
|
|
|
|
The rehash delayed work migrates filters from one region to another.
|
|
This is done by iterating over all chunks (all the filters with the same
|
|
priority) in the region and in each chunk iterating over all the
|
|
filters.
|
|
|
|
If the migration fails, the code tries to migrate the filters back to
|
|
the old region. However, the rollback itself can also fail in which case
|
|
another migration will be erroneously performed. Besides the fact that
|
|
this ping pong is not a very good idea, it also creates a problem.
|
|
|
|
Each virtual chunk references two chunks: The currently used one
|
|
('vchunk->chunk') and a backup ('vchunk->chunk2'). During migration the
|
|
first holds the chunk we want to migrate filters to and the second holds
|
|
the chunk we are migrating filters from.
|
|
|
|
The code currently assumes - but does not verify - that the backup chunk
|
|
does not exist (NULL) if the currently used chunk does not reference the
|
|
target region. This assumption breaks when we are trying to rollback a
|
|
rollback, resulting in the backup chunk being overwritten and leaked
|
|
[1].
|
|
|
|
Fix by not rolling back a failed rollback and add a warning to avoid
|
|
future cases.
|
|
|
|
[1]
|
|
WARNING: CPU: 5 PID: 1063 at lib/parman.c:291 parman_destroy+0x17/0x20
|
|
Modules linked in:
|
|
CPU: 5 PID: 1063 Comm: kworker/5:11 Tainted: G W 6.9.0-rc2-custom-00784-gc6a05c468a0b #14
|
|
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
|
|
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
|
|
RIP: 0010:parman_destroy+0x17/0x20
|
|
[...]
|
|
Call Trace:
|
|
<TASK>
|
|
mlxsw_sp_acl_atcam_region_fini+0x19/0x60
|
|
mlxsw_sp_acl_tcam_region_destroy+0x49/0xf0
|
|
mlxsw_sp_acl_tcam_vregion_rehash_work+0x1f1/0x470
|
|
process_one_work+0x151/0x370
|
|
worker_thread+0x2cb/0x3e0
|
|
kthread+0xd0/0x100
|
|
ret_from_fork+0x34/0x50
|
|
ret_from_fork_asm+0x1a/0x30
|
|
</TASK></Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-35853</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehash
|
|
|
|
The rehash delayed work migrates filters from one region to another
|
|
according to the number of available credits.
|
|
|
|
The migrated from region is destroyed at the end of the work if the
|
|
number of credits is non-negative as the assumption is that this is
|
|
indicative of migration being complete. This assumption is incorrect as
|
|
a non-negative number of credits can also be the result of a failed
|
|
migration.
|
|
|
|
The destruction of a region that still has filters referencing it can
|
|
result in a use-after-free [1].
|
|
|
|
Fix by not destroying the region if migration failed.
|
|
|
|
[1]
|
|
BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230
|
|
Read of size 8 at addr ffff8881735319e8 by task kworker/0:31/3858
|
|
|
|
CPU: 0 PID: 3858 Comm: kworker/0:31 Tainted: G W 6.9.0-rc2-custom-00782-gf2275c2157d8 #5
|
|
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
|
|
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
|
|
Call Trace:
|
|
<TASK>
|
|
dump_stack_lvl+0xc6/0x120
|
|
print_report+0xce/0x670
|
|
kasan_report+0xd7/0x110
|
|
mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230
|
|
mlxsw_sp_acl_ctcam_entry_del+0x2e/0x70
|
|
mlxsw_sp_acl_atcam_entry_del+0x81/0x210
|
|
mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3cd/0xb50
|
|
mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300
|
|
process_one_work+0x8eb/0x19b0
|
|
worker_thread+0x6c9/0xf70
|
|
kthread+0x2c9/0x3b0
|
|
ret_from_fork+0x4d/0x80
|
|
ret_from_fork_asm+0x1a/0x30
|
|
</TASK>
|
|
|
|
Allocated by task 174:
|
|
kasan_save_stack+0x33/0x60
|
|
kasan_save_track+0x14/0x30
|
|
__kasan_kmalloc+0x8f/0xa0
|
|
__kmalloc+0x19c/0x360
|
|
mlxsw_sp_acl_tcam_region_create+0xdf/0x9c0
|
|
mlxsw_sp_acl_tcam_vregion_rehash_work+0x954/0x1300
|
|
process_one_work+0x8eb/0x19b0
|
|
worker_thread+0x6c9/0xf70
|
|
kthread+0x2c9/0x3b0
|
|
ret_from_fork+0x4d/0x80
|
|
ret_from_fork_asm+0x1a/0x30
|
|
|
|
Freed by task 7:
|
|
kasan_save_stack+0x33/0x60
|
|
kasan_save_track+0x14/0x30
|
|
kasan_save_free_info+0x3b/0x60
|
|
poison_slab_object+0x102/0x170
|
|
__kasan_slab_free+0x14/0x30
|
|
kfree+0xc1/0x290
|
|
mlxsw_sp_acl_tcam_region_destroy+0x272/0x310
|
|
mlxsw_sp_acl_tcam_vregion_rehash_work+0x731/0x1300
|
|
process_one_work+0x8eb/0x19b0
|
|
worker_thread+0x6c9/0xf70
|
|
kthread+0x2c9/0x3b0
|
|
ret_from_fork+0x4d/0x80
|
|
ret_from_fork_asm+0x1a/0x30</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-35854</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
riscv: process: Fix kernel gp leakage
|
|
|
|
childregs represents the registers which are active for the new thread
|
|
in user context. For a kernel thread, childregs->gp is never used since
|
|
the kernel gp is not touched by switch_to. For a user mode helper, the
|
|
gp value can be observed in user space after execve or possibly by other
|
|
means.
|
|
|
|
[From the email thread]
|
|
|
|
The /* Kernel thread */ comment is somewhat inaccurate in that it is also used
|
|
for user_mode_helper threads, which exec a user process, e.g. /sbin/init or
|
|
when /proc/sys/kernel/core_pattern is a pipe. Such threads do not have
|
|
PF_KTHREAD set and are valid targets for ptrace etc. even before they exec.
|
|
|
|
childregs is the *user* context during syscall execution and it is observable
|
|
from userspace in at least five ways:
|
|
|
|
1. kernel_execve does not currently clear integer registers, so the starting
|
|
register state for PID 1 and other user processes started by the kernel has
|
|
sp = user stack, gp = kernel __global_pointer$, all other integer registers
|
|
zeroed by the memset in the patch comment.
|
|
|
|
This is a bug in its own right, but I'm unwilling to bet that it is the only
|
|
way to exploit the issue addressed by this patch.
|
|
|
|
2. ptrace(PTRACE_GETREGSET): you can PTRACE_ATTACH to a user_mode_helper thread
|
|
before it execs, but ptrace requires SIGSTOP to be delivered which can only
|
|
happen at user/kernel boundaries.
|
|
|
|
3. /proc/*/task/*/syscall: this is perfectly happy to read pt_regs for
|
|
user_mode_helpers before the exec completes, but gp is not one of the
|
|
registers it returns.
|
|
|
|
4. PERF_SAMPLE_REGS_USER: LOCKDOWN_PERF normally prevents access to kernel
|
|
addresses via PERF_SAMPLE_REGS_INTR, but due to this bug kernel addresses
|
|
are also exposed via PERF_SAMPLE_REGS_USER which is permitted under
|
|
LOCKDOWN_PERF. I have not attempted to write exploit code.
|
|
|
|
5. Much of the tracing infrastructure allows access to user registers. I have
|
|
not attempted to determine which forms of tracing allow access to user
|
|
registers without already allowing access to kernel registers.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-35871</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="27" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="27" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
bpf, sockmap: Prevent lock inversion deadlock in map delete elem
|
|
|
|
syzkaller started using corpuses where a BPF tracing program deletes
|
|
elements from a sockmap/sockhash map. Because BPF tracing programs can be
|
|
invoked from any interrupt context, locks taken during a map_delete_elem
|
|
operation must be hardirq-safe. Otherwise a deadlock due to lock inversion
|
|
is possible, as reported by lockdep:
|
|
|
|
CPU0 CPU1
|
|
---- ----
|
|
lock(&htab->buckets[i].lock);
|
|
local_irq_disable();
|
|
lock(&host->lock);
|
|
lock(&htab->buckets[i].lock);
|
|
<Interrupt>
|
|
lock(&host->lock);
|
|
|
|
Locks in sockmap are hardirq-unsafe by design. We expects elements to be
|
|
deleted from sockmap/sockhash only in task (normal) context with interrupts
|
|
enabled, or in softirq context.
|
|
|
|
Detect when map_delete_elem operation is invoked from a context which is
|
|
_not_ hardirq-unsafe, that is interrupts are disabled, and bail out with an
|
|
error.
|
|
|
|
Note that map updates are not affected by this issue. BPF verifier does not
|
|
allow updating sockmap/sockhash from a BPF tracing program today.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-35895</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="29" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="29" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: 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-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
bpf: Protect against int overflow for stack access size
|
|
|
|
This patch re-introduces protection against the size of access to stack
|
|
memory being negative; the access size can appear negative as a result
|
|
of overflowing its signed int representation. This should not actually
|
|
happen, as there are other protections along the way, but we should
|
|
protect against it anyway. One code path was missing such protections
|
|
(fixed in the previous patch in the series), causing out-of-bounds array
|
|
accesses in check_stack_range_initialized(). This patch causes the
|
|
verification of a program with such a non-sensical access size to fail.
|
|
|
|
This check used to exist in a more indirect way, but was inadvertendly
|
|
removed in a833a17aeac7.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-35905</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
usb: typec: ucsi: Limit read size on v1.2
|
|
|
|
Between UCSI 1.2 and UCSI 2.0, the size of the MESSAGE_IN region was
|
|
increased from 16 to 256. In order to avoid overflowing reads for older
|
|
systems, add a mechanism to use the read UCSI version to truncate read
|
|
sizes on UCSI v1.2.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-35924</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
Bluetooth: SCO: Fix not validating setsockopt user input
|
|
|
|
syzbot reported sco_sock_setsockopt() is copying data without
|
|
checking user input length.
|
|
|
|
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset
|
|
include/linux/sockptr.h:49 [inline]
|
|
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr
|
|
include/linux/sockptr.h:55 [inline]
|
|
BUG: KASAN: slab-out-of-bounds in sco_sock_setsockopt+0xc0b/0xf90
|
|
net/bluetooth/sco.c:893
|
|
Read of size 4 at addr ffff88805f7b15a3 by task syz-executor.5/12578</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-35967</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
geneve: fix header validation in geneve[6]_xmit_skb
|
|
|
|
syzbot is able to trigger an uninit-value in geneve_xmit() [1]
|
|
|
|
Problem : While most ip tunnel helpers (like ip_tunnel_get_dsfield())
|
|
uses skb_protocol(skb, true), pskb_inet_may_pull() is only using
|
|
skb->protocol.
|
|
|
|
If anything else than ETH_P_IPV6 or ETH_P_IP is found in skb->protocol,
|
|
pskb_inet_may_pull() does nothing at all.
|
|
|
|
If a vlan tag was provided by the caller (af_packet in the syzbot case),
|
|
the network header might not point to the correct location, and skb
|
|
linear part could be smaller than expected.
|
|
|
|
Add skb_vlan_inet_prepare() to perform a complete mac validation.
|
|
|
|
Use this in geneve for the moment, I suspect we need to adopt this
|
|
more broadly.
|
|
|
|
v4 - Jakub reported v3 broke l2_tos_ttl_inherit.sh selftest
|
|
- Only call __vlan_get_protocol() for vlan types.
|
|
|
|
v2,v3 - Addressed Sabrina comments on v1 and v2
|
|
|
|
[1]
|
|
|
|
BUG: KMSAN: uninit-value in geneve_xmit_skb drivers/net/geneve.c:910 [inline]
|
|
BUG: KMSAN: uninit-value in geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030
|
|
geneve_xmit_skb drivers/net/geneve.c:910 [inline]
|
|
geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030
|
|
__netdev_start_xmit include/linux/netdevice.h:4903 [inline]
|
|
netdev_start_xmit include/linux/netdevice.h:4917 [inline]
|
|
xmit_one net/core/dev.c:3531 [inline]
|
|
dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547
|
|
__dev_queue_xmit+0x348d/0x52c0 net/core/dev.c:4335
|
|
dev_queue_xmit include/linux/netdevice.h:3091 [inline]
|
|
packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276
|
|
packet_snd net/packet/af_packet.c:3081 [inline]
|
|
packet_sendmsg+0x8bb0/0x9ef0 net/packet/af_packet.c:3113
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg+0x30f/0x380 net/socket.c:745
|
|
__sys_sendto+0x685/0x830 net/socket.c:2191
|
|
__do_sys_sendto net/socket.c:2203 [inline]
|
|
__se_sys_sendto net/socket.c:2199 [inline]
|
|
__x64_sys_sendto+0x125/0x1d0 net/socket.c:2199
|
|
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
|
|
packet_alloc_skb net/packet/af_packet.c:2930 [inline]
|
|
packet_snd net/packet/af_packet.c:3024 [inline]
|
|
packet_sendmsg+0x722d/0x9ef0 net/packet/af_packet.c:3113
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
__sock_sendmsg+0x30f/0x380 net/socket.c:745
|
|
__sys_sendto+0x685/0x830 net/socket.c:2191
|
|
__do_sys_sendto net/socket.c:2203 [inline]
|
|
__se_sys_sendto net/socket.c:2199 [inline]
|
|
__x64_sys_sendto+0x125/0x1d0 net/socket.c:2199
|
|
do_syscall_64+0xd5/0x1f0
|
|
entry_SYSCALL_64_after_hwframe+0x6d/0x75
|
|
|
|
CPU: 0 PID: 5033 Comm: syz-executor346 Not tainted 6.9.0-rc1-syzkaller-00005-g928a87efa423 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-35973</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
batman-adv: Avoid infinite loop trying to resize local TT
|
|
|
|
If the MTU of one of an attached interface becomes too small to transmit
|
|
the local translation table then it must be resized to fit inside all
|
|
fragments (when enabled) or a single packet.
|
|
|
|
But if the MTU becomes too low to transmit even the header + the VLAN
|
|
specific part then the resizing of the local TT will never succeed. This
|
|
can for example happen when the usable space is 110 bytes and 11 VLANs are
|
|
on top of batman-adv. In this case, at least 116 byte would be needed.
|
|
There will just be an endless spam of
|
|
|
|
batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110)
|
|
|
|
in the log but the function will never finish. Problem here is that the
|
|
timeout will be halved all the time and will then stagnate at 0 and
|
|
therefore never be able to reduce the table even more.
|
|
|
|
There are other scenarios possible with a similar result. The number of
|
|
BATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too
|
|
high to fit inside a packet. Such a scenario can therefore happen also with
|
|
only a single VLAN + 7 non-purgable addresses - requiring at least 120
|
|
bytes.
|
|
|
|
While this should be handled proactively when:
|
|
|
|
* interface with too low MTU is added
|
|
* VLAN is added
|
|
* non-purgeable local mac is added
|
|
* MTU of an attached interface is reduced
|
|
* fragmentation setting gets disabled (which most likely requires dropping
|
|
attached interfaces)
|
|
|
|
not all of these scenarios can be prevented because batman-adv is only
|
|
consuming events without the the possibility to prevent these actions
|
|
(non-purgable MAC address added, MTU of an attached interface is reduced).
|
|
It is therefore necessary to also make sure that the code is able to handle
|
|
also the situations when there were already incompatible system
|
|
configuration are present.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-35982</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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: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-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
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-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
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-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
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-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
tipc: fix UAF in error path
|
|
|
|
Sam Page (sam4k) working with Trend Micro Zero Day Initiative reported
|
|
a UAF in the tipc_buf_append() error path:
|
|
|
|
BUG: KASAN: slab-use-after-free in kfree_skb_list_reason+0x47e/0x4c0
|
|
linux/net/core/skbuff.c:1183
|
|
Read of size 8 at addr ffff88804d2a7c80 by task poc/8034
|
|
|
|
CPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
|
|
1.16.0-debian-1.16.0-5 04/01/2014
|
|
Call Trace:
|
|
<IRQ>
|
|
__dump_stack linux/lib/dump_stack.c:88
|
|
dump_stack_lvl+0xd9/0x1b0 linux/lib/dump_stack.c:106
|
|
print_address_description linux/mm/kasan/report.c:377
|
|
print_report+0xc4/0x620 linux/mm/kasan/report.c:488
|
|
kasan_report+0xda/0x110 linux/mm/kasan/report.c:601
|
|
kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183
|
|
skb_release_data+0x5af/0x880 linux/net/core/skbuff.c:1026
|
|
skb_release_all linux/net/core/skbuff.c:1094
|
|
__kfree_skb linux/net/core/skbuff.c:1108
|
|
kfree_skb_reason+0x12d/0x210 linux/net/core/skbuff.c:1144
|
|
kfree_skb linux/./include/linux/skbuff.h:1244
|
|
tipc_buf_append+0x425/0xb50 linux/net/tipc/msg.c:186
|
|
tipc_link_input+0x224/0x7c0 linux/net/tipc/link.c:1324
|
|
tipc_link_rcv+0x76e/0x2d70 linux/net/tipc/link.c:1824
|
|
tipc_rcv+0x45f/0x10f0 linux/net/tipc/node.c:2159
|
|
tipc_udp_recv+0x73b/0x8f0 linux/net/tipc/udp_media.c:390
|
|
udp_queue_rcv_one_skb+0xad2/0x1850 linux/net/ipv4/udp.c:2108
|
|
udp_queue_rcv_skb+0x131/0xb00 linux/net/ipv4/udp.c:2186
|
|
udp_unicast_rcv_skb+0x165/0x3b0 linux/net/ipv4/udp.c:2346
|
|
__udp4_lib_rcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422
|
|
ip_protocol_deliver_rcu+0x30c/0x4e0 linux/net/ipv4/ip_input.c:205
|
|
ip_local_deliver_finish+0x2e4/0x520 linux/net/ipv4/ip_input.c:233
|
|
NF_HOOK linux/./include/linux/netfilter.h:314
|
|
NF_HOOK linux/./include/linux/netfilter.h:308
|
|
ip_local_deliver+0x18e/0x1f0 linux/net/ipv4/ip_input.c:254
|
|
dst_input linux/./include/net/dst.h:461
|
|
ip_rcv_finish linux/net/ipv4/ip_input.c:449
|
|
NF_HOOK linux/./include/linux/netfilter.h:314
|
|
NF_HOOK linux/./include/linux/netfilter.h:308
|
|
ip_rcv+0x2c5/0x5d0 linux/net/ipv4/ip_input.c:569
|
|
__netif_receive_skb_one_core+0x199/0x1e0 linux/net/core/dev.c:5534
|
|
__netif_receive_skb+0x1f/0x1c0 linux/net/core/dev.c:5648
|
|
process_backlog+0x101/0x6b0 linux/net/core/dev.c:5976
|
|
__napi_poll.constprop.0+0xba/0x550 linux/net/core/dev.c:6576
|
|
napi_poll linux/net/core/dev.c:6645
|
|
net_rx_action+0x95a/0xe90 linux/net/core/dev.c:6781
|
|
__do_softirq+0x21f/0x8e7 linux/kernel/softirq.c:553
|
|
do_softirq linux/kernel/softirq.c:454
|
|
do_softirq+0xb2/0xf0 linux/kernel/softirq.c:441
|
|
</IRQ>
|
|
<TASK>
|
|
__local_bh_enable_ip+0x100/0x120 linux/kernel/softirq.c:381
|
|
local_bh_enable linux/./include/linux/bottom_half.h:33
|
|
rcu_read_unlock_bh linux/./include/linux/rcupdate.h:851
|
|
__dev_queue_xmit+0x871/0x3ee0 linux/net/core/dev.c:4378
|
|
dev_queue_xmit linux/./include/linux/netdevice.h:3169
|
|
neigh_hh_output linux/./include/net/neighbour.h:526
|
|
neigh_output linux/./include/net/neighbour.h:540
|
|
ip_finish_output2+0x169f/0x2550 linux/net/ipv4/ip_output.c:235
|
|
__ip_finish_output linux/net/ipv4/ip_output.c:313
|
|
__ip_finish_output+0x49e/0x950 linux/net/ipv4/ip_output.c:295
|
|
ip_finish_output+0x31/0x310 linux/net/ipv4/ip_output.c:323
|
|
NF_HOOK_COND linux/./include/linux/netfilter.h:303
|
|
ip_output+0x13b/0x2a0 linux/net/ipv4/ip_output.c:433
|
|
dst_output linux/./include/net/dst.h:451
|
|
ip_local_out linux/net/ipv4/ip_output.c:129
|
|
ip_send_skb+0x3e5/0x560 linux/net/ipv4/ip_output.c:1492
|
|
udp_send_skb+0x73f/0x1530 linux/net/ipv4/udp.c:963
|
|
udp_sendmsg+0x1a36/0x2b40 linux/net/ipv4/udp.c:1250
|
|
inet_sendmsg+0x105/0x140 linux/net/ipv4/af_inet.c:850
|
|
sock_sendmsg_nosec linux/net/socket.c:730
|
|
__sock_sendmsg linux/net/socket.c:745
|
|
__sys_sendto+0x42c/0x4e0 linux/net/socket.c:2191
|
|
__do_sys_sendto linux/net/socket.c:2203
|
|
__se_sys_sendto linux/net/socket.c:2199
|
|
__x64_sys_sendto+0xe0/0x1c0 linux/net/socket.c:2199
|
|
do_syscall_x64 linux/arch/x86/entry/common.c:52
|
|
do_syscall_
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-36886</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
mptcp: ensure snd_nxt is properly initialized on connect
|
|
|
|
Christoph reported a splat hinting at a corrupted snd_una:
|
|
|
|
WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005
|
|
Modules linked in:
|
|
CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 #59
|
|
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
|
|
Workqueue: events mptcp_worker
|
|
RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005
|
|
Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8
|
|
8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe
|
|
<0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9
|
|
RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293
|
|
RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4
|
|
RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001
|
|
RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000
|
|
R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000
|
|
FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0
|
|
Call Trace:
|
|
<TASK>
|
|
__mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]
|
|
mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]
|
|
__mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615
|
|
mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767
|
|
process_one_work+0x1e0/0x560 kernel/workqueue.c:3254
|
|
process_scheduled_works kernel/workqueue.c:3335 [inline]
|
|
worker_thread+0x3c7/0x640 kernel/workqueue.c:3416
|
|
kthread+0x121/0x170 kernel/kthread.c:388
|
|
ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147
|
|
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243
|
|
</TASK>
|
|
|
|
When fallback to TCP happens early on a client socket, snd_nxt
|
|
is not yet initialized and any incoming ack will copy such value
|
|
into snd_una. If the mptcp worker (dumbly) tries mptcp-level
|
|
re-injection after such ack, that would unconditionally trigger a send
|
|
buffer cleanup using 'bad' snd_una values.
|
|
|
|
We could easily disable re-injection for fallback sockets, but such
|
|
dumb behavior already helped catching a few subtle issues and a very
|
|
low to zero impact in practice.
|
|
|
|
Instead address the issue always initializing snd_nxt (and write_seq,
|
|
for consistency) at connect time.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-36889</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
gpiolib: cdev: fix uninitialised kfifo
|
|
|
|
If a line is requested with debounce, and that results in debouncing
|
|
in software, and the line is subsequently reconfigured to enable edge
|
|
detection then the allocation of the kfifo to contain edge events is
|
|
overlooked. This results in events being written to and read from an
|
|
uninitialised kfifo. Read events are returned to userspace.
|
|
|
|
Initialise the kfifo in the case where the software debounce is
|
|
already active.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-36898</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.1</BaseScore>
|
|
<Vector>AV:L/AC: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-1707</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:
|
|
|
|
gpiolib: cdev: Fix use after free in lineinfo_changed_notify
|
|
|
|
The use-after-free issue occurs as follows: when the GPIO chip device file
|
|
is being closed by invoking gpio_chrdev_release(), watched_lines is freed
|
|
by bitmap_free(), but the unregistration of lineinfo_changed_nb notifier
|
|
chain failed due to waiting write rwsem. Additionally, one of the GPIO
|
|
chip's lines is also in the release process and holds the notifier chain's
|
|
read rwsem. Consequently, a race condition leads to the use-after-free of
|
|
watched_lines.
|
|
|
|
Here is the typical stack when issue happened:
|
|
|
|
[free]
|
|
gpio_chrdev_release()
|
|
--> bitmap_free(cdev->watched_lines) <-- freed
|
|
--> blocking_notifier_chain_unregister()
|
|
--> down_write(&nh->rwsem) <-- waiting rwsem
|
|
--> __down_write_common()
|
|
--> rwsem_down_write_slowpath()
|
|
--> schedule_preempt_disabled()
|
|
--> schedule()
|
|
|
|
[use]
|
|
st54spi_gpio_dev_release()
|
|
--> gpio_free()
|
|
--> gpiod_free()
|
|
--> gpiod_free_commit()
|
|
--> gpiod_line_state_notify()
|
|
--> blocking_notifier_call_chain()
|
|
--> down_read(&nh->rwsem); <-- held rwsem
|
|
--> notifier_call_chain()
|
|
--> lineinfo_changed_notify()
|
|
--> test_bit(xxxx, cdev->watched_lines) <-- use after free
|
|
|
|
The side effect of the use-after-free issue is that a GPIO line event is
|
|
being generated for userspace where it shouldn't. However, since the chrdev
|
|
is being closed, userspace won't have the chance to read that event anyway.
|
|
|
|
To fix the issue, call the bitmap_free() function after the unregistration
|
|
of lineinfo_changed_nb notifier chain.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-36899</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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: prevent NULL dereference in ip6_output()
|
|
|
|
According to syzbot, there is a chance that ip6_dst_idev()
|
|
returns NULL in ip6_output(). Most places in IPv6 stack
|
|
deal with a NULL idev just fine, but not here.
|
|
|
|
syzbot reported:
|
|
|
|
general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI
|
|
KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7]
|
|
CPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
|
|
RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237
|
|
Code: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff
|
|
RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202
|
|
RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000
|
|
RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48
|
|
RBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad
|
|
R10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0
|
|
R13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000
|
|
FS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0
|
|
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
Call Trace:
|
|
<TASK>
|
|
NF_HOOK include/linux/netfilter.h:314 [inline]
|
|
ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358
|
|
sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248
|
|
sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653
|
|
sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783
|
|
sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline]
|
|
sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212
|
|
sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline]
|
|
sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169
|
|
sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73
|
|
__sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234
|
|
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-36901</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
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-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
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-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
ARM: 9381/1: kasan: clear stale stack poison
|
|
|
|
We found below OOB crash:
|
|
|
|
[ 33.452494] ==================================================================
|
|
[ 33.453513] BUG: KASAN: stack-out-of-bounds in refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec
|
|
[ 33.454660] Write of size 164 at addr c1d03d30 by task swapper/0/0
|
|
[ 33.455515]
|
|
[ 33.455767] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 6.1.25-mainline #1
|
|
[ 33.456880] Hardware name: Generic DT based system
|
|
[ 33.457555] unwind_backtrace from show_stack+0x18/0x1c
|
|
[ 33.458326] show_stack from dump_stack_lvl+0x40/0x4c
|
|
[ 33.459072] dump_stack_lvl from print_report+0x158/0x4a4
|
|
[ 33.459863] print_report from kasan_report+0x9c/0x148
|
|
[ 33.460616] kasan_report from kasan_check_range+0x94/0x1a0
|
|
[ 33.461424] kasan_check_range from memset+0x20/0x3c
|
|
[ 33.462157] memset from refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec
|
|
[ 33.463064] refresh_cpu_vm_stats.constprop.0 from tick_nohz_idle_stop_tick+0x180/0x53c
|
|
[ 33.464181] tick_nohz_idle_stop_tick from do_idle+0x264/0x354
|
|
[ 33.465029] do_idle from cpu_startup_entry+0x20/0x24
|
|
[ 33.465769] cpu_startup_entry from rest_init+0xf0/0xf4
|
|
[ 33.466528] rest_init from arch_post_acpi_subsys_init+0x0/0x18
|
|
[ 33.467397]
|
|
[ 33.467644] The buggy address belongs to stack of task swapper/0/0
|
|
[ 33.468493] and is located at offset 112 in frame:
|
|
[ 33.469172] refresh_cpu_vm_stats.constprop.0+0x0/0x2ec
|
|
[ 33.469917]
|
|
[ 33.470165] This frame has 2 objects:
|
|
[ 33.470696] [32, 76) 'global_zone_diff'
|
|
[ 33.470729] [112, 276) 'global_node_diff'
|
|
[ 33.471294]
|
|
[ 33.472095] The buggy address belongs to the physical page:
|
|
[ 33.472862] page:3cd72da8 refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x41d03
|
|
[ 33.473944] flags: 0x1000(reserved|zone=0)
|
|
[ 33.474565] raw: 00001000 ed741470 ed741470 00000000 00000000 00000000 ffffffff 00000001
|
|
[ 33.475656] raw: 00000000
|
|
[ 33.476050] page dumped because: kasan: bad access detected
|
|
[ 33.476816]
|
|
[ 33.477061] Memory state around the buggy address:
|
|
[ 33.477732] c1d03c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
|
[ 33.478630] c1d03c80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00
|
|
[ 33.479526] >c1d03d00: 00 04 f2 f2 f2 f2 00 00 00 00 00 00 f1 f1 f1 f1
|
|
[ 33.480415] ^
|
|
[ 33.481195] c1d03d80: 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3 f3 f3
|
|
[ 33.482088] c1d03e00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
|
|
[ 33.482978] ==================================================================
|
|
|
|
We find the root cause of this OOB is that arm does not clear stale stack
|
|
poison in the case of cpuidle.
|
|
|
|
This patch refer to arch/arm64/kernel/sleep.S to resolve this issue.
|
|
|
|
From cited commit [1] that explain the problem
|
|
|
|
Functions which the compiler has instrumented for KASAN place poison on
|
|
the stack shadow upon entry and remove this poison prior to returning.
|
|
|
|
In the case of cpuidle, CPUs exit the kernel a number of levels deep in
|
|
C code. Any instrumented functions on this critical path will leave
|
|
portions of the stack shadow poisoned.
|
|
|
|
If CPUs lose context and return to the kernel via a cold path, we
|
|
restore a prior context saved in __cpu_suspend_enter are forgotten, and
|
|
we never remove the poison they placed in the stack shadow area by
|
|
functions calls between this and the actual exit of the kernel.
|
|
|
|
Thus, (depending on stackframe layout) subsequent calls to instrumented
|
|
functions may hit this stale poison, resulting in (spurious) KASAN
|
|
splats to the console.
|
|
|
|
To avoid this, clear any stale poison from the idle thread for a CPU
|
|
prior to bringing a CPU online.
|
|
|
|
From cited commit [2]
|
|
|
|
Extend to check for CONFIG_KASAN_STACK
|
|
|
|
[1] commit 0d97e6d8024c ("arm64: kasan: clear stale stack poison")
|
|
[2] commit d56a9ef84bd0 ("kasan, arm64: unpoison stack only with CONFIG_KASAN_STACK")</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-36906</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</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:
|
|
|
|
blk-iocost: do not WARN if iocg was already offlined
|
|
|
|
In iocg_pay_debt(), warn is triggered if 'active_list' is empty, which
|
|
is intended to confirm iocg is active when it has debt. However, warn
|
|
can be triggered during a blkcg or disk removal, if iocg_waitq_timer_fn()
|
|
is run at that time:
|
|
|
|
WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocg_pay_debt+0x14c/0x190
|
|
Call trace:
|
|
iocg_pay_debt+0x14c/0x190
|
|
iocg_kick_waitq+0x438/0x4c0
|
|
iocg_waitq_timer_fn+0xd8/0x130
|
|
__run_hrtimer+0x144/0x45c
|
|
__hrtimer_run_queues+0x16c/0x244
|
|
hrtimer_interrupt+0x2cc/0x7b0
|
|
|
|
The warn in this situation is meaningless. Since this iocg is being
|
|
removed, the state of the 'active_list' is irrelevant, and 'waitq_timer'
|
|
is canceled after removing 'active_list' in ioc_pd_free(), which ensures
|
|
iocg is freed after iocg_waitq_timer_fn() returns.
|
|
|
|
Therefore, add the check if iocg was already offlined to avoid warn
|
|
when removing a blkcg or disk.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-36908</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="48" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="48" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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-22.03-LTS-SP3</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-1707</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="49" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="49" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.7</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="50" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="50" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
s390/qeth: Fix kernel panic after setting hsuid
|
|
|
|
Symptom:
|
|
When the hsuid attribute is set for the first time on an IQD Layer3
|
|
device while the corresponding network interface is already UP,
|
|
the kernel will try to execute a napi function pointer that is NULL.
|
|
|
|
Example:
|
|
---------------------------------------------------------------------------
|
|
[ 2057.572696] illegal operation: 0001 ilc:1 [#1] SMP
|
|
[ 2057.572702] Modules linked in: af_iucv qeth_l3 zfcp scsi_transport_fc sunrpc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6
|
|
nft_reject nft_ct nf_tables_set nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink ghash_s390 prng xts aes_s390 des_s390 de
|
|
s_generic sha3_512_s390 sha3_256_s390 sha512_s390 vfio_ccw vfio_mdev mdev vfio_iommu_type1 eadm_sch vfio ext4 mbcache jbd2 qeth_l2 bridge stp llc dasd_eckd_mod qeth dasd_mod
|
|
qdio ccwgroup pkey zcrypt
|
|
[ 2057.572739] CPU: 6 PID: 60182 Comm: stress_client Kdump: loaded Not tainted 4.18.0-541.el8.s390x #1
|
|
[ 2057.572742] Hardware name: IBM 3931 A01 704 (LPAR)
|
|
[ 2057.572744] Krnl PSW : 0704f00180000000 0000000000000002 (0x2)
|
|
[ 2057.572748] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3
|
|
[ 2057.572751] Krnl GPRS: 0000000000000004 0000000000000000 00000000a3b008d8 0000000000000000
|
|
[ 2057.572754] 00000000a3b008d8 cb923a29c779abc5 0000000000000000 00000000814cfd80
|
|
[ 2057.572756] 000000000000012c 0000000000000000 00000000a3b008d8 00000000a3b008d8
|
|
[ 2057.572758] 00000000bab6d500 00000000814cfd80 0000000091317e46 00000000814cfc68
|
|
[ 2057.572762] Krnl Code:#0000000000000000: 0000 illegal
|
|
>0000000000000002: 0000 illegal
|
|
0000000000000004: 0000 illegal
|
|
0000000000000006: 0000 illegal
|
|
0000000000000008: 0000 illegal
|
|
000000000000000a: 0000 illegal
|
|
000000000000000c: 0000 illegal
|
|
000000000000000e: 0000 illegal
|
|
[ 2057.572800] Call Trace:
|
|
[ 2057.572801] ([<00000000ec639700>] 0xec639700)
|
|
[ 2057.572803] [<00000000913183e2>] net_rx_action+0x2ba/0x398
|
|
[ 2057.572809] [<0000000091515f76>] __do_softirq+0x11e/0x3a0
|
|
[ 2057.572813] [<0000000090ce160c>] do_softirq_own_stack+0x3c/0x58
|
|
[ 2057.572817] ([<0000000090d2cbd6>] do_softirq.part.1+0x56/0x60)
|
|
[ 2057.572822] [<0000000090d2cc60>] __local_bh_enable_ip+0x80/0x98
|
|
[ 2057.572825] [<0000000091314706>] __dev_queue_xmit+0x2be/0xd70
|
|
[ 2057.572827] [<000003ff803dd6d6>] afiucv_hs_send+0x24e/0x300 [af_iucv]
|
|
[ 2057.572830] [<000003ff803dd88a>] iucv_send_ctrl+0x102/0x138 [af_iucv]
|
|
[ 2057.572833] [<000003ff803de72a>] iucv_sock_connect+0x37a/0x468 [af_iucv]
|
|
[ 2057.572835] [<00000000912e7e90>] __sys_connect+0xa0/0xd8
|
|
[ 2057.572839] [<00000000912e9580>] sys_socketcall+0x228/0x348
|
|
[ 2057.572841] [<0000000091514e1a>] system_call+0x2a6/0x2c8
|
|
[ 2057.572843] Last Breaking-Event-Address:
|
|
[ 2057.572844] [<0000000091317e44>] __napi_poll+0x4c/0x1d8
|
|
[ 2057.572846]
|
|
[ 2057.572847] Kernel panic - not syncing: Fatal exception in interrupt
|
|
-------------------------------------------------------------------------------------------
|
|
|
|
Analysis:
|
|
There is one napi structure per out_q: card->qdio.out_qs[i].napi
|
|
The napi.poll functions are set during qeth_open().
|
|
|
|
Since
|
|
commit 1cfef80d4c2b ("s390/qeth: Don't call dev_close/dev_open (DOWN/UP)")
|
|
qeth_set_offline()/qeth_set_online() no longer call dev_close()/
|
|
dev_open(). So if qeth_free_qdio_queues() cleared
|
|
card->qdio.out_qs[i].napi.poll while the network interface was UP and the
|
|
card was offline, they are not set again.
|
|
|
|
Reproduction:
|
|
chzdev -e $devno layer2=0
|
|
ip link set dev $network_interface up
|
|
echo 0 > /sys/bus/ccw
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-36928</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</BaseScore>
|
|
<Vector>AV:L/AC: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-1707</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="51" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="51" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: core: reject skb_copy(_expand) for fraglist GSO skbs
|
|
|
|
SKB_GSO_FRAGLIST skbs must not be linearized, otherwise they become
|
|
invalid. Return NULL if such an skb is passed to skb_copy or
|
|
skb_copy_expand, in order to prevent a crash on a potential later
|
|
call to skb_gso_segment.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-36929</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="52" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="52" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
amd/amdkfd: sync all devices to wait all processes being evicted
|
|
|
|
If there are more than one device doing reset in parallel, the first
|
|
device will call kfd_suspend_all_processes() to evict all processes
|
|
on all devices, this call takes time to finish. other device will
|
|
start reset and recover without waiting. if the process has not been
|
|
evicted before doing recover, it will be restored, then caused page
|
|
fault.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-36949</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.7</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="53" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="53" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="54" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="54" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
octeontx2-af: avoid off-by-one read from userspace
|
|
|
|
We try to access count + 1 byte from userspace with memdup_user(buffer,
|
|
count + 1). However, the userspace only provides buffer of count bytes and
|
|
only these count bytes are verified to be okay to access. To ensure the
|
|
copied buffer is NUL terminated, we use memdup_user_nul instead.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-14</ReleaseDate>
|
|
<CVE>CVE-2024-36957</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="55" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="55" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
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-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-14</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1707</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |