| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The mobile application (com.transsnet.store) has a man-in-the-middle attack vulnerability, which may lead to code injection risks. |
| Logical vulnerability in the mobile application (com.transsion.carlcare) may lead to user information leakage risks. |
| Insertion of Sensitive Information into Log File in Checkmk GmbH's Checkmk versions <2.3.0p27, <2.2.0p40, and 2.1.0p51 (EOL) causes LDAP credentials to be written to Apache error log file accessible to administrators. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: dwc3: gadget: check that event count does not exceed event buffer length
The event count is read from register DWC3_GEVNTCOUNT.
There is a check for the count being zero, but not for exceeding the
event buffer length.
Check that event count does not exceed event buffer length,
avoiding an out-of-bounds access when memcpy'ing the event.
Crash log:
Unable to handle kernel paging request at virtual address ffffffc0129be000
pc : __memcpy+0x114/0x180
lr : dwc3_check_event_buf+0xec/0x348
x3 : 0000000000000030 x2 : 000000000000dfc4
x1 : ffffffc0129be000 x0 : ffffff87aad60080
Call trace:
__memcpy+0x114/0x180
dwc3_interrupt+0x24/0x34 |
| In the Linux kernel, the following vulnerability has been resolved:
mcb: fix a double free bug in chameleon_parse_gdd()
In chameleon_parse_gdd(), if mcb_device_register() fails, 'mdev'
would be released in mcb_device_register() via put_device().
Thus, goto 'err' label and free 'mdev' again causes a double free.
Just return if mcb_device_register() fails. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/shmem-helper: Remove another errant put in error path
drm_gem_shmem_mmap() doesn't own reference in error code path, resulting
in the dma-buf shmem GEM object getting prematurely freed leading to a
later use-after-free. |
| In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix UaF in listener shutdown
As reported by Christoph after having refactored the passive
socket initialization, the mptcp listener shutdown path is prone
to an UaF issue.
BUG: KASAN: use-after-free in _raw_spin_lock_bh+0x73/0xe0
Write of size 4 at addr ffff88810cb23098 by task syz-executor731/1266
CPU: 1 PID: 1266 Comm: syz-executor731 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
kasan_check_range+0x14a/0x1a0
_raw_spin_lock_bh+0x73/0xe0
subflow_error_report+0x6d/0x110
sk_error_report+0x3b/0x190
tcp_disconnect+0x138c/0x1aa0
inet_child_forget+0x6f/0x2e0
inet_csk_listen_stop+0x209/0x1060
__mptcp_close_ssk+0x52d/0x610
mptcp_destroy_common+0x165/0x640
mptcp_destroy+0x13/0x80
__mptcp_destroy_sock+0xe7/0x270
__mptcp_close+0x70e/0x9b0
mptcp_close+0x2b/0x150
inet_release+0xe9/0x1f0
__sock_release+0xd2/0x280
sock_close+0x15/0x20
__fput+0x252/0xa20
task_work_run+0x169/0x250
exit_to_user_mode_prepare+0x113/0x120
syscall_exit_to_user_mode+0x1d/0x40
do_syscall_64+0x48/0x90
entry_SYSCALL_64_after_hwframe+0x72/0xdc
The msk grace period can legitly expire in between the last
reference count dropped in mptcp_subflow_queue_clean() and
the later eventual access in inet_csk_listen_stop()
After the previous patch we don't need anymore special-casing
msk listener socket cleanup: the mptcp worker will process each
of the unaccepted msk sockets.
Just drop the now unnecessary code.
Please note this commit depends on the two parent ones:
mptcp: refactor passive socket initialization
mptcp: use the workqueue to destroy unaccepted sockets |
| 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:
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:
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:
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/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:
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. |
| 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. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue
When the task management thread processes reply queues while the reset
thread resets them, the task management thread accesses an invalid queue ID
(0xFFFF), set by the reset thread, which points to unallocated memory,
causing a crash.
Add flag 'io_admin_reset_sync' to synchronize access between the reset,
I/O, and admin threads. Before a reset, the reset handler sets this flag to
block I/O and admin processing threads. If any thread bypasses the initial
check, the reset thread waits up to 10 seconds for processing to finish. If
the wait exceeds 10 seconds, the controller is marked as unrecoverable. |
| In the Linux kernel, the following vulnerability has been resolved:
perf/core: Fix perf_output_begin parameter is incorrectly invoked in perf_event_bpf_output
syzkaller reportes a KASAN issue with stack-out-of-bounds.
The call trace is as follows:
dump_stack+0x9c/0xd3
print_address_description.constprop.0+0x19/0x170
__kasan_report.cold+0x6c/0x84
kasan_report+0x3a/0x50
__perf_event_header__init_id+0x34/0x290
perf_event_header__init_id+0x48/0x60
perf_output_begin+0x4a4/0x560
perf_event_bpf_output+0x161/0x1e0
perf_iterate_sb_cpu+0x29e/0x340
perf_iterate_sb+0x4c/0xc0
perf_event_bpf_event+0x194/0x2c0
__bpf_prog_put.constprop.0+0x55/0xf0
__cls_bpf_delete_prog+0xea/0x120 [cls_bpf]
cls_bpf_delete_prog_work+0x1c/0x30 [cls_bpf]
process_one_work+0x3c2/0x730
worker_thread+0x93/0x650
kthread+0x1b8/0x210
ret_from_fork+0x1f/0x30
commit 267fb27352b6 ("perf: Reduce stack usage of perf_output_begin()")
use on-stack struct perf_sample_data of the caller function.
However, perf_event_bpf_output uses incorrect parameter to convert
small-sized data (struct perf_bpf_event) into large-sized data
(struct perf_sample_data), which causes memory overwriting occurs in
__perf_event_header__init_id. |
| SolarWinds Observability Self-Hosted
was susceptible to a cross-site scripting (XSS) vulnerability due to an unsanitized field in the URL. The attack requires authentication using an administrator-level account and user interaction is required. |
| SolarWinds Observability Self-Hosted is susceptible to Deserialization of Untrusted Data Local Privilege Escalation vulnerability. An attacker with low privileges can escalate privileges to run malicious files copied to a permission-protected folder. This vulnerability requires authentication from a low-level account and local access to the host server. |
| Authenticated command injection vulnerabilities exist in the AOS-10 GW and AOS-8 Controller/Mobility Conductor web-based management interface. Successful exploitation of these vulnerabilities allows an Authenticated attacker to execute arbitrary commands as a privileged user on the underlying operating system. |