NewsThe Register — Security
Debian's latest kernel security update has 1,313 reasons to patch
Teaser from the source
AI-assisted bug hunting adds to maintainers' workload, while broad CVE rules help explain the sprawling tally
This is the RSS-feed teaser. Read the full article at the original source.
Read at The Register — SecurityMore on Debian's
Other advisories
- Not ratedosv:ECHO-a40f-fcbc-6816Out-of-bounds write of one or two bytes when the printf builtin (and echo %b) converts a \u or \U Unicode escape into a multi-byte sequence. dash 0.5.12 has no \u or \U escapes. conv_escape() in src/bltin/printf.c handles only \\ \a \b \f \n \r \t \v and octal escapes; Debian's patch 0008-Support-e-in-echo-and-printf-builtins adds \e and nothing else. The Unicode-escape conversion arrived with upstream's "dollar single quote" work and was first released in dash 0.5.13. Trixie ships 0.5.12-12. MUST re-evaluate if trixie moves dash to 0.5.13 or later.
- Not ratedosv:ECHO-1fcb-1955-3c69NULL pointer write in the wget applet's -T/--timeout handling (networking/wget.c): getopt32() is handed NULL as the -T storage only when busybox is built with CONFIG_WGET but WITHOUT CONFIG_FEATURE_WGET_TIMEOUT ("IF_NOT_FEATURE_WGET_TIMEOUT(NULL)"). Every busybox Echo ships is built from Debian's own configs, where that combination never occurs: debian/config/pkg/deb and debian/config/pkg/static (busybox, busybox-static, busybox-syslogd, udhcpc, udhcpd) set CONFIG_FEATURE_WGET_TIMEOUT=y, so -T is stored in G.timeout_seconds, and debian/config/pkg/udeb does not build wget at all. Verified on 1:1.38.0-3: a build from debian/config/pkg/deb and Debian's busybox and busybox-static binaries answer "wget -T 5" and "wget --timeout 5" normally, while the same tree with only FEATURE_WGET_TIMEOUT turned off segfaults on "wget -T 5". The cited "patch" 83a40bf is a commit in a third-party fork, not in upstream busybox, and bundles unrelated applet changes. Debian rates the CVE unimportant ("crash in CLI tool, no security impact").
- Not ratedosv:ECHO-2327-9760-e268Claimed out-of-bounds write in dlx_rtype_to_howto() (bfd/elf32-dlx.c), reached from elf32_dlx_info_to_howto_rel() via the relocation type of a crafted ELF/DLX object. The DLX backend is not built. dlx_elf32_be_vec is selected only by the dlx-*-elf target triple (bfd/config.bfd), and that vec is the sole trigger for compiling elf32-dlx.lo (bfd/configure.ac); debian/rules passes an explicit per-architecture --enable-targets list and never --enable-targets=all. Verified against the shipped amd64 and arm64 debs: libbfd exports no dlx symbols, `objdump -b elf32-dlx` returns "invalid bfd target", `ld -m elf32dlx` is an unrecognised emulation, and a crafted EM_DLX (0x5aa5) object carrying relocation types past the end of the howto table is claimed by the generic elf32-big backend, which reports "architecture: UNKNOWN!" and every relocation as UNKNOWN. The function is never entered. Note that readelf prints DLX machine and relocation names from its own tables, independent of BFD, so its output is not evidence of the backend being present. Upstream also rejects the finding on its merits, even with DLX enabled. On the Red Hat bug that Debian's tracker carries as its only reference, maintainer Andrew Burgess concludes "I don't believe that this is actually a bug": DLX relocation types are a contiguous 0-9, not the non-contiguous space with extended types at 0x10000+ that the advisory describes; dlx_rtype_to_howto() already rejects r_type >= R_DLX_max (10); and types 6-9 have their own case arms, so the indexed access can only ever reach 0-5 of the 6-entry dlx_elf_howto_table. Patrick Monnerat adds that the advisory claims an out-of-bounds write while the procedure performs no indexed write at all. Both observations hold against the 2.45.50.20251201 source. Debian marks it unimportant (binutils not covered by security support) and ships no fix in any suite including forky/sid, so there is nothing to bump.
- Not ratedosv:ECHO-f2c1-328c-2bc2Vulnerability is in libavfilter/vf_quirc.c (QR decode via libquirc). Debian's ffmpeg package does not enable --enable-libquirc (default off; not present in debian/rules CONFIG), so the quirc filter is not built into our binary. Refs: - https://security-tracker.debian.org/tracker/CVE-2026-66041 - https://github.com/FFmpeg/FFmpeg/commit/4da9812e25894fb51d62a8875cfa8eb39b5e20f5 details: | Upstream fix resizes quirc buffers when input size changes. Clean upstream patch applies to the source tree, but the filter is not compiled in. If --enable-libquirc is ever added to debian/rules, convert this to a real PATCH_TYPE_UPSTREAM_PATCH entry.
- Not ratedosv:ECHO-a7ed-bfec-5fe3Array index error in gd_gif_in.c in the bundled GD graphics library (libgd before 2.0.35), reached via the GIF reader (gdImageCreateFromGif). libwmf carries its own copy of GD under src/extra/gd and compiles it (Debian does not build-depend on libgd-dev, so LIBWMF_OPT_SYS_GD is off), but that copy ships no GIF reader at all: there is no gd_gif_in.c/gd_gif_out.c and libgd_la_SOURCES in src/extra/gd/Makefile.am compiles no GIF source. libwmf uses GD only as a rasterization/output backend and never decodes GIF input. The vulnerable code is not present or reachable in this package; scanners flag it only via Debian's stale source-package match (trixie is "unimportant / unfixed" while standalone libgd2 is fixed).
- Not ratedosv:ECHO-0435-d140-fc4aBuffer overflow/over-read in _gdGetColors (gd_gd.c) reached via the GD-file reader (gdImageCreateFromGd) when colorsTotal is not validated (libgd 2.x / PHP before 5.3.1). libwmf uses its bundled GD only as an output backend and exposes no API that decodes an untrusted .gd file, so the vulnerable reader path is never invoked. Additionally the upstream validation is already present in this trixie source: _gdGetColors in src/extra/gd/gd_gd.c rejects colorsTotal > gdMaxColors, and the non-2x branch reads colorsTotal as a single byte (<= 255 < gdMaxColors). Not reachable and already remediated in source; scanners flag it only via Debian's stale source-package match (trixie "unimportant / unfixed"; standalone libgd2 is fixed).
- Not ratedosv:ECHO-f542-a708-8974Heap buffer overflow in libvpx. Debian's firefox-esr links against the system libvpx (libvpx9), not the bundled copy in the source tree. The system libvpx in trixie (1.15.0-2.1+deb13u1) already includes the fix via DSA-6143-1. The Debian security tracker even notes: "Firefox, Firefox ESR and Thunderbird use the system libvpx library". https://security-tracker.debian.org/tracker/CVE-2026-2447
- Not ratedosv:ECHO-c437-171f-6a8aHeap buffer overflow in vp8 encoding in libvpx. Same as CVE-2026-2447 — Debian's firefox-esr uses the system libvpx, not the bundled copy. The system libvpx in trixie is already patched. https://security-tracker.debian.org/tracker/CVE-2023-5217
ID