| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: scsi_debug: Don't call kcalloc() if size arg is zero
If the size arg to kcalloc() is zero, it returns ZERO_SIZE_PTR. Because of
that, for a following NULL pointer check to work on the returned pointer,
kcalloc() must not be called with the size arg equal to zero. Return early
without error before the kcalloc() call if size arg is zero.
BUG: KASAN: null-ptr-deref in memcpy include/linux/fortify-string.h:191 [inline]
BUG: KASAN: null-ptr-deref in sg_copy_buffer+0x138/0x240 lib/scatterlist.c:974
Write of size 4 at addr 0000000000000010 by task syz-executor.1/22789
CPU: 1 PID: 22789 Comm: syz-executor.1 Not tainted 5.15.0-syzk #1
Hardware name: Red Hat KVM, BIOS 1.13.0-2
Call Trace:
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106
__kasan_report mm/kasan/report.c:446 [inline]
kasan_report.cold.14+0x112/0x117 mm/kasan/report.c:459
check_region_inline mm/kasan/generic.c:183 [inline]
kasan_check_range+0x1a3/0x210 mm/kasan/generic.c:189
memcpy+0x3b/0x60 mm/kasan/shadow.c:66
memcpy include/linux/fortify-string.h:191 [inline]
sg_copy_buffer+0x138/0x240 lib/scatterlist.c:974
do_dout_fetch drivers/scsi/scsi_debug.c:2954 [inline]
do_dout_fetch drivers/scsi/scsi_debug.c:2946 [inline]
resp_verify+0x49e/0x930 drivers/scsi/scsi_debug.c:4276
schedule_resp+0x4d8/0x1a70 drivers/scsi/scsi_debug.c:5478
scsi_debug_queuecommand+0x8c9/0x1ec0 drivers/scsi/scsi_debug.c:7533
scsi_dispatch_cmd drivers/scsi/scsi_lib.c:1520 [inline]
scsi_queue_rq+0x16b0/0x2d40 drivers/scsi/scsi_lib.c:1699
blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1639
__blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325
blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358
__blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1761
__blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1838
blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891
blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474
blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:62
blk_execute_rq+0xdb/0x360 block/blk-exec.c:102
sg_scsi_ioctl drivers/scsi/scsi_ioctl.c:621 [inline]
scsi_ioctl+0x8bb/0x15c0 drivers/scsi/scsi_ioctl.c:930
sg_ioctl_common+0x172d/0x2710 drivers/scsi/sg.c:1112
sg_ioctl+0xa2/0x180 drivers/scsi/sg.c:1165
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:874 [inline]
__se_sys_ioctl fs/ioctl.c:860 [inline]
__x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Fix scsi_mode_sense() buffer length handling
Several problems exist with scsi_mode_sense() buffer length handling:
1) The allocation length field of the MODE SENSE(10) command is 16-bits,
occupying bytes 7 and 8 of the CDB. With this command, access to mode
pages larger than 255 bytes is thus possible. However, the CDB
allocation length field is set by assigning len to byte 8 only, thus
truncating buffer length larger than 255.
2) If scsi_mode_sense() is called with len smaller than 8 with
sdev->use_10_for_ms set, or smaller than 4 otherwise, the buffer length
is increased to 8 and 4 respectively, and the buffer is zero filled
with these increased values, thus corrupting the memory following the
buffer.
Fix these 2 problems by using put_unaligned_be16() to set the allocation
length field of MODE SENSE(10) CDB and by returning an error when len is
too small.
Furthermore, if len is larger than 255B, always try MODE SENSE(10) first,
even if the device driver did not set sdev->use_10_for_ms. In case of
invalid opcode error for MODE SENSE(10), access to mode pages larger than
255 bytes are not retried using MODE SENSE(6). To avoid buffer length
overflows for the MODE_SENSE(10) case, check that len is smaller than 65535
bytes.
While at it, also fix the folowing:
* Use get_unaligned_be16() to retrieve the mode data length and block
descriptor length fields of the mode sense reply header instead of using
an open coded calculation.
* Fix the kdoc dbd argument explanation: the DBD bit stands for Disable
Block Descriptor, which is the opposite of what the dbd argument
description was. |
| In the Linux kernel, the following vulnerability has been resolved:
USB: usbfs: Don't WARN about excessively large memory allocations
Syzbot found that the kernel generates a WARNing if the user tries to
submit a bulk transfer through usbfs with a buffer that is way too
large. This isn't a bug in the kernel; it's merely an invalid request
from the user and the usbfs code does handle it correctly.
In theory the same thing can happen with async transfers, or with the
packet descriptor table for isochronous transfers.
To prevent the MM subsystem from complaining about these bad
allocation requests, add the __GFP_NOWARN flag to the kmalloc calls
for these buffers. |
| In onHeaderDecoded of LocalImageResolver.java, there is a possible persistent denial of service due to resource exhaustion. This could lead to remote denial of service with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In getComponentName of MediaButtonReceiverHolder.java, there is a possible desync in persistence due to resource exhaustion. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In InputMethodInfo of InputMethodInfo.java, there is a possible permanent denial of service due to resource exhaustion. This could lead to local denial of service with no additional execution privileges needed. User interaction is not needed for exploitation. |
| InvenTree is an Open Source Inventory Management System. Prior to version 0.17.13, the skip field in the built-in `label-sheet` plugin lacks an upper bound, so a large value forces the server to allocate an enormous Python list. This lets any authenticated label-printing user trigger a denial-of-service via memory exhaustion. the issue is fixed in versions 0.17.13 and higher. No workaround is available aside from upgrading to the patched version. |
| node-tar is a Tar for Node.js. node-tar prior to version 6.2.1 has no limit on the number of sub-folders created in the folder creation process. An attacker who generates a large number of sub-folders can consume memory on the system running node-tar and even crash the Node.js client within few seconds of running it using a path with too many sub-folders inside. Version 6.2.1 fixes this issue by preventing extraction in excessively deep sub-folders. |
| A Denial Of Service via File Upload (DOS) vulnerability in the Liferay Portal 7.4.3.0 through 7.4.3.132, and Liferay DXP 2025.Q1.0 through 2025.Q1.8, 2024.Q4.0 through 2024.Q4.7, 2024.Q3.0 through 2024.Q3.13, 2024.Q2.0 through 2024.Q2.13, 2024.Q1.1 through 2024.Q1.16 and 7.4 GA through update 92 allows a user to upload more than 300kb profile picture into the user profile. This size more than the noted max 300kb size. This extra amount of data can make Liferay slower. |
| Liferay Portal 7.4.0 through 7.4.3.132, and Liferay DXP 2025.Q1.0 through 2025.Q1.4, 2024.Q4.0 through 2024.Q4.7, 2024.Q3.1 through 2024.Q3.13, 2024.Q2.0 through 2024.Q2.13, 2024.Q1.1 through 2024.Q1.15 and 7.4 GA through update 92 allow users to upload an unlimited amount of files through the object entries attachment fields, the files are stored in the document_library allowing an attacker to cause a potential DDoS. |
| Liferay Portal 7.4.0 through 7.4.3.132, and Liferay DXP 2025.Q1.0 through 2025.Q1.1, 2024.Q4.0 through 2024.Q4.7, 2024.Q3.1 through 2024.Q3.13, 2024.Q2.0 through 2024.Q2.13, 2024.Q1.1 through 2024.Q1.14 and 7.4 GA through update 92 allow users to upload an unlimited amount of files through the forms, the files are stored in the document_library allowing an attacker to cause a potential DDoS. |
| SSH servers parsing GSSAPI authentication requests do not validate the number of mechanisms specified in the request, allowing an attacker to cause unbounded memory consumption. |
| GitLab has remediated an issue in GitLab CE/EE affecting all versions from 8.3 before 18.4.5, 18.5 before 18.5.3, and 18.6 before 18.6.1 that could have allowed an authenticated user with specific permissions to cause a denial of service condition through HTTP response processing. |
| GitLab has remediated an issue in GitLab CE/EE affecting all versions from 17.10 before 18.4.5, 18.5 before 18.5.3, and 18.6 before 18.6.1 that could have allowed an unauthenticated user to cause a Denial of Service condition by sending specifically crafted requests containing malicious JSON payloads. |
| IBM watsonx.data 2.2 through 2.2.1 could allow an authenticated user to cause a denial of service through ingestion pods due to improper allocation of resources without limits. |
| A security issue exists within 432ES-IG3 Series A, which affects GuardLink® EtherNet/IP Interface, resulting in denial-of-service. A manual power cycle is required to recover the device. |
| Realchar version v0.0.4 is vulnerable to an unauthenticated denial of service (DoS) attack. The vulnerability exists in the file upload request handling, where appending characters, such as dashes (-), to the end of a multipart boundary in an HTTP request causes the server to continuously process each character. This leads to excessive resource consumption and renders the service unavailable. The issue is unauthenticated and does not require any user interaction, impacting all users of the service. |
| urllib3 is a user-friendly HTTP client library for Python. Starting in version 1.24 and prior to 2.6.0, the number of links in the decompression chain was unbounded allowing a malicious server to insert a virtually unlimited number of compression steps leading to high CPU usage and massive memory allocation for the decompressed data. This vulnerability is fixed in 2.6.0. |
| The ParseAddress function constructs domain-literal address components through repeated string concatenation. When parsing large domain-literal components, this can cause excessive CPU consumption. |
| In multiple locations, there is a possible permanent denial of service due to resource exhaustion. This could lead to local denial of service with no additional execution privileges needed. User interaction is not needed for exploitation. |
