Total
2095 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2022-20705 | 1 Cisco | 18 Rv160, Rv160 Firmware, Rv160w and 15 more | 2024-11-21 | 10 Critical |
| Multiple vulnerabilities in Cisco Small Business RV160, RV260, RV340, and RV345 Series Routers could allow an attacker to do any of the following: Execute arbitrary code Elevate privileges Execute arbitrary commands Bypass authentication and authorization protections Fetch and run unsigned software Cause denial of service (DoS) For more information about these vulnerabilities, see the Details section of this advisory. | ||||
| CVE-2022-20704 | 1 Cisco | 18 Rv160, Rv160 Firmware, Rv160w and 15 more | 2024-11-21 | 10 Critical |
| Multiple vulnerabilities in Cisco Small Business RV160, RV260, RV340, and RV345 Series Routers could allow an attacker to do any of the following: Execute arbitrary code Elevate privileges Execute arbitrary commands Bypass authentication and authorization protections Fetch and run unsigned software Cause denial of service (DoS) For more information about these vulnerabilities, see the Details section of this advisory. | ||||
| CVE-2022-20703 | 1 Cisco | 18 Rv160, Rv160 Firmware, Rv160w and 15 more | 2024-11-21 | 10 Critical |
| Multiple vulnerabilities in Cisco Small Business RV160, RV260, RV340, and RV345 Series Routers could allow an attacker to do any of the following: Execute arbitrary code Elevate privileges Execute arbitrary commands Bypass authentication and authorization protections Fetch and run unsigned software Cause denial of service (DoS) For more information about these vulnerabilities, see the Details section of this advisory. | ||||
| CVE-2022-20702 | 1 Cisco | 18 Rv160, Rv160 Firmware, Rv160w and 15 more | 2024-11-21 | 10 Critical |
| Multiple vulnerabilities in Cisco Small Business RV160, RV260, RV340, and RV345 Series Routers could allow an attacker to do any of the following: Execute arbitrary code Elevate privileges Execute arbitrary commands Bypass authentication and authorization protections Fetch and run unsigned software Cause denial of service (DoS) For more information about these vulnerabilities, see the Details section of this advisory. | ||||
| CVE-2022-20701 | 1 Cisco | 8 Rv340, Rv340 Firmware, Rv340w and 5 more | 2024-11-21 | 10 Critical |
| Multiple vulnerabilities in Cisco Small Business RV160, RV260, RV340, and RV345 Series Routers could allow an attacker to do any of the following: Execute arbitrary code Elevate privileges Execute arbitrary commands Bypass authentication and authorization protections Fetch and run unsigned software Cause denial of service (DoS) For more information about these vulnerabilities, see the Details section of this advisory. | ||||
| CVE-2022-20700 | 1 Cisco | 18 Rv160, Rv160 Firmware, Rv160w and 15 more | 2024-11-21 | 10 Critical |
| Multiple vulnerabilities in Cisco Small Business RV160, RV260, RV340, and RV345 Series Routers could allow an attacker to do any of the following: Execute arbitrary code Elevate privileges Execute arbitrary commands Bypass authentication and authorization protections Fetch and run unsigned software Cause denial of service (DoS) For more information about these vulnerabilities, see the Details section of this advisory. | ||||
| CVE-2022-20699 | 1 Cisco | 8 Rv340, Rv340 Firmware, Rv340w and 5 more | 2024-11-21 | 10 Critical |
| Multiple vulnerabilities in Cisco Small Business RV160, RV260, RV340, and RV345 Series Routers could allow an attacker to do any of the following: Execute arbitrary code Elevate privileges Execute arbitrary commands Bypass authentication and authorization protections Fetch and run unsigned software Cause denial of service (DoS) For more information about these vulnerabilities, see the Details section of this advisory. | ||||
| CVE-2022-1888 | 1 Fujielectric | 2 Alpha7 Pc Loader, Alpha7 Pc Loader Firmware | 2024-11-21 | 7.8 High |
| Alpha7 PC Loader (All versions) is vulnerable to a stack-based buffer overflow while processing a specifically crafted project file, which may allow an attacker to execute arbitrary code. | ||||
| CVE-2022-1669 | 1 Circutor | 2 Compact Dc-s Basic, Compact Dc-s Basic Firmware | 2024-11-21 | 6.8 Medium |
| A buffer overflow vulnerability has been detected in the firewall function of the device management web portal. The device runs a CGI binary (index.cgi) to offer a management web application. Once authenticated with valid credentials in this web portal, a potential attacker could submit any "Address" value and it would be copied to a second variable with a "strcpy" vulnerable function without checking its length. Because of this, it is possible to send a long address value to overflow the process stack, controlling the function return address. | ||||
| CVE-2022-1405 | 1 Deltaww | 1 Cncsoft | 2024-11-21 | 7.8 High |
| CNCSoft: All versions prior to 1.01.32 does not properly sanitize input while processing a specific project file, allowing a possible stack-based buffer overflow condition. | ||||
| CVE-2022-1355 | 5 Debian, Fedoraproject, Libtiff and 2 more | 5 Debian Linux, Fedora, Libtiff and 2 more | 2024-11-21 | 6.1 Medium |
| A stack buffer overflow flaw was found in Libtiffs' tiffcp.c in main() function. This flaw allows an attacker to pass a crafted TIFF file to the tiffcp tool, triggering a stack buffer overflow issue, possibly corrupting the memory, and causing a crash that leads to a denial of service. | ||||
| CVE-2022-1211 | 1 Tildearrow | 1 Furnace | 2024-11-21 | 6.3 Medium |
| A vulnerability classified as critical has been found in tildearrow Furnace dev73. This affects the FUR to VGM converter in console mode which causes stack-based overflows and crashes. It is possible to initiate the attack remotely but it requires user-interaction. A POC has been disclosed to the public and may be used. | ||||
| CVE-2022-1068 | 1 Modbustools | 1 Modbus Slave | 2024-11-21 | 5.5 Medium |
| Modbus Tools Modbus Slave (versions 7.4.2 and prior) is vulnerable to a stack-based buffer overflow in the registration field. This may cause the program to crash when a long character string is used. | ||||
| CVE-2022-0650 | 1 Tp-link | 2 Tl-wr940n, Tl-wr940n Firmware | 2024-11-21 | 8.0 High |
| This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of TP-Link TL-WR940N 3.20.1 Build 200316 Rel.34392n (5553) routers. Authentication is required to exploit this vulnerability. The specific flaw exists within the httpd service, which listens on TCP port 80 by default. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a fixed-length stack-based buffer. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-13993. | ||||
| CVE-2022-0629 | 4 Apple, Debian, Fedoraproject and 1 more | 4 Macos, Debian Linux, Fedora and 1 more | 2024-11-21 | 7.8 High |
| Stack-based Buffer Overflow in GitHub repository vim/vim prior to 8.2. | ||||
| CVE-2022-0408 | 3 Debian, Fedoraproject, Vim | 3 Debian Linux, Fedora, Vim | 2024-11-21 | 7.8 High |
| Stack-based Buffer Overflow in GitHub repository vim/vim prior to 8.2. | ||||
| CVE-2022-0194 | 2 Debian, Netatalk | 2 Debian Linux, Netatalk | 2024-11-21 | 9.8 Critical |
| This vulnerability allows remote attackers to execute arbitrary code on affected installations of Netatalk. Authentication is not required to exploit this vulnerability. The specific flaw exists within the ad_addcomment function. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a fixed-length stack-based buffer. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-15876. | ||||
| CVE-2021-47567 | 2024-11-21 | 5.5 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: powerpc/32: Fix hardlockup on vmap stack overflow Since the commit c118c7303ad5 ("powerpc/32: Fix vmap stack - Do not activate MMU before reading task struct") a vmap stack overflow results in a hard lockup. This is because emergency_ctx is still addressed with its virtual address allthough data MMU is not active anymore at that time. Fix it by using a physical address instead. | ||||
| CVE-2021-47465 | 2024-11-21 | 7.1 High | ||
| In the Linux kernel, the following vulnerability has been resolved: KVM: PPC: Book3S HV: Fix stack handling in idle_kvm_start_guest() In commit 10d91611f426 ("powerpc/64s: Reimplement book3s idle code in C") kvm_start_guest() became idle_kvm_start_guest(). The old code allocated a stack frame on the emergency stack, but didn't use the frame to store anything, and also didn't store anything in its caller's frame. idle_kvm_start_guest() on the other hand is written more like a normal C function, it creates a frame on entry, and also stores CR/LR into its callers frame (per the ABI). The problem is that there is no caller frame on the emergency stack. The emergency stack for a given CPU is allocated with: paca_ptrs[i]->emergency_sp = alloc_stack(limit, i) + THREAD_SIZE; So emergency_sp actually points to the first address above the emergency stack allocation for a given CPU, we must not store above it without first decrementing it to create a frame. This is different to the regular kernel stack, paca->kstack, which is initialised to point at an initial frame that is ready to use. idle_kvm_start_guest() stores the backchain, CR and LR all of which write outside the allocation for the emergency stack. It then creates a stack frame and saves the non-volatile registers. Unfortunately the frame it creates is not large enough to fit the non-volatiles, and so the saving of the non-volatile registers also writes outside the emergency stack allocation. The end result is that we corrupt whatever is at 0-24 bytes, and 112-248 bytes above the emergency stack allocation. In practice this has gone unnoticed because the memory immediately above the emergency stack happens to be used for other stack allocations, either another CPUs mc_emergency_sp or an IRQ stack. See the order of calls to irqstack_early_init() and emergency_stack_init(). The low addresses of another stack are the top of that stack, and so are only used if that stack is under extreme pressue, which essentially never happens in practice - and if it did there's a high likelyhood we'd crash due to that stack overflowing. Still, we shouldn't be corrupting someone else's stack, and it is purely luck that we aren't corrupting something else. To fix it we save CR/LR into the caller's frame using the existing r1 on entry, we then create a SWITCH_FRAME_SIZE frame (which has space for pt_regs) on the emergency stack with the backchain pointing to the existing stack, and then finally we switch to the new frame on the emergency stack. | ||||
| CVE-2021-47390 | 2024-11-21 | 5.1 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Fix stack-out-of-bounds memory access from ioapic_write_indirect() KASAN reports the following issue: BUG: KASAN: stack-out-of-bounds in kvm_make_vcpus_request_mask+0x174/0x440 [kvm] Read of size 8 at addr ffffc9001364f638 by task qemu-kvm/4798 CPU: 0 PID: 4798 Comm: qemu-kvm Tainted: G X --------- --- Hardware name: AMD Corporation DAYTONA_X/DAYTONA_X, BIOS RYM0081C 07/13/2020 Call Trace: dump_stack+0xa5/0xe6 print_address_description.constprop.0+0x18/0x130 ? kvm_make_vcpus_request_mask+0x174/0x440 [kvm] __kasan_report.cold+0x7f/0x114 ? kvm_make_vcpus_request_mask+0x174/0x440 [kvm] kasan_report+0x38/0x50 kasan_check_range+0xf5/0x1d0 kvm_make_vcpus_request_mask+0x174/0x440 [kvm] kvm_make_scan_ioapic_request_mask+0x84/0xc0 [kvm] ? kvm_arch_exit+0x110/0x110 [kvm] ? sched_clock+0x5/0x10 ioapic_write_indirect+0x59f/0x9e0 [kvm] ? static_obj+0xc0/0xc0 ? __lock_acquired+0x1d2/0x8c0 ? kvm_ioapic_eoi_inject_work+0x120/0x120 [kvm] The problem appears to be that 'vcpu_bitmap' is allocated as a single long on stack and it should really be KVM_MAX_VCPUS long. We also seem to clear the lower 16 bits of it with bitmap_zero() for no particular reason (my guess would be that 'bitmap' and 'vcpu_bitmap' variables in kvm_bitmap_or_dest_vcpus() caused the confusion: while the later is indeed 16-bit long, the later should accommodate all possible vCPUs). | ||||