CVE-2026-98493
NoneCVSS
—
EPSS
0.2%
Published
Oct 18, 2026
CISA due date
—
Cloudanix analysis
A bug in the Linux kernel's network startup code can cause computers to crash when they receive certain network settings over DHCP.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Buffer Overflow
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Unbounded writes of hostname (option 12) and vendor-class (option 60) DHCP options into the fixed 312-byte bootp_pkt.exten[] buffer in ic_dhcp_init_options() allow a field-spanning write when combined option lengths exceed available space before the END marker.
Why it matters to the business
Systems using DHCP with long hostnames or dhcpclass identifiers may panic on boot, causing downtime and requiring manual intervention or kernel reconfiguration to recover.
How an attack unfolds
An attacker supplies a long hostname via DHCP or sets a large dhcpclass identifier so that the combined option payloads plus headers exceed the 312-byte buffer; the kernel performs an out-of-bounds memcpy that FORTIFY_SOURCE detects and aborts boot when panic_on_warn is enabled.
How to fix it
Apply the upstream fix that routes optional options through a bounds-checked helper ensuring space for the option header, payload, and END marker; rebuild and deploy the patched kernel; consider disabling panic_on_warn or shortening DHCP options as temporary workarounds.
How to confirm the fix worked
Boot a test system with the patched kernel, supply long hostname and dhcpclass values, and confirm no FORTIFY_SOURCE warning or panic occurs; inspect ic_dhcp_init_options() source to verify the new helper enforces remaining space checks.
Typical attack path
- Configure DHCP server or rogue responder to return hostname >=64 bytes and dhcpclass identifier >=252 bytes
- Target host boots and runs ipconfig/DHCP client code path
- ic_dhcp_init_options() performs unbounded writes into exten[]
- FORTIFY_SOURCE detects field-spanning write and triggers kernel panic when panic_on_warn=1
How to detect it
Examine kernel logs and boot messages for FORTIFY_SOURCE field-spanning write reports or panic_on_warn aborts during ipconfig/DHCP initialization; search dmesg or journalctl for references to ic_dhcp_init_options or bootp_pkt.exten.
What your security team should do
- Prioritize kernel update for any distribution shipping the affected ipconfig code
- Audit DHCP client configurations for oversized hostname or vendor-class options
- Monitor boot logs for FORTIFY_SOURCE warnings on systems with panic_on_warn enabled
- Test patched kernels in staging before production rollout given the 5-day publication window
The record
In the Linux kernel, the following vulnerability has been resolved: net: ipconfig: bound DHCP option construction ic_dhcp_init_options() appends the hostname (option 12), vendor-class (option 60) and client-ID (option 61) options into the fixed 312-byte bootp_pkt.exten[] buffer. Only the client-ID branch checked the remaining space; the hostname and vendor-class writes were unbounded. A 64-byte hostname together with the maximum 252-byte dhcpclass= identifier needs 18 + (2 + 64) + (2 + 252) = 338 of the 312 available bytes even before the terminating END marker, so the vendor-class memcpy runs past the end of exten[]. With CONFIG_FORTIFY_SOURCE this is reported as a field-spanning write and, when the kernel is booted with panic_on_warn=1, aborts boot with a panic. Route the optional options through a common helper that makes sure the option, its 2-byte header and the END marker all fit and drops an option that would not. Configurations with short options keep sending exactly the same bytes as before.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|