AMD System Management Unit (SMU) may experience an integer overflow when an invalid length is provided which may result in a potential loss of resources.
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.
A NULL pointer dereference in AMD Crash Defender could allow an attacker to write a NULL output to a log file potentially resulting in a system crash and loss of availability.
Improper input validation within AMD uprof can allow a local attacker to overwrite MSR registers, potentially resulting in crash or denial of service.
Improper input validation within AMD uprof can allow a local attacker to write to an arbitrary physical address, potentially resulting in crash or denial of service.
Improper input validation within AMD uProf can allow a local attacker to write out of bounds, potentially resulting in a crash or denial of service
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 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 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.
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.
Insufficient checks in System Management Unit (SMU) FeatureConfig may result in reenabling features potentially resulting in denial of resources and/or 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
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 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 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 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 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 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.
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.
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 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 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 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.
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.
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.
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.
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.
AMD Graphics Driver for Windows 10, amdfender.sys may improperly handle input validation on InputBuffer which may result in a denial of service (DoS).
Failure to validate the address and size in TEE (Trusted Execution Environment) may allow a malicious x86 attacker to send malformed messages to the graphics mailbox resulting in an overlap of a TMR (Trusted Memory Region) that was previously allocated by the ASP bootloader leading to a potential loss of integrity.
Improper input validation within the XOCL driver may allow a local attacker to generate an integer overflow condition, potentially resulting in crash or denial of service.
Integer Overflow within atihdwt6.sys can allow a local attacker to cause out of bound read/write potentially leading to loss of confidentiality, integrity and availability
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.
Improper input validation within the XOCL driver may allow a local attacker to generate an integer overflow condition, potentially resulting in loss of confidentiality or availability.
Insufficient parameter sanitization in AMD Secure Processor (ASP) Boot Loader could allow an attacker with access to SPIROM upgrade to overwrite the memory, potentially resulting in arbitrary code execution.
An integer overflow in the SMU could allow a privileged attacker to potentially write memory beyond the end of the reserved dRAM area resulting in loss of 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.
Insufficient parameter validation while allocating process space in the Trusted OS (TOS) may allow for a malicious userspace process to trigger an integer overflow, leading to a potential denial of service.
A compromised Trusted OS (TOS) driver could issue a malformed call that could potentially allow memory access outside the intended range resulting in loss of integrity.
In the Linux kernel, the following vulnerability has been resolved: cpufreq: CPPC: Add u64 casts to avoid overflowing The fields of the _CPC object are unsigned 32-bits values. To avoid overflows while using _CPC's values, add 'u64' casts.
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix a couple integer overflows on 32bit systems On 32bit systems the "off + sizeof(struct NTFS_DE)" addition can have an integer wrapping issue. Fix it by using size_add().
In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix page_size variable overflow Change all variables storing mlx5_umem_mkc_find_best_pgsz() result to unsigned long to support values larger than 31 and avoid overflow. For example: If we try to register 4GB of memory that is contiguous in physical memory, the driver will optimize the page_size and try to use an mkey with 4GB entity size. The 'unsigned int' page_size variable will overflow to '0' and we'll hit the WARN_ON() in alloc_cacheable_mr(). WARNING: CPU: 2 PID: 1203 at drivers/infiniband/hw/mlx5/mr.c:1124 alloc_cacheable_mr+0x22/0x580 [mlx5_ib] Modules linked in: mlx5_ib mlx5_core bonding ip6_gre ip6_tunnel tunnel6 ip_gre gre rdma_rxe rdma_ucm ib_uverbs ib_ipoib ib_umad rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm fuse ib_core [last unloaded: mlx5_core] CPU: 2 UID: 70878 PID: 1203 Comm: rdma_resource_l Tainted: G W 6.14.0-rc4-dirty #43 Tainted: [W]=WARN Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:alloc_cacheable_mr+0x22/0x580 [mlx5_ib] Code: 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 41 52 53 48 83 ec 30 f6 46 28 04 4c 8b 77 08 75 21 <0f> 0b 49 c7 c2 ea ff ff ff 48 8d 65 d0 4c 89 d0 5b 41 5a 41 5c 41 RSP: 0018:ffffc900006ffac8 EFLAGS: 00010246 RAX: 0000000004c0d0d0 RBX: ffff888217a22000 RCX: 0000000000100001 RDX: 00007fb7ac480000 RSI: ffff8882037b1240 RDI: ffff8882046f0600 RBP: ffffc900006ffb28 R08: 0000000000000001 R09: 0000000000000000 R10: 00000000000007e0 R11: ffffea0008011d40 R12: ffff8882037b1240 R13: ffff8882046f0600 R14: ffff888217a22000 R15: ffffc900006ffe00 FS: 00007fb7ed013340(0000) GS:ffff88885fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb7ed1d8000 CR3: 00000001fd8f6006 CR4: 0000000000772eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __warn+0x81/0x130 ? alloc_cacheable_mr+0x22/0x580 [mlx5_ib] ? report_bug+0xfc/0x1e0 ? handle_bug+0x55/0x90 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? alloc_cacheable_mr+0x22/0x580 [mlx5_ib] create_real_mr+0x54/0x150 [mlx5_ib] ib_uverbs_reg_mr+0x17f/0x2a0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xca/0x140 [ib_uverbs] ib_uverbs_run_method+0x6d0/0x780 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x19b/0x360 [ib_uverbs] ? walk_system_ram_range+0x79/0xd0 ? ___pte_offset_map+0x1b/0x110 ? __pte_offset_map_lock+0x80/0x100 ib_uverbs_ioctl+0xac/0x110 [ib_uverbs] __x64_sys_ioctl+0x94/0xb0 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fb7ecf0737b Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 7d 2a 0f 00 f7 d8 64 89 01 48 RSP: 002b:00007ffdbe03ecc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffdbe03edb8 RCX: 00007fb7ecf0737b RDX: 00007ffdbe03eda0 RSI: 00000000c0181b01 RDI: 0000000000000003 RBP: 00007ffdbe03ed80 R08: 00007fb7ecc84010 R09: 00007ffdbe03eed4 R10: 0000000000000009 R11: 0000000000000246 R12: 00007ffdbe03eed4 R13: 000000000000000c R14: 000000000000000c R15: 00007fb7ecc84150 </TASK>
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Prevent integer overflow in hdr_first_de() The "de_off" and "used" variables come from the disk so they both need to check. The problem is that on 32bit systems if they're both greater than UINT_MAX - 16 then the check does work as intended because of an integer overflow.
In the Linux kernel, the following vulnerability has been resolved: udp: Fix multiple wraparounds of sk->sk_rmem_alloc. __udp_enqueue_schedule_skb() has the following condition: if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf) goto drop; sk->sk_rcvbuf is initialised by net.core.rmem_default and later can be configured by SO_RCVBUF, which is limited by net.core.rmem_max, or SO_RCVBUFFORCE. If we set INT_MAX to sk->sk_rcvbuf, the condition is always false as sk->sk_rmem_alloc is also signed int. Then, the size of the incoming skb is added to sk->sk_rmem_alloc unconditionally. This results in integer overflow (possibly multiple times) on sk->sk_rmem_alloc and allows a single socket to have skb up to net.core.udp_mem[1]. For example, if we set a large value to udp_mem[1] and INT_MAX to sk->sk_rcvbuf and flood packets to the socket, we can see multiple overflows: # cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 7956736 <-- (7956736 << 12) bytes > INT_MAX * 15 ^- PAGE_SHIFT # ss -uam State Recv-Q ... UNCONN -1757018048 ... <-- flipping the sign repeatedly skmem:(r2537949248,rb2147483646,t0,tb212992,f1984,w0,o0,bl0,d0) Previously, we had a boundary check for INT_MAX, which was removed by commit 6a1f12dd85a8 ("udp: relax atomic operation on sk->sk_rmem_alloc"). A complete fix would be to revert it and cap the right operand by INT_MAX: rmem = atomic_add_return(size, &sk->sk_rmem_alloc); if (rmem > min(size + (unsigned int)sk->sk_rcvbuf, INT_MAX)) goto uncharge_drop; but we do not want to add the expensive atomic_add_return() back just for the corner case. Casting rmem to unsigned int prevents multiple wraparounds, but we still allow a single wraparound. # cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 524288 <-- (INT_MAX + 1) >> 12 # ss -uam State Recv-Q ... UNCONN -2147482816 ... <-- INT_MAX + 831 bytes skmem:(r2147484480,rb2147483646,t0,tb212992,f3264,w0,o0,bl0,d14468947) So, let's define rmem and rcvbuf as unsigned int and check skb->truesize only when rcvbuf is large enough to lower the overflow possibility. Note that we still have a small chance to see overflow if multiple skbs to the same socket are processed on different core at the same time and each size does not exceed the limit but the total size does. Note also that we must ignore skb->truesize for a small buffer as explained in commit 363dc73acacb ("udp: be less conservative with sock rmem accounting").
In the Linux kernel, the following vulnerability has been resolved: neighbour: allow NUD_NOARP entries to be forced GCed IFF_POINTOPOINT interfaces use NUD_NOARP entries for IPv6. It's possible to fill up the neighbour table with enough entries that it will overflow for valid connections after that. This behaviour is more prevalent after commit 58956317c8de ("neighbor: Improve garbage collection") is applied, as it prevents removal from entries that are not NUD_FAILED, unless they are more than 5s old.