Export limit exceeded: 24290 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (24290 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-16946 | 1 Ibm | 3 Aix, Powervm Vios, Vios | 2026-08-24 | 7.8 High |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a local attacker to gain elevated privileges due to a heap buffer overflow. | ||||
| CVE-2026-16944 | 1 Ibm | 3 Aix, Powervm Vios, Vios | 2026-08-24 | 6.7 Medium |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a local attacker to execute arbitrary code due to a stack-based buffer overflow. | ||||
| CVE-2026-16943 | 1 Ibm | 3 Aix, Powervm Vios, Vios | 2026-08-24 | 8.2 High |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a local attacker to execute arbitrary code due to a heap-based buffer overflow. | ||||
| CVE-2026-16936 | 1 Ibm | 3 Aix, Powervm Vios, Vios | 2026-08-24 | 8.8 High |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a local attacker to execute arbitrary code due to a buffer overflow. | ||||
| CVE-2026-16934 | 1 Ibm | 3 Aix, Powervm Vios, Vios | 2026-08-24 | 8.8 High |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a local attacker to gain elevated privileges due to a heap-based buffer overflow. | ||||
| CVE-2026-56389 | 1 Gnu | 1 Bison | 2026-08-24 | 8.6 High |
| GNU Bison allows for an execution of an arbitrary program during HTML report generation due to improper handling of grammar-defined configuration variables. A grammar file can override the executable used for the XML‑to‑HTML transformation step via %define tool.xsltproc, which is accepted without restriction and passed directly to execvp(). When running bison --html on a attacker-provided grammar, this behavior allows execution of an arbitrary program with the privileges of the Bison process. Maintainers of this project were notified about this vulnerability, and fixed the issue in commit 3169c1e7a2c6acc4c59dfcf8b089896d6881925b. However, they did not provide vulnerable version range. Version 3.8.2 was tested and confirmed as vulnerable, other versions were not tested but might also be vulnerable. | ||||
| CVE-2026-16842 | 1 Ibm | 3 Aix, Powervm Vios, Vios | 2026-08-24 | 8.8 High |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a remote attacker to execute arbitrary commands due to improper neutralization of special elements used in an OS command. | ||||
| CVE-2026-16844 | 1 Ibm | 3 Aix, Powervm Vios, Vios | 2026-08-24 | 8.8 High |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a remote attacker to execute arbitrary commands due to improper neutralization of special elements used in an OS command. | ||||
| CVE-2026-16845 | 1 Ibm | 3 Aix, Powervm Vios, Vios | 2026-08-24 | 9.8 Critical |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a remote attacker to execute arbitrary code due to a heap buffer overflow. | ||||
| CVE-2026-16847 | 1 Ibm | 3 Aix, Powervm Vios, Vios | 2026-08-24 | 8.8 High |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a remote attacker to execute arbitrary code due to a heap buffer overflow. | ||||
| CVE-2026-16848 | 1 Ibm | 3 Aix, Powervm Vios, Vios | 2026-08-24 | 8.8 High |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a remote attacker to execute arbitrary commands due to improper neutralization of shell metacharacters in DHCP options. | ||||
| CVE-2026-16855 | 1 Ibm | 3 Aix, Powervm Vios, Vios | 2026-08-24 | 5.5 Medium |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a local attacker to cause a denial of service due to a heap buffer overflow. | ||||
| CVE-2026-16862 | 1 Ibm | 3 Aix, Powervm Vios, Vios | 2026-08-24 | 9.8 Critical |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a remote attacker to execute arbitrary code due to a stack buffer overflow. | ||||
| CVE-2026-16825 | 1 Ibm | 3 Aix, Powervm Vios, Vios | 2026-08-24 | 4.2 Medium |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a remote authenticated attacker to obtain sensitive information and cause a denial of service due to an out-of-bounds write. | ||||
| CVE-2026-16840 | 1 Ibm | 3 Aix, Powervm Vios, Vios | 2026-08-24 | 9.8 Critical |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a remote attacker to execute arbitrary code due to an out-of-bounds write. | ||||
| CVE-2026-16841 | 1 Ibm | 3 Aix, Powervm Vios, Vios | 2026-08-24 | 8.8 High |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a remote attacker to execute arbitrary code due to a stack buffer overflow. | ||||
| CVE-2026-16864 | 1 Ibm | 3 Aix, Powervm Vios, Vios | 2026-08-24 | 9.8 Critical |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a remote attacker to execute arbitrary code due to a stack buffer overflow. | ||||
| CVE-2026-72252 | 1 Linux | 1 Linux Kernel | 2026-08-23 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: don't leak bad clone into future transaction On memory allocation failure the cloned nft_pipapo_match can enter a bad state: - some fields can have their lookup tables resized while others did not - bits might have been toggled - scratch map can be undersized which also means m->bsize_max can be lower than what is required This means that the next insertion in the same batch can trigger out-of-bounds writes. Furthermore, a failure in the first can result in the bad clone to leak into the next transaction because the abort callback is never executed in this case (the upper layer saw an error and no attempt to allocate a transactional request was made). Record a state for the nft_pipapo_match structure: - NEW (pristine clone) - MOD (modified clone with good state) - ERR (potentially bogus content) Then make it so that deletes and insertions fail when the clone entered ERR state. In case the very first insert attempt results in an error, free the clone right away. | ||||
| CVE-2026-74659 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: bridge: mrp: fix uninitialised bytes on the wire br_mrp_alloc_test_skb() builds MRP test frames on an skb from dev_alloc_skb(), which does not clear the linear data area. On the MRA ring-role branch the sub-option TLV header is appended with sub_tlv = skb_put(skb, sizeof(*sub_tlv)); sub_tlv->type = BR_MRP_SUB_TLV_HEADER_TEST_AUTO_MGR; so sub_tlv->length is never written, and the two trailing alignment bytes are appended with a bare skb_put() that does not clear them either. The neighbouring oui and sub_opt regions are explicitly zeroed, so three uninitialised bytes are left in every MRA MRP_Test frame that goes out. Put the sub-option TLV header and the alignment padding in a single skb_put_zero(), which clears both. The AUTO_MGR sub-TLV carries no payload, so the zeroed length field is already the value it should have. | ||||
| CVE-2026-72427 | 1 Linux | 1 Linux Kernel | 2026-08-22 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Fix effective prog array index with BPF_F_PREORDER replace_effective_prog() and purge_effective_progs() located the slot in the effective array by walking the program hlist and counting entries linearly. That count does not match the array layout: compute_effective_ progs() places BPF_F_PREORDER programs at the front (ancestor cgroup first, attach order within a cgroup) and the rest after them (descendant cgroup first). So when a preorder program is present, the linear hlist position no longer equals the program's index in the effective array. For replace_effective_prog() (bpf_link_update()) this overwrote the wrong slot, corrupting the effective order. For purge_effective_progs(), it could dummy out a slot belonging to a different program and leave the detached program in the array while bpf_prog_put() drops its reference, i.e. a use-after-free. Fix both by replaying compute_effective_progs()'s placement (including the per-cgroup preorder reversal) in a shared effective_prog_pos() helper. Identify the entry by its struct bpf_prog_list pointer rather than by (prog, link) value, so the lookup resolves to exactly the attachment the syscall selected even when the same bpf_prog is attached to several cgroups in the hierarchy. | ||||