Filtered by CWE-121
Total 2081 CVE
CVE Vendors Products Updated CVSS v3.1
CVE-2024-42094 2 Linux, Redhat 2 Linux Kernel, Enterprise Linux 2024-11-21 7.8 High
In the Linux kernel, the following vulnerability has been resolved: net/iucv: Avoid explicit cpumask var allocation on stack For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. Use *cpumask_var API(s) to address it.
CVE-2024-42093 1 Linux 1 Linux Kernel 2024-11-21 7.8 High
In the Linux kernel, the following vulnerability has been resolved: net/dpaa2: Avoid explicit cpumask var allocation on stack For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. Use *cpumask_var API(s) to address it.
CVE-2024-41881 2024-11-21 8.8 High
SDoP versions prior to 1.11 fails to handle appropriately some parameters inside the input data, resulting in a stack-based buffer overflow vulnerability. When a user of the affected product is tricked to process a specially crafted XML file, arbitrary code may be executed on the user's environment.
CVE-2024-41492 1 Tenda 1 Ax1806 Firmware 2024-11-21 7.5 High
A stack overflow in Tenda AX1806 v1.0.0.1 allows attackers to cause a Denial of Service (DoS) via a crafted input.
CVE-2024-41466 2 Tenda, Tendacn 3 Fh1201 Firmware, Fh1201, Fh1201 Firmware 2024-11-21 7.5 High
Tenda FH1201 v1.2.0.14 was discovered to contain a stack-based buffer overflow vulnerability via the page parameter at ip/goform/NatStaticSetting.
CVE-2024-41465 2 Tenda, Tendacn 3 Fh1201 Firmware, Fh1201, Fh1201 Firmware 2024-11-21 7.5 High
Tenda FH1201 v1.2.0.14 was discovered to contain a stack-based buffer overflow vulnerability via the funcpara1 parameter at ip/goform/setcfm.
CVE-2024-41463 2 Tenda, Tendacn 3 Fh1201 Firmware, Fh1201, Fh1201 Firmware 2024-11-21 4.3 Medium
Tenda FH1201 v1.2.0.14 was discovered to contain a stack-based buffer overflow vulnerability via the entrys parameter at ip/goform/addressNat.
CVE-2024-41462 2 Tenda, Tendacn 3 Fh1201 Firmware, Fh1201, Fh1201 Firmware 2024-11-21 4.3 Medium
Tenda FH1201 v1.2.0.14 was discovered to contain a stack-based buffer overflow vulnerability via the page parameter at ip/goform/DhcpListClient.
CVE-2024-41460 2 Tenda, Tendacn 3 Fh1201 Firmware, Fh1201, Fh1201 Firmware 2024-11-21 6.5 Medium
Tenda FH1201 v1.2.0.14 was discovered to contain a stack-based buffer overflow vulnerability via the entrys parameter at ip/goform/RouteStatic.
CVE-2024-41459 2 Tenda, Tendacn 3 Fh1201 Firmware, Fh1201, Fh1201 Firmware 2024-11-21 8.8 High
Tenda FH1201 v1.2.0.14 was discovered to contain a stack-based buffer overflow vulnerability via the PPPOEPassword parameter at ip/goform/QuickIndex.
CVE-2024-41281 1 Linksys 1 Wrt54g 2024-11-21 8.8 High
Linksys WRT54G v4.21.5 has a stack overflow vulnerability in get_merge_mac function.
CVE-2024-41042 1 Redhat 1 Enterprise Linux 2024-11-21 4.1 Medium
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prefer nft_chain_validate nft_chain_validate already performs loop detection because a cycle will result in a call stack overflow (ctx->level >= NFT_JUMP_STACK_SIZE). It also follows maps via ->validate callback in nft_lookup, so there appears no reason to iterate the maps again. nf_tables_check_loops() and all its helper functions can be removed. This improves ruleset load time significantly, from 23s down to 12s. This also fixes a crash bug. Old loop detection code can result in unbounded recursion: BUG: TASK stack guard page was hit at .... Oops: stack guard page: 0000 [#1] PREEMPT SMP KASAN CPU: 4 PID: 1539 Comm: nft Not tainted 6.10.0-rc5+ #1 [..] with a suitable ruleset during validation of register stores. I can't see any actual reason to attempt to check for this from nft_validate_register_store(), at this point the transaction is still in progress, so we don't have a full picture of the rule graph. For nf-next it might make sense to either remove it or make this depend on table->validate_state in case we could catch an error earlier (for improved error reporting to userspace).
CVE-2024-41009 2 Linux, Redhat 5 Linux Kernel, Enterprise Linux, Rhel Aus and 2 more 2024-11-21 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that "owns" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter.
CVE-2024-40902 1 Linux 1 Linux Kernel 2024-11-21 7.8 High
In the Linux kernel, the following vulnerability has been resolved: jfs: xattr: fix buffer overflow for invalid xattr When an xattr size is not what is expected, it is printed out to the kernel log in hex format as a form of debugging. But when that xattr size is bigger than the expected size, printing it out can cause an access off the end of the buffer. Fix this all up by properly restricting the size of the debug hex dump in the kernel log.
CVE-2024-40897 2 Gstreamer, Redhat 6 Orc, Enterprise Linux, Rhel Aus and 3 more 2024-11-21 6.7 Medium
Stack-based buffer overflow vulnerability exists in orcparse.c of ORC versions prior to 0.4.39. If a developer is tricked to process a specially crafted file with the affected ORC compiler, an arbitrary code may be executed on the developer's build environment. This may lead to compromise of developer machines or CI build environments.
CVE-2024-40535 2024-11-21 9.8 Critical
Shenzhen Libituo Technology Co., Ltd LBT-T300-T400 v3.2 was discovered to contain a stack overflow via the apn_name_3g parameter in the config_3g_para function.
CVE-2024-40417 1 Tenda 1 Ax1806 Firmware 2024-11-21 6.5 Medium
A vulnerability was found in Tenda AX1806 1.0.0.1. Affected by this issue is the function formSetRebootTimer of the file /goform/SetIpMacBind. The manipulation of the argument list leads to stack-based buffer overflow.
CVE-2024-40416 1 Tenda 2 Ax1806, Ax1806 Firmware 2024-11-21 6.5 Medium
A vulnerability in /goform/SetVirtualServerCfg in the sub_6320C function in Tenda AX1806 1.0.0.1 firmware leads to stack-based buffer overflow.
CVE-2024-40414 1 Tenda 2 Ax1806, Ax1806 Firmware 2024-11-21 9.6 Critical
A vulnerability in /goform/SetNetControlList in the sub_656BC function in Tenda AX1806 1.0.0.1 firmware leads to stack-based buffer overflow.
CVE-2024-40412 1 Tenda 2 Ax12, Ax12 Firmware 2024-11-21 6.8 Medium
Tenda AX12 v1.0 v22.03.01.46 contains a stack overflow in the deviceList parameter of the sub_42E410 function.