CVE-2019-12900

Published Jun 19, 2019

Last updated 8 days ago

CVSS critical 9.8

Overview

Description
BZ2_decompress in decompress.c in bzip2 through 1.0.6 has an out-of-bounds write when there are many selectors.
Source
cve@mitre.org
NVD status
Modified
Products
bzip2, debian_linux, leap, ubuntu_linux, freebsd, python

Risk scores

CVSS 3.1

Type
Primary
Base score
9.8
Impact score
5.9
Exploitability score
3.9
Vector string
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Severity
CRITICAL

CVSS 2.0

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

Weaknesses

nvd@nist.gov
CWE-787
134c704f-9b21-4f2e-91b3-4a467353bcc0
CWE-787

Social media

Hype score
Not currently trending

  1. ⚠️Actualizaciones de seguridad para los productos de Juniper ❗CVE-2023-38408 ❗CVE-2024-47538 ❗CVE-2019-12900 ❗CVE-2025-59964 ➡️Más info: https://t.co/rHxl8RhXIn https://t.co/2wT2YyImtU

    @CERTpy

    13 Oct 2025

    113 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

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.