Failure to validate the integer operand in ASP (AMD Secure Processor) bootloader may allow an attacker to introduce an integer overflow in the L2 directory table in SPI flash resulting in a potential denial of service.
Insufficient input validation during parsing of the System Management Mode (SMM) binary may allow a maliciously crafted SMM executable binary to corrupt Dynamic Root of Trust for Measurement (DRTM) user application memory that may result in a potential denial of service.
A potential denial of service issue exists in the AMD Display driver Escape 0x130007 Call handler. An attacker with low privilege could potentially induce a Windows BugCheck.
Insufficient fencing and checks in System Management Unit (SMU) may result in access to invalid message port registers that could result in a potential denial-of-service.
Insufficient ID command validation in the SEV Firmware may allow a local authenticated attacker to perform a denial of service of the PSP.
Insufficient bound checks in System Management Unit (SMU) PCIe Hot Plug table may result in access/updates from/to invalid address space that could result in denial of service.
AMD System Management Unit (SMU) may experience a heap-based overflow which may result in a loss of resources.
Insufficient validation of the AMD SEV Signing Key (ASK) in the SEND_START command in the SEV Firmware may allow a local authenticated attacker to perform a denial of service of the PSP
A bug in AMD CPU’s core logic may allow for an attacker, using specific code from an unprivileged VM, to trigger a CPU core hang resulting in a potential denial of service. AMD believes the specific code includes a specific x86 instruction sequence that would not be generated by compilers.
Improper input validation in AMD Crash Defender could allow an attacker to provide the Windows® system process ID to a kernel-mode driver, resulting in an operating system crash, potentially leading to denial of service.
Improper validation of user input in the NPU driver could allow an attacker to provide a buffer with unexpected size, potentially leading to system crash.
Insufficient validation of the Input Output Control (IOCTL) input buffer in AMD μProf may allow an authenticated attacker to cause an out-of-bounds write, potentially causing a Windows® OS crash, resulting in denial of service.
Improper input validation in AMD μProf could allow an attacker to perform a write to an invalid address, potentially resulting in denial of service.
Insufficient General Purpose IO (GPIO) bounds check in System Management Unit (SMU) may result in access/updates from/to invalid address space that could result in denial of service.
Insufficient checks in System Management Unit (SMU) FeatureConfig may result in reenabling features potentially resulting in denial of resources and/or denial of service.
Insufficient validation of the IOCTL (Input Output Control) input buffer in AMD μProf may allow an authenticated user to send an arbitrary buffer potentially resulting in a Windows crash leading to denial of service.
AMD Graphics Driver for Windows 10, amdfender.sys may improperly handle input validation on InputBuffer which may result in a denial of service (DoS).
Insufficient input validation in SEV firmware may allow an attacker to perform out-of-bounds memory reads within the ASP boot loader, potentially leading to a denial of service.
Insufficient bounds checking in the ASP (AMD Secure Processor) may allow an attacker to access memory outside the bounds of what is permissible to a TA (Trusted Application) resulting in a potential denial of service.
A denial of service vulnerability exists in the D3DKMTEscape handler functionality of AMD ATIKMDAG.SYS (e.g. version 26.20.15029.27017). A specially crafted D3DKMTEscape API request can cause an out-of-bounds read in Windows OS kernel memory area. This vulnerability can be triggered from a non-privileged account.
A denial of service vulnerability exists in the D3DKMTCreateAllocation handler functionality of AMD ATIKMDAG.SYS (e.g. version 26.20.15029.27017). A specially crafted D3DKMTCreateAllocation API request can cause an out-of-bounds read and denial of service (BSOD). This vulnerability can be triggered from a non-privileged account.
Insufficient validation of the IOCTL (Input Output Control) input buffer in AMD μProf may allow an authenticated user to send an arbitrary address potentially resulting in a Windows crash leading to denial of service.
Improper validation of the BIOS directory may allow for searches to read beyond the directory table copy in RAM, exposing out of bounds memory contents, resulting in a potential denial of service.
Insufficient bound checks in the System Management Unit (SMU) may result in a system voltage malfunction that could result in denial of resources and/or possibly denial of service.
Insufficient bound checks related to PCIE in the System Management Unit (SMU) may result in access to an invalid address space that could result in denial of service.
Insufficient DRAM address validation in System Management Unit (SMU) may result in a DMA (Direct Memory Access) read/write from/to invalid DRAM address that could result in denial of service.
Insufficient bounds checking in System Management Unit (SMU) may cause invalid memory accesses/updates that could result in SMU hang and subsequent failure to service any further requests from other components.
Insufficient bound checks in the System Management Unit (SMU) may result in access to an invalid address space that could result in denial of service.
Insufficient input validation in the SNP_GUEST_REQUEST command may lead to a potential data abort error and a denial of service.
Insufficient bounds checking in an SMU mailbox register could allow an attacker to potentially read outside of the SRAM address range which could result in an exception handling leading to a potential denial of service.
Integer overflow within AMD NPU Driver could allow a local attacker to write out of bounds, potentially leading to loss of confidentiality, integrity or availability.
Integer overflow within AMD NPU Driver could allow a local attacker to write out of bounds, potentially leading to loss of integrity or availability.
Integer overflow within the AMD NPU Driver could allow a local attacker to write out of bounds, potentially leading to a loss of confidentiality, integrity, or availability.
An integer overflow in the ASP could allow a privileged attacker to perform an out-of-bounds write, potentially resulting in loss of data integrity.
In the Linux kernel, the following vulnerability has been resolved: binfmt_flat: Fix integer overflow bug on 32 bit systems Most of these sizes and counts are capped at 256MB so the math doesn't result in an integer overflow. The "relocs" count needs to be checked as well. Otherwise on 32bit systems the calculation of "full_data" could be wrong. full_data = data_len + relocs * sizeof(unsigned long);
In the Linux kernel, the following vulnerability has been resolved: rdma/cxgb4: Prevent potential integer overflow on 32bit The "gl->tot_len" variable is controlled by the user. It comes from process_responses(). On 32bit systems, the "gl->tot_len + sizeof(struct cpl_pass_accept_req) + sizeof(struct rss_header)" addition could have an integer wrapping bug. Use size_add() to prevent this.
In the Linux kernel, the following vulnerability has been resolved: printk: Fix signed integer overflow when defining LOG_BUF_LEN_MAX Shifting 1 << 31 on a 32-bit int causes signed integer overflow, which leads to undefined behavior. To prevent this, cast 1 to u32 before performing the shift, ensuring well-defined behavior. This change explicitly avoids any potential overflow by ensuring that the shift occurs on an unsigned 32-bit integer.
In the Linux kernel, the following vulnerability has been resolved: rtc: tps6594: Fix integer overflow on 32bit systems The problem is this multiply in tps6594_rtc_set_offset() tmp = offset * TICKS_PER_HOUR; The "tmp" variable is an s64 but "offset" is a long in the (-277774)-277774 range. On 32bit systems a long can hold numbers up to approximately two billion. The number of TICKS_PER_HOUR is really large, (32768 * 3600) or roughly a hundred million. When you start multiplying by a hundred million it doesn't take long to overflow the two billion mark. Probably the safest way to fix this is to change the type of TICKS_PER_HOUR to long long because it's such a large number.
Integer overflow vulnerability during glTF model loading in the 3D engine module Impact: Successful exploitation of this vulnerability may affect availability.
In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent a potential integer overflow If the tag length is >= U32_MAX - 3 then the "length + 4" addition can result in an integer overflow. Address this by splitting the decoding into several steps so that decode_cb_compound4res() does not have to perform arithmetic on the unsafe length value.
In the Linux kernel, the following vulnerability has been resolved: drm: zynqmp_dp: Fix integer overflow in zynqmp_dp_rate_get() This patch fixes a potential integer overflow in the zynqmp_dp_rate_get() The issue comes up when the expression drm_dp_bw_code_to_link_rate(dp->test.bw_code) * 10000 is evaluated using 32-bit Now the constant is a compatible 64-bit type. Resolves coverity issues: CID 1636340 and CID 1635811
In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix address wraparound in move_page_tables() On 32-bit platforms, it is possible for the expression `len + old_addr < old_end` to be false-positive if `len + old_addr` wraps around. `old_addr` is the cursor in the old range up to which page table entries have been moved; so if the operation succeeded, `old_addr` is the *end* of the old region, and adding `len` to it can wrap. The overflow causes mremap() to mistakenly believe that PTEs have been copied; the consequence is that mremap() bails out, but doesn't move the PTEs back before the new VMA is unmapped, causing anonymous pages in the region to be lost. So basically if userspace tries to mremap() a private-anon region and hits this bug, mremap() will return an error and the private-anon region's contents appear to have been zeroed. The idea of this check is that `old_end - len` is the original start address, and writing the check that way also makes it easier to read; so fix the check by rearranging the comparison accordingly. (An alternate fix would be to refactor this function by introducing an "orig_old_start" variable or such.) Tested in a VM with a 32-bit X86 kernel; without the patch: ``` user@horn:~/big_mremap$ cat test.c #define _GNU_SOURCE #include <stdlib.h> #include <stdio.h> #include <err.h> #include <sys/mman.h> #define ADDR1 ((void*)0x60000000) #define ADDR2 ((void*)0x10000000) #define SIZE 0x50000000uL int main(void) { unsigned char *p1 = mmap(ADDR1, SIZE, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p1 == MAP_FAILED) err(1, "mmap 1"); unsigned char *p2 = mmap(ADDR2, SIZE, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p2 == MAP_FAILED) err(1, "mmap 2"); *p1 = 0x41; printf("first char is 0x%02hhx\n", *p1); unsigned char *p3 = mremap(p1, SIZE, SIZE, MREMAP_MAYMOVE|MREMAP_FIXED, p2); if (p3 == MAP_FAILED) { printf("mremap() failed; first char is 0x%02hhx\n", *p1); } else { printf("mremap() succeeded; first char is 0x%02hhx\n", *p3); } } user@horn:~/big_mremap$ gcc -static -o test test.c user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() failed; first char is 0x00 ``` With the patch: ``` user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() succeeded; first char is 0x41 ```
Transient DOS can occur while processing UCI command.
In the Linux kernel, the following vulnerability has been resolved: io_uring: check for overflows in io_pin_pages WARNING: CPU: 0 PID: 5834 at io_uring/memmap.c:144 io_pin_pages+0x149/0x180 io_uring/memmap.c:144 CPU: 0 UID: 0 PID: 5834 Comm: syz-executor825 Not tainted 6.12.0-next-20241118-syzkaller #0 Call Trace: <TASK> __io_uaddr_map+0xfb/0x2d0 io_uring/memmap.c:183 io_rings_map io_uring/io_uring.c:2611 [inline] io_allocate_scq_urings+0x1c0/0x650 io_uring/io_uring.c:3470 io_uring_create+0x5b5/0xc00 io_uring/io_uring.c:3692 io_uring_setup io_uring/io_uring.c:3781 [inline] ... </TASK> io_pin_pages()'s uaddr parameter came directly from the user and can be garbage. Don't just add size to it as it can overflow.
In the Linux kernel, the following vulnerability has been resolved: svcrdma: Address an integer overflow Dan Carpenter reports: > Commit 78147ca8b4a9 ("svcrdma: Add a "parsed chunk list" data > structure") from Jun 22, 2020 (linux-next), leads to the following > Smatch static checker warning: > > net/sunrpc/xprtrdma/svc_rdma_recvfrom.c:498 xdr_check_write_chunk() > warn: potential user controlled sizeof overflow 'segcount * 4 * 4' > > net/sunrpc/xprtrdma/svc_rdma_recvfrom.c > 488 static bool xdr_check_write_chunk(struct svc_rdma_recv_ctxt *rctxt) > 489 { > 490 u32 segcount; > 491 __be32 *p; > 492 > 493 if (xdr_stream_decode_u32(&rctxt->rc_stream, &segcount)) > ^^^^^^^^ > > 494 return false; > 495 > 496 /* A bogus segcount causes this buffer overflow check to fail. */ > 497 p = xdr_inline_decode(&rctxt->rc_stream, > --> 498 segcount * rpcrdma_segment_maxsz * sizeof(*p)); > > > segcount is an untrusted u32. On 32bit systems anything >= SIZE_MAX / 16 will > have an integer overflow and some those values will be accepted by > xdr_inline_decode().
Integer overflow in the vrend_create_shader function in vrend_renderer.c in virglrenderer before 0.6.0 allows local guest OS users to cause a denial of service (process crash) via crafted pkt_length and offlen values, which trigger an out-of-bounds access.
In the Linux kernel, the following vulnerability has been resolved: block: fix integer overflow in BLKSECDISCARD I independently rediscovered commit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 block: fix overflow in blk_ioctl_discard() but for secure erase. Same problem: uint64_t r[2] = {512, 18446744073709551104ULL}; ioctl(fd, BLKSECDISCARD, r); will enter near infinite loop inside blkdev_issue_secure_erase(): a.out: attempt to access beyond end of device loop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048 bio_check_eod: 3286214 callbacks suppressed
The microweber application allows large characters to insert in the input field "fist & last name" which can allow attackers to cause a Denial of Service (DoS) via a crafted HTTP request. in microweber/microweber in GitHub repository microweber/microweber prior to 1.2.12.
MariaDB before 10.6.5 has a sql_lex.cc integer overflow, leading to an application crash.
Integer overflow in the macro ROUND_UP (n, d) in Quick Emulator (Qemu) allows a user to cause a denial of service (Qemu process crash).