| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A heap overflow in the evalcommand() function (shell/ash.c) of Busybox v1.38.0 allows attackers to cause a Denial of Service (DoS) via supplying a crafted input. |
| Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability |
| Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability |
| Win32k Elevation of Privilege Vulnerability |
| Microsoft Streaming Service Elevation of Privilege Vulnerability |
| Windows OLE Remote Code Execution Vulnerability |
| Windows Link Layer Topology Discovery Protocol Remote Code Execution Vulnerability |
| Windows Link Layer Topology Discovery Protocol Remote Code Execution Vulnerability |
| A stack overflow in the evaluate() function (editors/awk.c) of BusyBox commit 371fe9 allows attackers to cause a Denial of Service (DoS) via supplying a crafted AWK script. |
| A vulnerability was found in RobinHerbots Inputmask up to 5.0.9. Affected by this issue is the function extendDefaults/extendDefinitions/extendAliases in the library lib/dependencyLibs/extend.js of the component Internal Deep Merge Helper. The manipulation results in improperly controlled modification of object prototype attributes. The attack may be performed from remote. The project was informed of the problem early through an issue report but has not responded yet. |
| joserfc is a Python library that provides an implementation of several JSON Object Signing and Encryption (JOSE) standards. Prior to 1.6.8, joserfc.jwt.decode accepts attacker-forged HMAC-signed tokens when the caller-supplied verification key is the empty string or None, because HMACAlgorithm.sign and HMACAlgorithm.verify in src/joserfc/_rfc7518/jws_algs.py pass the output of OctKey.get_op_key(...) to hmac.new(...) and OctKey.import_key in src/joserfc/_rfc7518/oct_key.py only emits a SecurityWarning for keys shorter than 14 bytes without rejecting zero-length input. This issue is fixed in version 1.6.8. |
| A security flaw has been discovered in davenardella snap7 up to 1.4.3. The impacted element is the function TSnap7Peer::NegotiatePDULength of the file src/core/s7_peer.cpp. The manipulation of the argument PDULength results in out-of-bounds write. The attack can be executed remotely. The exploit has been released to the public and may be used for attacks. |
| IBM PowerVM Novalink 2.2.02.2.12.2.1.1, and 2.3.02.3.0.12.3.12.3.2 IBM NovaLink APIs misconfiguration may increase attack surface and enable unintended or unauthorized operations under non-default conditions. |
| HAPI FHIR is a complete implementation of the HL7 FHIR standard for healthcare interoperability in Java. Prior to 6.9.9 and 6.9.4.2, all implementations of FHIRPathEngine accept arbitrary FHIRPath expressions and evaluate them without input validation, and the FHIRPath functions matches(), matchesFull(), and replaceMatches() pass user-controlled regular expressions to Java's Pattern.compile() and String.replaceAll() through an incomplete timeout utility. An attacker can send a resource containing an evil regex pattern that causes catastrophic backtracking, exhausting CPU resources and causing denial of service in the FHIR Validator HTTP endpoint and affected org.hl7.fhir.* modules. This issue is fixed in versions 6.9.9 and 6.9.4.2. |
| In the Linux kernel, the following vulnerability has been resolved:
mm: fix __vm_normal_page() to handle missing support for pmd_special()/pud_special()
On x86 32-bit with THP enabled, zap_huge_pmd() is seen to generate a
"WARNING: mm/memory.c:735 at __vm_normal_page+0x6a/0x7d", from the
VM_WARN_ON_ONCE(is_zero_pfn(pfn) || is_huge_zero_pfn(pfn)); followed by
"BUG: Bad rss-counter state"s, then later "BUG: Bad page state"s when
reclaim gets to call shrink_huge_zero_folio_scan().
It's as if the _PAGE_SPECIAL bit never got set in the huge_zero pmd: and
indeed, whereas pte_special() and pte_mkspecial() are subject to a
dedicated CONFIG_ARCH_HAS_PTE_SPECIAL, pmd_special() and pmd_mkspecial()
are subject to CONFIG_ARCH_SUPPORTS_PMD_PFNMAP, which is never enabled on
any 32-bit architecture.
While the problem was exposed through commit d80a9cb1a64a
("mm/huge_memory: add and use normal_or_softleaf_folio_pmd()"), it was an
oversight in commit af38538801c6 ("mm/memory: factor out common code from
vm_normal_page_*()") and would result in other problems:
* huge zero folio accounted in smaps, pagemap (PAGE_IS_FILE) and
numamaps as file-backed THP
* folio_walk_start() returning the folio even without FW_ZEROPAGE set.
Callers seem to tolerate that, though.
... and triggering the VM_WARN_ON_ONE(), although never reported so far.
To fix it, teach vm_normal_page_pmd()/vm_normal_page_pud() to consider
whether pmd_special/pud_special is actually implemented. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: asihpi: Fix potential OOB array access at reading cache
find_control() to retrieve a cached info accesses the array with the
given index blindly, which may lead to an OOB array access.
Add a sanity check for avoiding it. |
| In the Linux kernel, the following vulnerability has been resolved:
net: bcmgenet: keep RBUF EEE/PM disabled
Setting RBUF_EEE_EN | RBUF_PM_EN in RBUF_ENERGY_CTRL breaks the RX
path on GENET hardware once MAC EEE becomes active. RX traffic stops
flowing while the link stays up and the usual descriptor/RX error
counters remain quiet. In that state the MAC still accepts frames
(rbuf_ovflow_cnt keeps climbing) but RBUF no longer forwards them to
DMA, so rx_packets is no longer incremented at the netdev level. On
some boards the corruption ends up as a paging fault in
skb_release_data via bcmgenet_rx_poll on an LPI exit.
Reproduced on Pi 4B (BCM2711 + BCM54213PE) and confirmed by Florian
Fainelli on an internal Broadcom 4908-family board with the same crash
signature. RBUF_PM_EN is not publicly documented.
This shows up more often now that phy_support_eee() enables EEE by
default, but it also affects older kernels as soon as TX LPI is
turned on via ethtool, so it is not specific to recent changes.
Always clear RBUF_EEE_EN | RBUF_PM_EN in bcmgenet_eee_enable_set so
the bits stay off across resets. UMAC and TBUF setup is left alone so
TX-side EEE keeps working. |
| In the Linux kernel, the following vulnerability has been resolved:
net: devmem: reject dma-buf bind with non-page-aligned size or SG length
net_devmem_bind_dmabuf() trusts dmabuf->size and sg_dma_len() to be
PAGE_SIZE multiples without checking:
- tx_vec is sized dmabuf->size / PAGE_SIZE, and
net_devmem_get_niov_at() only bounds-checks virt_addr < dmabuf->size
before indexing tx_vec[virt_addr / PAGE_SIZE]. With size =
N*PAGE_SIZE + r (1 <= r < PAGE_SIZE), sendmsg() at iov_base =
N*PAGE_SIZE passes the bound check and reads tx_vec[N] -- one past.
- owner->area.num_niovs = len / PAGE_SIZE while gen_pool_add_owner()
covers the full byte len, so a non-page-multiple non-final sg
desyncs num_niovs from the gen_pool region for every later sg, on
both RX and TX.
dma-buf does not require page-aligned sizes, so the bind path has to
enforce what its own indexing assumes. Reject both with -EINVAL.
The size check is TX-only (only tx_vec is sized off dmabuf->size); the
SG-length check covers both directions. |
| In the Linux kernel, the following vulnerability has been resolved:
qed: fix double free in qed_cxt_tables_alloc()
If one of the later PF or VF CID bitmap allocations fails,
qed_cid_map_alloc() jumps to cid_map_fail and frees the previously
allocated CID bitmaps before returning an error. qed_cxt_tables_alloc()
then calls qed_cxt_mngr_free(), which invokes qed_cid_map_free()
again.
Fix this by setting each CID bitmap pointer to NULL after bitmap_free()
to avoid double free.
The bug was first flagged by an experimental analysis tool we are
developing for kernel memory-management bugs while analyzing
v6.13-rc1. The tool is still under development and is not yet publicly
available. Manual inspection confirms that the bug is still
present in v7.1-rc3.
Runtime reproduction was not attempted because exercising the failing
allocation path requires device-specific setup. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Validate GPIO pin LUT table size before iterating
[Why&How]
The GPIO pin table parsers in get_gpio_i2c_info() and
bios_parser_get_gpio_pin_info() derive an element count from the VBIOS
table_header.structuresize field, then iterate over gpio_pin[] entries.
However, GET_IMAGE() only validates that the table header itself fits
within the BIOS image. If the VBIOS reports a structuresize larger than
the actual mapped data, the loop reads past the end of the BIOS image,
causing an out-of-bounds read.
Fix this by calling bios_get_image() to validate that the full claimed
structuresize is accessible within the BIOS image before entering the
loop in both functions.
(cherry picked from commit ba5e95b43b773ae1bf1f66ee6b31eb774e65afe3) |
