Security vulnerabilities and automated fixes for windows issues
7 posts found
A classic buffer overflow vulnerability was discovered in `bld/pbide/dlldbg/dlldbg.c` at line 80, where an unbounded `sprintf()` call wrote a user-influenced `dllName` string into a fixed-size `fmtBuffer` without any length checking. An attacker supplying a maliciously crafted DLL name could overflow the buffer, overwrite adjacent memory, and potentially achieve arbitrary code execution. The fix replaces `sprintf()` with `snprintf()`, passing `sizeof(fmtBuffer)` as an explicit bound to ensure th
A critical integer overflow vulnerability in `include/compat/dirent_msvc.h` allowed an attacker-controlled directory path length to wrap the `sizeof(wchar_t) * n + 16` allocation calculation, resulting in a dangerously undersized heap buffer. Subsequent writes to that buffer caused a heap overflow, enabling potential memory corruption or code execution on Windows systems. The fix adds a pre-allocation bounds check and proper errno signaling to safely reject overflow-inducing inputs.
A critical stack buffer overflow vulnerability was discovered in GDI/Comdlg32.cpp where the `memcpy()` function used a caller-controlled `lStructSize` field without validation, allowing attackers to write beyond stack-allocated buffers. The fix applies a simple `min()` check across four affected dialog functions to ensure copy operations never exceed the destination buffer size.
A high-severity integer overflow vulnerability (CWE-190) was discovered in `libs/clipboard/src/windows/wf_cliprdr.c` at line 774, where the `m_nStreams` value derived from remote clipboard data was passed directly to `calloc()` without bounds validation. A malicious remote peer could supply a crafted stream count near `SIZE_MAX / sizeof(LPSTREAM)`, causing the size calculation to overflow and producing an undersized allocation that subsequent writes would overflow. The fix adds explicit bounds c
A critical buffer overflow vulnerability was discovered and patched in the Windows USB HID host library, where four unsafe `memcpy` calls copied data using device-reported sizes without validating destination buffer capacity. The most dangerous instance could overflow a heap buffer by as little as one byte — enough to corrupt heap metadata and potentially allow arbitrary code execution. This post breaks down how the vulnerability works, why it matters, and how to write safer memory operations in
A critical use-after-free vulnerability was discovered and patched in the multi-threaded ICMP processing path of a Windows/Cygwin network probing library, where freed memory pointers were not nullified, creating a dangerous race condition between concurrent threads. Left unpatched, this flaw could allow attackers to corrupt heap metadata, potentially leading to arbitrary code execution or denial of service. The fix ensures that dangling pointers are eliminated immediately after memory is freed,
A critical vulnerability in Tabby's UAC component allowed local attackers to predict Windows named pipe names generated with a weak pseudo-random number generator, enabling them to hijack privileged communication channels before the elevated process could claim them. This pipe squatting attack could grant unprivileged users the ability to inject commands that execute with Administrator or SYSTEM privileges. The fix removes the unsafe exec() pattern and replaces the predictable pipe naming scheme