CVE-2015-3294

What it actually does

Improper handling of the setup_reply return value in tcp_request allows an out-of-bounds read from process memory on malformed TCP DNS requests, resulting in information disclosure and a crash.

Why it matters to the business

Service disruption for name resolution combined with potential leakage of sensitive process memory can interrupt operations and expose confidential data to remote attackers.

How an attack unfolds

An attacker crafts a malformed DNS request and sends it over TCP to a vulnerable Dnsmasq instance; the missing return-value check triggers an out-of-bounds read that either leaks memory contents or crashes the daemon.

How to fix it

Upgrade Dnsmasq to version 2.73rc4 or later; apply vendor patches for Oracle Solaris; restart the service after upgrade and verify the new version string.

How to confirm the fix worked

Query the running binary or package manager for version >= 2.73rc4; attempt controlled malformed TCP DNS requests in a lab environment and confirm absence of crashes or memory leaks.

Typical attack path

1. Locate an exposed Dnsmasq TCP DNS listener
2. Send a single malformed DNS query packet
3. Observe memory disclosure in the response or a daemon crash

How to detect it

Review Dnsmasq logs for repeated malformed query entries or segmentation-fault crashes; correlate with network captures showing unusual TCP DNS payloads from untrusted sources.

What your security team should do

• Prioritize upgrade of all Dnsmasq instances to 2.73rc4 or newer within 30 days
• Restrict TCP DNS access to trusted networks where possible
• Monitor daemon logs and process health for unexpected crashes
• Inventory downstream dependents and schedule staged rollouts