CVE-2005-0988

Published May 2, 2005

Last updated 4 months ago

CVSS info 3.7

Overview

Description
Race condition in gzip 1.2.4, 1.3.3, and earlier, when decompressing a gzipped file, allows local users to modify permissions of arbitrary files via a hard link attack on a file while it is being decompressed, whose permissions are changed by gzip after the decompression is complete.
Source
cve@mitre.org
NVD status
Modified
Products
gzip, freebsd, linux, enterprise_linux, enterprise_linux_desktop, linux_advanced_workstation, secure_linux, turbolinux_appliance_server, turbolinux_desktop, turbolinux_home, turbolinux_server, turbolinux_workstation, ubuntu_linux

Risk scores

CVSS 2.0

Type
Primary
Base score
3.7
Impact score
6.4
Exploitability score
1.9
Vector string
AV:L/AC:H/Au:N/C:P/I:P/A:P

Weaknesses

nvd@nist.gov
NVD-CWE-Other

Social media

Hype score
Not currently trending

Vendor comments

  • Red HatRed Hat Enterprise Linux 5 is not vulnerable to this issue as it contains a backported patch.

Configurations

Related CVEs

  1. When copying knotes from a parent kqueue to a child, the copy code did not correctly exclude marker knotes (used internally to track list traversal position) before marking them as in-flux and releasing the kqueue lock. If another thread freed a marker while the lock was dropped, the subsequent in-flux decrement operated on freed memory. An unprivileged local user may be able to exploit these races to escalate privileges.•CVE-2026-58099
  2. kqueue_fork_copy_knote() indexed into the child's file descriptor table using a knote's file descriptor number without a bounds check. Because the child's table is copied before knotes are transferred, a concurrent thread in the parent could grow the parent's table and register knotes with file descriptor numbers beyond the end of the child's table, causing an out-of-bounds read. An unprivileged local user may be able to exploit these races to escalate privileges.•CVE-2026-58100
  3. When semop(2) blocks waiting for a semaphore condition, it releases the per-set lock and sleeps. Upon waking, it checks the sequence number embedded in the semaphore set's IPC identifier to detect whether the set was removed while the caller was asleep. This sequence number is only 15 bits wide. If enough semaphore sets are created and destroyed in the same table slot while a caller is blocked, the counter wraps around, and semop(2) may falsely conclude that the original set still exists. The subsequent access to a semaphore within the set may then be out of bounds. An unprivileged local user can trigger an out-of-bounds access on kernel heap memory, potentially leading to privilege escalation.•CVE-2026-58098
  4. When an audio channel's buffer needs to be resized, the sound(4) driver checks that the buffer is not memory-mapped and then drops the channel lock to allocate a new buffer. An mmap(2) call on another thread can complete during this window, after which the resize path frees the now-mapped buffer without rechecking. An unprivileged local user with access to a sound device can exploit this race to trigger a use-after-free in the kernel, potentially escalating privileges.•CVE-2026-101308
  5. When the PCM sample array needs to grow, the RACK stack doubles a 16-bit allocation counter. Repeated doublings caused the counter to wrap to zero, resulting in a near-zero-length allocation followed by a copy of the existing samples into the undersized buffer. A remote peer can trigger the expansion by sending a sufficient number of ACKs on an established connection. A remote attacker who can establish a TCP connection to a system using the RACK stack can trigger an out-of-bounds write of approximately 512 KB in the kernel heap possibly resulting in a kernel panic.•CVE-2026-101307

References

Sources include official advisories and independent security research.