GHSA-q4h9-7rxj-7gx2

What it actually does

This advisory is marked withdrawn, so it should not be treated as a confirmed, standalone vulnerability in lettuce-core based solely on this record. The originally assigned weakness family is denial of service with medium severity, implying the suspected impact would be service instability, excessive resource consumption, connection handling failure, or process/kernel disruption rather than code execution or data disclosure. The record also lists affected Ubuntu 14.04/16.04 kernel package variants and lettuce-core, so exposure assessment should focus on whether deployed software still contains the affected dependency or kernel versions and whether vendor-fixed versions have been applied.

Why it matters to the business

If an affected component were exploitable, an attacker could degrade or interrupt services that depend on Redis client connectivity, networking, or vulnerable kernel packages, causing application errors, downtime, delayed processing, and operational disruption. Because the advisory is withdrawn, has no known exploit maturity, and is not listed in CISA KEV or ransomware use, urgency is lower than for actively exploited issues; however, the age of the advisory and the presence of legacy Ubuntu LTS kernel packages make this a useful patch-hygiene and end-of-life risk item.

How an attack unfolds

For a confirmed denial-of-service flaw of this type, an attacker would first identify an exposed application, service, or host using an affected version of lettuce-core, its underlying Netty dependency, or one of the listed Ubuntu kernel package lines. The attacker would then send crafted network traffic, Redis-facing input, or workload patterns that trigger the vulnerable code path, with the goal of exhausting CPU, memory, connection pools, event loops, or kernel resources, or causing a crash. Successful exploitation would be observed as application timeouts, failed Redis operations, connection resets, degraded throughput, service restarts, kernel warnings, or system instability. Because this advisory has been withdrawn, defenders should avoid assuming exploitation from this record alone and should corroborate with vendor advisories, dependency evidence, runtime symptoms, and logs.

How to fix it

Treat the withdrawn status as a signal to verify applicability before emergency response, but still upgrade affected components where present. Upgrade Maven package io.lettuce:lettuce-core to 6.5.1.RELEASE or later. For Ubuntu 14.04 LTS package lines, upgrade linux to 3.13.0-168.218 or later, linux-aws to 4.4.0-1016.16 or later, linux-azure to 4.15.0-1023.24~14.04.1 or later, and linux-lts-xenial to 4.4.0-119.143~14.04.1 or later. For Ubuntu 16.04 LTS package lines, upgrade linux to 4.4.0-119.143 or later, linux-aws to 4.4.0-1054.63 or later, linux-azure to 4.15.0-1013.13~16.04.2 or later, linux-gcp to 4.15.0-1014.14~16.04.1 or later, linux-gke to 4.4.0-1031.31 or later, linux-hwe to 4.15.0-24.26~16.04.1 or later, linux-kvm to 4.4.0-1020.25 or later, linux-oem to 4.13.0-1008.9 or later, and linux-raspi2 to 4.4.0-1086.94 or later. Where immediate upgrade is not possible, reduce exposure by limiting access to Redis-dependent services, enforcing rate limits and connection limits, monitoring event-loop and connection-pool saturation, and prioritizing replacement of unsupported legacy operating systems.

How to confirm the fix worked

Confirm dependency versions using software composition analysis, Maven dependency trees, build manifests, container image scans, and runtime artifact inspection; verify io.lettuce:lettuce-core is 6.5.1.RELEASE or later where used. Confirm kernel package versions with package inventory or host commands such as uname -r and package-manager queries, then compare against the listed fixed versions for the relevant Ubuntu flavor. Validate that patched services were rebuilt, redeployed, and restarted so the fixed dependency is actually loaded at runtime. For host kernel updates, confirm the system has rebooted into the fixed kernel rather than only installing the package. Because the advisory is withdrawn, also validate against upstream vendor advisories and package changelogs to determine whether this record applies to the specific deployed product lineage.

Typical attack path

1. Identify internet-facing or reachable services that rely on affected Redis client, Netty, or listed Ubuntu kernel package versions.
2. Confirm behavior that suggests the target processes attacker-controlled network input or high-volume connection activity.
3. Send crafted or high-volume requests intended to trigger resource exhaustion, connection handling failure, or crash conditions.
4. Monitor for degraded responses, service unavailability, connection resets, or process restarts.
5. Repeat or automate the traffic pattern to sustain denial of service until the vulnerable component is patched, restarted, rate-limited, or isolated.

How to detect it

Because the advisory is withdrawn and no public exploit indicators are provided, detection should focus on signs of possible denial-of-service activity rather than fixed signatures. Review application logs for bursts of Redis client failures, command timeouts, connection pool exhaustion, event-loop blockage, and repeated reconnect attempts. Review Redis server logs and network telemetry for unusual spikes in connections, reconnect loops, client-output-buffer pressure, connection resets, or traffic from a small set of sources. Review host telemetry for process restarts, watchdog events, kernel warnings, soft lockups, out-of-memory kills, high CPU, high memory pressure, socket exhaustion, and abnormal load averages around service degradation windows. Review deployment and package-management logs to determine whether vulnerable versions were present during incidents and whether fixed versions were installed and rebooted into. Since there are no named threat actors, KEV listing, ransomware association, or exploit maturity for this record, correlate symptoms with exposure evidence before declaring compromise.

What your security team should do

• Do not treat this withdrawn advisory as confirmed exploitation evidence; first verify whether affected versions are actually present in deployed applications, containers, and hosts.
• Upgrade lettuce-core to 6.5.1.RELEASE or later and apply the listed Ubuntu kernel fixed versions where those legacy package lines remain in use.
• Prioritize retirement or isolation of Ubuntu 14.04 and 16.04 systems because they represent broader lifecycle and patch-availability risk.
• Add SCA and package-inventory checks to detect stale lettuce-core, Netty transitive dependencies, and unfixed kernel packages in CI/CD and production images.
• Apply compensating controls for any temporarily unpatched service, including network access restrictions, Redis/service allowlisting, request rate limits, connection limits, and automated restart safeguards.
• Monitor for denial-of-service symptoms such as sudden connection spikes, Redis command latency, application timeout bursts, event-loop saturation, out-of-memory activity, kernel warnings, and repeated service restarts.
• Track upstream advisory status because withdrawn records can be reissued, superseded, or mapped to a different underlying CVE or package advisory.