Vulnerabilidades de la pila Sistemas operativos · Página 46

Furnace through 0.6.8.3 Out-of-Bounds Read via FamiTracker Module Import

Furnace through 0.6.8.3 contains an out-of-bounds heap read vulnerability in DivEngine::loadFTM() in src/engine/fileOps/ftm.cpp, triggered by an unbounded DPCM note count during FamiTracker module import. Attackers can craft a .ftm, .dnm or 0CC/E-FamiTracker module with a 2A03 instrument note count above 120 to read past the noteMap array and crash Furnace when opened.

libfvde through 20260923 Heap Out-of-Bounds Read via libfvde_encrypted_metadata_read_type_0x001a

libfvde through 20260923 contains a heap out-of-bounds read vulnerability in libfvde_encrypted_metadata_read_type_0x001a() caused by an unbounded strlen on embedded XML plist data. Attackers can supply a crafted FileVault 2 volume with non-NUL-terminated plist data, causing libfvde_volume_open() to read past the heap block buffer.

libfvde through 20260923 Heap Out-of-Bounds Read via libfvde_encrypted_metadata_read_type_0x0024

libfvde through 20260923 contains a heap out-of-bounds read vulnerability in libfvde_encrypted_metadata_read_type_0x0024() because xml_plist_data_size is not checked against the source metadata block. Attackers can supply a crafted FileVault 2 Core Storage volume that makes libfvde_volume_open() copy past the heap block buffer, crashing the application.

gbsplay through 0.0.103 Heap Out-of-Bounds Read via vgm_open in gbs.c

gbsplay through 0.0.103 contains a heap out-of-bounds read vulnerability in vgm_open() in gbs.c that walks the VGM command stream without bounds checks. Attackers can supply a crafted VGM file with wait opcodes and no 0x66 terminator to read past the heap buffer and crash the player.

gbsplay through 0.0.103 Heap Out-of-Bounds Read via gbr_open GBR Title

Gbsplay through 0.0.103 contains a heap out-of-bounds read vulnerability in gbr_open() in gbs.c that fails to verify file length before scanning the GBR ROM title field. Attackers can supply a crafted GBR file of 0x21 to 0x162 bytes to read past the heap buffer, crashing gbsplay or leaking memory.

gbsplay through 0.0.103 Out-of-Bounds Read via mapper_map ROM Bank Index

gbsplay through 0.0.103 contains an out-of-bounds read vulnerability in mapper_map() in mapper.c that fails to reject ROM bank indexes beyond the ROM size, causing an underflowed bank length. Attackers can supply crafted .gbr, .gbs or .gb files with malicious bank indexes to make bank_get() read far past the heap ROM buffer and crash the player.

FLTK through 1.4.5 Heap Buffer Overflow via Fl_BMP_Image Integer Overflow

FLTK through 1.4.5 contains an integer overflow vulnerability in Fl_BMP_Image::load_bmp_() that causes undersized pixel buffer allocation from file-supplied width and height. Attackers can supply a crafted BMP or ICO file with large dimensions so row decoding writes file-derived data past the heap buffer, corrupting the application heap.

FLTK through 1.4.5 Stack Buffer Overflow via Fl_BMP_Image colors_used Field

FLTK through 1.4.5 contains a stack-based buffer overflow vulnerability in Fl_BMP_Image::load_bmp_() that allows attackers to corrupt stack memory by supplying an oversized BMP colors_used field. Attackers can craft BMP or ICO files with colors_used above 256 to overflow the 768-byte colormap array, causing crashes or potential code execution.

snappy-java: JVM crash from unchecked ranges in Snappy.arrayCopy and SnappyOutputStream.rawWrite

snappy-java is a Java port of the snappy, a fast C++ compresser/decompresser developed by Google. Prior to 1.1.10.9, Snappy.arrayCopy(Object src, int offset, int byteLength, Object dest, int destOffset) passes caller-supplied ranges to native memcpy without validating either array, allowing negative or oversized byteLength and offset values to read or write outside array bounds and crash the JVM. SnappyOutputStream.rawWrite and SnappyInputStream.rawRead, including their typed-array write and read methods, pass caller-controlled ranges through this primitive, and typed-array byte-size calculations can overflow int. This issue is fixed in versi

Go JOSE: DoS when parsing JWKs that contain RSA keys

Go JOSE provides an implementation of the Javascript Object Signing and Encryption set of standards in Go, including support for JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Token (JWT) standards. Prior to 4.1.6, go-jose parses attacker-controlled RSA modulus and prime values from JWKs without enforcing size and consistency bounds before passing them to crypto/rsa.PrivateKey.Validate. On Go 1.24 and later, crafted large or degenerate RSA parameters can make that validation consume cubic CPU time, allowing remote denial of service in applications that parse JWKs from untrusted sources. This issue is fixed in version 4.1.6.

Go JOSE: Panics in JSON parsing

Go JOSE provides an implementation of the Javascript Object Signing and Encryption set of standards in Go, including support for JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Token (JWT) standards. Prior to 4.1.5, parsing attacker-controlled JSON through go-jose allows deeply nested arrays or objects to exceed Go's stack limit. The resulting stack overflow crashes the application and permits denial of service in applications that parse untrusted JSON through go-jose. This issue is fixed in version 4.1.5.

Go JOSE: Panic during CBC-HMAC processing

Go JOSE provides an implementation of the Javascript Object Signing and Encryption set of standards in Go, including support for JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Token (JWT) standards. Prior to 4.1.5, decrypting untrusted JWE ciphertext with A128CBC-HS256, A192CBC-HS384, or A256CBC-HS512 can pass an empty ciphertext buffer to CBC-HMAC unpadding. Insufficient validation allows the empty buffer to be indexed, causing a panic and denial of service. Applications that decrypt attacker-controlled ciphertext with one of these content-encryption algorithms are affected. This issue is fixed in version 4.1.5.

Autobahn Python: permessage-brotli inflates a whole frame before maxMessagePayloadSize is checked (incomplete fix of GHSA-hxp9-w8x3-p566)

Autobahn Python is a WebSocket and WAMP implementation for Python that supports Twisted and asyncio. From 26.7.1 until 26.10.1, PerMessageBrotli.decompress_message_data in compress_brotli.py calls the Brotli decompressor without an output limit and checks maxMessagePayloadSize only after a complete frame has been inflated. An unauthenticated WebSocket client can send a small, highly compressed frame that allocates hundreds of MiB before rejection, causing memory-exhaustion denial of service on servers that enable the opt-in permessage-brotli feature through the compress extra. Deflate and bzip2 already enforce the remaining output budget and

• Actualiza a 26.10.1

Tornado: Open redirect in RedirectHandler via protocol-relative URLs

Tornado is a Python web framework and asynchronous networking library. Prior to 6.6, tornado.web.RedirectHandler URL templates can place regex-capture substitutions where crafted request paths change the redirect scheme or network location. Affected placements include substitutions at the start of a path, directly after a fixed host, or at the beginning of the template, including protocol-relative, absolute, backslash, encoded, host-extension, and user-info variants interpreted by browsers as attacker-controlled destinations. Static templates and substitutions after a fixed host followed by a slash are not affected. An attacker can use the re

• Actualiza a 6.6

Tornado: Quadratic CPU usage when parsing HTTP headers with line folding

Tornado is a Python web framework and asynchronous networking library. Prior to 6.6, Tornado's HTTP header parser accepts obsolete line folding and repeatedly concatenates short continuation lines, causing quadratic CPU consumption on the IOLoop thread. An unauthenticated client can submit a header block containing many obsolete line-folding continuations before application code runs, blocking other connections served by the process. The cost grows with max_header_size, and only availability is affected. This issue is fixed in version 6.6.

• Actualiza a 6.6

systeminformation: Windows command injection in services() through Unicode quotation marks

systeminformation is a System and OS information library for node.js. Prior to 5.33.16, services() in lib/processes.js inserts a caller-supplied service name into a PowerShell Get-CimInstance filter after processing it with sanitizeShellString() in lib/util.js. On Windows, the sanitizer removes ASCII quotes but permits Unicode quotation marks that PowerShell accepts as string delimiters, allowing crafted input to terminate the filter and place a PowerShell expression in the command executed by util.powerShell(). The expression runs with the Node.js process account's permissions and may read or change accessible files, alter application data,

• Actualiza a 5.33.16

Infinite loop in Xpdf due to missing validation in JPEG 2000 decoder

Infinite loop in Xpdf 4.06 and earlier, due to incorrect validation of progression order field in JPEG 2000 image.

Timing side-channel in pure-Erlang X25519 scalar multiplication leaks the private key in jose

Observable Timing Discrepancy vulnerability in potatosalad jose allows recovery of a long-term X25519 private key through a timing side channel in the pure-Erlang Curve25519 fallback. The pure-Erlang X25519 implementation performs scalar multiplication over the secret private key using a recursive Montgomery ladder (jose_jwa_x25519:curve25519/2) whose clauses branch on individual bits of the clamped private scalar, and whose per-step operations (jose_jwa_x25519:montgomery_add/3 and jose_jwa_x25519:montgomery_double/1) and field inversion are built from value-dependent Erlang bignum arithmetic (multiplication, remainder, and modular exponenti

• Actualiza a 1.11.13

ECDSA signature length is not validated in jose, allowing signature malleability

The jose library accepts ECDSA (ES256, ES256K, ES384, and ES512) JWS signatures of a non-canonical length. When verifying an ECDSA signature, jose_jwk_kty_ec:verify/4 in src/jwk/jose_jwk_kty_ec.erl splits the raw signature in half by its actual byte length (split_binary(Signature, byte_size(Signature) div 2)) instead of enforcing the fixed length required by RFC 7518 §3.4, and then decodes each half with crypto:bytes_to_integer/1, which ignores leading zero bytes. As a result, an attacker who holds one valid token can prepend leading zero bytes to each of the R and S halves to produce longer signatures that still split evenly and decode to t

• Actualiza a 1.11.13

erlang-jose RSA JWK parsing attempts to factor an attacker-controlled modulus, enabling CPU-exhaustion denial of service

Inefficient Algorithmic Complexity in erlang-jose allows an unauthenticated remote attacker to cause a CPU-exhaustion denial of service by submitting a crafted RSA JSON Web Key. When an application parses an untrusted JWK through the public jose_jwk:from_binary/1 or jose_jwk:from_map/1 API (or the Elixir wrappers JOSE.JWK.from_binary/1 and JOSE.JWK.from_map/1), an RSA private key that supplies d, e, and n but omits all Chinese Remainder Theorem parameters (p, q, dp, dq, qi) is routed into convert_sfm_to_crt/1, which tries to recover the missing primes by factoring the modulus. The three integers are read straight from the base64url input and

• Actualiza a 1.11.13