Vulnerability-Lookup

GHSA-27F9-CGJJ-WVCV

Vulnerability from github – Published: 2026-09-02 18:32 – Updated: 2026-09-02 18:32

Details

A vulnerability exists in NGINX JavaScript where a malformed HTTP response received by ngx.fetch() can crash an NGINX worker when trusted JavaScript reads Response.statusText. Exploitation requires control or influence over the fetched HTTP response.

Impact: This vulnerability may allow remote attackers to cause a denial-of-service (DoS) on the NGINX system. There is no control plane exposure; this is a data plane issue only.

Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

8.7 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-78222"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-02T16:17:23Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability exists in NGINX JavaScript where a malformed HTTP response received by ngx.fetch() can crash an NGINX worker when trusted JavaScript reads Response.statusText. Exploitation requires control or influence over the fetched HTTP response.\n\nImpact:\nThis vulnerability may allow remote attackers to cause a denial-of-service (DoS) on the NGINX system. There is no control plane exposure; this is a data plane issue only.\n\n\n\n\nNote: Software versions which have reached End of Technical Support (EoTS) are not evaluated.",
  "id": "GHSA-27f9-cgjj-wvcv",
  "modified": "2026-09-02T18:32:11Z",
  "published": "2026-09-02T18:32:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-78222"
    },
    {
      "type": "WEB",
      "url": "https://my.f5.com/manage/s/article/K000162603"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-27FW-6HP8-FGWW

Vulnerability from github – Published: 2022-05-17 00:27 – Updated: 2022-05-17 00:27

Details

The av_color_primaries_name function in libavutil/pixdesc.c in FFmpeg 3.3.3 may return a NULL pointer depending on a value contained in a file, but callers do not anticipate this, as demonstrated by the avcodec_string function in libavcodec/utils.c, leading to a NULL pointer dereference. (It is also conceivable that there is security relevance for a NULL pointer dereference in av_color_primaries_name calls within the ffprobe command-line program.)

Severity

8.8 (High)


                  
                    CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2017-14225"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-09-09T08:29:00Z",
    "severity": "HIGH"
  },
  "details": "The av_color_primaries_name function in libavutil/pixdesc.c in FFmpeg 3.3.3 may return a NULL pointer depending on a value contained in a file, but callers do not anticipate this, as demonstrated by the avcodec_string function in libavcodec/utils.c, leading to a NULL pointer dereference. (It is also conceivable that there is security relevance for a NULL pointer dereference in av_color_primaries_name calls within the ffprobe command-line program.)",
  "id": "GHSA-27fw-6hp8-fgww",
  "modified": "2022-05-17T00:27:12Z",
  "published": "2022-05-17T00:27:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-14225"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FFmpeg/FFmpeg/commit/837cb4325b712ff1aab531bf41668933f61d75d2"
    },
    {
      "type": "WEB",
      "url": "https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-August/215198.html"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2017/dsa-3996"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/100704"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-27H4-M228-RWM7

Vulnerability from github – Published: 2022-05-24 19:01 – Updated: 2022-05-24 19:01

Details

Improper validation of the ChassisID TLV in userdisk/vport_lldpd in Moxa Camera VPort 06EC-2V Series, version 1.1, allows attackers to cause a denial of service due to a NULL pointer dereference via a crafted lldp packet.

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2021-25845"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-05-10T11:15:00Z",
    "severity": "HIGH"
  },
  "details": "Improper validation of the ChassisID TLV in userdisk/vport_lldpd in Moxa Camera VPort 06EC-2V Series, version 1.1, allows attackers to cause a denial of service due to a NULL pointer dereference via a crafted lldp packet.",
  "id": "GHSA-27h4-m228-rwm7",
  "modified": "2022-05-24T19:01:56Z",
  "published": "2022-05-24T19:01:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25845"
    },
    {
      "type": "WEB",
      "url": "https://www.moxa.com/en"
    },
    {
      "type": "WEB",
      "url": "https://www.moxa.com/en/support/product-support/security-advisory/vport-06ec-2v-series-ip-cameras-vulnerabilities"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-27H8-GF7J-V5HC

Vulnerability from github – Published: 2026-10-21 20:32 – Updated: 2026-10-21 20:32

Summary

Pillow: NULL dereference in ImagingExpand via rank filters on zero-size images

Details

============================================================================
NULL dereference in ImagingExpand via rank filters on zero-size images
Location: src/libImaging/Filter.c:79  in ImagingExpand()
Commit:   a707c6b21c313880d0771e54965d142dd42358b6
============================================================================

Applying Pillow's median, minimum, maximum or rank filter to an image with zero width or zero height crashes the whole Python process instead of raising an error. Empty images like this are easy to produce with ordinary calls, for example a crop box whose left and right edges (or top and bottom edges) are equal, or the second page of a crafted multi-page image file. An attacker who can supply crop coordinates or an uploaded file to an application that runs one of these filters can kill its worker process. The effect is a crash only, with no memory disclosure or corruption.

The fault is in ImagingExpand() in src/libImaging/Filter.c. This is the edge-padding step that RankFilter.filter() always runs through the core expand() method, so MedianFilter, MinFilter and MaxFilter go through it too. It fills the margin by copying the input's edge pixels, reading imIn->image[y][0] and rows 0 / ysize-1, and never checks that the input has any pixels. For an empty image, ImagingAllocateArray leaves the line pointers NULL, so the first read dereferences NULL and the process dies with SIGSEGV, in every mode.

Zero-size images reach this point through public API alone:

Image.crop(), ImageOps.crop() and Image.new();
a multi-page TIFF opened by path whose second IFD declares ImageLength = 0, on which seek(1) and load() succeed.

Every other ImageFilter returns an empty image for the same inputs. The zero-height case has crashed since the original PIL import, and the zero-width case since Pillow 4.3.0. This is separate from the margin == 0 fix in #9755: the path is the same, but here the degenerate value is the image size rather than the kernel size. It has the same shape as the zero-dimension ImagingOffset crash fixed under GHSA-f87v-9578-p47w.

The attached reproducer shows a one-pixel-wide control crop filtering normally, while four empty crops passed through the rank filters are each killed by SIGSEGV. A patch that returns early in ImagingExpand for empty input is included.

Details

ImagingExpand() (src/libImaging/Filter.c), the edge-padding helper that ImageFilter.RankFilter runs before the actual rank filter, reads the first pixel of each input line without checking that the input has any pixels. For an image with width 0 or height 0 the line pointers are NULL, so Image.filter() with MedianFilter, MinFilter, MaxFilter or RankFilter kills the interpreter with SIGSEGV instead of returning or raising:

from PIL import Image, ImageFilter
im = Image.new("L", (10, 10)).crop((3, 0, 3, 10))   # size (0, 10); crop() accepts left == right
im.filter(ImageFilter.MedianFilter(3))               # SIGSEGV

Under gdb on the stock build the fault is at ImagingExpand (imIn=…, margin=1) at src/libImaging/Filter.c:105 (the EXPAND(UINT8, image8) expansion), called from _expand_image at src/_imaging.c:1151, with imIn->xsize = 0 and imIn->image[0] = 0x0. The same happens for every mode the rank filters accept (L, RGB, RGBA, I, F), and the core expand(m) method with m >= 1 crashes the same way in any mode, including P. The same input through BoxBlur, GaussianBlur, Kernel, ModeFilter and UnsharpMask returns a (0, 10) image; a (1, 10) crop through MedianFilter also returns normally.

The unchecked edge reads date from the PIL import (9a640e315, 2010, so every Pillow release): the zero-height case has crashed since then, and the zero-width case since fd907fbdc ("Fix 0-width and 0-height images other way", Pillow 4.3.0), which stopped backing zero-width images with a dummy block and left their row pointers NULL. It is adjacent to the margin == 0 divide-by-zero fix in #9755 — same expand() → ImagingExpand() path, but the unhandled degenerate value here is the image size rather than the kernel size.

The path:

# src/PIL/ImageFilter.py:111-116   RankFilter.filter  (MedianFilter/MinFilter/MaxFilter subclass it)
        image = image.expand(self.size // 2)
        return image.rankfilter(self.size, self.rank)

expand(m) with m > 0 is ImagingExpand(self->image, m) (src/_imaging.c:1142-1151). It validates only margin, allocates an output of (xsize+2*margin) × (ysize+2*margin) — which is non-empty, so the allocation succeeds — and then fills the margin by replicating edge pixels of the input:

// src/libImaging/Filter.c:70-101
    imOut =
        ImagingNewDirty(imIn->mode, imIn->xsize + 2 * margin, imIn->ysize + 2 * margin);
    …
#define EXPAND_LINE(type, image, yin, yout)                       \
    {                                                             \
        for (x = 0; x < margin; x++) {                            \
            imOut->image[yout][x] = imIn->image[yin][0];          \   // line 79
        }                                                         \
        …                                                         \
        for (x = 0; x < margin; x++) {                            \
            imOut->image[yout][margin + imIn->xsize + x] =        \
                imIn->image[yin][imIn->xsize - 1];                \   // [-1] when xsize == 0
        }                                                         \
    }

#define EXPAND(type, image)                                                      \
    {                                                                            \
        for (y = 0; y < margin; y++) {                                           \
            EXPAND_LINE(type, image, 0, y);                                      \   // line 0 of a 0-line image
        }                                                                        \
        …
        for (y = 0; y < margin; y++) {                                           \
            EXPAND_LINE(type, image, imIn->ysize - 1, margin + imIn->ysize + y); \   // line -1 when ysize == 0
        }                                                                        \
    }

Why the line pointers are NULL: ImagingNewPrologueSubtype callocs the im->image pointer array (src/libImaging/Storage.c:216, at least one entry), and ImagingAllocateArray returns before assigning any of them for an empty image:

// src/libImaging/Storage.c:423-426
    /* 0-width or 0-height image. No need to do anything */
    if (!im->linesize || !im->ysize) {
        return im;
    }

So with xsize == 0 every imIn->image[y] is NULL and imIn->image[yin][0] faults; with ysize == 0 the top-margin pass reads imIn->image[0] (the single calloc'd NULL slot) and faults the same way, and the bottom-margin pass would index imIn->image[-1]. ImagingRankFilter is never reached.

Zero-size images are ordinary objects in Pillow and arrive at filter() through public API only:

Image.crop(box) rejects only inverted boxes (src/PIL/Image.py:1385-1390); left == right or upper == lower yields a 0×N / N×0 image. ImageOps.crop(im, border) with border == width // 2, and Image.new(mode, (0, n)), do the same.
From a file: ImageFile.__init__ refuses a zero first-frame size (src/PIL/ImageFile.py:167-173), but TiffImagePlugin._setup() takes ImageWidth/ImageLength of every later IFD as-is on seek() (src/PIL/TiffImagePlugin.py:1468-1481). For an uncompressed page of an image opened by path, ImageFile.load() takes the mmap branch (src/PIL/ImageFile.py:307, 325-347) and Image.core.map_buffer builds an 8×0 core image without complaint (src/map.c:127-141), so im.seek(1); im.load() succeeds and a following im.filter(ImageFilter.MedianFilter(3)) segfaults in ImagingExpand exactly as above (verified under gdb: imIn->ysize = 0, imIn->image[0] = 0x0). A 384-byte two-page TIFF is enough.

Impact

Denial of service: the whole embedding process (web worker, pipeline process) dies with SIGSEGV rather than the request failing with a Python exception. It is reachable by a remote user in two realistic shapes: (a) an application that crops an upload to user-supplied coordinates and then applies a median/min/max filter (denoise, dilate/erode, thumbnail clean-up) — a box with x0 == x1 or y0 == y1 passes crop() and crashes the worker; (b) an application that opens an uploaded TIFF from disk by path, iterates its pages and applies a rank filter to each — a crafted second IFD with ImageLength = 0 crashes it. The faulting access is a read at address 0 (or a fixed small negative offset from the pointer array for the [-1] cases, which is not reached because the first read already faults), so there is no memory disclosure or corruption beyond the crash. The same shape, a zero-dimension image crashing C code reached through public API, was fixed in ImagingOffset in 39d14a0db (GHSA-f87v-9578-p47w).

Reproducing

repro is a single Python script that uses the installed Pillow as-is (no rebuild). It runs each case in a fresh child interpreter, with core dumps disabled. That way a segfault shows up as the child's exit status and the script itself keeps running. Each child builds Image.new("L", (10, 10)).crop(box), prints its size, calls im.filter(...) and then prints the size of the result.

Control: a (1, 10) crop ((3, 0, 4, 10)) through MedianFilter(3). The rank filter accepts a thin image and must return normally.
PoC: the rank filters on empty crops.
A (0, 10) crop (left == right, (3, 0, 3, 10)) through MedianFilter(3) and MaxFilter(5).
A (10, 0) crop (upper == lower, (0, 3, 10, 3)) through MinFilter(3).
A (0, 0) crop ((3, 3, 3, 3)) through RankFilter(3, 4).

Expected output on the stock build:

  crop(3, 0, 4, 10)    MedianFilter(3)    (1, 10) -> (1, 10)
  crop(3, 0, 3, 10)    MedianFilter(3)    (0, 10) -> killed by SIGSEGV
  crop(3, 0, 3, 10)    MaxFilter(5)       (0, 10) -> killed by SIGSEGV
  crop(0, 3, 10, 3)    MinFilter(3)       (10, 0) -> killed by SIGSEGV
  crop(3, 3, 3, 3)     RankFilter(3, 4)   (0, 0) -> killed by SIGSEGV
BUG

The size printed before -> shows that the empty image was created without error. The crash happens inside filter(), in ImagingExpand. The last line is BUG if the control returned normally and at least one rank-filter child was killed by SIGSEGV. Otherwise it is OK. The script covers the crop route only; the TIFF route described above fails the same way (im.seek(1); im.load(); im.filter(ImageFilter.MedianFilter(3)) on a by-path two-page TIFF whose second IFD has ImageLength = 0). With the attached patch, every PoC line prints the unchanged size (for example (0, 10) -> (0, 10)) and the script prints OK.

Suggested fix

The attached patch handles the empty input in ImagingExpand (src/libImaging/Filter.c), right after the margin checks and before the ImagingNewDirty allocation and the replication loops. With xsize == 0 or ysize == 0 there are no edge pixels to replicate, so it returns a zeroed (ImagingNew, not ImagingNewDirty) image of the expanded size, with the input's palette copied. This keeps ImagingExpand's size contract, so ImagingRankFilter then produces an output of xsize - 2*margin × ysize - 2*margin, i.e. the original empty size, matching every other filter. It mirrors the existing zero-dimension early returns in src/libImaging/BoxBlur.c (127004368) and src/libImaging/Offset.c (39d14a0db):

--- a/src/libImaging/Filter.c
+++ b/src/libImaging/Filter.c
@@ -67,6 +67,17 @@ ImagingExpand(Imaging imIn, int margin) {
         return (Imaging)ImagingError_ValueError("filter size too large");
     }

+    if (imIn->xsize == 0 || imIn->ysize == 0) {
+        /* No edge pixels to replicate (and no lines to read from), so
+           return a zeroed image of the expanded size */
+        imOut = ImagingNew(imIn->mode, imIn->xsize + 2 * margin, imIn->ysize + 2 * margin);
+        if (!imOut) {
+            return NULL;
+        }
+        ImagingCopyPalette(imOut, imIn);
+        return imOut;
+    }
+
     imOut =
         ImagingNewDirty(imIn->mode, imIn->xsize + 2 * margin, imIn->ysize + 2 * margin);
     if (!imOut) {

The patch also adds test_rankfilter_zero_dimension next to test_rankfilter_error in Tests/test_image_filter.py, which filters Image.new("L", size) for size in ((0, 6), (6, 0), (0, 0)) with MinFilter, MedianFilter, MaxFilter and RankFilter(3, 2) and asserts the size is preserved. Applied to a clean checkout and rebuilt, the reproducer prints OK and Tests/test_image_filter.py passes. A Python-level guard in RankFilter.filter (if 0 in image.size: return image.copy()) would also stop the crash, but the C-level check protects any other caller of expand().

The patch

Return a zeroed image from ImagingExpand when the input has zero width or height instead of reading NULL line pointers

Applies to src/libImaging/Filter.c at the commit above.

diff --git a/Tests/test_image_filter.py b/Tests/test_image_filter.py
index 974d4b7a3..8dc8e1a1a 100644
--- a/Tests/test_image_filter.py
+++ b/Tests/test_image_filter.py
@@ -155,6 +155,23 @@ def test_rankfilter_error(filter: ImageFilter.RankFilter) -> None:
         im.filter(filter).getpixel((1, 1))


+@pytest.mark.parametrize(
+    "filter",
+    (
+        ImageFilter.MinFilter,
+        ImageFilter.MedianFilter,
+        ImageFilter.MaxFilter,
+        ImageFilter.RankFilter(3, 2),
+    ),
+)
+@pytest.mark.parametrize("size", ((0, 6), (6, 0), (0, 0)))
+def test_rankfilter_zero_dimension(
+    filter: ImageFilter.RankFilter, size: tuple[int, int]
+) -> None:
+    im = Image.new("L", size)
+    assert im.filter(filter).size == size
+
+
 def test_rankfilter_properties() -> None:
     rankfilter = ImageFilter.RankFilter(3, 2)

diff --git a/src/libImaging/Filter.c b/src/libImaging/Filter.c
index 3492a871f..d702db5f9 100644
--- a/src/libImaging/Filter.c
+++ b/src/libImaging/Filter.c
@@ -67,6 +67,17 @@ ImagingExpand(Imaging imIn, int margin) {
         return (Imaging)ImagingError_ValueError("filter size too large");
     }

+    if (imIn->xsize == 0 || imIn->ysize == 0) {
+        /* No edge pixels to replicate (and no lines to read from), so
+           return a zeroed image of the expanded size */
+        imOut = ImagingNew(imIn->mode, imIn->xsize + 2 * margin, imIn->ysize + 2 * margin);
+        if (!imOut) {
+            return NULL;
+        }
+        ImagingCopyPalette(imOut, imIn);
+        return imOut;
+    }
+
     imOut =
         ImagingNewDirty(imIn->mode, imIn->xsize + 2 * margin, imIn->ysize + 2 * margin);
     if (!imOut) {

The reproducer

Reproducer — repro, 1,333 bytes (click to open) Its last line is `BUG` when the issue triggers and `OK` when it does not. Re-run on a clean build of that commit it printed `BUG`.

#!/usr/bin/env python3
# Pillow: rank filters (Median/Min/Max/RankFilter) on a 0-wide or 0-high image
# SIGSEGV in ImagingExpand (src/libImaging/Filter.c) - NULL line pointer read.
# Each case runs in a child interpreter; BUG if the control returns and any
# zero-size case dies of SIGSEGV.
import signal, subprocess, sys

CHILD = """
import resource; resource.setrlimit(resource.RLIMIT_CORE, (0, 0))
from PIL import Image, ImageFilter
im = Image.new("L", (10, 10)).crop(%s)      # public API; crop accepts x0==x1 / y0==y1
print(im.size, "->", end=" ", flush=True)
print(im.filter(ImageFilter.%s).size)
"""

def run(box, flt):
    p = subprocess.run([sys.executable, "-c", CHILD % (box, flt)],
                       capture_output=True, text=True)
    out = p.stdout.strip()
    if p.returncode < 0:
        out += " killed by " + signal.Signals(-p.returncode).name
    print(f"  crop{box!s:<16} {flt:<18} {out}")
    return p.returncode

ctrl = run((3, 0, 4, 10), "MedianFilter(3)")          # (1,10): must work
rcs = [run((3, 0, 3, 10), "MedianFilter(3)"),        # (0,10)
       run((3, 0, 3, 10), "MaxFilter(5)"),
       run((0, 3, 10, 3), "MinFilter(3)"),           # (10,0)
       run((3, 3, 3, 3), "RankFilter(3, 4)")]        # (0,0)
bug = ctrl == 0 and any(rc == -signal.SIGSEGV for rc in rcs)
print("BUG" if bug else "OK")

Severity

8.2 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 12.3.0"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "Pillow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "13.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-112392"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-21T20:32:37Z",
    "nvd_published_at": "2026-10-19T22:17:06Z",
    "severity": "HIGH"
  },
  "details": "```\n============================================================================\nNULL dereference in ImagingExpand via rank filters on zero-size images\nLocation: src/libImaging/Filter.c:79  in ImagingExpand()\nCommit:   a707c6b21c313880d0771e54965d142dd42358b6\n============================================================================\n```\n\nApplying Pillow\u0027s median, minimum, maximum or rank filter to an image with zero width or zero height crashes the whole Python process instead of raising an error. Empty images like this are easy to produce with ordinary calls, for example a crop box whose left and right edges (or top and bottom edges) are equal, or the second page of a crafted multi-page image file. An attacker who can supply crop coordinates or an uploaded file to an application that runs one of these filters can kill its worker process. The effect is a crash only, with no memory disclosure or corruption.\n\nThe fault is in `ImagingExpand()` in `src/libImaging/Filter.c`. This is the edge-padding step that `RankFilter.filter()` always runs through the core `expand()` method, so `MedianFilter`, `MinFilter` and `MaxFilter` go through it too. It fills the margin by copying the input\u0027s edge pixels, reading `imIn-\u003eimage[y][0]` and rows `0` / `ysize-1`, and never checks that the input has any pixels. For an empty image, `ImagingAllocateArray` leaves the line pointers NULL, so the first read dereferences NULL and the process dies with SIGSEGV, in every mode.\n\nZero-size images reach this point through public API alone:\n\n- `Image.crop()`, `ImageOps.crop()` and `Image.new()`;\n- a multi-page TIFF opened by path whose second IFD declares `ImageLength = 0`, on which `seek(1)` and `load()` succeed.\n\nEvery other `ImageFilter` returns an empty image for the same inputs. The zero-height case has crashed since the original PIL import, and the zero-width case since Pillow 4.3.0. This is separate from the `margin == 0` fix in #9755: the path is the same, but here the degenerate value is the image size rather than the kernel size. It has the same shape as the zero-dimension `ImagingOffset` crash fixed under GHSA-f87v-9578-p47w.\n\nThe attached reproducer shows a one-pixel-wide control crop filtering normally, while four empty crops passed through the rank filters are each killed by SIGSEGV. A patch that returns early in `ImagingExpand` for empty input is included.\n\n## Details\n\n`ImagingExpand()` (`src/libImaging/Filter.c`), the edge-padding helper that `ImageFilter.RankFilter` runs before the actual rank filter, reads the first pixel of each input line without checking that the input has any pixels. For an image with width 0 or height 0 the line pointers are NULL, so `Image.filter()` with `MedianFilter`, `MinFilter`, `MaxFilter` or `RankFilter` kills the interpreter with SIGSEGV instead of returning or raising:\n\n```python\nfrom PIL import Image, ImageFilter\nim = Image.new(\"L\", (10, 10)).crop((3, 0, 3, 10))   # size (0, 10); crop() accepts left == right\nim.filter(ImageFilter.MedianFilter(3))               # SIGSEGV\n```\n\nUnder gdb on the stock build the fault is at `ImagingExpand (imIn=\u2026, margin=1) at src/libImaging/Filter.c:105` (the `EXPAND(UINT8, image8)` expansion), called from `_expand_image` at `src/_imaging.c:1151`, with `imIn-\u003exsize = 0` and `imIn-\u003eimage[0] = 0x0`. The same happens for every mode the rank filters accept (`L`, `RGB`, `RGBA`, `I`, `F`), and the core `expand(m)` method with `m \u003e= 1` crashes the same way in any mode, including `P`. The same input through `BoxBlur`, `GaussianBlur`, `Kernel`, `ModeFilter` and `UnsharpMask` returns a `(0, 10)` image; a `(1, 10)` crop through `MedianFilter` also returns normally.\n\nThe unchecked edge reads date from the PIL import (`9a640e315`, 2010, so every Pillow release): the zero-height case has crashed since then, and the zero-width case since `fd907fbdc` (\"Fix 0-width and 0-height images other way\", Pillow 4.3.0), which stopped backing zero-width images with a dummy block and left their row pointers NULL. It is adjacent to the `margin == 0` divide-by-zero fix in #9755 \u2014 same `expand()` \u2192 `ImagingExpand()` path, but the unhandled degenerate value here is the image size rather than the kernel size.\n\nThe path:\n\n```python\n# src/PIL/ImageFilter.py:111-116   RankFilter.filter  (MedianFilter/MinFilter/MaxFilter subclass it)\n        image = image.expand(self.size // 2)\n        return image.rankfilter(self.size, self.rank)\n```\n\n`expand(m)` with `m \u003e 0` is `ImagingExpand(self-\u003eimage, m)` (`src/_imaging.c:1142-1151`). It validates only `margin`, allocates an output of `(xsize+2*margin) \u00d7 (ysize+2*margin)` \u2014 which is non-empty, so the allocation succeeds \u2014 and then fills the margin by replicating edge pixels of the input:\n\n```c\n// src/libImaging/Filter.c:70-101\n    imOut =\n        ImagingNewDirty(imIn-\u003emode, imIn-\u003exsize + 2 * margin, imIn-\u003eysize + 2 * margin);\n    \u2026\n#define EXPAND_LINE(type, image, yin, yout)                       \\\n    {                                                             \\\n        for (x = 0; x \u003c margin; x++) {                            \\\n            imOut-\u003eimage[yout][x] = imIn-\u003eimage[yin][0];          \\   // line 79\n        }                                                         \\\n        \u2026                                                         \\\n        for (x = 0; x \u003c margin; x++) {                            \\\n            imOut-\u003eimage[yout][margin + imIn-\u003exsize + x] =        \\\n                imIn-\u003eimage[yin][imIn-\u003exsize - 1];                \\   // [-1] when xsize == 0\n        }                                                         \\\n    }\n\n#define EXPAND(type, image)                                                      \\\n    {                                                                            \\\n        for (y = 0; y \u003c margin; y++) {                                           \\\n            EXPAND_LINE(type, image, 0, y);                                      \\   // line 0 of a 0-line image\n        }                                                                        \\\n        \u2026\n        for (y = 0; y \u003c margin; y++) {                                           \\\n            EXPAND_LINE(type, image, imIn-\u003eysize - 1, margin + imIn-\u003eysize + y); \\   // line -1 when ysize == 0\n        }                                                                        \\\n    }\n```\n\nWhy the line pointers are NULL: `ImagingNewPrologueSubtype` callocs the `im-\u003eimage` pointer array (`src/libImaging/Storage.c:216`, at least one entry), and `ImagingAllocateArray` returns before assigning any of them for an empty image:\n\n```c\n// src/libImaging/Storage.c:423-426\n    /* 0-width or 0-height image. No need to do anything */\n    if (!im-\u003elinesize || !im-\u003eysize) {\n        return im;\n    }\n```\n\nSo with `xsize == 0` every `imIn-\u003eimage[y]` is NULL and `imIn-\u003eimage[yin][0]` faults; with `ysize == 0` the top-margin pass reads `imIn-\u003eimage[0]` (the single calloc\u0027d NULL slot) and faults the same way, and the bottom-margin pass would index `imIn-\u003eimage[-1]`. `ImagingRankFilter` is never reached.\n\nZero-size images are ordinary objects in Pillow and arrive at `filter()` through public API only:\n\n- `Image.crop(box)` rejects only inverted boxes (`src/PIL/Image.py:1385-1390`); `left == right` or `upper == lower` yields a 0\u00d7N / N\u00d70 image. `ImageOps.crop(im, border)` with `border == width // 2`, and `Image.new(mode, (0, n))`, do the same.\n- From a file: `ImageFile.__init__` refuses a zero first-frame size (`src/PIL/ImageFile.py:167-173`), but `TiffImagePlugin._setup()` takes `ImageWidth`/`ImageLength` of every later IFD as-is on `seek()` (`src/PIL/TiffImagePlugin.py:1468-1481`). For an uncompressed page of an image opened by path, `ImageFile.load()` takes the mmap branch (`src/PIL/ImageFile.py:307, 325-347`) and `Image.core.map_buffer` builds an `8\u00d70` core image without complaint (`src/map.c:127-141`), so `im.seek(1); im.load()` succeeds and a following `im.filter(ImageFilter.MedianFilter(3))` segfaults in `ImagingExpand` exactly as above (verified under gdb: `imIn-\u003eysize = 0`, `imIn-\u003eimage[0] = 0x0`). A 384-byte two-page TIFF is enough.\n\n## Impact\n\nDenial of service: the whole embedding process (web worker, pipeline process) dies with SIGSEGV rather than the request failing with a Python exception. It is reachable by a remote user in two realistic shapes: (a) an application that crops an upload to user-supplied coordinates and then applies a median/min/max filter (denoise, dilate/erode, thumbnail clean-up) \u2014 a box with `x0 == x1` or `y0 == y1` passes `crop()` and crashes the worker; (b) an application that opens an uploaded TIFF from disk by path, iterates its pages and applies a rank filter to each \u2014 a crafted second IFD with `ImageLength = 0` crashes it. The faulting access is a read at address 0 (or a fixed small negative offset from the pointer array for the `[-1]` cases, which is not reached because the first read already faults), so there is no memory disclosure or corruption beyond the crash. The same shape, a zero-dimension image crashing C code reached through public API, was fixed in `ImagingOffset` in 39d14a0db (GHSA-f87v-9578-p47w).\n\n## Reproducing\n\n`repro` is a single Python script that uses the installed Pillow as-is (no rebuild). It runs each case in a fresh child interpreter, with core dumps disabled. That way a segfault shows up as the child\u0027s exit status and the script itself keeps running. Each child builds `Image.new(\"L\", (10, 10)).crop(box)`, prints its size, calls `im.filter(...)` and then prints the size of the result.\n\n- **Control**: a `(1, 10)` crop (`(3, 0, 4, 10)`) through `MedianFilter(3)`. The rank filter accepts a thin image and must return normally.\n- **PoC**: the rank filters on empty crops.\n  - A `(0, 10)` crop (`left == right`, `(3, 0, 3, 10)`) through `MedianFilter(3)` and `MaxFilter(5)`.\n  - A `(10, 0)` crop (`upper == lower`, `(0, 3, 10, 3)`) through `MinFilter(3)`.\n  - A `(0, 0)` crop (`(3, 3, 3, 3)`) through `RankFilter(3, 4)`.\n\nExpected output on the stock build:\n\n```\n  crop(3, 0, 4, 10)    MedianFilter(3)    (1, 10) -\u003e (1, 10)\n  crop(3, 0, 3, 10)    MedianFilter(3)    (0, 10) -\u003e killed by SIGSEGV\n  crop(3, 0, 3, 10)    MaxFilter(5)       (0, 10) -\u003e killed by SIGSEGV\n  crop(0, 3, 10, 3)    MinFilter(3)       (10, 0) -\u003e killed by SIGSEGV\n  crop(3, 3, 3, 3)     RankFilter(3, 4)   (0, 0) -\u003e killed by SIGSEGV\nBUG\n```\n\nThe size printed before `-\u003e` shows that the empty image was created without error. The crash happens inside `filter()`, in `ImagingExpand`. The last line is `BUG` if the control returned normally and at least one rank-filter child was killed by SIGSEGV. Otherwise it is `OK`. The script covers the crop route only; the TIFF route described above fails the same way (`im.seek(1); im.load(); im.filter(ImageFilter.MedianFilter(3))` on a by-path two-page TIFF whose second IFD has `ImageLength = 0`). With the attached patch, every PoC line prints the unchanged size (for example `(0, 10) -\u003e (0, 10)`) and the script prints `OK`.\n\n## Suggested fix\n\nThe attached patch handles the empty input in `ImagingExpand` (`src/libImaging/Filter.c`), right after the `margin` checks and before the `ImagingNewDirty` allocation and the replication loops. With `xsize == 0` or `ysize == 0` there are no edge pixels to replicate, so it returns a zeroed (`ImagingNew`, not `ImagingNewDirty`) image of the expanded size, with the input\u0027s palette copied. This keeps `ImagingExpand`\u0027s size contract, so `ImagingRankFilter` then produces an output of `xsize - 2*margin` \u00d7 `ysize - 2*margin`, i.e. the original empty size, matching every other filter. It mirrors the existing zero-dimension early returns in `src/libImaging/BoxBlur.c` (127004368) and `src/libImaging/Offset.c` (39d14a0db):\n\n```diff\n--- a/src/libImaging/Filter.c\n+++ b/src/libImaging/Filter.c\n@@ -67,6 +67,17 @@ ImagingExpand(Imaging imIn, int margin) {\n         return (Imaging)ImagingError_ValueError(\"filter size too large\");\n     }\n \n+    if (imIn-\u003exsize == 0 || imIn-\u003eysize == 0) {\n+        /* No edge pixels to replicate (and no lines to read from), so\n+           return a zeroed image of the expanded size */\n+        imOut = ImagingNew(imIn-\u003emode, imIn-\u003exsize + 2 * margin, imIn-\u003eysize + 2 * margin);\n+        if (!imOut) {\n+            return NULL;\n+        }\n+        ImagingCopyPalette(imOut, imIn);\n+        return imOut;\n+    }\n+\n     imOut =\n         ImagingNewDirty(imIn-\u003emode, imIn-\u003exsize + 2 * margin, imIn-\u003eysize + 2 * margin);\n     if (!imOut) {\n```\n\nThe patch also adds `test_rankfilter_zero_dimension` next to `test_rankfilter_error` in `Tests/test_image_filter.py`, which filters `Image.new(\"L\", size)` for `size` in `((0, 6), (6, 0), (0, 0))` with `MinFilter`, `MedianFilter`, `MaxFilter` and `RankFilter(3, 2)` and asserts the size is preserved. Applied to a clean checkout and rebuilt, the reproducer prints `OK` and `Tests/test_image_filter.py` passes. A Python-level guard in `RankFilter.filter` (`if 0 in image.size: return image.copy()`) would also stop the crash, but the C-level check protects any other caller of `expand()`.\n\n## The patch\n\nReturn a zeroed image from ImagingExpand when the input has zero width or height instead of reading NULL line pointers\n\nApplies to `src/libImaging/Filter.c` at the commit above.\n\n```diff\ndiff --git a/Tests/test_image_filter.py b/Tests/test_image_filter.py\nindex 974d4b7a3..8dc8e1a1a 100644\n--- a/Tests/test_image_filter.py\n+++ b/Tests/test_image_filter.py\n@@ -155,6 +155,23 @@ def test_rankfilter_error(filter: ImageFilter.RankFilter) -\u003e None:\n         im.filter(filter).getpixel((1, 1))\n \n \n+@pytest.mark.parametrize(\n+    \"filter\",\n+    (\n+        ImageFilter.MinFilter,\n+        ImageFilter.MedianFilter,\n+        ImageFilter.MaxFilter,\n+        ImageFilter.RankFilter(3, 2),\n+    ),\n+)\n+@pytest.mark.parametrize(\"size\", ((0, 6), (6, 0), (0, 0)))\n+def test_rankfilter_zero_dimension(\n+    filter: ImageFilter.RankFilter, size: tuple[int, int]\n+) -\u003e None:\n+    im = Image.new(\"L\", size)\n+    assert im.filter(filter).size == size\n+\n+\n def test_rankfilter_properties() -\u003e None:\n     rankfilter = ImageFilter.RankFilter(3, 2)\n \ndiff --git a/src/libImaging/Filter.c b/src/libImaging/Filter.c\nindex 3492a871f..d702db5f9 100644\n--- a/src/libImaging/Filter.c\n+++ b/src/libImaging/Filter.c\n@@ -67,6 +67,17 @@ ImagingExpand(Imaging imIn, int margin) {\n         return (Imaging)ImagingError_ValueError(\"filter size too large\");\n     }\n \n+    if (imIn-\u003exsize == 0 || imIn-\u003eysize == 0) {\n+        /* No edge pixels to replicate (and no lines to read from), so\n+           return a zeroed image of the expanded size */\n+        imOut = ImagingNew(imIn-\u003emode, imIn-\u003exsize + 2 * margin, imIn-\u003eysize + 2 * margin);\n+        if (!imOut) {\n+            return NULL;\n+        }\n+        ImagingCopyPalette(imOut, imIn);\n+        return imOut;\n+    }\n+\n     imOut =\n         ImagingNewDirty(imIn-\u003emode, imIn-\u003exsize + 2 * margin, imIn-\u003eysize + 2 * margin);\n     if (!imOut) {\n```\n\n## The reproducer\n\n\u003cdetails\u003e\n\u003csummary\u003eReproducer \u2014 \u003ccode\u003erepro\u003c/code\u003e, 1,333 bytes (click to open)\u003c/summary\u003e\n\nIts last line is `BUG` when the issue triggers and `OK` when it does not. Re-run on a clean build of that commit it printed `BUG`.\n\n```python\n#!/usr/bin/env python3\n# Pillow: rank filters (Median/Min/Max/RankFilter) on a 0-wide or 0-high image\n# SIGSEGV in ImagingExpand (src/libImaging/Filter.c) - NULL line pointer read.\n# Each case runs in a child interpreter; BUG if the control returns and any\n# zero-size case dies of SIGSEGV.\nimport signal, subprocess, sys\n\nCHILD = \"\"\"\nimport resource; resource.setrlimit(resource.RLIMIT_CORE, (0, 0))\nfrom PIL import Image, ImageFilter\nim = Image.new(\"L\", (10, 10)).crop(%s)      # public API; crop accepts x0==x1 / y0==y1\nprint(im.size, \"-\u003e\", end=\" \", flush=True)\nprint(im.filter(ImageFilter.%s).size)\n\"\"\"\n\ndef run(box, flt):\n    p = subprocess.run([sys.executable, \"-c\", CHILD % (box, flt)],\n                       capture_output=True, text=True)\n    out = p.stdout.strip()\n    if p.returncode \u003c 0:\n        out += \" killed by \" + signal.Signals(-p.returncode).name\n    print(f\"  crop{box!s:\u003c16} {flt:\u003c18} {out}\")\n    return p.returncode\n\nctrl = run((3, 0, 4, 10), \"MedianFilter(3)\")          # (1,10): must work\nrcs = [run((3, 0, 3, 10), \"MedianFilter(3)\"),        # (0,10)\n       run((3, 0, 3, 10), \"MaxFilter(5)\"),\n       run((0, 3, 10, 3), \"MinFilter(3)\"),           # (10,0)\n       run((3, 3, 3, 3), \"RankFilter(3, 4)\")]        # (0,0)\nbug = ctrl == 0 and any(rc == -signal.SIGSEGV for rc in rcs)\nprint(\"BUG\" if bug else \"OK\")\n```\n\u003c/details\u003e\n\n---",
  "id": "GHSA-27h8-gf7j-v5hc",
  "modified": "2026-10-21T20:32:37Z",
  "published": "2026-10-21T20:32:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/python-pillow/Pillow/security/advisories/GHSA-27h8-gf7j-v5hc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-112392"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-pillow/Pillow/commit/443e3130a8c11594fd0e296afad497e11e678961"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/python-pillow/Pillow"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-pillow/Pillow/releases/tag/13.0.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Pillow: NULL dereference in ImagingExpand via rank filters on zero-size images"
}

GHSA-27Q7-WQ4M-6CJM

Vulnerability from github – Published: 2022-05-14 03:24 – Updated: 2022-05-14 03:24

Details

In Android before security patch level 2018-04-05 on Qualcomm Snapdragon Mobile and Snapdragon Wear MDM9206, MDM9607, MDM9635M, MDM9640, MDM9645, MDM9650, MDM9655, MSM8909W, SD 210/SD 212/SD 205, SD 425, SD 430, SD 450, SD 625, SD 650/52, SD 820, SD 835, SD 845, SD 850, added a change to check if the pointer has been reset to NULL or not, before writing to the memory pointed by the pointer.

Severity

9.8 (Critical)


                  
                    CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2018-3592"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-04-11T15:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "In Android before security patch level 2018-04-05 on Qualcomm Snapdragon Mobile and Snapdragon Wear MDM9206, MDM9607, MDM9635M, MDM9640, MDM9645, MDM9650, MDM9655, MSM8909W, SD 210/SD 212/SD 205, SD 425, SD 430, SD 450, SD 625, SD 650/52, SD 820, SD 835, SD 845, SD 850, added a change to check if the pointer has been reset to NULL or not, before writing to the memory pointed by the pointer.",
  "id": "GHSA-27q7-wq4m-6cjm",
  "modified": "2022-05-14T03:24:17Z",
  "published": "2022-05-14T03:24:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-3592"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2018-04-01"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/103671"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-27QM-738J-QWW9

Vulnerability from github – Published: 2026-05-06 12:30 – Updated: 2026-05-11 21:31

Details

In the Linux kernel, the following vulnerability has been resolved:

HID: prodikeys: Check presence of pm->input_ep82

Fake USB devices can send their own report descriptors for which the input_mapping() hook does not get called. In this case, pm->input_ep82 stays NULL, which leads to a crash later.

This does not happen with the real device, but can be provoked by imposing as one.

Severity

5.5 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-43251"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-06T12:16:45Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nHID: prodikeys: Check presence of pm-\u003einput_ep82\n\nFake USB devices can send their own report descriptors for which the\ninput_mapping() hook does not get called.  In this case, pm-\u003einput_ep82 stays\nNULL, which leads to a crash later.\n\nThis does not happen with the real device, but can be provoked by imposing as\none.",
  "id": "GHSA-27qm-738j-qww9",
  "modified": "2026-05-11T21:31:31Z",
  "published": "2026-05-06T12:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43251"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3f1b21cc67a15d7d081378a9b8747dd000a017b8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cee8337e1bad168136aecfe6416ecd7d3aa7529a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d08f35f843881ec504d7537a9bb728a073db3366"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d5512ce892f774d37c53082adadfcad04f21b50e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e7ac1cd823cd2e9fcbd5cb0b261d6d35dbb79341"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/edccbf7d6dc05d692bde3a89de5a4001f72a0fa4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ee572578f09f0e743e9383393a75c3a7a0f9b4c2"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f580c79683356632f12f2c2029f2fe936d953aa1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-27QW-FFF9-QJQ8

Vulnerability from github – Published: 2025-07-07 03:30 – Updated: 2025-07-07 03:30

Details

Null pointer dereference vulnerability in the PDF preview module Impact: Successful exploitation of this vulnerability may affect function stability.

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-53180"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-122",
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-07T03:15:29Z",
    "severity": "MODERATE"
  },
  "details": "Null pointer dereference vulnerability in the PDF preview module\nImpact: Successful exploitation of this vulnerability may affect function stability.",
  "id": "GHSA-27qw-fff9-qjq8",
  "modified": "2025-07-07T03:30:23Z",
  "published": "2025-07-07T03:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53180"
    },
    {
      "type": "WEB",
      "url": "https://consumer.huawei.com/en/support/bulletin/2025/7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-27QW-RMPJ-379Q

Vulnerability from github – Published: 2024-08-26 12:31 – Updated: 2025-11-04 00:31

Details

In the Linux kernel, the following vulnerability has been resolved:

jfs: fix null ptr deref in dtInsertEntry

[syzbot reported] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 5061 Comm: syz-executor404 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:dtInsertEntry+0xd0c/0x1780 fs/jfs/jfs_dtree.c:3713 ... [Analyze] In dtInsertEntry(), when the pointer h has the same value as p, after writing name in UniStrncpy_to_le(), p->header.flag will be cleared. This will cause the previously true judgment "p->header.flag & BT-LEAF" to change to no after writing the name operation, this leads to entering an incorrect branch and accessing the uninitialized object ih when judging this condition for the second time.

[Fix] After got the page, check freelist first, if freelist == 0 then exit dtInsert() and return -EINVAL.

Severity

5.5 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-44939"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-26T12:15:06Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\njfs: fix null ptr deref in dtInsertEntry\n\n[syzbot reported]\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\nCPU: 0 PID: 5061 Comm: syz-executor404 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nRIP: 0010:dtInsertEntry+0xd0c/0x1780 fs/jfs/jfs_dtree.c:3713\n...\n[Analyze]\nIn dtInsertEntry(), when the pointer h has the same value as p, after writing\nname in UniStrncpy_to_le(), p-\u003eheader.flag will be cleared. This will cause the\npreviously true judgment \"p-\u003eheader.flag \u0026 BT-LEAF\" to change to no after writing\nthe name operation, this leads to entering an incorrect branch and accessing the\nuninitialized object ih when judging this condition for the second time.\n\n[Fix]\nAfter got the page, check freelist first, if freelist == 0 then exit dtInsert()\nand return -EINVAL.",
  "id": "GHSA-27qw-rmpj-379q",
  "modified": "2025-11-04T00:31:19Z",
  "published": "2024-08-26T12:31:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44939"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/53023ab11836ac56fd75f7a71ec1356e50920fa9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6ea10dbb1e6c58384136e9adfd75f81951e423f6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9c2ac38530d1a3ee558834dfa16c85a40fd0e702"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ce6dede912f064a855acf6f04a04cbb2c25b8c8c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f98bf80b20f4a930589cda48a35f751a64fe0dc2"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-27RC-RCPV-8MR7

Vulnerability from github – Published: 2025-10-01 09:30 – Updated: 2026-01-16 21:30

Details

In the Linux kernel, the following vulnerability has been resolved:

mm/slub: avoid accessing metadata when pointer is invalid in object_err()

object_err() reports details of an object for further debugging, such as the freelist pointer, redzone, etc. However, if the pointer is invalid, attempting to access object metadata can lead to a crash since it does not point to a valid object.

One known path to the crash is when alloc_consistency_checks() determines the pointer to the allocated object is invalid because of a freelist corruption, and calls object_err() to report it. The debug code should report and handle the corruption gracefully and not crash in the process.

In case the pointer is NULL or check_valid_pointer() returns false for the pointer, only print the pointer value and skip accessing metadata.

Severity

5.5 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-39902"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-01T08:15:32Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/slub: avoid accessing metadata when pointer is invalid in object_err()\n\nobject_err() reports details of an object for further debugging, such as\nthe freelist pointer, redzone, etc. However, if the pointer is invalid,\nattempting to access object metadata can lead to a crash since it does\nnot point to a valid object.\n\nOne known path to the crash is when alloc_consistency_checks()\ndetermines the pointer to the allocated object is invalid because of a\nfreelist corruption, and calls object_err() to report it. The debug code\nshould report and handle the corruption gracefully and not crash in the\nprocess.\n\nIn case the pointer is NULL or check_valid_pointer() returns false for\nthe pointer, only print the pointer value and skip accessing metadata.",
  "id": "GHSA-27rc-rcpv-8mr7",
  "modified": "2026-01-16T21:30:27Z",
  "published": "2025-10-01T09:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39902"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0ef7058b4dc6fcef622ac23b45225db57f17b83f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1f0797f17927b5cad0fb7eced422f9a7c30a3191"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3baa1da473e6e50281324ff1d332d1a07a3bb02e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7e287256904ee796c9477e3ec92b07f236481ef3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/872f2c34ff232af1e65ad2df86d61163c8ffad42"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b4efccec8d06ceb10a7d34d7b1c449c569d53770"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/dda6ec365ab04067adae40ef17015db447e90736"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f66012909e7bf383fcdc5850709ed5716073fdc4"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-27RH-47J7-25G8

Vulnerability from github – Published: 2022-05-14 03:33 – Updated: 2022-05-14 03:33

Details

An issue was discovered in ImageMagick 7.0.7. A NULL pointer dereference vulnerability was found in the function LoadOpenCLDevices in MagickCore/opencl.c, which allows attackers to cause a denial of service via a crafted file.

Severity

6.5 (Medium)


                  
                    CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2017-18253"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-03-27T03:29:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in ImageMagick 7.0.7. A NULL pointer dereference vulnerability was found in the function LoadOpenCLDevices in MagickCore/opencl.c, which allows attackers to cause a denial of service via a crafted file.",
  "id": "GHSA-27rh-47j7-25g8",
  "modified": "2022-05-14T03:33:42Z",
  "published": "2022-05-14T03:33:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-18253"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ImageMagick/ImageMagick/issues/794"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

CWE-476

NULL Pointer Dereference

GHSA-27F9-CGJJ-WVCV

GHSA-27FW-6HP8-FGWW

GHSA-27H4-M228-RWM7

GHSA-27H8-GF7J-V5HC

Details

Impact

Reproducing

Suggested fix

The patch

The reproducer

GHSA-27Q7-WQ4M-6CJM

GHSA-27QM-738J-QWW9

GHSA-27QW-FFF9-QJQ8

GHSA-27QW-RMPJ-379Q

GHSA-27RC-RCPV-8MR7

GHSA-27RH-47J7-25G8

Mitigation MIT-56

Mitigation

Mitigation

Mitigation

Mitigation