CWE-908
AllowedUse of Uninitialized Resource
Abstraction: Base · Status: Incomplete
The product uses or accesses a resource that has not been initialized.
1055 vulnerabilities reference this CWE, most recent first.
GHSA-Q45J-58J2-45RG
Vulnerability from github – Published: 2026-10-20 20:52 – Updated: 2026-10-20 20:52============================================================================
TiffDecode returns uninitialized memory as pixels for short JPEG strips
Location: src/libImaging/TiffDecode.c:554 in _decodeStrip()
Commit: a707c6b21c313880d0771e54965d142dd42358b6
============================================================================
Pillow hands back leftover process memory as image pixels when it opens a small crafted TIFF file. Anyone who can get an application to open their image, and can see something produced from its pixels (a thumbnail, a preview, a converted copy), can read heap memory that the process had previously used and freed. This works in the default configuration: opening and loading the 478-byte file succeeds with no error or warning, and every row below the first eight holds stale memory instead of picture content.
The bug is in _decodeStrip() in src/libImaging/TiffDecode.c, and _decodeTile() has the same shape. The function realloc()s state->buffer to TIFFStripSize() bytes without initialising it and calls TIFFReadEncodedStrip(). Whenever that call does not return -1, it copies all RowsPerStrip rows of the buffer into the image. libtiff's JPEG codec only warns when the JPEG embedded in a strip has fewer rows than the strip, and Pillow silences libtiff warnings. The codec decodes the rows that exist and still returns the full strip size, so the untouched remainder is copied out as pixels. libtiff's Group 4 fax codec behaves the same way for a stream that ends early.
The attached reproducer builds a 256×256 TIFF whose single strip or tile is a 256×8 JPEG. Before loading it, the script frees buffers filled with b"LEAK". It then finds 15,872 copies of LEAK in rows 8–255 of the decoded image (the same freed chunk was reused in 500 of 500 runs). Under glibc's MALLOC_PERTURB_, those rows are entirely the allocator's fill byte. A well-formed control file decodes correctly in both cases.
This is a read of uninitialised heap memory, not memory corruption. Each strip can disclose up to width × RowsPerStrip bytes, and what comes back depends on the allocator's state at the time. The strip path was introduced in e91b851fdc1c ("Add reading old-JPEG compressed TIFFs", first released in Pillow 6.0.0). The tile path has had the same pattern since f0436a4ddc95 (Pillow 5.3.0).
Details
src/libImaging/TiffDecode.c decodes compressed TIFFs through libtiff into a strip
(or tile) buffer that it realloc()s to TIFFStripSize() bytes and never initialises, and
then copies all RowsPerStrip rows of that buffer into the image whenever
TIFFReadEncodedStrip() does not return -1. libtiff's JPEG codec does not fail when the
JPEG stream inside a strip has fewer rows than the strip: it decodes the rows that exist
and returns the full strip size. The rows it did not write are whatever the heap held
before, and Pillow returns them as pixels.
A 478-byte file shows it: a classic little-endian TIFF, 256×256, BitsPerSample=8,
Compression=7, PhotometricInterpretation=1, RowsPerStrip=256, one strip whose data
is a baseline JPEG of 256×8 pixels (as written by Image.new("L",(256,8),200).save(…,"JPEG")).
Image.open(BytesIO(data)).load() succeeds with default settings (compressed TIFFs always
take the libtiff path). Rows 0–7 of the result are the JPEG content (value 200); the
remaining 63488 bytes of im.tobytes() are heap garbage: run under glibc's
MALLOC_PERTURB_=1 they are all 0xFE, under MALLOC_PERTURB_=170 all 0x55 (the
fresh-malloc fill byte), and in a process that has just freed buffers containing
b"LEAK" they contain 15872 copies of LEAK.
Feeding the same file to libtiff 4.5.0 directly confirms the library side:
TIFFReadEncodedStrip(t, 0, buf, 65536) prints
JPEGPreDecode: Warning, Improper JPEG strip/tile size, expected 256x256, got 256x8.,
returns 65536, and leaves 63488 of the 65536 buffer bytes untouched. Pillow installs
TIFFSetWarningHandler(NULL) (TiffDecode.c:682), so the warning is not visible either.
The strip path:
// src/libImaging/TiffDecode.c:552
/* realloc to fit whole strip */
/* malloc check above */
new_data = realloc(state->buffer, state->bytes); // state->bytes = TIFFStripSize()
…
state->buffer = new_data;
for (; state->y < state->ysize; state->y += rows_per_strip) {
…
if (TIFFReadEncodedStrip(
tiff,
TIFFComputeStrip(tiff, state->y, plane),
(tdata_t)state->buffer,
strip_size
) == -1) {
… return -1;
}
…
// iterate over each row in the strip and stuff data into image
for (strip_row = 0;
strip_row < MIN((INT32)rows_per_strip, state->ysize - state->y);
strip_row++) {
…
shuffler(
(UINT8 *)im->image[state->y + state->yoff + strip_row] +
state->xoff * im->pixelsize,
state->buffer + strip_row * row_byte_size,
state->xsize
);
state->buffer arrives here as the one-row calloc made by decode.c:230
((bits*xsize+7)/8 = 256 bytes for the example). The realloc to 65536 bytes hands back
a different, uninitialised chunk; nothing zeroes it. TIFFReadEncodedStrip() returns the
nominal strip size on success, not the number of rows produced, and the only check is
== -1, so the row loop unconditionally copies 256 rows × 256 bytes into im->image
(which itself is zeroed by core.new, so the garbage provably comes from state->buffer).
_decodeTile() has the same shape (TiffDecode.c:448 realloc to TIFFTileSize(), then
tile_length rows copied after each TIFFReadTile() at 460–488).
For a well-formed file the JPEG inside the strip is 256×256, libtiff fills all 65536 bytes and the copy is correct. The malicious file differs only in the SOF height of the embedded JPEG; libtiff treats "JPEG smaller than strip" as a warning, clamps the row count to the JPEG height, and reports success.
JPEG is not the only libtiff codec that succeeds on a short strip. Fax4Decode
(Compression=4) returns success for a T.6 stream that ends early: a 133-byte 512×256
1-bit TIFF whose strip is the Group 4 stream of a 512×16 image loads without error,
libtiff writes 17 rows (1088 bytes) of the 16384-byte buffer
(Fax4Decode: Warning, Premature EOL at line 16, return value 16384) and the other
15296 bytes are again heap contents. LZW, Deflate, PackBits, Group 3 and CCITT RLE were
checked and do return -1 on short data, so Pillow raises OSError for those.
The strip path was introduced in e91b851fdc1c ("Add reading old-JPEG compressed TIFFs",
2018-12-08), first released in Pillow 6.0.0, which replaced row-by-row TIFFReadScanline()
(where libtiff errors on the first missing row) with the whole-strip realloc() and copy.
The tile path has had the same shape since it was added in f0436a4ddc95 (2018-07-02,
Pillow 5.3.0).
Impact
Any application that opens attacker-supplied images with Pillow in the default
configuration and returns something derived from the pixels (thumbnail, preview, format
conversion, OCR text) discloses freed heap memory of the worker process to the uploader:
everything below the rows the embedded JPEG/G4 stream actually encodes, up to
ImageWidth × RowsPerStrip × SamplesPerPixel bytes per strip and tens of MB per image
within the default MAX_IMAGE_PIXELS. load() raises nothing, so the application has no
signal that the image is malformed. What comes back depends on allocator state; in a
long-running web worker it is typically recently freed request bodies, other users'
decoded image buffers and Python object contents. There is no memory corruption; this is
a read of uninitialised (previously used) heap memory, analogous in effect to an
out-of-bounds read that lands in pixels.
Reproducing
repro is a short Python script that runs against the installed Pillow build with
default settings: no rebuild, no sanitizer, no files written. It runs twice, once normally
and once re-executing itself under glibc's MALLOC_PERTURB_=170, and the last line it
prints is BUG or OK.
Input. tiff(jpeg_rows, tiled) builds a little-endian TIFF in memory. The header
declares a 256×256 8-bit greyscale image with Compression=7 (JPEG), either as one strip
(RowsPerStrip=256) or as one 256×256 tile (TileWidth/TileLength). The strip or tile
is a baseline JPEG of 256×jpeg_rows pixels, all value 200, written by Pillow's own JPEG
encoder. For each layout the script builds two files:
- Control:
jpeg_rows=256. This is a well-formed file, and libtiff fills the whole 64 KiB strip/tile. - Crafted:
jpeg_rows=8, 478 bytes (strip) or 490 bytes (tile). The only difference is the embedded JPEG's height. libtiff decodes 8 rows (2048 bytes), warnsImproper JPEG strip/tile size(Pillow silences the warning) and returns the full strip/tile size as success.
Steps. Each file is opened (the script asserts it takes the libtiff decoder). Just
before im.load() the script allocates and frees six 64 KiB bytearrays filled with
b"LEAK", which leaves freed heap chunks about the size of the buffer that
_decodeStrip()/_decodeTile() is about to realloc(). For rows 8–255 it then counts
copies of LEAK and bytes equal to 0x55 (glibc's fresh-malloc fill under
MALLOC_PERTURB_=170). The files contain no LEAK bytes (the script asserts this), so
any copy in the image came from freed heap memory. It reports BUG if a crafted file
shows any LEAK in the normal pass, or rows 8–255 entirely 0x55 in the perturbed pass.
Expected output on this tree:
[normal ] strip well-formed (1222 B) rows 8-255: 0 x b'LEAK', 0/63488 == 0x55, head=b'\xc8\xc8\xc8\xc8\xc8\xc8\xc8\xc8'
[normal ] strip crafted ( 478 B) rows 8-255: 15872 x b'LEAK', 0/63488 == 0x55, head=b'LEAKLEAK'
[normal ] tiled well-formed (1234 B) rows 8-255: 0 x b'LEAK', 0/63488 == 0x55, head=b'\xc8\xc8\xc8\xc8\xc8\xc8\xc8\xc8'
[normal ] tiled crafted ( 490 B) rows 8-255: 15872 x b'LEAK', 0/63488 == 0x55, head=b'LEAKLEAK'
[perturb] strip well-formed (1222 B) rows 8-255: 0 x b'LEAK', 0/63488 == 0x55, head=b'\xc8\xc8\xc8\xc8\xc8\xc8\xc8\xc8'
[perturb] strip crafted ( 478 B) rows 8-255: 0 x b'LEAK', 63488/63488 == 0x55, head=b'UUUUUUUU'
[perturb] tiled well-formed (1234 B) rows 8-255: 0 x b'LEAK', 0/63488 == 0x55, head=b'\xc8\xc8\xc8\xc8\xc8\xc8\xc8\xc8'
[perturb] tiled crafted ( 490 B) rows 8-255: 0 x b'LEAK', 63488/63488 == 0x55, head=b'UUUUUUUU'
BUG
im.load() succeeds for every file. For the crafted files rows 8–255 are the uninitialised
strip/tile buffer, copied as-is into the image. With the attached patch applied, rows 8–255
of the crafted files come back as \x00 bytes, with no LEAK and no 0x55, and the
script ends with OK.
The LEAK count depends on where glibc places the buffer (the same freed chunk was reused
in 500 of 500 runs here); the MALLOC_PERTURB_ pass does not. The script covers the JPEG
codec only. The Group 4 variant in the Details section (Compression=4, a T.6 stream that
ends early) goes through the same _decodeStrip() copy, and the same fix covers it.
Suggested fix
The attached patch zeroes state->buffer before each libtiff read in both loops of
src/libImaging/TiffDecode.c — before TIFFReadTile() in _decodeTile() and before
TIFFReadEncodedStrip() in _decodeStrip() — so rows a codec does not produce are
deterministic zeros rather than stale heap:
--- a/src/libImaging/TiffDecode.c
+++ b/src/libImaging/TiffDecode.c
@@ _decodeTile
for (x = state->xoff; x < state->xsize; x += tile_width) {
+ memset(state->buffer, 0, state->bytes);
if (TIFFReadTile(tiff, (tdata_t)state->buffer, x, y, 0, plane) == -1) {
@@ _decodeStrip
for (plane = 0; plane < planes; plane++) {
ImagingShuffler shuffler = unpackers[plane];
+ memset(state->buffer, 0, state->bytes);
if (TIFFReadEncodedStrip(
A memset per strip/tile (rather than one calloc after the size is known) is needed
because the same buffer is reused for every strip, and a short last strip would otherwise
expose the previous strip's rows — harmless for disclosure, but the per-read memset
keeps the behaviour uniform at the cost of one extra pass over the buffer. Promoting
libtiff warnings to errors via a warning handler is not a good alternative: both codecs
only warn (Improper JPEG strip/tile size, Premature EOL), but so do many legitimate
files (unknown tags, bad tag counts), and the return value of TIFFReadEncodedStrip()
carries no row count to check against. Initialising the buffer covers every codec.
_decodeAsRGBA() needs no change: TIFFRGBAImageGet() fills its whole raster, and JPEG
files do not reach it (JPEGCOLORMODE_RGB sends them down the strip path).
Valid files decode exactly as before; rows a codec does not produce are now black instead
of garbage, and nothing that previously loaded now fails. The patch also adds
test_jpeg_short_strip to Tests/test_file_libtiff.py, parametrised over strip and tile,
which builds the 256×8-JPEG-in-256×256 file and asserts rows 8–255 are zero. It is a
regression guard for the fixed code rather than a reliable detector of the bug: in a fresh
pytest process the unfixed strip variant can pass because the new heap chunk happens to be
zero (the tiled variant fails before the fix). With the patch, Tests/test_file_libtiff.py
and Tests/test_file_tiff.py pass and the reproducer prints OK.
The patch
Zero the libtiff strip/tile buffer before each TIFFReadEncodedStrip/TIFFReadTile in TiffDecode.c so short strips do not expose uninitialised heap
Applies to src/libImaging/TiffDecode.c at the commit above.
diff --git a/Tests/test_file_libtiff.py b/Tests/test_file_libtiff.py
index 3d804ea4a..67bc96329 100644
--- a/Tests/test_file_libtiff.py
+++ b/Tests/test_file_libtiff.py
@@ -1162,6 +1162,45 @@ class TestFileLibTiff(LibTiffTestCase):
im.load()
assert im.size == (950, 975)
+ @pytest.mark.parametrize("tiled", (False, True))
+ def test_jpeg_short_strip(self, tiled: bool) -> None:
+ # The JPEG data in the strip/tile only contains 8 of the 256 rows that
+ # RowsPerStrip/TileLength declare. libtiff decodes the rows that exist
+ # and still reports success, so the remaining rows must be cleared
+ # rather than left as uninitialised memory.
+ jpeg = io.BytesIO()
+ Image.new("L", (256, 8), 200).save(jpeg, "JPEG")
+ jpeg_data = jpeg.getvalue()
+
+ ifd = TiffImagePlugin.ImageFileDirectory_v2()
+ ifd[256] = 256 # ImageWidth
+ ifd[257] = 256 # ImageLength
+ ifd[258] = 8 # BitsPerSample
+ ifd[259] = 7 # Compression: JPEG
+ ifd[262] = 1 # PhotometricInterpretation: BlackIsZero
+ ifd[277] = 1 # SamplesPerPixel
+ if tiled:
+ ifd[322] = 256 # TileWidth
+ ifd[323] = 256 # TileLength
+ ifd[324] = 0 # TileOffsets
+ ifd[325] = len(jpeg_data) # TileByteCounts
+ # Point the tile data at the end of the IFD
+ ifd[324] = 8 + len(ifd.tobytes(8))
+ else:
+ ifd[278] = 256 # RowsPerStrip
+ ifd[STRIPOFFSETS] = 0 # Updated by tobytes() to follow the IFD
+ ifd[279] = len(jpeg_data) # StripByteCounts
+
+ b = io.BytesIO()
+ ifd.save(b)
+ b.write(jpeg_data)
+
+ with Image.open(b) as im:
+ assert im.tile[0][0] == "libtiff"
+ im.load()
+ assert im.crop((0, 0, 256, 8)).getextrema() == (200, 200)
+ assert im.crop((0, 8, 256, 256)).getextrema() == (0, 0)
+
def test_orientation(self) -> None:
with Image.open("Tests/images/g4_orientation_1.tif") as base_im:
for i in range(2, 9):
diff --git a/src/libImaging/TiffDecode.c b/src/libImaging/TiffDecode.c
index 8a57c523d..d1d6bfbbb 100644
--- a/src/libImaging/TiffDecode.c
+++ b/src/libImaging/TiffDecode.c
@@ -457,6 +457,11 @@ _decodeTile(
for (plane = 0; plane < planes; plane++) {
ImagingShuffler shuffler = unpackers[plane];
for (x = state->xoff; x < state->xsize; x += tile_width) {
+ // Some codecs (e.g. JPEG, Group 4) succeed on a tile that decodes
+ // to fewer rows than the tile length, leaving the rest of the
+ // buffer untouched. Clear it so that uninitialised memory is not
+ // copied into the image.
+ memset(state->buffer, 0, state->bytes);
if (TIFFReadTile(tiff, (tdata_t)state->buffer, x, y, 0, plane) == -1) {
TRACE(("Decode Error, Tile at %dx%d\n", x, y));
state->errcode = IMAGING_CODEC_BROKEN;
@@ -563,6 +568,11 @@ _decodeStrip(
int plane;
for (plane = 0; plane < planes; plane++) {
ImagingShuffler shuffler = unpackers[plane];
+ // Some codecs (e.g. JPEG, Group 4) succeed on a strip that decodes
+ // to fewer rows than RowsPerStrip, leaving the rest of the buffer
+ // untouched. Clear it so that uninitialised memory is not copied
+ // into the image.
+ memset(state->buffer, 0, state->bytes);
if (TIFFReadEncodedStrip(
tiff,
TIFFComputeStrip(tiff, state->y, plane),
The reproducer
Reproducer —repro, 2,688 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 TiffDecode.c _decodeStrip/_decodeTile: strip/tile buffer is realloc()ed, never
# initialised, and copied whole into the image even when libtiff's JPEG codec decoded
# fewer rows than RowsPerStrip/TileLength. Two independent signals:
# pass 1 (normal heap): seed freed 64 KiB chunks with b"LEAK" just before load() and
# count copies of LEAK in the decoded pixels (file contains no such bytes);
# pass 2 (same script re-run under glibc MALLOC_PERTURB_=170): fresh malloc memory is
# 0x55, so rows that come back all-0x55 are provably uninitialised heap.
import gc, io, os, struct, subprocess, sys
from PIL import Image
W = H = 256; ROWS = 8
perturbed = os.environ.get("MALLOC_PERTURB_") == "170"
if not perturbed:
print("Pillow", Image.__version__, Image.core.__file__)
def tiff(jpeg_rows, tiled):
j = io.BytesIO(); Image.new("L", (W, jpeg_rows), 200).save(j, "JPEG"); j = j.getvalue()
tags = [(256,3,1,W), (257,3,1,H), (258,3,1,8), (259,3,1,7), (262,3,1,1), (277,3,1,1)]
tags += ([(322,3,1,W), (323,3,1,H), (324,4,1,0), (325,4,1,len(j))] if tiled else
[(273,4,1,0), (278,3,1,H), (279,4,1,len(j))])
tags.sort(); off = 8 + 2 + 12*len(tags) + 4
tags = [(t,ty,c, off if t in (273,324) else v) for t,ty,c,v in tags]
ifd = struct.pack("<H", len(tags)) + b"".join(struct.pack("<HHLL", *t) for t in tags)
return b"II*\0" + struct.pack("<L", 8) + ifd + struct.pack("<L", 0) + j
bug = False
for tiled in (False, True):
for jpeg_rows, label in ((H, "well-formed"), (ROWS, "crafted")):
data = tiff(jpeg_rows, tiled); assert b"LEAK" not in data
im = Image.open(io.BytesIO(data)); assert im.tile[0][0] == "libtiff"
junk = [bytearray(b"LEAK" * (W*H//4)) for _ in range(6)]; del junk; gc.collect()
im.load() # no exception for either file
below = im.tobytes()[W*ROWS:]
n55, nleak = below.count(0x55), below.count(b"LEAK")
print(f"[{'perturb' if perturbed else 'normal '}] {'tiled' if tiled else 'strip'} "
f"{label:11s} ({len(data):4d} B) rows {ROWS}-{H-1}: {nleak:5d} x b'LEAK', "
f"{n55:5d}/{len(below)} == 0x55, head={below[:8]!r}")
if jpeg_rows == ROWS and (nleak > 0 or (perturbed and n55 == len(below))):
bug = True
if not perturbed:
r = subprocess.run([sys.executable, sys.argv[0]], env={**os.environ, "MALLOC_PERTURB_": "170"},
capture_output=True, text=True)
lines = r.stdout.rstrip().split("\n")
print("\n".join(lines[:-1])); sys.stderr.write(r.stderr)
bug = bug or lines[-1] == "BUG"
print("BUG" if bug else "OK")
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "Pillow"
},
"ranges": [
{
"events": [
{
"introduced": "5.3.0"
},
{
"fixed": "13.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-112897"
],
"database_specific": {
"cwe_ids": [
"CWE-908"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-20T20:52:43Z",
"nvd_published_at": "2026-10-19T22:17:09Z",
"severity": "HIGH"
},
"details": "```\n============================================================================\nTiffDecode returns uninitialized memory as pixels for short JPEG strips\nLocation: src/libImaging/TiffDecode.c:554 in _decodeStrip()\nCommit: a707c6b21c313880d0771e54965d142dd42358b6\n============================================================================\n```\n\nPillow hands back leftover process memory as image pixels when it opens a small crafted TIFF file. Anyone who can get an application to open their image, and can see something produced from its pixels (a thumbnail, a preview, a converted copy), can read heap memory that the process had previously used and freed. This works in the default configuration: opening and loading the 478-byte file succeeds with no error or warning, and every row below the first eight holds stale memory instead of picture content.\n\nThe bug is in `_decodeStrip()` in `src/libImaging/TiffDecode.c`, and `_decodeTile()` has the same shape. The function `realloc()`s `state-\u003ebuffer` to `TIFFStripSize()` bytes without initialising it and calls `TIFFReadEncodedStrip()`. Whenever that call does not return -1, it copies all `RowsPerStrip` rows of the buffer into the image. libtiff\u0027s JPEG codec only warns when the JPEG embedded in a strip has fewer rows than the strip, and Pillow silences libtiff warnings. The codec decodes the rows that exist and still returns the full strip size, so the untouched remainder is copied out as pixels. libtiff\u0027s Group 4 fax codec behaves the same way for a stream that ends early.\n\nThe attached reproducer builds a 256\u00d7256 TIFF whose single strip or tile is a 256\u00d78 JPEG. Before loading it, the script frees buffers filled with `b\"LEAK\"`. It then finds 15,872 copies of `LEAK` in rows 8\u2013255 of the decoded image (the same freed chunk was reused in 500 of 500 runs). Under glibc\u0027s `MALLOC_PERTURB_`, those rows are entirely the allocator\u0027s fill byte. A well-formed control file decodes correctly in both cases.\n\nThis is a read of uninitialised heap memory, not memory corruption. Each strip can disclose up to width \u00d7 `RowsPerStrip` bytes, and what comes back depends on the allocator\u0027s state at the time. The strip path was introduced in e91b851fdc1c (\"Add reading old-JPEG compressed TIFFs\", first released in Pillow 6.0.0). The tile path has had the same pattern since f0436a4ddc95 (Pillow 5.3.0).\n\n## Details\n\n`src/libImaging/TiffDecode.c` decodes compressed TIFFs through libtiff into a strip\n(or tile) buffer that it `realloc()`s to `TIFFStripSize()` bytes and never initialises, and\nthen copies all `RowsPerStrip` rows of that buffer into the image whenever\n`TIFFReadEncodedStrip()` does not return -1. libtiff\u0027s JPEG codec does not fail when the\nJPEG stream inside a strip has fewer rows than the strip: it decodes the rows that exist\nand returns the full strip size. The rows it did not write are whatever the heap held\nbefore, and Pillow returns them as pixels.\n\nA 478-byte file shows it: a classic little-endian TIFF, 256\u00d7256, `BitsPerSample=8`,\n`Compression=7`, `PhotometricInterpretation=1`, `RowsPerStrip=256`, one strip whose data\nis a baseline JPEG of 256\u00d7**8** pixels (as written by `Image.new(\"L\",(256,8),200).save(\u2026,\"JPEG\")`).\n`Image.open(BytesIO(data)).load()` succeeds with default settings (compressed TIFFs always\ntake the libtiff path). Rows 0\u20137 of the result are the JPEG content (value 200); the\nremaining 63488 bytes of `im.tobytes()` are heap garbage: run under glibc\u0027s\n`MALLOC_PERTURB_=1` they are all `0xFE`, under `MALLOC_PERTURB_=170` all `0x55` (the\nfresh-`malloc` fill byte), and in a process that has just freed buffers containing\n`b\"LEAK\"` they contain 15872 copies of `LEAK`.\n\nFeeding the same file to libtiff 4.5.0 directly confirms the library side:\n`TIFFReadEncodedStrip(t, 0, buf, 65536)` prints\n`JPEGPreDecode: Warning, Improper JPEG strip/tile size, expected 256x256, got 256x8.`,\nreturns 65536, and leaves 63488 of the 65536 buffer bytes untouched. Pillow installs\n`TIFFSetWarningHandler(NULL)` (`TiffDecode.c:682`), so the warning is not visible either.\n\nThe strip path:\n\n```c\n// src/libImaging/TiffDecode.c:552\n /* realloc to fit whole strip */\n /* malloc check above */\n new_data = realloc(state-\u003ebuffer, state-\u003ebytes); // state-\u003ebytes = TIFFStripSize()\n \u2026\n state-\u003ebuffer = new_data;\n\n for (; state-\u003ey \u003c state-\u003eysize; state-\u003ey += rows_per_strip) {\n \u2026\n if (TIFFReadEncodedStrip(\n tiff,\n TIFFComputeStrip(tiff, state-\u003ey, plane),\n (tdata_t)state-\u003ebuffer,\n strip_size\n ) == -1) {\n \u2026 return -1;\n }\n \u2026\n // iterate over each row in the strip and stuff data into image\n for (strip_row = 0;\n strip_row \u003c MIN((INT32)rows_per_strip, state-\u003eysize - state-\u003ey);\n strip_row++) {\n \u2026\n shuffler(\n (UINT8 *)im-\u003eimage[state-\u003ey + state-\u003eyoff + strip_row] +\n state-\u003exoff * im-\u003epixelsize,\n state-\u003ebuffer + strip_row * row_byte_size,\n state-\u003exsize\n );\n```\n\n`state-\u003ebuffer` arrives here as the one-row `calloc` made by `decode.c:230`\n(`(bits*xsize+7)/8` = 256 bytes for the example). The `realloc` to 65536 bytes hands back\na different, uninitialised chunk; nothing zeroes it. `TIFFReadEncodedStrip()` returns the\nnominal strip size on success, not the number of rows produced, and the only check is\n`== -1`, so the row loop unconditionally copies 256 rows \u00d7 256 bytes into `im-\u003eimage`\n(which itself is zeroed by `core.new`, so the garbage provably comes from `state-\u003ebuffer`).\n`_decodeTile()` has the same shape (`TiffDecode.c:448` `realloc` to `TIFFTileSize()`, then\n`tile_length` rows copied after each `TIFFReadTile()` at 460\u2013488).\n\nFor a well-formed file the JPEG inside the strip is 256\u00d7256, libtiff fills all 65536 bytes\nand the copy is correct. The malicious file differs only in the SOF height of the embedded\nJPEG; libtiff treats \"JPEG smaller than strip\" as a warning, clamps the row count to the\nJPEG height, and reports success.\n\nJPEG is not the only libtiff codec that succeeds on a short strip. `Fax4Decode`\n(`Compression=4`) returns success for a T.6 stream that ends early: a 133-byte 512\u00d7256\n1-bit TIFF whose strip is the Group 4 stream of a 512\u00d716 image loads without error,\nlibtiff writes 17 rows (1088 bytes) of the 16384-byte buffer\n(`Fax4Decode: Warning, Premature EOL at line 16`, return value 16384) and the other\n15296 bytes are again heap contents. LZW, Deflate, PackBits, Group 3 and CCITT RLE were\nchecked and do return -1 on short data, so Pillow raises `OSError` for those.\n\nThe strip path was introduced in `e91b851fdc1c` (\"Add reading old-JPEG compressed TIFFs\",\n2018-12-08), first released in Pillow 6.0.0, which replaced row-by-row `TIFFReadScanline()`\n(where libtiff errors on the first missing row) with the whole-strip `realloc()` and copy.\nThe tile path has had the same shape since it was added in `f0436a4ddc95` (2018-07-02,\nPillow 5.3.0).\n\n## Impact\n\nAny application that opens attacker-supplied images with Pillow in the default\nconfiguration and returns something derived from the pixels (thumbnail, preview, format\nconversion, OCR text) discloses freed heap memory of the worker process to the uploader:\neverything below the rows the embedded JPEG/G4 stream actually encodes, up to\n`ImageWidth \u00d7 RowsPerStrip \u00d7 SamplesPerPixel` bytes per strip and tens of MB per image\nwithin the default `MAX_IMAGE_PIXELS`. `load()` raises nothing, so the application has no\nsignal that the image is malformed. What comes back depends on allocator state; in a\nlong-running web worker it is typically recently freed request bodies, other users\u0027\ndecoded image buffers and Python object contents. There is no memory corruption; this is\na read of uninitialised (previously used) heap memory, analogous in effect to an\nout-of-bounds read that lands in pixels.\n\n## Reproducing\n\n`repro` is a short Python script that runs against the installed Pillow build with\ndefault settings: no rebuild, no sanitizer, no files written. It runs twice, once normally\nand once re-executing itself under glibc\u0027s `MALLOC_PERTURB_=170`, and the last line it\nprints is `BUG` or `OK`.\n\n**Input.** `tiff(jpeg_rows, tiled)` builds a little-endian TIFF in memory. The header\ndeclares a 256\u00d7256 8-bit greyscale image with `Compression=7` (JPEG), either as one strip\n(`RowsPerStrip=256`) or as one 256\u00d7256 tile (`TileWidth`/`TileLength`). The strip or tile\nis a baseline JPEG of 256\u00d7`jpeg_rows` pixels, all value 200, written by Pillow\u0027s own JPEG\nencoder. For each layout the script builds two files:\n\n- **Control:** `jpeg_rows=256`. This is a well-formed file, and libtiff fills the whole\n 64 KiB strip/tile.\n- **Crafted:** `jpeg_rows=8`, 478 bytes (strip) or 490 bytes (tile). The only difference\n is the embedded JPEG\u0027s height. libtiff decodes 8 rows (2048 bytes), warns\n `Improper JPEG strip/tile size` (Pillow silences the warning) and returns the full\n strip/tile size as success.\n\n**Steps.** Each file is opened (the script asserts it takes the `libtiff` decoder). Just\nbefore `im.load()` the script allocates and frees six 64 KiB `bytearray`s filled with\n`b\"LEAK\"`, which leaves freed heap chunks about the size of the buffer that\n`_decodeStrip()`/`_decodeTile()` is about to `realloc()`. For rows 8\u2013255 it then counts\ncopies of `LEAK` and bytes equal to `0x55` (glibc\u0027s fresh-`malloc` fill under\n`MALLOC_PERTURB_=170`). The files contain no `LEAK` bytes (the script asserts this), so\nany copy in the image came from freed heap memory. It reports `BUG` if a crafted file\nshows any `LEAK` in the normal pass, or rows 8\u2013255 entirely `0x55` in the perturbed pass.\n\n**Expected output on this tree:**\n\n```\n[normal ] strip well-formed (1222 B) rows 8-255: 0 x b\u0027LEAK\u0027, 0/63488 == 0x55, head=b\u0027\\xc8\\xc8\\xc8\\xc8\\xc8\\xc8\\xc8\\xc8\u0027\n[normal ] strip crafted ( 478 B) rows 8-255: 15872 x b\u0027LEAK\u0027, 0/63488 == 0x55, head=b\u0027LEAKLEAK\u0027\n[normal ] tiled well-formed (1234 B) rows 8-255: 0 x b\u0027LEAK\u0027, 0/63488 == 0x55, head=b\u0027\\xc8\\xc8\\xc8\\xc8\\xc8\\xc8\\xc8\\xc8\u0027\n[normal ] tiled crafted ( 490 B) rows 8-255: 15872 x b\u0027LEAK\u0027, 0/63488 == 0x55, head=b\u0027LEAKLEAK\u0027\n[perturb] strip well-formed (1222 B) rows 8-255: 0 x b\u0027LEAK\u0027, 0/63488 == 0x55, head=b\u0027\\xc8\\xc8\\xc8\\xc8\\xc8\\xc8\\xc8\\xc8\u0027\n[perturb] strip crafted ( 478 B) rows 8-255: 0 x b\u0027LEAK\u0027, 63488/63488 == 0x55, head=b\u0027UUUUUUUU\u0027\n[perturb] tiled well-formed (1234 B) rows 8-255: 0 x b\u0027LEAK\u0027, 0/63488 == 0x55, head=b\u0027\\xc8\\xc8\\xc8\\xc8\\xc8\\xc8\\xc8\\xc8\u0027\n[perturb] tiled crafted ( 490 B) rows 8-255: 0 x b\u0027LEAK\u0027, 63488/63488 == 0x55, head=b\u0027UUUUUUUU\u0027\nBUG\n```\n\n`im.load()` succeeds for every file. For the crafted files rows 8\u2013255 are the uninitialised\nstrip/tile buffer, copied as-is into the image. With the attached patch applied, rows 8\u2013255\nof the crafted files come back as `\\x00` bytes, with no `LEAK` and no `0x55`, and the\nscript ends with `OK`.\n\nThe `LEAK` count depends on where glibc places the buffer (the same freed chunk was reused\nin 500 of 500 runs here); the `MALLOC_PERTURB_` pass does not. The script covers the JPEG\ncodec only. The Group 4 variant in the Details section (`Compression=4`, a T.6 stream that\nends early) goes through the same `_decodeStrip()` copy, and the same fix covers it.\n\n## Suggested fix\n\nThe attached patch zeroes `state-\u003ebuffer` before each libtiff read in both loops of\n`src/libImaging/TiffDecode.c` \u2014 before `TIFFReadTile()` in `_decodeTile()` and before\n`TIFFReadEncodedStrip()` in `_decodeStrip()` \u2014 so rows a codec does not produce are\ndeterministic zeros rather than stale heap:\n\n```diff\n--- a/src/libImaging/TiffDecode.c\n+++ b/src/libImaging/TiffDecode.c\n@@ _decodeTile\n for (x = state-\u003exoff; x \u003c state-\u003exsize; x += tile_width) {\n+ memset(state-\u003ebuffer, 0, state-\u003ebytes);\n if (TIFFReadTile(tiff, (tdata_t)state-\u003ebuffer, x, y, 0, plane) == -1) {\n@@ _decodeStrip\n for (plane = 0; plane \u003c planes; plane++) {\n ImagingShuffler shuffler = unpackers[plane];\n+ memset(state-\u003ebuffer, 0, state-\u003ebytes);\n if (TIFFReadEncodedStrip(\n```\n\nA `memset` per strip/tile (rather than one `calloc` after the size is known) is needed\nbecause the same buffer is reused for every strip, and a short last strip would otherwise\nexpose the previous strip\u0027s rows \u2014 harmless for disclosure, but the per-read `memset`\nkeeps the behaviour uniform at the cost of one extra pass over the buffer. Promoting\nlibtiff warnings to errors via a warning handler is not a good alternative: both codecs\nonly warn (`Improper JPEG strip/tile size`, `Premature EOL`), but so do many legitimate\nfiles (unknown tags, bad tag counts), and the return value of `TIFFReadEncodedStrip()`\ncarries no row count to check against. Initialising the buffer covers every codec.\n`_decodeAsRGBA()` needs no change: `TIFFRGBAImageGet()` fills its whole raster, and JPEG\nfiles do not reach it (`JPEGCOLORMODE_RGB` sends them down the strip path).\n\nValid files decode exactly as before; rows a codec does not produce are now black instead\nof garbage, and nothing that previously loaded now fails. The patch also adds\n`test_jpeg_short_strip` to `Tests/test_file_libtiff.py`, parametrised over strip and tile,\nwhich builds the 256\u00d78-JPEG-in-256\u00d7256 file and asserts rows 8\u2013255 are zero. It is a\nregression guard for the fixed code rather than a reliable detector of the bug: in a fresh\npytest process the unfixed strip variant can pass because the new heap chunk happens to be\nzero (the tiled variant fails before the fix). With the patch, `Tests/test_file_libtiff.py`\nand `Tests/test_file_tiff.py` pass and the reproducer prints `OK`.\n\n## The patch\n\nZero the libtiff strip/tile buffer before each TIFFReadEncodedStrip/TIFFReadTile in TiffDecode.c so short strips do not expose uninitialised heap\n\nApplies to `src/libImaging/TiffDecode.c` at the commit above.\n\n```diff\ndiff --git a/Tests/test_file_libtiff.py b/Tests/test_file_libtiff.py\nindex 3d804ea4a..67bc96329 100644\n--- a/Tests/test_file_libtiff.py\n+++ b/Tests/test_file_libtiff.py\n@@ -1162,6 +1162,45 @@ class TestFileLibTiff(LibTiffTestCase):\n im.load()\n assert im.size == (950, 975)\n \n+ @pytest.mark.parametrize(\"tiled\", (False, True))\n+ def test_jpeg_short_strip(self, tiled: bool) -\u003e None:\n+ # The JPEG data in the strip/tile only contains 8 of the 256 rows that\n+ # RowsPerStrip/TileLength declare. libtiff decodes the rows that exist\n+ # and still reports success, so the remaining rows must be cleared\n+ # rather than left as uninitialised memory.\n+ jpeg = io.BytesIO()\n+ Image.new(\"L\", (256, 8), 200).save(jpeg, \"JPEG\")\n+ jpeg_data = jpeg.getvalue()\n+\n+ ifd = TiffImagePlugin.ImageFileDirectory_v2()\n+ ifd[256] = 256 # ImageWidth\n+ ifd[257] = 256 # ImageLength\n+ ifd[258] = 8 # BitsPerSample\n+ ifd[259] = 7 # Compression: JPEG\n+ ifd[262] = 1 # PhotometricInterpretation: BlackIsZero\n+ ifd[277] = 1 # SamplesPerPixel\n+ if tiled:\n+ ifd[322] = 256 # TileWidth\n+ ifd[323] = 256 # TileLength\n+ ifd[324] = 0 # TileOffsets\n+ ifd[325] = len(jpeg_data) # TileByteCounts\n+ # Point the tile data at the end of the IFD\n+ ifd[324] = 8 + len(ifd.tobytes(8))\n+ else:\n+ ifd[278] = 256 # RowsPerStrip\n+ ifd[STRIPOFFSETS] = 0 # Updated by tobytes() to follow the IFD\n+ ifd[279] = len(jpeg_data) # StripByteCounts\n+\n+ b = io.BytesIO()\n+ ifd.save(b)\n+ b.write(jpeg_data)\n+\n+ with Image.open(b) as im:\n+ assert im.tile[0][0] == \"libtiff\"\n+ im.load()\n+ assert im.crop((0, 0, 256, 8)).getextrema() == (200, 200)\n+ assert im.crop((0, 8, 256, 256)).getextrema() == (0, 0)\n+\n def test_orientation(self) -\u003e None:\n with Image.open(\"Tests/images/g4_orientation_1.tif\") as base_im:\n for i in range(2, 9):\ndiff --git a/src/libImaging/TiffDecode.c b/src/libImaging/TiffDecode.c\nindex 8a57c523d..d1d6bfbbb 100644\n--- a/src/libImaging/TiffDecode.c\n+++ b/src/libImaging/TiffDecode.c\n@@ -457,6 +457,11 @@ _decodeTile(\n for (plane = 0; plane \u003c planes; plane++) {\n ImagingShuffler shuffler = unpackers[plane];\n for (x = state-\u003exoff; x \u003c state-\u003exsize; x += tile_width) {\n+ // Some codecs (e.g. JPEG, Group 4) succeed on a tile that decodes\n+ // to fewer rows than the tile length, leaving the rest of the\n+ // buffer untouched. Clear it so that uninitialised memory is not\n+ // copied into the image.\n+ memset(state-\u003ebuffer, 0, state-\u003ebytes);\n if (TIFFReadTile(tiff, (tdata_t)state-\u003ebuffer, x, y, 0, plane) == -1) {\n TRACE((\"Decode Error, Tile at %dx%d\\n\", x, y));\n state-\u003eerrcode = IMAGING_CODEC_BROKEN;\n@@ -563,6 +568,11 @@ _decodeStrip(\n int plane;\n for (plane = 0; plane \u003c planes; plane++) {\n ImagingShuffler shuffler = unpackers[plane];\n+ // Some codecs (e.g. JPEG, Group 4) succeed on a strip that decodes\n+ // to fewer rows than RowsPerStrip, leaving the rest of the buffer\n+ // untouched. Clear it so that uninitialised memory is not copied\n+ // into the image.\n+ memset(state-\u003ebuffer, 0, state-\u003ebytes);\n if (TIFFReadEncodedStrip(\n tiff,\n TIFFComputeStrip(tiff, state-\u003ey, plane),\n```\n\n## The reproducer\n\n\u003cdetails\u003e\n\u003csummary\u003eReproducer \u2014 \u003ccode\u003erepro\u003c/code\u003e, 2,688 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 TiffDecode.c _decodeStrip/_decodeTile: strip/tile buffer is realloc()ed, never\n# initialised, and copied whole into the image even when libtiff\u0027s JPEG codec decoded\n# fewer rows than RowsPerStrip/TileLength. Two independent signals:\n# pass 1 (normal heap): seed freed 64 KiB chunks with b\"LEAK\" just before load() and\n# count copies of LEAK in the decoded pixels (file contains no such bytes);\n# pass 2 (same script re-run under glibc MALLOC_PERTURB_=170): fresh malloc memory is\n# 0x55, so rows that come back all-0x55 are provably uninitialised heap.\nimport gc, io, os, struct, subprocess, sys\nfrom PIL import Image\nW = H = 256; ROWS = 8\nperturbed = os.environ.get(\"MALLOC_PERTURB_\") == \"170\"\nif not perturbed:\n print(\"Pillow\", Image.__version__, Image.core.__file__)\n\ndef tiff(jpeg_rows, tiled):\n j = io.BytesIO(); Image.new(\"L\", (W, jpeg_rows), 200).save(j, \"JPEG\"); j = j.getvalue()\n tags = [(256,3,1,W), (257,3,1,H), (258,3,1,8), (259,3,1,7), (262,3,1,1), (277,3,1,1)]\n tags += ([(322,3,1,W), (323,3,1,H), (324,4,1,0), (325,4,1,len(j))] if tiled else\n [(273,4,1,0), (278,3,1,H), (279,4,1,len(j))])\n tags.sort(); off = 8 + 2 + 12*len(tags) + 4\n tags = [(t,ty,c, off if t in (273,324) else v) for t,ty,c,v in tags]\n ifd = struct.pack(\"\u003cH\", len(tags)) + b\"\".join(struct.pack(\"\u003cHHLL\", *t) for t in tags)\n return b\"II*\\0\" + struct.pack(\"\u003cL\", 8) + ifd + struct.pack(\"\u003cL\", 0) + j\n\nbug = False\nfor tiled in (False, True):\n for jpeg_rows, label in ((H, \"well-formed\"), (ROWS, \"crafted\")):\n data = tiff(jpeg_rows, tiled); assert b\"LEAK\" not in data\n im = Image.open(io.BytesIO(data)); assert im.tile[0][0] == \"libtiff\"\n junk = [bytearray(b\"LEAK\" * (W*H//4)) for _ in range(6)]; del junk; gc.collect()\n im.load() # no exception for either file\n below = im.tobytes()[W*ROWS:]\n n55, nleak = below.count(0x55), below.count(b\"LEAK\")\n print(f\"[{\u0027perturb\u0027 if perturbed else \u0027normal \u0027}] {\u0027tiled\u0027 if tiled else \u0027strip\u0027} \"\n f\"{label:11s} ({len(data):4d} B) rows {ROWS}-{H-1}: {nleak:5d} x b\u0027LEAK\u0027, \"\n f\"{n55:5d}/{len(below)} == 0x55, head={below[:8]!r}\")\n if jpeg_rows == ROWS and (nleak \u003e 0 or (perturbed and n55 == len(below))):\n bug = True\nif not perturbed:\n r = subprocess.run([sys.executable, sys.argv[0]], env={**os.environ, \"MALLOC_PERTURB_\": \"170\"},\n capture_output=True, text=True)\n lines = r.stdout.rstrip().split(\"\\n\")\n print(\"\\n\".join(lines[:-1])); sys.stderr.write(r.stderr)\n bug = bug or lines[-1] == \"BUG\"\nprint(\"BUG\" if bug else \"OK\")\n```\n\u003c/details\u003e\n\n---",
"id": "GHSA-q45j-58j2-45rg",
"modified": "2026-10-20T20:52:43Z",
"published": "2026-10-20T20:52:43Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/python-pillow/Pillow/security/advisories/GHSA-q45j-58j2-45rg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-112897"
},
{
"type": "WEB",
"url": "https://github.com/python-pillow/Pillow/commit/1d4773e6cea0c4a2814e6d4cdc099bbcf56da6ce"
},
{
"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:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Pillow: TiffDecode returns uninitialized memory as pixels for short JPEG strips"
}
GHSA-Q46P-VH9H-4P2C
Vulnerability from github – Published: 2025-07-25 18:30 – Updated: 2025-07-25 18:30In high traffic environments, a Silicon Labs OpenThread RCP (see impacted versions) fails to clear the SPI transmit buffer and may send a corrupt packet over SPI to its host, causing the host to reset the RCP which results in a denial of service.
{
"affected": [],
"aliases": [
"CVE-2025-2329"
],
"database_specific": {
"cwe_ids": [
"CWE-908"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-25T16:15:28Z",
"severity": "MODERATE"
},
"details": "In high traffic environments, a Silicon Labs OpenThread RCP (see impacted versions) fails to clear the SPI transmit buffer and may send a corrupt packet over SPI to its host,\u00a0 causing the host to reset the RCP which results in a denial of service.",
"id": "GHSA-q46p-vh9h-4p2c",
"modified": "2025-07-25T18:30:38Z",
"published": "2025-07-25T18:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-2329"
},
{
"type": "WEB",
"url": "https://community.silabs.com/069Vm00000SNyueIAD"
},
{
"type": "WEB",
"url": "https://github.com/SiliconLabs/gecko_sdk/releases"
},
{
"type": "WEB",
"url": "https://github.com/SiliconLabs/simplicity_sdk/releases"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/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-Q529-WQG7-HJ25
Vulnerability from github – Published: 2025-06-18 12:30 – Updated: 2025-11-17 21:31In the Linux kernel, the following vulnerability has been resolved:
wifi: wil6210: debugfs: fix uninitialized variable use in wil_write_file_wmi()
Commit 7a4836560a61 changes simple_write_to_buffer() with memdup_user() but it forgets to change the value to be returned that came from simple_write_to_buffer() call. It results in the following warning:
warning: variable 'rc' is uninitialized when used here [-Wuninitialized] return rc; ^~
Remove rc variable and just return the passed in length if the memdup_user() succeeds.
{
"affected": [],
"aliases": [
"CVE-2022-50165"
],
"database_specific": {
"cwe_ids": [
"CWE-908"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-18T11:15:46Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: wil6210: debugfs: fix uninitialized variable use in `wil_write_file_wmi()`\n\nCommit 7a4836560a61 changes simple_write_to_buffer() with memdup_user()\nbut it forgets to change the value to be returned that came from\nsimple_write_to_buffer() call. It results in the following warning:\n\n warning: variable \u0027rc\u0027 is uninitialized when used here [-Wuninitialized]\n return rc;\n ^~\n\nRemove rc variable and just return the passed in length if the\nmemdup_user() succeeds.",
"id": "GHSA-q529-wqg7-hj25",
"modified": "2025-11-17T21:31:18Z",
"published": "2025-06-18T12:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50165"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/409bd72e544fdf4809ea0dac337bb5a1f11a25a9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/52b11a48cf073e0aab923ae809a765d756cecf13"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/689e5caf63e99e15d2f485ec297c1bf9243e0e28"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6c5fee83bdbeffe8d607d1ab125122a75f40bd1a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b13c84e877d7a3095bacb14665db304b2c00e95f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c9fde3a44da566d8929070ab6bda4f0dfa9955d0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d4742c886043b69d2d058bfde3998ef333b66595"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d578e0af3a003736f6c440188b156483d451b329"
}
],
"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-Q6H5-3VM3-9H46
Vulnerability from github – Published: 2024-05-22 09:31 – Updated: 2025-09-24 03:30In the Linux kernel, the following vulnerability has been resolved:
netfilter: xt_IDLETIMER: fix panic that occurs when timer_type has garbage value
Currently, when the rule related to IDLETIMER is added, idletimer_tg timer structure is initialized by kmalloc on executing idletimer_tg_create function. However, in this process timer->timer_type is not defined to a specific value. Thus, timer->timer_type has garbage value and it occurs kernel panic. So, this commit fixes the panic by initializing timer->timer_type using kzalloc instead of kmalloc.
Test commands: # iptables -A OUTPUT -j IDLETIMER --timeout 1 --label test $ cat /sys/class/xt_idletimer/timers/test Killed
Splat looks like: BUG: KASAN: user-memory-access in alarm_expires_remaining+0x49/0x70 Read of size 8 at addr 0000002e8c7bc4c8 by task cat/917 CPU: 12 PID: 917 Comm: cat Not tainted 5.14.0+ #3 79940a339f71eb14fc81aee1757a20d5bf13eb0e Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: dump_stack_lvl+0x6e/0x9c kasan_report.cold+0x112/0x117 ? alarm_expires_remaining+0x49/0x70 __asan_load8+0x86/0xb0 alarm_expires_remaining+0x49/0x70 idletimer_tg_show+0xe5/0x19b [xt_IDLETIMER 11219304af9316a21bee5ba9d58f76a6b9bccc6d] dev_attr_show+0x3c/0x60 sysfs_kf_seq_show+0x11d/0x1f0 ? device_remove_bin_file+0x20/0x20 kernfs_seq_show+0xa4/0xb0 seq_read_iter+0x29c/0x750 kernfs_fop_read_iter+0x25a/0x2c0 ? __fsnotify_parent+0x3d1/0x570 ? iov_iter_init+0x70/0x90 new_sync_read+0x2a7/0x3d0 ? __x64_sys_llseek+0x230/0x230 ? rw_verify_area+0x81/0x150 vfs_read+0x17b/0x240 ksys_read+0xd9/0x180 ? vfs_write+0x460/0x460 ? do_syscall_64+0x16/0xc0 ? lockdep_hardirqs_on+0x79/0x120 __x64_sys_read+0x43/0x50 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f0cdc819142 Code: c0 e9 c2 fe ff ff 50 48 8d 3d 3a ca 0a 00 e8 f5 19 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24 RSP: 002b:00007fff28eee5b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f0cdc819142 RDX: 0000000000020000 RSI: 00007f0cdc032000 RDI: 0000000000000003 RBP: 00007f0cdc032000 R08: 00007f0cdc031010 R09: 0000000000000000 R10: 0000000000000022 R11: 0000000000000246 R12: 00005607e9ee31f0 R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000
{
"affected": [],
"aliases": [
"CVE-2021-47451"
],
"database_specific": {
"cwe_ids": [
"CWE-908"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-22T07:15:10Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: xt_IDLETIMER: fix panic that occurs when timer_type has garbage value\n\nCurrently, when the rule related to IDLETIMER is added, idletimer_tg timer\nstructure is initialized by kmalloc on executing idletimer_tg_create\nfunction. However, in this process timer-\u003etimer_type is not defined to\na specific value. Thus, timer-\u003etimer_type has garbage value and it occurs\nkernel panic. So, this commit fixes the panic by initializing\ntimer-\u003etimer_type using kzalloc instead of kmalloc.\n\nTest commands:\n # iptables -A OUTPUT -j IDLETIMER --timeout 1 --label test\n $ cat /sys/class/xt_idletimer/timers/test\n Killed\n\nSplat looks like:\n BUG: KASAN: user-memory-access in alarm_expires_remaining+0x49/0x70\n Read of size 8 at addr 0000002e8c7bc4c8 by task cat/917\n CPU: 12 PID: 917 Comm: cat Not tainted 5.14.0+ #3 79940a339f71eb14fc81aee1757a20d5bf13eb0e\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014\n Call Trace:\n dump_stack_lvl+0x6e/0x9c\n kasan_report.cold+0x112/0x117\n ? alarm_expires_remaining+0x49/0x70\n __asan_load8+0x86/0xb0\n alarm_expires_remaining+0x49/0x70\n idletimer_tg_show+0xe5/0x19b [xt_IDLETIMER 11219304af9316a21bee5ba9d58f76a6b9bccc6d]\n dev_attr_show+0x3c/0x60\n sysfs_kf_seq_show+0x11d/0x1f0\n ? device_remove_bin_file+0x20/0x20\n kernfs_seq_show+0xa4/0xb0\n seq_read_iter+0x29c/0x750\n kernfs_fop_read_iter+0x25a/0x2c0\n ? __fsnotify_parent+0x3d1/0x570\n ? iov_iter_init+0x70/0x90\n new_sync_read+0x2a7/0x3d0\n ? __x64_sys_llseek+0x230/0x230\n ? rw_verify_area+0x81/0x150\n vfs_read+0x17b/0x240\n ksys_read+0xd9/0x180\n ? vfs_write+0x460/0x460\n ? do_syscall_64+0x16/0xc0\n ? lockdep_hardirqs_on+0x79/0x120\n __x64_sys_read+0x43/0x50\n do_syscall_64+0x3b/0xc0\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n RIP: 0033:0x7f0cdc819142\n Code: c0 e9 c2 fe ff ff 50 48 8d 3d 3a ca 0a 00 e8 f5 19 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 \u003c48\u003e 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24\n RSP: 002b:00007fff28eee5b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000\n RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f0cdc819142\n RDX: 0000000000020000 RSI: 00007f0cdc032000 RDI: 0000000000000003\n RBP: 00007f0cdc032000 R08: 00007f0cdc031010 R09: 0000000000000000\n R10: 0000000000000022 R11: 0000000000000246 R12: 00005607e9ee31f0\n R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000",
"id": "GHSA-q6h5-3vm3-9h46",
"modified": "2025-09-24T03:30:25Z",
"published": "2024-05-22T09:31:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47451"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2a670c323055282c9b72794a491d53cef86bbeaf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/902c0b1887522a099aa4e1e6b4b476c2fe5dd13e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cae7cab804c943d723d52724a3aeb07a3f4a2650"
}
],
"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-Q7CG-9VQH-8MC2
Vulnerability from github – Published: 2024-11-19 03:31 – Updated: 2026-05-12 15:30In the Linux kernel, the following vulnerability has been resolved:
sctp: properly validate chunk size in sctp_sf_ootb()
A size validation fix similar to that in Commit 50619dbf8db7 ("sctp: add size validation when walking chunks") is also required in sctp_sf_ootb() to address a crash reported by syzbot:
BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233
{
"affected": [],
"aliases": [
"CVE-2024-50299"
],
"database_specific": {
"cwe_ids": [
"CWE-908"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-19T02:16:32Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: properly validate chunk size in sctp_sf_ootb()\n\nA size validation fix similar to that in Commit 50619dbf8db7 (\"sctp: add\nsize validation when walking chunks\") is also required in sctp_sf_ootb()\nto address a crash reported by syzbot:\n\n BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712\n sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712\n sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166\n sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407\n sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88\n sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243\n sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159\n ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205\n ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233",
"id": "GHSA-q7cg-9vqh-8mc2",
"modified": "2026-05-12T15:30:41Z",
"published": "2024-11-19T03:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50299"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-355557.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-398330.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0ead60804b64f5bd6999eec88e503c6a1a242d41"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/40b283ba76665437bc2ac72079c51b57b25bff9e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/67b9a278b80f71ec62091ded97c6bcbea33b5ec3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8820d2d6589f62ee5514793fff9b50c9f8101182"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9b5d42aeaf1a52f73b003a33da6deef7df34685f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a758aa6a773bb872196bcc3173171ef8996bddf0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bf9bff13225baf5f658577f7d985fc4933d79527"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d3fb3cc83cf313e4f87063ce0f3fea76b071567b"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.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-Q85F-69Q7-55H2
Vulnerability from github – Published: 2022-02-09 23:26 – Updated: 2024-11-13 22:47Impact
The implementation of AssignOp can result in copying unitialized data to a new tensor. This later results in undefined behavior.
The implementation has a check that the left hand side of the assignment is initialized (to minimize number of allocations), but does not check that the right hand side is also initialized.
Patches
We have patched the issue in GitHub commit ef1d027be116f25e25bb94a60da491c2cf55bd0b.
The fix will be included in TensorFlow 2.8.0. We will also cherrypick this commit on TensorFlow 2.7.1, TensorFlow 2.6.3, and TensorFlow 2.5.3, as these are also affected and still in supported range.
For more information
Please consult our security guide for more information regarding the security model and how to contact us with issues and questions.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.5.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "2.6.0"
},
{
"fixed": "2.6.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "2.7.0"
},
{
"fixed": "2.7.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"2.7.0"
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.5.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.6.0"
},
{
"fixed": "2.6.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.7.0"
},
{
"fixed": "2.7.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"2.7.0"
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.5.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.6.0"
},
{
"fixed": "2.6.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.7.0"
},
{
"fixed": "2.7.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"2.7.0"
]
}
],
"aliases": [
"CVE-2022-23573"
],
"database_specific": {
"cwe_ids": [
"CWE-908"
],
"github_reviewed": true,
"github_reviewed_at": "2022-02-04T19:03:53Z",
"nvd_published_at": "2022-02-04T23:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\nThe [implementation of `AssignOp`](https://github.com/tensorflow/tensorflow/blob/a1320ec1eac186da1d03f033109191f715b2b130/tensorflow/core/kernels/assign_op.h#L30-L143) can result in copying unitialized data to a new tensor. This later results in undefined behavior.\n\nThe implementation has a check that the left hand side of the assignment is initialized (to minimize number of allocations), but does not check that the right hand side is also initialized.\n \n### Patches\nWe have patched the issue in GitHub commit [ef1d027be116f25e25bb94a60da491c2cf55bd0b](https://github.com/tensorflow/tensorflow/commit/ef1d027be116f25e25bb94a60da491c2cf55bd0b).\n \nThe fix will be included in TensorFlow 2.8.0. We will also cherrypick this commit on TensorFlow 2.7.1, TensorFlow 2.6.3, and TensorFlow 2.5.3, as these are also affected and still in supported range.\n\n### For more information\nPlease consult [our security guide](https://github.com/tensorflow/tensorflow/blob/master/SECURITY.md) for more information regarding the security model and how to contact us with issues and questions.\n",
"id": "GHSA-q85f-69q7-55h2",
"modified": "2024-11-13T22:47:22Z",
"published": "2022-02-09T23:26:50Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tensorflow/tensorflow/security/advisories/GHSA-q85f-69q7-55h2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23573"
},
{
"type": "WEB",
"url": "https://github.com/tensorflow/tensorflow/commit/ef1d027be116f25e25bb94a60da491c2cf55bd0b"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-cpu/PYSEC-2022-82.yaml"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-gpu/PYSEC-2022-137.yaml"
},
{
"type": "WEB",
"url": "https://github.com/tensorflow/tensorflow"
},
{
"type": "WEB",
"url": "https://github.com/tensorflow/tensorflow/blob/a1320ec1eac186da1d03f033109191f715b2b130/tensorflow/core/kernels/assign_op.h#L30-L143"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Uninitialized variable access in Tensorflow"
}
GHSA-Q873-78WM-C7GV
Vulnerability from github – Published: 2022-05-11 00:01 – Updated: 2022-05-18 00:00In private_handle_t of mali_gralloc_buffer.h, there is a possible information disclosure due to uninitialized data. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-213170715References: N/A
{
"affected": [],
"aliases": [
"CVE-2022-20119"
],
"database_specific": {
"cwe_ids": [
"CWE-908"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-05-10T21:15:00Z",
"severity": "MODERATE"
},
"details": "In private_handle_t of mali_gralloc_buffer.h, there is a possible information disclosure due to uninitialized data. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-213170715References: N/A",
"id": "GHSA-q873-78wm-c7gv",
"modified": "2022-05-18T00:00:49Z",
"published": "2022-05-11T00:01:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20119"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2022-05-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-Q884-JCXW-49WR
Vulnerability from github – Published: 2024-06-19 15:30 – Updated: 2024-08-19 18:32In the Linux kernel, the following vulnerability has been resolved:
inet_diag: fix kernel-infoleak for UDP sockets
KMSAN reported a kernel-infoleak [1], that can exploited by unpriv users.
After analysis it turned out UDP was not initializing r->idiag_expires. Other users of inet_sk_diag_fill() might make the same mistake in the future, so fix this in inet_sk_diag_fill().
[1] BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline] BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:156 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670 instrument_copy_to_user include/linux/instrumented.h:121 [inline] copyout lib/iov_iter.c:156 [inline] _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670 copy_to_iter include/linux/uio.h:155 [inline] simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519 __skb_datagram_iter+0x2cb/0x1280 net/core/datagram.c:425 skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533 skb_copy_datagram_msg include/linux/skbuff.h:3657 [inline] netlink_recvmsg+0x660/0x1c60 net/netlink/af_netlink.c:1974 sock_recvmsg_nosec net/socket.c:944 [inline] sock_recvmsg net/socket.c:962 [inline] sock_read_iter+0x5a9/0x630 net/socket.c:1035 call_read_iter include/linux/fs.h:2156 [inline] new_sync_read fs/read_write.c:400 [inline] vfs_read+0x1631/0x1980 fs/read_write.c:481 ksys_read+0x28c/0x520 fs/read_write.c:619 __do_sys_read fs/read_write.c:629 [inline] __se_sys_read fs/read_write.c:627 [inline] __x64_sys_read+0xdb/0x120 fs/read_write.c:627 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae
Uninit was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1126 [inline] netlink_dump+0x3d5/0x16a0 net/netlink/af_netlink.c:2245 __netlink_dump_start+0xd1c/0xee0 net/netlink/af_netlink.c:2370 netlink_dump_start include/linux/netlink.h:254 [inline] inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1343 sock_diag_rcv_msg+0x24a/0x620 netlink_rcv_skb+0x447/0x800 net/netlink/af_netlink.c:2491 sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:276 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x1095/0x1360 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x16f3/0x1870 net/netlink/af_netlink.c:1916 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg net/socket.c:724 [inline] sock_write_iter+0x594/0x690 net/socket.c:1057 do_iter_readv_writev+0xa7f/0xc70 do_iter_write+0x52c/0x1500 fs/read_write.c:851 vfs_writev fs/read_write.c:924 [inline] do_writev+0x63f/0xe30 fs/read_write.c:967 __do_sys_writev fs/read_write.c:1040 [inline] __se_sys_writev fs/read_write.c:1037 [inline] __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae
Bytes 68-71 of 312 are uninitialized Memory access of size 312 starts at ffff88812ab54000 Data copied to user address 0000000020001440
CPU: 1 PID: 6365 Comm: syz-executor801 Not tainted 5.16.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
{
"affected": [],
"aliases": [
"CVE-2021-47597"
],
"database_specific": {
"cwe_ids": [
"CWE-908"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-19T15:15:54Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ninet_diag: fix kernel-infoleak for UDP sockets\n\nKMSAN reported a kernel-infoleak [1], that can exploited\nby unpriv users.\n\nAfter analysis it turned out UDP was not initializing\nr-\u003eidiag_expires. Other users of inet_sk_diag_fill()\nmight make the same mistake in the future, so fix this\nin inet_sk_diag_fill().\n\n[1]\nBUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline]\nBUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:156 [inline]\nBUG: KMSAN: kernel-infoleak in _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670\n instrument_copy_to_user include/linux/instrumented.h:121 [inline]\n copyout lib/iov_iter.c:156 [inline]\n _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670\n copy_to_iter include/linux/uio.h:155 [inline]\n simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519\n __skb_datagram_iter+0x2cb/0x1280 net/core/datagram.c:425\n skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533\n skb_copy_datagram_msg include/linux/skbuff.h:3657 [inline]\n netlink_recvmsg+0x660/0x1c60 net/netlink/af_netlink.c:1974\n sock_recvmsg_nosec net/socket.c:944 [inline]\n sock_recvmsg net/socket.c:962 [inline]\n sock_read_iter+0x5a9/0x630 net/socket.c:1035\n call_read_iter include/linux/fs.h:2156 [inline]\n new_sync_read fs/read_write.c:400 [inline]\n vfs_read+0x1631/0x1980 fs/read_write.c:481\n ksys_read+0x28c/0x520 fs/read_write.c:619\n __do_sys_read fs/read_write.c:629 [inline]\n __se_sys_read fs/read_write.c:627 [inline]\n __x64_sys_read+0xdb/0x120 fs/read_write.c:627\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nUninit was created at:\n slab_post_alloc_hook mm/slab.h:524 [inline]\n slab_alloc_node mm/slub.c:3251 [inline]\n __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974\n kmalloc_reserve net/core/skbuff.c:354 [inline]\n __alloc_skb+0x545/0xf90 net/core/skbuff.c:426\n alloc_skb include/linux/skbuff.h:1126 [inline]\n netlink_dump+0x3d5/0x16a0 net/netlink/af_netlink.c:2245\n __netlink_dump_start+0xd1c/0xee0 net/netlink/af_netlink.c:2370\n netlink_dump_start include/linux/netlink.h:254 [inline]\n inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1343\n sock_diag_rcv_msg+0x24a/0x620\n netlink_rcv_skb+0x447/0x800 net/netlink/af_netlink.c:2491\n sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:276\n netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]\n netlink_unicast+0x1095/0x1360 net/netlink/af_netlink.c:1345\n netlink_sendmsg+0x16f3/0x1870 net/netlink/af_netlink.c:1916\n sock_sendmsg_nosec net/socket.c:704 [inline]\n sock_sendmsg net/socket.c:724 [inline]\n sock_write_iter+0x594/0x690 net/socket.c:1057\n do_iter_readv_writev+0xa7f/0xc70\n do_iter_write+0x52c/0x1500 fs/read_write.c:851\n vfs_writev fs/read_write.c:924 [inline]\n do_writev+0x63f/0xe30 fs/read_write.c:967\n __do_sys_writev fs/read_write.c:1040 [inline]\n __se_sys_writev fs/read_write.c:1037 [inline]\n __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nBytes 68-71 of 312 are uninitialized\nMemory access of size 312 starts at ffff88812ab54000\nData copied to user address 0000000020001440\n\nCPU: 1 PID: 6365 Comm: syz-executor801 Not tainted 5.16.0-rc3-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011",
"id": "GHSA-q884-jcxw-49wr",
"modified": "2024-08-19T18:32:03Z",
"published": "2024-06-19T15:30:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47597"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3a4f6dba1eb98101abc012ef968a8b10dac1ce50"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/71ddeac8cd1d217744a0e060ff520e147c9328d1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7b5596e531253ce84213d9daa7120b71c9d83198"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e5d28205bf1de7082d904ed277ceb2db2879e302"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-Q8J2-M6JW-5583
Vulnerability from github – Published: 2024-11-19 21:31 – Updated: 2024-11-20 18:32In BnAudioPolicyService::onTransact of AudioPolicyService.cpp, there is a possible information disclosure due to uninitialized data. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.
{
"affected": [],
"aliases": [
"CVE-2018-9346"
],
"database_specific": {
"cwe_ids": [
"CWE-908"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-19T19:15:06Z",
"severity": "MODERATE"
},
"details": "In BnAudioPolicyService::onTransact of AudioPolicyService.cpp, there is a possible information disclosure due to uninitialized data. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.",
"id": "GHSA-q8j2-m6jw-5583",
"modified": "2024-11-20T18:32:16Z",
"published": "2024-11-19T21:31:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-9346"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2018-06-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-Q8QV-35PX-5J77
Vulnerability from github – Published: 2024-04-17 12:32 – Updated: 2024-11-06 18:31In the Linux kernel, the following vulnerability has been resolved:
geneve: make sure to pull inner header in geneve_rx()
syzbot triggered a bug in geneve_rx() [1]
Issue is similar to the one I fixed in commit 8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()")
We have to save skb->network_header in a temporary variable in order to be able to recompute the network_header pointer after a pskb_inet_may_pull() call.
pskb_inet_may_pull() makes sure the needed headers are in skb->head.
[1] BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] BUG: KMSAN: uninit-value in geneve_rx drivers/net/geneve.c:279 [inline] BUG: KMSAN: uninit-value in geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391 IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] geneve_rx drivers/net/geneve.c:279 [inline] geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391 udp_queue_rcv_one_skb+0x1d39/0x1f20 net/ipv4/udp.c:2108 udp_queue_rcv_skb+0x6ae/0x6e0 net/ipv4/udp.c:2186 udp_unicast_rcv_skb+0x184/0x4b0 net/ipv4/udp.c:2346 __udp4_lib_rcv+0x1c6b/0x3010 net/ipv4/udp.c:2422 udp_rcv+0x7d/0xa0 net/ipv4/udp.c:2604 ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:461 [inline] ip_rcv_finish net/ipv4/ip_input.c:449 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569 __netif_receive_skb_one_core net/core/dev.c:5534 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648 process_backlog+0x480/0x8b0 net/core/dev.c:5976 __napi_poll+0xe3/0x980 net/core/dev.c:6576 napi_poll net/core/dev.c:6645 [inline] net_rx_action+0x8b8/0x1870 net/core/dev.c:6778 __do_softirq+0x1b7/0x7c5 kernel/softirq.c:553 do_softirq+0x9a/0xf0 kernel/softirq.c:454 __local_bh_enable_ip+0x9b/0xa0 kernel/softirq.c:381 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:820 [inline] __dev_queue_xmit+0x2768/0x51c0 net/core/dev.c:4378 dev_queue_xmit include/linux/netdevice.h:3171 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at: slab_post_alloc_hook mm/slub.c:3819 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_node+0x5cb/0xbc0 mm/slub.c:3903 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x352/0x790 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1296 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6394 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2783 packet_alloc_skb net/packet/af_packet.c:2930 [inline] packet_snd net/packet/af_packet.c:3024 [inline] packet_sendmsg+0x70c2/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
{
"affected": [],
"aliases": [
"CVE-2024-26857"
],
"database_specific": {
"cwe_ids": [
"CWE-908"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-17T11:15:08Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ngeneve: make sure to pull inner header in geneve_rx()\n\nsyzbot triggered a bug in geneve_rx() [1]\n\nIssue is similar to the one I fixed in commit 8d975c15c0cd\n(\"ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()\")\n\nWe have to save skb-\u003enetwork_header in a temporary variable\nin order to be able to recompute the network_header pointer\nafter a pskb_inet_may_pull() call.\n\npskb_inet_may_pull() makes sure the needed headers are in skb-\u003ehead.\n\n[1]\nBUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]\n BUG: KMSAN: uninit-value in geneve_rx drivers/net/geneve.c:279 [inline]\n BUG: KMSAN: uninit-value in geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391\n IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]\n geneve_rx drivers/net/geneve.c:279 [inline]\n geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391\n udp_queue_rcv_one_skb+0x1d39/0x1f20 net/ipv4/udp.c:2108\n udp_queue_rcv_skb+0x6ae/0x6e0 net/ipv4/udp.c:2186\n udp_unicast_rcv_skb+0x184/0x4b0 net/ipv4/udp.c:2346\n __udp4_lib_rcv+0x1c6b/0x3010 net/ipv4/udp.c:2422\n udp_rcv+0x7d/0xa0 net/ipv4/udp.c:2604\n ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205\n ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254\n dst_input include/net/dst.h:461 [inline]\n ip_rcv_finish net/ipv4/ip_input.c:449 [inline]\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569\n __netif_receive_skb_one_core net/core/dev.c:5534 [inline]\n __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648\n process_backlog+0x480/0x8b0 net/core/dev.c:5976\n __napi_poll+0xe3/0x980 net/core/dev.c:6576\n napi_poll net/core/dev.c:6645 [inline]\n net_rx_action+0x8b8/0x1870 net/core/dev.c:6778\n __do_softirq+0x1b7/0x7c5 kernel/softirq.c:553\n do_softirq+0x9a/0xf0 kernel/softirq.c:454\n __local_bh_enable_ip+0x9b/0xa0 kernel/softirq.c:381\n local_bh_enable include/linux/bottom_half.h:33 [inline]\n rcu_read_unlock_bh include/linux/rcupdate.h:820 [inline]\n __dev_queue_xmit+0x2768/0x51c0 net/core/dev.c:4378\n dev_queue_xmit include/linux/netdevice.h:3171 [inline]\n packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276\n packet_snd net/packet/af_packet.c:3081 [inline]\n packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n __sys_sendto+0x735/0xa10 net/socket.c:2191\n __do_sys_sendto net/socket.c:2203 [inline]\n __se_sys_sendto net/socket.c:2199 [inline]\n __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\n\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:3819 [inline]\n slab_alloc_node mm/slub.c:3860 [inline]\n kmem_cache_alloc_node+0x5cb/0xbc0 mm/slub.c:3903\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560\n __alloc_skb+0x352/0x790 net/core/skbuff.c:651\n alloc_skb include/linux/skbuff.h:1296 [inline]\n alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6394\n sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2783\n packet_alloc_skb net/packet/af_packet.c:2930 [inline]\n packet_snd net/packet/af_packet.c:3024 [inline]\n packet_sendmsg+0x70c2/0x9f10 net/packet/af_packet.c:3113\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n __sys_sendto+0x735/0xa10 net/socket.c:2191\n __do_sys_sendto net/socket.c:2203 [inline]\n __se_sys_sendto net/socket.c:2199 [inline]\n __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b",
"id": "GHSA-q8qv-35px-5j77",
"modified": "2024-11-06T18:31:04Z",
"published": "2024-04-17T12:32:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26857"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/048e16dee1fc609c1c85072ccd70bfd4b5fef6ca"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0ece581d2a66e8e488c0d3b3e7b5760dbbfdbdd5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1ca1ba465e55b9460e4e75dec9fff31e708fec74"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/59d2a4076983303f324557a114cfd5c32e1f6b29"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c0b22568a9d8384fd000cc49acb8f74bde40d1b5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c7137900691f5692fe3de54566ea7b30bb35d66c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e431c3227864b5646601c97f5f898d99472f2914"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e77e0b0f2a11735c64b105edaee54d6344faca8a"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.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"
}
]
}
Mitigation
Explicitly initialize the resource before use. If this is performed through an API function or standard procedure, follow all required steps.
Mitigation
Pay close attention to complex conditionals that affect initialization, since some branches might not perform the initialization.
Mitigation
Avoid race conditions (CWE-362) during initialization routines.
Mitigation
Run or compile the product with settings that generate warnings about uninitialized variables or data.
No CAPEC attack patterns related to this CWE.