What were you trying to do that didn't work?

  Running keylime_verifier service under normal operations on RHEL 10.1. During stress testing with Valgrind, we discovered that the verifier leaks SQLite database connections during routine operations (agent management, policy CRUD operations, concurrent API calls).

What is the impact of this issue to you?

SQLite database connection leaks will accumulate over time in production environments, eventually leading to connection pool exhaustion and service degradation or failure on long-running RHEL 10.1 deployments. The issue scales with the number of worker processes (CPU cores), making it worse on larger systems.

Please provide the package NVR for which the bug is seen:

  python3-keylime-7.12.1-11.el10_1.2.x86_64
  python3-keylime-7.12.1-11.el10_1.3.x86_64 (post CVE-2025-13609 patch - leak persists)

How reproducible is this bug?:

  100% reproducible on RHEL 10.1 across all tested configurations (1-core and 12-core systems). Not reproducible on RHEL 9.7 with identical keylime versions.

Steps to reproduce

  1. Install keylime on RHEL 10.1
  2. Configure verifier with small database connection pool (pool_size=2, max_overflow=1)
  3. Run keylime_verifier under valgrind with FD tracking:
     valgrind --track-fds=yes --leak-check=full --log-file=verifier.log python3 /usr/bin/keylime_verifier
  4. Perform any of the following operations:
     - Add/delete agents multiple times (keylime_tenant -c add/delete)
     - Create/read/update/delete runtime or measured boot policies
     - Concurrent API calls (cvlist, status, policy operations)
  5. Stop verifier and check valgrind logs for "Open file descriptor" entries pointing to cv_data.sqlite

Expected results

  Zero SQLite database connection leaks after verifier shutdown (consistent with RHEL 9.7 behavior). All database connections should be properly closed and file descriptors released.

Actual results

  RHEL 10.1 - Persistent SQLite connection leaks:
  - 1-core systems: 1-3 leaked SQLite connections per test phase
  - 12-core systems: 7-24 leaked SQLite connections per test phase
  - Most worker processes leak 1-2 database connections each
  - Leak count scales with number of workers (CPU cores)

  RHEL 9.7 - No leaks observed (baseline correct behavior)