Good First Issues in C

Summary With SSL_OP_CLEANSE_PLAINTEXT set, decrypted application data that is still in the TLS record layer's read buffer when the connection is freed is passed to OPENSSL_free() without being cleansed. The documentation says this data is cleansed "when releasing the connection (e.g. SSL_free(3))", and OpenSSL 3.0 and 3.1 did so. The cleanse was lost when the record layer was rewritten in 3.2.0. Affected versions Checked in the source of the latest release of each branch: Version Read buffer cleansed on free 3.0.22, 3.1.8 yes 3.2.6, 3.3.7, 3.4.8, 3.5.9, 3.6.5, 4.0.3 no master @ b86f4c1 no Details Free path on master: SSL_free() → ossl_ssl_connection_free() → RECORD_LAYER_clear() (ssl_lib.c#L1587) → rrlmethod->free() (rec_layer_s3.c#L55-L56) → tls_free() → tls_int_free() tls_int_free() releases rl->rbuf with ossl_tls_buffer_release(), which is a plain OPENSSL_free() (tls_common.c#L1430-L1435). tls_release_read_buffer() already cleanses the buffer under the option

Everything after the next line is the original report Markdown from @fabwa… Attachment: harness_smuggle4.c Processor State Confusion and Markup Smuggling on Resume After CDATA in Internal Entity Package: libexpat/libexpat Tested Versions: 2.8.2 (commit 7d93af0), 2.8.3 / master (commit 7a3215e) Affected Files expat/lib/xmlparse.c -- doContent, CDATA section processor state assignment on suspend/resume when parsing an internal general entity that contains a CDATA section expat/lib/xmlparse.c -- cdataSectionProcessor, buffer selection on resume routes through the document buffer instead of the entity buffer Root Cause When a parser is suspended mid-document inside a CDATA section that was expanded from an internal general entity, libexpat records m_processor = cdataSectionProcessor. On XML_ResumeParser, that processor scans the document buffer rather than the entity buffer, causing subsequent document markup to be delivered as character data. The result is a differential parse: the

Describe the Bug I'm designing a new keyboard and added my QMK_HOME as a submodule of the repo I'm using to track the process. This setup causes qmk doctor to report "QMK home does not appear to be a Git repository!" and skip the remainder of the Git checks. Digging into the code, this is just a matter of qmk doctor expecting <qmk_home>/.git to be a directory, but in submodules and worktrees it's a file. I've put together a PR to address this (and a couple of other things I found while in there), which I'll be posting momentarily. Keyboard Used N/A Link to product page (if applicable) N/A Operating System Arch Linux qmk doctor Output Ψ QMK Doctor is checking your environment. Ψ Python version: 3.14.7 Ψ CLI version: 1.2.0 Ψ QMK home: /home/five35/Documents/Projects/Q535/qmk_firmware Ψ Detected Linux (Arch Linux). Ψ Userspace enabled: False ⚠ QMK home does not appear to be a Git repository! (no .git folder) Ψ All dependencies are installed. Ψ Found arm-none-eabi-gcc version 16.

I'm hitting the same 04-test_bio_dgram.t hang reported for AIX in #27899, but on HP-UX 11.31 IA64 (both 32-bit and 64-bit), with openssl-3.5.9. Build config: ./config threads shared hpux64-ia64-cc (64-bit) / threads shared no-asm hpux-ia64-cc (32-bit), aCC 6.29, perl 5.24.1. make test output on both architectures: 04-test_bio_core.t ...................... ok # OPENSSL_TEST_RAND_SEED=<seed> not ok 3 - iteration 3 then nothing further - the process never returns, even after 36+ hours in our original CI run. I attached gdb (as the process owner, so no ttrace restriction) to a live hung process and confirmed it's genuinely blocked in the kernel, not spinning: 0xc000000000655310:0 in _recvmsg2_sys+0x30 () from /usr/lib/hpux64/libc.so.1 "iteration 3" is the 3rd case of the first ADD_ALL_TESTS(test_bio_dgram, bio_dgram_cases) group (AF_INET, local=1), not test_bio_dgram_pair - confirmed by this trace alone, since the in-memory BIO_s_dgram_mem path exercised by test_bio_dgra

The temporary DER buffers used when reading and writing private keys are freed with OPENSSL_free() rather than OPENSSL_clear_free(), so the encoded key is left in freed memory: openssl/providers/implementations/encode_decode/decode_der2key.c Line 341 in 0673930 OPENSSL_free(der); (also the error path at L370) openssl/providers/implementations/encode_decode/decode_spki2typespki.c Line 95 in 0673930 OPENSSL_free(der); openssl/providers/implementations/encode_decode/decode_pem2der.c Line 264 in 0673930 OPENSSL_free(der); openssl/providers/implementations/encode_decode/decode_epki2pki.c Line 193 in 0673930

Summary The memory-module lock trace events on AIE2/AIE2P (LOCK_SEL0..7_ACQ_EQ, LOCK_SEL0..7_ACQ_GE, LOCK_SEL0..7_EQUAL_TO_VALUE and LOCK_0..7_REL) do not refer to fixed lock IDs. Each one reports the lock chosen by selection slot n, which is the Locks_Event_Selection_n register. None of the trace paths in mlir-aie write those registers today: the aie.trace dialect (trace.event, trace.reg, trace.combo_event, trace.edge_event); aie.utils.trace.configure_trace; IRON's Program.enable_trace. All eight slots keep their reset value. Its lock-select field is 0, so every LOCK_SELn_* and LOCK_n_REL event reports lock 0. A trace that asks for LOCK_SEL2_ACQ_GE looks plausible but shows lock 0's activity. This matters most when you are hunting a lock stall. CoreEvent.LOCK_STALL tells you the core stalled. The per-lock memory-module events would tell you which ObjectFifo, but right now they cannot. Registers The registers are identical in aie-rt xaie2pgbl_params.h and in mlir-aie lib/Dialect/AIE/

Describe the bug When MsQuic is built with QUIC_ENABLE_LOGGING=OFF, QuicConnLogOutFlowStats() still scans all live streams to collect statistics that goes nowhere. I've added an early return in QuicConnLogOutFlowStats() and it reduced latency by 90% at following SecNetPerf benchmark: ./build/repro/bin/Release/secnetperf -target:localhost -conns:1 -streams:1000 -rstream:1 -run:10s -up:512 -down:4kb -plat:1 Modified code: QUIC_INLINE void QuicConnLogOutFlowStats( _In_ const QUIC_CONNECTION* const Connection ) { // Added this branching #if defined(QUIC_EVENTS_STUB) && !defined(QUIC_EVENTS_STDOUT) // Event tracing is a no-op; avoid scanning all live streams for statistics. return; #endif if (!QuicTraceEventEnabled(ConnOutFlowStats)) { return; } QuicCongestionControlLogOutFlowStatus(&Connection->CongestionControl); uint64_t FcAvailable, SendWindow; QuicStreamSetGetFlowControlSummary( &Connection->Streams, &FcAvailable,

One note from asm analysis: IRON's range_ casts to index: 64-bit counters on the core, two registers and a carry each. aie2p is not friendly with 64-bit integers, and as result, it produces larger program code, and adds more register pressure. The workaround from user side exists: use custom function with scf.for from 0 to stop (an int or an i32 value) with i32 bounds; yields the i32 induction variable def range32(stop: object) -> Iterator[object]: c0, c1 = arith.constant(T.i32(), 0), arith.constant(T.i32(), 1) stop = arith.constant(T.i32(), stop) if isinstance(stop, int) else stop if isinstance(stop.type, IndexType): stop = index.casts(T.i32(), stop) for_op = scf.ForOp(c0, stop, c1) with InsertionPoint(for_op.body): yield for_op.induction_variable scf.yield_([]) However, I wonder, it can be improved on mlir-aie side? The simplest solution is add dtype= parameter to _range and let user to decide, but maybe there is something smarter than this

Describe the Bug Hello, I have a Round 2 B104 beam spring with the Leyden Jar controller, and I love it. I ran into one small fault and believe I have found the cause, so I wanted to pass it along. Symptom On my home PC (Windows, keyboard plugged directly into the motherboard), the Num Lock, Caps Lock, and Scroll Lock LEDs went dark after roughly 30 to 60 minutes of normal use. The PC had not gone to sleep and the keys kept working. Pressing the lock keys still changed the state in Windows, but the LEDs stayed dark. Unplugging the keyboard, or pressing a key mapped to QK_REBOOT, brought them back. The solenoid was off. The fault did not appear on my work computer over a full day. Likely cause In keyboards/leyden_jar/io_expander.c, the IO expander is configured only once, in io_expander_init(). After that, io_expander_update_state() writes the output register only when the LED state changes. If the chip ever loses its configuration and its pins revert to inputs, nothing restores it, whi

macOS is using an outdated and vulnerable copy of livbexpat 2.7.4 at https://github.com/apple-oss-distributions/expat . I want to make them aware but: the repository does not have "Issues" or "Pull Requests" activated. I find no e-mail address for user @apple-oss-distributions. I tried mailing to [email protected] but only get robot replies back. https://security.apple.com/submit/ needs an Apple account and I don't have one. Here is what I would like to send to them: Hi! It has come to my attention via [1][2] that latest macOS is using vulnerable libexpat 2.7.4 rather than the latest release 2.8.5. From a quick look, macOS is missing fixes to all of these CVEs: # git diff R_2_7_4 R_2_8_5 -- expat/Changes | grep '^+' \ | grep -o 'CVE-[0-9-]\+' | sed 's,^,- ,' | sort -u - CVE-2022-25235 - CVE-2026-32776 - CVE-2026-32777 - CVE-2026-32778 - CVE-2026-41080 - CVE-2026-45186 - CVE-2026-50219 - CVE-2026-56131 - CVE-2026-56132 - CVE-2026-56403 - CVE-2

I have noticed a strange corruption issue occurring in AES encryption/decryption on a specific embedded board using a Cortex-A53 CPU (AARCH64) 4 cores. The problem shows as random corruptions when decrypting or encrypting data, the larger the data is the more probable corruption will happen. It is best shown by running a SSH server. Additionally it seems to happen much less frequently when the load of the CPU is low. The version of OpenSSL used in 3.0.13 with the VPAES implementation. When building OpenSSL with no assembly (no-asm option) all problems disappear and large messages are properly decoded or encoded.

The AEGIS Authenticated Encryption Algorithms https://www.rfc-editor.org/rfc/rfc10032.html Support was requested in #5524, is this something OpenSSL could implement since this is a RFC now?

What happened? How can we reproduce this? Suppose a matchBinaries selector with followChildren: true lists the same path twice. Deleting that policy does not release its mbset ID. Only 64 IDs exist (mbset.MaxIDs), so after 64 add/delete cycles no policy that uses followChildren can load until the agent restarts. Every add and delete in the loop succeeds, so the only sign of the problem is a warning in the agent log. Reproduce Run a standalone agent built from main (no Kubernetes needed): sudo ./tetragon --bpf-lib bpf/objs Save a policy with a repeated followChildren value as dup.yaml: apiVersion: cilium.io/v1alpha1 kind: TracingPolicy metadata: name: mbset-dup-path spec: kprobes: - call: "fd_install" syscall: false selectors: - matchBinaries: - operator: In values: - "/usr/bin/cat" - "/usr/bin/cat" followChildren: true Save the same policy without the repeated value as valid.yaml: apiVersion: cilium.io/v1alpha1 kind: TracingPo

Describe the Bug On current master, a clean build of gmmk/pro/rev1/ansi with the default keymap only lights the LEDs controlled by the second AW20216S driver (right-hand columns and side strips). All LEDs on the first driver (indices 0–65, most of the board) stay dark and don't respond to RGB Matrix changes. Hardware is fine: the prebuilt VIA/Vial firmware lights every LED correctly. Pin config on master matches the older working Vial config (CS B13/B14, EN C13, SPI A5/A6/A7), so pins aren't the issue. Adding this to the keymap's config.h fixes it completely: #define AW20216S_SPI_DIVISOR 8 This suggests the first driver can't reliably handle the default SPI clock on at least some rev1 boards. Consider setting a higher default divisor for this keyboard. Keyboard Used gmmk/pro/rev1/ansi Link to product page (if applicable) https://www.gloriousgaming.com/products/gmmk-pro-black-slate-75-barebone Operating System macOS qmk doctor Output Ψ QMK Doctor is checking your environment. Ψ Pyt

It seems that there is an error in case when get_crl function is used and checked certificate contains several CRL Distribution Points with different reasons. The error occurred after the merge of #29199 related to #26786. See the following code: if (ctx->get_crl != NULL) { X509 *crl_issuer = NULL; unsigned int reasons = 0; ok = ctx->get_crl(ctx, &crl, x); if (crl != NULL) { ctx->current_crl_score = get_crl_score(ctx, &crl_issuer, &reasons, crl, x); ctx->current_issuer = crl_issuer; ctx->current_reasons = reasons; } } The variable reasons is initialized to 0 on every get_crl callback invocation, preventing accumulation of revocation reasons across multiple CRL Distribution Points (CDPs). As a result, the loop condition while (ctx->current_reasons != CRLDP_ALL_REASONS) may never become false, causing a premature exit with X509_V_ERR_UNABLE_TO_

Thanks for addressing issues and sorry for the late review. I have one nonblocking suggestion in extract_symmetric_key, apps/pkcs12.c, lines 1048-1056: could we handle the enc != NULL branch immediately after the NOKEYS check, before decrypting and importing the key? That branch only prints the original encrypted bag, so it shouldn't need a successful EVP_SKEY import. This doesn't hold up my approval. Originally posted by @idrassi in #32978 (review)

SSL_load_client_CA_file() does not extract a subject name from a PEM file containing a valid -----BEGIN TRUSTED CERTIFICATE----- block. The error queue reports "error:0480006C:PEM routines::no start line". The function is intended to return a list of certificate subject names for use as the client CA list. The auxiliary trust attributes are not needed for that purpose, but the certificate's subject should still be available. OpenSSL version: OpenSSL 3.6.0 1 Oct 2025 (Library: OpenSSL 3.6.0 1 Oct 2025) built on: Wed Oct 8 20:29:58 2025 UTC platform: VC-WIN64A options: bn(64,64) compiler: cl /Z7 /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo /O2 -DL_ENDIAN -DOPENSSL_PIC -D"OPENSSL_BUILDING_OPENSSL" -D"OPENSSL_SYS_WIN32" -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE" -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS" -D"NDEBUG" -D_WINSOCK_DEPRECATED_NO_WARNINGS -D_WIN32_WINNT=0x0502 Platform: Windows

The documentation (https://docs.openssl.org/master/man3/PEM_read_bio_PrivateKey/) for the PEM_read_bio_X509 function says: The X509 functions process an X509 certificate using an X509 structure. They will also process a trusted X509 certificate but any trust settings are discarded. However, PEM_read_bio_X509 returns NULL when the input contains a single valid -----BEGIN TRUSTED CERTIFICATE----- block. The error queue reports "error:0480006C:PEM routines::no start line". Reading the same input file with PEM_read_bio_X509_AUX succeeds. The paragraph in the documentation states that the trust certificate will be successfully read, with the exception of its auxiliary trust settings. But that isn’t happening. OpenSSL version: OpenSSL 3.6.0 1 Oct 2025 (Library: OpenSSL 3.6.0 1 Oct 2025) built on: Wed Oct 8 20:29:58 2025 UTC platform: VC-WIN64A options: bn(64,64) compiler: cl /Z7 /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo /O2 -DL_ENDIAN -DOPENSSL_PIC -D"OPENSSL_BUILDING_OPE

Currently kew doesnt expose the currently playing file path via xesam:url. The MPRIS spec doesnt enforce it, but even if its a kind of niche feature is useful for other apps/widgets/etc to be able to access file metadata like album cover, lyrics, etc, directly. kew: mpv (other audio players also expose this metadata):

Summary Variant analysis of historical fixes in openssl identified 1 code site where an integer-overflow guard, bounds check, or safe-allocation wrapper exists at one location but is missing at a structurally identical sibling location (same file, same function, or same pattern family) elsewhere in the codebase. Each finding below is code-confirmed against the current HEAD (verified by cloning the repository fresh and checking the pattern is still present), with the exact file/line locations, the root cause, a description of the trigger path, and — where available — ASan/execution verification output or a proof-of-concept. Note on origin: these were surfaced by an automated variant-analysis pipeline that diffs historical fix commits against sibling code paths, then has each candidate manually reviewed. I'm posting them together per-project rather than as separate issues to respect maintainer time. Happy to split, close, or reprioritize any of these as you see fit. Finding 1: OpenS

OpenSSLConfig.cmake computes its prefix by walking up from its own path. If CMake finds the file through a symlinked directory, the walk ends somewhere that doesn't contain the headers or libraries. This hits every CMake user on a merged-/usr distribution like Arch, as soon as /bin comes before /usr/bin in PATH. CMake derives search prefixes from PATH entries, so /bin gives the prefix /. /lib is a symlink to usr/lib, so /lib/cmake/OpenSSL/OpenSSLConfig.cmake exists and gets picked. Walking up three levels from there gives /, which the config turns into an empty prefix, and everything ends up under /include and /lib. Repro on Arch (openssl 3.6.4-1, cmake 4.4.3): $ cat CMakeLists.txt cmake_minimum_required(VERSION 3.20) project(t C) find_package(OpenSSL CONFIG REQUIRED) get_target_property(inc OpenSSL::SSL INTERFACE_INCLUDE_DIRECTORIES) message(STATUS "OpenSSL_DIR=${OpenSSL_DIR}") message(STATUS "OPENSSL_INCLUDE_DIR=${OPENSSL_INCLUDE_DIR}") message(STATUS "OpenSSL::SSL include=${inc}")

Issues with backgrounds on systems that use a Jumper Pak are related to memory fragmentation. We need to handle it better.

Even for non-exportable symmetric keys the length of the key is normally available. We should implement it. Contract: 0 indicates error, positive value is length.

Building master for linux64-loongarch64 with --strict-warnings fails: $ ./Configure linux64-loongarch64 --strict-warnings $ make ... crypto/loongarchcap.c:14:6: error: no previous prototype for 'OPENSSL_cpuid_setup' [-Werror=missing-prototypes] 14 | void OPENSSL_cpuid_setup(void) | ^~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[1]: *** [Makefile:20340: crypto/libcrypto-lib-loongarchcap.o] Error 1 crypto/loongarchcap.c does not include internal/cryptlib.h, which declares OPENSSL_cpuid_setup(). The other *cap.c files (armcap.c, ppccap.c, riscvcap.c, s390xcap.c, sparcv9cap.c) all include it. This has been the case since the file was added in 7f2d618. It is the only error in a make -k build of master, and adding the include fixes it.

Is your feature request related to a problem? Please describe. In the default assembly browsing view (Vp) it is very easy to get lost about where in the binary you are currently. In Cutter and all the other GUI frameworks we have this bar at the top, which has a cursor to show you were you are in the binary (the absolute location). But I think this is not the optional solution. Because I think it could be more helpful to know, where you are in respect to a certain fix point. For example: You know where main() is. While browsing you want to keep an eye on how "deep" you are into the programs CFG. Or "how many jumps/calls you are away from main". This is especially useful for firmware boot code (few indirect jumps). To track how deep you are currently in the boot procedure. Describe the solution you'd like Adding some indicator of how many jumps/calls the user is away from a predefined fixed location (like an firmware entry point). Here a mockup: ┌────────────

Appending a NULL sentinel to a range of C strings might be a common pattern in C, but it has significant disadvantages. A missing sentinel can result in out-of-bounds access, and determining the size of the range requires scanning it. Modern C++ and Rust interfaces generally represent ranges using a pointer and size instead. This is especially relevant when interfacing matio with C++ or Rust, where requiring a sentinel makes interoperability unnecessarily cumbersome. I therefore propose to undeprecate Mat_VarCreateStruct, or even provide interfaces that accept sized ranges directly. I would even go further and refactor the interface to something like that: matvar_t * Mat_VarCreateStruct(const char *name, size_t nname, int rank, const size_t *dims, const char *const *fields, size_t nfields)

Summary The DTLS listener packet handler accesses sc->d1->rx while another supported listener thread can be inside SSL_clear() resetting or replacing sc->d1. This is a separate race from the duplicate-drive guard issue above: after moving the drive guard to stable storage, stress still produced a SIGSEGV with ossl_dtls_rx_inject_urxe(rx=0x0, ...) at the top of the core backtrace. The packet handler already holds dl->mutex, but the state-machine thread performing SSL_clear() does not hold that mutex while changing d1, so the check and dereference are not synchronized with reset. Version and build Confirmed on current OpenSSL master: OpenSSL 4.2.0-dev Commit 411499a19ccab8cc8389d3061889f3de2886e1b8 Clang debug build with strict warnings Reproducer and discriminator Use the standalone dtls-listener-race-poc.c reproducer attached to this report. The original tree crashes frequently from the combined listener races. To isolate this one, the drive-guard fix was applied first. Five direct t

Summary A multithreaded DTLS listener created without SSL_LISTENER_FLAG_SINGLE_THREAD can drive the same pending connection from two threads when SSL_clear() temporarily resets the per-connection being_driven guard. The resulting concurrent state-machine entry causes record-layer memory corruption, crashes, and a captured permanent self-deadlock. The supplied loopback reproducer uses only the documented multithreaded listener mode. Repeated testing reproduced frequent record-layer crashes and captured the self-deadlock on the listener mutex. Version and build Confirmed on current OpenSSL master: OpenSSL 4.2.0-dev Commit 411499a Clang debug build with strict warnings Relevant source: ssl/d1_lib.c, dtls_listener_packet_handler(), dtls_listener_drive_pending(), and dtls1_clear() ssl/ssl_lib.c, ossl_ssl_connection_reset() ssl/ssl_local.h, SSL_CONNECTION and DTLS1_STATE Reproducer The standalone reproducer is dtls-listener-race-poc.c. Example: $ ./dtls-listener-race-poc 10 4 4 4 64 0 li

Summary PKCS12_newpass() can overflow an OpenSSL-allocated heap buffer when a PKCS#12 shrouded key uses AES-WRAP-PAD and the decrypted PKCS#8 plaintext is not aligned to the 8-byte wrap block size. PKCS12_pbe_crypt_ex() allocates inlen + block_size, but AES-WRAP-PAD encryption writes roundup(inlen, block_size) + block_size. For the reproduced 138-byte PKCS#8 input, OpenSSL allocates 146 bytes and writes 152 bytes. The input PFX is accepted by PKCS12_parse() under the supplied old password before the overflow is triggered by the documented PKCS12_newpass() API. Version and build Confirmed on current OpenSSL master: OpenSSL 4.2.0-dev Commit 411499a19ccab8cc8389d3061889f3de2886e1b8 Clang debug build with strict warnings Relevant source: crypto/pkcs12/p12_decr.c, PKCS12_pbe_crypt_ex() crypto/evp/evp_enc.c, EVP_EncryptUpdate() crypto/evp/evp_lib.c, EVP_Cipher() providers/implementations/ciphers/cipher_aes_wrp.c, aes_wrap_cipher() Reproducer The standalone pkcs12-wrap-poc.c reproducer in

Summary EVP_KDF_CTX_set_params() correctly rejects an invalid zero-length SNMPKDF password, but the provider stores the rejected password in the context before validating its length. If the context is subsequently reused, EVP_KDF_derive(ctx, ..., NULL) enters an infinite loop because SNMPKDF() advances its password-processing loop by password_len, which is zero. This report does not claim a security vulnerability. The reproducer deliberately continues after EVP_KDF_CTX_set_params() returned failure. The robustness concern is that the rejected update leaves the context in a state that can later hang instead of preserving the previous valid state or failing promptly during derivation. Version and build Reproduced on: OpenSSL 4.2.0-dev Commit 859aea422b5be17ee9fc0f7678e9de302eb67b72 ASan/UBSan instrumented build Relevant source: providers/implementations/kdfs/snmpkdf.c, kdf_snmpkdf_set_ctx_params() providers/implementations/kdfs/snmpkdf.c, SNMPKDF() Minimal reproducer #include <openss