| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A vulnerability in the Cisco Express Forwarding functionality of Cisco IOS XE Software for Cisco ASR 903 Aggregation Services Routers with Route Switch Processor 3 (RSP3C) could allow an unauthenticated, adjacent attacker to trigger a denial of service (DoS) condition.
This vulnerability is due to improper memory management when Cisco IOS XE Software is processing Address Resolution Protocol (ARP) messages. An attacker could exploit this vulnerability by sending crafted ARP messages at a high rate over a period of time to an affected device. A successful exploit could allow the attacker to exhaust system resources, which eventually triggers a reload of the active route switch processor (RSP). If a redundant RSP is not present, the router reloads. |
| A memory corruption vulnerability in HddPassword in Insyde InsydeH2O kernel 5.2 before 05.29.09, kernel 5.3 before 05.38.09, kernel 5.4 before 05.46.09, kernel 5.5 before 05.54.09, and kernel 5.6 before 05.61.09 could lead to escalating privileges in SMM. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: typec: tipd: Free IRQ only if it was requested before
In polling mode, if no IRQ was requested there is no need to free it.
Call devm_free_irq() only if client->irq is set. This fixes the warning
caused by the tps6598x module removal:
WARNING: CPU: 2 PID: 333 at kernel/irq/devres.c:144 devm_free_irq+0x80/0x8c
...
...
Call trace:
devm_free_irq+0x80/0x8c
tps6598x_remove+0x28/0x88 [tps6598x]
i2c_device_remove+0x2c/0x9c
device_remove+0x4c/0x80
device_release_driver_internal+0x1cc/0x228
driver_detach+0x50/0x98
bus_remove_driver+0x6c/0xbc
driver_unregister+0x30/0x60
i2c_del_driver+0x54/0x64
tps6598x_i2c_driver_exit+0x18/0xc3c [tps6598x]
__arm64_sys_delete_module+0x184/0x264
invoke_syscall+0x48/0x110
el0_svc_common.constprop.0+0xc8/0xe8
do_el0_svc+0x20/0x2c
el0_svc+0x28/0x98
el0t_64_sync_handler+0x13c/0x158
el0t_64_sync+0x190/0x194 |
| BerriAI/litellm is vulnerable to Server-Side Template Injection (SSTI) via the `/completions` endpoint. The vulnerability arises from the `hf_chat_template` method processing the `chat_template` parameter from the `tokenizer_config.json` file through the Jinja template engine without proper sanitization. Attackers can exploit this by crafting malicious `tokenizer_config.json` files that execute arbitrary code on the server. |
| parisneo/lollms-webui, in its latest version, is vulnerable to remote code execution due to an insecure dependency on llama-cpp-python version llama_cpp_python-0.2.61+cpuavx2-cp311-cp311-manylinux_2_31_x86_64. The vulnerability arises from the application's 'binding_zoo' feature, which allows attackers to upload and interact with a malicious model file hosted on hugging-face, leading to remote code execution. The issue is linked to a known vulnerability in llama-cpp-python, CVE-2024-34359, which has not been patched in lollms-webui as of commit b454f40a. The vulnerability is exploitable through the application's handling of model files in the 'bindings_zoo' feature, specifically when processing gguf format model files. |
| An issue was discovered in Samsung Semiconductor Mobile Processor and Modem Exynos 9820, Exynos 9825, Exynos 980, Exynos 990, Exynos 850, Exynos 1080, Exynos 2100, Exynos 2200, Exynos 1280, Exynos 1380, Exynos 1330, Exynos 9110, Exynos W920, Exynos W930, Exynos Modem 5123, Exynos Modem 5300. The baseband software does not properly check a pointer specified by the SM (Session Management module), which can lead to Denial of Service (Untrusted Pointer Dereference). |
| There is a memory management vulnerability in Absolute
Secure Access server versions 9.0 to 13.54. Attackers with network access to
the server can cause a Denial of Service by sending a specially crafted
sequence of packets to the server. The attack complexity is low, there are no
attack requirements, privileges, or user interaction required. Loss of
availability is high; there is no impact on confidentiality or integrity. |
| Memory corruption while reading ACPI config through the user mode app. |
|
An Improper Neutralization of Equivalent Special Elements vulnerability in the Packet Forwarding Engine (PFE) of Juniper Networks Junos OS on PTX Series allows a unauthenticated, adjacent attacker to cause a Denial of Service (DoS).
When MPLS packets are meant to be sent to a flexible tunnel interface (FTI) and if the FTI tunnel is down, these will hit the reject NH, due to which the packets get sent to the CPU and cause a host path wedge condition. This will cause the FPC to hang and requires a manual restart to recover.
Please note that this issue specifically affects PTX1000, PTX3000, PTX5000 with FPC3, PTX10002-60C, and PTX10008/16 with LC110x. Other PTX Series devices and Line Cards (LC) are not affected.
The following log message can be seen when the issue occurs:
Cmerror Op Set: Host Loopback: HOST LOOPBACK WEDGE DETECTED IN PATH ID <id> (URI: /fpc/<fpc>/pfe/<pfe>/cm/<cm>/Host_Loopback/<cm>/HOST_LOOPBACK_MAKE_CMERROR_ID[<id>])
This issue affects Juniper Networks Junos OS:
* All versions earlier than 20.4R3-S8;
* 21.1 versions earlier than 21.1R3-S4;
* 21.2 versions earlier than 21.2R3-S6;
* 21.3 versions earlier than 21.3R3-S3;
* 21.4 versions earlier than 21.4R3-S5;
* 22.1 versions earlier than 22.1R2-S2, 22.1R3;
* 22.2 versions earlier than 22.2R2-S1, 22.2R3.
|
| Redis is an in-memory database that persists on disk. Redis incorrectly handles resizing of memory buffers which can result in integer overflow that leads to heap overflow and potential remote code execution. This issue has been patched in version 7.0.15 and 7.2.4. |
| V-SFT v6.2.5.0 and earlier contains an issue with free of pointer not at start of buffer in VS6EditData.dll!CWinFontInf::WinFontMsgCheck function. Opening specially crafted V7 or V8 files may lead to crash, information disclosure, and arbitrary code execution. |
| In the Linux kernel through 6.2.7, fs/ntfs3/inode.c has an invalid kfree because it does not validate MFT flags before replaying logs. |
| When a BIG-IP Advanced WAF/ASM security policy is configured on a virtual server, undisclosed requests can cause the bd process to terminate. |
| The Gutenberg Template Library & Redux Framework plugin <= 4.2.11 for WordPress registered several AJAX actions available to unauthenticated users in the `includes` function in `redux-core/class-redux-core.php` that were unique to a given site but deterministic and predictable given that they were based on an md5 hash of the site URL with a known salt value of '-redux' and an md5 hash of the previous hash with a known salt value of '-support'. These AJAX actions could be used to retrieve a list of active plugins and their versions, the site's PHP version, and an unsalted md5 hash of site’s `AUTH_KEY` concatenated with the `SECURE_AUTH_KEY`. |
| In the Linux kernel, the following vulnerability has been resolved:
bluetooth/hci: disallow setting handle bigger than HCI_CONN_HANDLE_MAX
Syzbot hit warning in hci_conn_del() caused by freeing handle that was
not allocated using ida allocator.
This is caused by handle bigger than HCI_CONN_HANDLE_MAX passed by
hci_le_big_sync_established_evt(), which makes code think it's unset
connection.
Add same check for handle upper bound as in hci_conn_set_handle() to
prevent warning. |
| In the Linux kernel, the following vulnerability has been resolved:
tee: optee: Fix incorrect page free bug
Pointer to the allocated pages (struct page *page) has already
progressed towards the end of allocation. It is incorrect to perform
__free_pages(page, order) using this pointer as we would free any
arbitrary pages. Fix this by stop modifying the page pointer. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/xe/preempt_fence: enlarge the fence critical section
It is really easy to introduce subtle deadlocks in
preempt_fence_work_func() since we operate on single global ordered-wq
for signalling our preempt fences behind the scenes, so even though we
signal a particular fence, everything in the callback should be in the
fence critical section, since blocking in the callback will prevent
other published fences from signalling. If we enlarge the fence critical
section to cover the entire callback, then lockdep should be able to
understand this better, and complain if we grab a sensitive lock like
vm->lock, which is also held when waiting on preempt fences. |
| In the Linux kernel, the following vulnerability has been resolved:
mmc: mmci: stm32: fix DMA API overlapping mappings warning
Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning:
DMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST,
overlapping mappings aren't supported
WARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568
add_dma_entry+0x234/0x2f4
Modules linked in:
CPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1
Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT)
Workqueue: events_freezable mmc_rescan
Call trace:
add_dma_entry+0x234/0x2f4
debug_dma_map_sg+0x198/0x350
__dma_map_sg_attrs+0xa0/0x110
dma_map_sg_attrs+0x10/0x2c
sdmmc_idma_prep_data+0x80/0xc0
mmci_prep_data+0x38/0x84
mmci_start_data+0x108/0x2dc
mmci_request+0xe4/0x190
__mmc_start_request+0x68/0x140
mmc_start_request+0x94/0xc0
mmc_wait_for_req+0x70/0x100
mmc_send_tuning+0x108/0x1ac
sdmmc_execute_tuning+0x14c/0x210
mmc_execute_tuning+0x48/0xec
mmc_sd_init_uhs_card.part.0+0x208/0x464
mmc_sd_init_card+0x318/0x89c
mmc_attach_sd+0xe4/0x180
mmc_rescan+0x244/0x320
DMA API debug brings to light leaking dma-mappings as dma_map_sg and
dma_unmap_sg are not correctly balanced.
If an error occurs in mmci_cmd_irq function, only mmci_dma_error
function is called and as this API is not managed on stm32 variant,
dma_unmap_sg is never called in this error path. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: mpt3sas: Page fault in reply q processing
A page fault was encountered in mpt3sas on a LUN reset error path:
[ 145.763216] mpt3sas_cm1: Task abort tm failed: handle(0x0002),timeout(30) tr_method(0x0) smid(3) msix_index(0)
[ 145.778932] scsi 1:0:0:0: task abort: FAILED scmd(0x0000000024ba29a2)
[ 145.817307] scsi 1:0:0:0: attempting device reset! scmd(0x0000000024ba29a2)
[ 145.827253] scsi 1:0:0:0: [sg1] tag#2 CDB: Receive Diagnostic 1c 01 01 ff fc 00
[ 145.837617] scsi target1:0:0: handle(0x0002), sas_address(0x500605b0000272b9), phy(0)
[ 145.848598] scsi target1:0:0: enclosure logical id(0x500605b0000272b8), slot(0)
[ 149.858378] mpt3sas_cm1: Poll ReplyDescriptor queues for completion of smid(0), task_type(0x05), handle(0x0002)
[ 149.875202] BUG: unable to handle page fault for address: 00000007fffc445d
[ 149.885617] #PF: supervisor read access in kernel mode
[ 149.894346] #PF: error_code(0x0000) - not-present page
[ 149.903123] PGD 0 P4D 0
[ 149.909387] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 149.917417] CPU: 24 PID: 3512 Comm: scsi_eh_1 Kdump: loaded Tainted: G S O 5.10.89-altav-1 #1
[ 149.934327] Hardware name: DDN 200NVX2 /200NVX2-MB , BIOS ATHG2.2.02.01 09/10/2021
[ 149.951871] RIP: 0010:_base_process_reply_queue+0x4b/0x900 [mpt3sas]
[ 149.961889] Code: 0f 84 22 02 00 00 8d 48 01 49 89 fd 48 8d 57 38 f0 0f b1 4f 38 0f 85 d8 01 00 00 49 8b 45 10 45 31 e4 41 8b 55 0c 48 8d 1c d0 <0f> b6 03 83 e0 0f 3c 0f 0f 85 a2 00 00 00 e9 e6 01 00 00 0f b7 ee
[ 149.991952] RSP: 0018:ffffc9000f1ebcb8 EFLAGS: 00010246
[ 150.000937] RAX: 0000000000000055 RBX: 00000007fffc445d RCX: 000000002548f071
[ 150.011841] RDX: 00000000ffff8881 RSI: 0000000000000001 RDI: ffff888125ed50d8
[ 150.022670] RBP: 0000000000000000 R08: 0000000000000000 R09: c0000000ffff7fff
[ 150.033445] R10: ffffc9000f1ebb68 R11: ffffc9000f1ebb60 R12: 0000000000000000
[ 150.044204] R13: ffff888125ed50d8 R14: 0000000000000080 R15: 34cdc00034cdea80
[ 150.054963] FS: 0000000000000000(0000) GS:ffff88dfaf200000(0000) knlGS:0000000000000000
[ 150.066715] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 150.076078] CR2: 00000007fffc445d CR3: 000000012448a006 CR4: 0000000000770ee0
[ 150.086887] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 150.097670] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 150.108323] PKRU: 55555554
[ 150.114690] Call Trace:
[ 150.120497] ? printk+0x48/0x4a
[ 150.127049] mpt3sas_scsih_issue_tm.cold.114+0x2e/0x2b3 [mpt3sas]
[ 150.136453] mpt3sas_scsih_issue_locked_tm+0x86/0xb0 [mpt3sas]
[ 150.145759] scsih_dev_reset+0xea/0x300 [mpt3sas]
[ 150.153891] scsi_eh_ready_devs+0x541/0x9e0 [scsi_mod]
[ 150.162206] ? __scsi_host_match+0x20/0x20 [scsi_mod]
[ 150.170406] ? scsi_try_target_reset+0x90/0x90 [scsi_mod]
[ 150.178925] ? blk_mq_tagset_busy_iter+0x45/0x60
[ 150.186638] ? scsi_try_target_reset+0x90/0x90 [scsi_mod]
[ 150.195087] scsi_error_handler+0x3a5/0x4a0 [scsi_mod]
[ 150.203206] ? __schedule+0x1e9/0x610
[ 150.209783] ? scsi_eh_get_sense+0x210/0x210 [scsi_mod]
[ 150.217924] kthread+0x12e/0x150
[ 150.224041] ? kthread_worker_fn+0x130/0x130
[ 150.231206] ret_from_fork+0x1f/0x30
This is caused by mpt3sas_base_sync_reply_irqs() using an invalid reply_q
pointer outside of the list_for_each_entry() loop. At the end of the full
list traversal the pointer is invalid.
Move the _base_process_reply_queue() call inside of the loop. |
| In the Linux kernel, the following vulnerability has been resolved:
mm/slub: actually fix freelist pointer vs redzoning
It turns out that SLUB redzoning ("slub_debug=Z") checks from
s->object_size rather than from s->inuse (which is normally bumped to
make room for the freelist pointer), so a cache created with an object
size less than 24 would have the freelist pointer written beyond
s->object_size, causing the redzone to be corrupted by the freelist
pointer. This was very visible with "slub_debug=ZF":
BUG test (Tainted: G B ): Right Redzone overwritten
-----------------------------------------------------------------------------
INFO: 0xffff957ead1c05de-0xffff957ead1c05df @offset=1502. First byte 0x1a instead of 0xbb
INFO: Slab 0xffffef3950b47000 objects=170 used=170 fp=0x0000000000000000 flags=0x8000000000000200
INFO: Object 0xffff957ead1c05d8 @offset=1496 fp=0xffff957ead1c0620
Redzone (____ptrval____): bb bb bb bb bb bb bb bb ........
Object (____ptrval____): 00 00 00 00 00 f6 f4 a5 ........
Redzone (____ptrval____): 40 1d e8 1a aa @....
Padding (____ptrval____): 00 00 00 00 00 00 00 00 ........
Adjust the offset to stay within s->object_size.
(Note that no caches of in this size range are known to exist in the
kernel currently.) |
