| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
mptcp: use the workqueue to destroy unaccepted sockets
Christoph reported a UaF at token lookup time after having
refactored the passive socket initialization part:
BUG: KASAN: use-after-free in __token_bucket_busy+0x253/0x260
Read of size 4 at addr ffff88810698d5b0 by task syz-executor653/3198
CPU: 1 PID: 3198 Comm: syz-executor653 Not tainted 6.2.0-rc59af4eaa31c1f6c00c8f1e448ed99a45c66340dd5 #6
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x6e/0x91
print_report+0x16a/0x46f
kasan_report+0xad/0x130
__token_bucket_busy+0x253/0x260
mptcp_token_new_connect+0x13d/0x490
mptcp_connect+0x4ed/0x860
__inet_stream_connect+0x80e/0xd90
tcp_sendmsg_fastopen+0x3ce/0x710
mptcp_sendmsg+0xff1/0x1a20
inet_sendmsg+0x11d/0x140
__sys_sendto+0x405/0x490
__x64_sys_sendto+0xdc/0x1b0
do_syscall_64+0x3b/0x90
entry_SYSCALL_64_after_hwframe+0x72/0xdc
We need to properly clean-up all the paired MPTCP-level
resources and be sure to release the msk last, even when
the unaccepted subflow is destroyed by the TCP internals
via inet_child_forget().
We can re-use the existing MPTCP_WORK_CLOSE_SUBFLOW infra,
explicitly checking that for the critical scenario: the
closed subflow is the MPC one, the msk is not accepted and
eventually going through full cleanup.
With such change, __mptcp_destroy_sock() is always called
on msk sockets, even on accepted ones. We don't need anymore
to transiently drop one sk reference at msk clone time.
Please note this commit depends on the parent one:
mptcp: refactor passive socket initialization |
| In the Linux kernel, the following vulnerability has been resolved:
perf/x86/amd/core: Always clear status for idx
The variable 'status' (which contains the unhandled overflow bits) is
not being properly masked in some cases, displaying the following
warning:
WARNING: CPU: 156 PID: 475601 at arch/x86/events/amd/core.c:972 amd_pmu_v2_handle_irq+0x216/0x270
This seems to be happening because the loop is being continued before
the status bit being unset, in case x86_perf_event_set_period()
returns 0. This is also causing an inconsistency because the "handled"
counter is incremented, but the status bit is not cleaned.
Move the bit cleaning together above, together when the "handled"
counter is incremented. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix ttm_bo calltrace warning in psp_hw_fini
The call trace occurs when the amdgpu is removed after
the mode1 reset. During mode1 reset, from suspend to resume,
there is no need to reinitialize the ta firmware buffer
which caused the bo pin_count increase redundantly.
[ 489.885525] Call Trace:
[ 489.885525] <TASK>
[ 489.885526] amdttm_bo_put+0x34/0x50 [amdttm]
[ 489.885529] amdgpu_bo_free_kernel+0xe8/0x130 [amdgpu]
[ 489.885620] psp_free_shared_bufs+0xb7/0x150 [amdgpu]
[ 489.885720] psp_hw_fini+0xce/0x170 [amdgpu]
[ 489.885815] amdgpu_device_fini_hw+0x2ff/0x413 [amdgpu]
[ 489.885960] ? blocking_notifier_chain_unregister+0x56/0xb0
[ 489.885962] amdgpu_driver_unload_kms+0x51/0x60 [amdgpu]
[ 489.886049] amdgpu_pci_remove+0x5a/0x140 [amdgpu]
[ 489.886132] ? __pm_runtime_resume+0x60/0x90
[ 489.886134] pci_device_remove+0x3e/0xb0
[ 489.886135] __device_release_driver+0x1ab/0x2a0
[ 489.886137] driver_detach+0xf3/0x140
[ 489.886138] bus_remove_driver+0x6c/0xf0
[ 489.886140] driver_unregister+0x31/0x60
[ 489.886141] pci_unregister_driver+0x40/0x90
[ 489.886142] amdgpu_exit+0x15/0x451 [amdgpu] |
| In the Linux kernel, the following vulnerability has been resolved:
ftrace: Fix invalid address access in lookup_rec() when index is 0
KASAN reported follow problem:
BUG: KASAN: use-after-free in lookup_rec
Read of size 8 at addr ffff000199270ff0 by task modprobe
CPU: 2 Comm: modprobe
Call trace:
kasan_report
__asan_load8
lookup_rec
ftrace_location
arch_check_ftrace_location
check_kprobe_address_safe
register_kprobe
When checking pg->records[pg->index - 1].ip in lookup_rec(), it can get a
pg which is newly added to ftrace_pages_start in ftrace_process_locs().
Before the first pg->index++, index is 0 and accessing pg->records[-1].ip
will cause this problem.
Don't check the ip when pg->index is 0. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: fix shift-out-of-bounds in CalculateVMAndRowBytes
[WHY]
When PTEBufferSizeInRequests is zero, UBSAN reports the following
warning because dml_log2 returns an unexpected negative value:
shift exponent 4294966273 is too large for 32-bit type 'int'
[HOW]
In the case PTEBufferSizeInRequests is zero, skip the dml_log2() and
assign the result directly. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: scsi_dh_alua: Fix memleak for 'qdata' in alua_activate()
If alua_rtpg_queue() failed from alua_activate(), then 'qdata' is not
freed, which will cause following memleak:
unreferenced object 0xffff88810b2c6980 (size 32):
comm "kworker/u16:2", pid 635322, jiffies 4355801099 (age 1216426.076s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
40 39 24 c1 ff ff ff ff 00 f8 ea 0a 81 88 ff ff @9$.............
backtrace:
[<0000000098f3a26d>] alua_activate+0xb0/0x320
[<000000003b529641>] scsi_dh_activate+0xb2/0x140
[<000000007b296db3>] activate_path_work+0xc6/0xe0 [dm_multipath]
[<000000007adc9ace>] process_one_work+0x3c5/0x730
[<00000000c457a985>] worker_thread+0x93/0x650
[<00000000cb80e628>] kthread+0x1ba/0x210
[<00000000a1e61077>] ret_from_fork+0x22/0x30
Fix the problem by freeing 'qdata' in error path. |
| In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Fix steering rules cleanup
vport's mc, uc and multicast rules are not deleted in teardown path when
EEH happens. Since the vport's promisc settings(uc, mc and all) in
firmware are reset after EEH, mlx5 driver will try to delete the above
rules in the initialization path. This cause kernel crash because these
software rules are no longer valid.
Fix by nullifying these rules right after delete to avoid accessing any dangling
pointers.
Call Trace:
__list_del_entry_valid+0xcc/0x100 (unreliable)
tree_put_node+0xf4/0x1b0 [mlx5_core]
tree_remove_node+0x30/0x70 [mlx5_core]
mlx5_del_flow_rules+0x14c/0x1f0 [mlx5_core]
esw_apply_vport_rx_mode+0x10c/0x200 [mlx5_core]
esw_update_vport_rx_mode+0xb4/0x180 [mlx5_core]
esw_vport_change_handle_locked+0x1ec/0x230 [mlx5_core]
esw_enable_vport+0x130/0x260 [mlx5_core]
mlx5_eswitch_enable_sriov+0x2a0/0x2f0 [mlx5_core]
mlx5_device_enable_sriov+0x74/0x440 [mlx5_core]
mlx5_load_one+0x114c/0x1550 [mlx5_core]
mlx5_pci_resume+0x68/0xf0 [mlx5_core]
eeh_report_resume+0x1a4/0x230
eeh_pe_dev_traverse+0x98/0x170
eeh_handle_normal_event+0x3e4/0x640
eeh_handle_event+0x4c/0x370
eeh_event_handler+0x14c/0x210
kthread+0x168/0x1b0
ret_from_kernel_thread+0x5c/0x84 |
| In the Linux kernel, the following vulnerability has been resolved:
xsk: Add missing overflow check in xdp_umem_reg
The number of chunks can overflow u32. Make sure to return -EINVAL on
overflow. Also remove a redundant u32 cast assigning umem->npgs. |
| In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix data corruption after failed write
When buffered write fails to copy data into underlying page cache page,
ocfs2_write_end_nolock() just zeroes out and dirties the page. This can
leave dirty page beyond EOF and if page writeback tries to write this page
before write succeeds and expands i_size, page gets into inconsistent
state where page dirty bit is clear but buffer dirty bits stay set
resulting in page data never getting written and so data copied to the
page is lost. Fix the problem by invalidating page beyond EOF after
failed write. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btsdio: fix use after free bug in btsdio_remove due to race condition
In btsdio_probe, the data->work is bound with btsdio_work. It will be
started in btsdio_send_frame.
If the btsdio_remove runs with a unfinished work, there may be a race
condition that hdev is freed but used in btsdio_work. Fix it by
canceling the work before do cleanup in btsdio_remove. |
| In the Linux kernel, the following vulnerability has been resolved:
vp_vdpa: fix the crash in hot unplug with vp_vdpa
While unplugging the vp_vdpa device, it triggers a kernel panic
The root cause is: vdpa_mgmtdev_unregister() will accesses modern
devices which will cause a use after free.
So need to change the sequence in vp_vdpa_remove
[ 195.003359] BUG: unable to handle page fault for address: ff4e8beb80199014
[ 195.004012] #PF: supervisor read access in kernel mode
[ 195.004486] #PF: error_code(0x0000) - not-present page
[ 195.004960] PGD 100000067 P4D 1001b6067 PUD 1001b7067 PMD 1001b8067 PTE 0
[ 195.005578] Oops: 0000 1 PREEMPT SMP PTI
[ 195.005968] CPU: 13 PID: 164 Comm: kworker/u56:10 Kdump: loaded Not tainted 5.14.0-252.el9.x86_64 #1
[ 195.006792] Hardware name: Red Hat KVM/RHEL, BIOS edk2-20221207gitfff6d81270b5-2.el9 unknown
[ 195.007556] Workqueue: kacpi_hotplug acpi_hotplug_work_fn
[ 195.008059] RIP: 0010:ioread8+0x31/0x80
[ 195.008418] Code: 77 28 48 81 ff 00 00 01 00 76 0b 89 fa ec 0f b6 c0 c3 cc cc cc cc 8b 15 ad 72 93 01 b8 ff 00 00 00 85 d2 75 0f c3 cc cc cc cc <8a> 07 0f b6 c0 c3 cc cc cc cc 83 ea 01 48 83 ec 08 48 89 fe 48 c7
[ 195.010104] RSP: 0018:ff4e8beb8067bab8 EFLAGS: 00010292
[ 195.010584] RAX: ffffffffc05834a0 RBX: ffffffffc05843c0 RCX: ff4e8beb8067bae0
[ 195.011233] RDX: ff1bcbd580f88000 RSI: 0000000000000246 RDI: ff4e8beb80199014
[ 195.011881] RBP: ff1bcbd587e39000 R08: ffffffff916fa2d0 R09: ff4e8beb8067ba68
[ 195.012527] R10: 000000000000001c R11: 0000000000000000 R12: ff1bcbd5a3de9120
[ 195.013179] R13: ffffffffc062d000 R14: 0000000000000080 R15: ff1bcbe402bc7805
[ 195.013826] FS: 0000000000000000(0000) GS:ff1bcbe402740000(0000) knlGS:0000000000000000
[ 195.014564] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 195.015093] CR2: ff4e8beb80199014 CR3: 0000000107dea002 CR4: 0000000000771ee0
[ 195.015741] PKRU: 55555554
[ 195.016001] Call Trace:
[ 195.016233] <TASK>
[ 195.016434] vp_modern_get_status+0x12/0x20
[ 195.016823] vp_vdpa_reset+0x1b/0x50 [vp_vdpa]
[ 195.017238] virtio_vdpa_reset+0x3c/0x48 [virtio_vdpa]
[ 195.017709] remove_vq_common+0x1f/0x3a0 [virtio_net]
[ 195.018178] virtnet_remove+0x5d/0x70 [virtio_net]
[ 195.018618] virtio_dev_remove+0x3d/0x90
[ 195.018986] device_release_driver_internal+0x1aa/0x230
[ 195.019466] bus_remove_device+0xd8/0x150
[ 195.019841] device_del+0x18b/0x3f0
[ 195.020167] ? kernfs_find_ns+0x35/0xd0
[ 195.020526] device_unregister+0x13/0x60
[ 195.020894] unregister_virtio_device+0x11/0x20
[ 195.021311] device_release_driver_internal+0x1aa/0x230
[ 195.021790] bus_remove_device+0xd8/0x150
[ 195.022162] device_del+0x18b/0x3f0
[ 195.022487] device_unregister+0x13/0x60
[ 195.022852] ? vdpa_dev_remove+0x30/0x30 [vdpa]
[ 195.023270] vp_vdpa_dev_del+0x12/0x20 [vp_vdpa]
[ 195.023694] vdpa_match_remove+0x2b/0x40 [vdpa]
[ 195.024115] bus_for_each_dev+0x78/0xc0
[ 195.024471] vdpa_mgmtdev_unregister+0x65/0x80 [vdpa]
[ 195.024937] vp_vdpa_remove+0x23/0x40 [vp_vdpa]
[ 195.025353] pci_device_remove+0x36/0xa0
[ 195.025719] device_release_driver_internal+0x1aa/0x230
[ 195.026201] pci_stop_bus_device+0x6c/0x90
[ 195.026580] pci_stop_and_remove_bus_device+0xe/0x20
[ 195.027039] disable_slot+0x49/0x90
[ 195.027366] acpiphp_disable_and_eject_slot+0x15/0x90
[ 195.027832] hotplug_event+0xea/0x210
[ 195.028171] ? hotplug_event+0x210/0x210
[ 195.028535] acpiphp_hotplug_notify+0x22/0x80
[ 195.028942] ? hotplug_event+0x210/0x210
[ 195.029303] acpi_device_hotplug+0x8a/0x1d0
[ 195.029690] acpi_hotplug_work_fn+0x1a/0x30
[ 195.030077] process_one_work+0x1e8/0x3c0
[ 195.030451] worker_thread+0x50/0x3b0
[ 195.030791] ? rescuer_thread+0x3a0/0x3a0
[ 195.031165] kthread+0xd9/0x100
[ 195.031459] ? kthread_complete_and_exit+0x20/0x20
[ 195.031899] ret_from_fork+0x22/0x30
[ 195.032233] </TASK> |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: prevent hang on link training fail
[Why]
When link training fails, the phy clock will be disabled. However, in
enable_streams, it is assumed that link training succeeded and the
mux selects the phy clock, causing a hang when a register write is made.
[How]
When enable_stream is hit, check if link training failed. If it did, fall
back to the ref clock to avoid a hang and keep the system in a recoverable
state. |
| In the Linux kernel, the following vulnerability has been resolved:
media: dw2102: Fix null-ptr-deref in dw2102_i2c_transfer()
In dw2102_i2c_transfer, msg is controlled by user. When msg[i].buf
is null and msg[i].len is zero, former checks on msg[i].buf would be
passed. Malicious data finally reach dw2102_i2c_transfer. If accessing
msg[i].buf[0] without sanity check, null ptr deref would happen.
We add check on msg[i].len to prevent crash.
Similar commit:
commit 950e252cb469
("[media] dw2102: limit messages to buffer size") |
| In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Use local fence in error path of xe_migrate_clear
The intent of the error path in xe_migrate_clear is to wait on locally
generated fence and then return. The code is waiting on m->fence which
could be the local fence but this is only stable under the job mutex
leading to a possible UAF. Fix code to wait on local fence.
(cherry picked from commit 762b7e95362170b3e13a8704f38d5e47eca4ba74) |
| In the Linux kernel, the following vulnerability has been resolved:
net: use sock_gen_put() when sk_state is TCP_TIME_WAIT
It is possible for a pointer of type struct inet_timewait_sock to be
returned from the functions __inet_lookup_established() and
__inet6_lookup_established(). This can cause a crash when the
returned pointer is of type struct inet_timewait_sock and
sock_put() is called on it. The following is a crash call stack that
shows sk->sk_wmem_alloc being accessed in sk_free() during the call to
sock_put() on a struct inet_timewait_sock pointer. To avoid this issue,
use sock_gen_put() instead of sock_put() when sk->sk_state
is TCP_TIME_WAIT.
mrdump.ko ipanic() + 120
vmlinux notifier_call_chain(nr_to_call=-1, nr_calls=0) + 132
vmlinux atomic_notifier_call_chain(val=0) + 56
vmlinux panic() + 344
vmlinux add_taint() + 164
vmlinux end_report() + 136
vmlinux kasan_report(size=0) + 236
vmlinux report_tag_fault() + 16
vmlinux do_tag_recovery() + 16
vmlinux __do_kernel_fault() + 88
vmlinux do_bad_area() + 28
vmlinux do_tag_check_fault() + 60
vmlinux do_mem_abort() + 80
vmlinux el1_abort() + 56
vmlinux el1h_64_sync_handler() + 124
vmlinux > 0xFFFFFFC080011294()
vmlinux __lse_atomic_fetch_add_release(v=0xF2FFFF82A896087C)
vmlinux __lse_atomic_fetch_sub_release(v=0xF2FFFF82A896087C)
vmlinux arch_atomic_fetch_sub_release(i=1, v=0xF2FFFF82A896087C)
+ 8
vmlinux raw_atomic_fetch_sub_release(i=1, v=0xF2FFFF82A896087C)
+ 8
vmlinux atomic_fetch_sub_release(i=1, v=0xF2FFFF82A896087C) + 8
vmlinux __refcount_sub_and_test(i=1, r=0xF2FFFF82A896087C,
oldp=0) + 8
vmlinux __refcount_dec_and_test(r=0xF2FFFF82A896087C, oldp=0) + 8
vmlinux refcount_dec_and_test(r=0xF2FFFF82A896087C) + 8
vmlinux sk_free(sk=0xF2FFFF82A8960700) + 28
vmlinux sock_put() + 48
vmlinux tcp6_check_fraglist_gro() + 236
vmlinux tcp6_gro_receive() + 624
vmlinux ipv6_gro_receive() + 912
vmlinux dev_gro_receive() + 1116
vmlinux napi_gro_receive() + 196
ccmni.ko ccmni_rx_callback() + 208
ccmni.ko ccmni_queue_recv_skb() + 388
ccci_dpmaif.ko dpmaif_rxq_push_thread() + 1088
vmlinux kthread() + 268
vmlinux 0xFFFFFFC08001F30C() |
| In the Linux kernel, the following vulnerability has been resolved:
drm/xe/userptr: fix notifier vs folio deadlock
User is reporting what smells like notifier vs folio deadlock, where
migrate_pages_batch() on core kernel side is holding folio lock(s) and
then interacting with the mappings of it, however those mappings are
tied to some userptr, which means calling into the notifier callback and
grabbing the notifier lock. With perfect timing it looks possible that
the pages we pulled from the hmm fault can get sniped by
migrate_pages_batch() at the same time that we are holding the notifier
lock to mark the pages as accessed/dirty, but at this point we also want
to grab the folio locks(s) to mark them as dirty, but if they are
contended from notifier/migrate_pages_batch side then we deadlock since
folio lock won't be dropped until we drop the notifier lock.
Fortunately the mark_page_accessed/dirty is not really needed in the
first place it seems and should have already been done by hmm fault, so
just remove it.
(cherry picked from commit bd7c0cb695e87c0e43247be8196b4919edbe0e85) |
| In the Linux kernel, the following vulnerability has been resolved:
mtd: inftlcore: Add error check for inftl_read_oob()
In INFTL_findwriteunit(), the return value of inftl_read_oob()
need to be checked. A proper implementation can be
found in INFTL_deleteblock(). The status will be set as
SECTOR_IGNORE to break from the while-loop correctly
if the inftl_read_oob() fails. |
| Multiple vulnerabilities exist in the web-based management interface of AOS-10 GW and AOS-8 Controller/Mobility Conductor. Successful exploitation of these vulnerabilities could allow an authenticated, remote attacker to download arbitrary files from the filesystem of an affected device. |
| This vulnerability allows access to arbitrary files in the application server file system due to a path traversal vulnerability in JavaServer Faces (JSF) 2.2.20 documented in CVE-2020-6950. The remediation for this vulnerability contained in this security fix provides additional changes to the remediation announced in May 2021 tracked by ETN IIQSAW-3585 and January 2024 tracked by IIQFW-336. This vulnerability in IdentityIQ is assigned CVE-2024-2227. |
| This vulnerability allows an authenticated user to perform a Lifecycle Manager flow or other QuickLink for a target user outside of the defined QuickLink Population. |
