Thread (3 messages) flat view 3 messages, 1 author, 2d ago
WARM2d

[PATCH net 0/1] net: ipconfig: bound DHCP option construction

From: Yuqi Xu <hidden>
Date: 2026-09-19 08:45:50
Also in: stable

Hi Linux kernel maintainers,

We found and validated an issue in net/ipv4/ipconfig.c.  Triggering it
requires control over the kernel command line (the ip= and dhcpclass=
boot parameters), so it is not reachable by an unprivileged user; a
root-controlled boot or a malicious boot configuration can still turn
it into a boot-time panic.

We've tested it, and it should not affect any other functionality.

We will provide detailed information about the bug
in this email, along with a PoC to trigger it.

---- details below ----

Bug details:

ic_dhcp_init_options() builds the DHCP options for a request inside the
fixed 312-byte bootp_pkt.exten[] buffer.  It writes the hostname
(option 12) and the vendor-class (option 60) options by appending
type/length/value bytes without checking how much room is left; only the
client-ID (option 61) branch looked at the remaining space.

The hostname comes from the ip= boot parameter (up to 64 bytes) and the
vendor-class from dhcpclass= (up to 252 bytes after strscpy).  Together
with the 18 bytes already emitted (magic cookie, message type and
parameter request list) they need 18 + (2 + 64) + (2 + 252) = 338 bytes,
more than the 312 available even before the terminating END marker
(255).  The vendor-class memcpy() therefore writes past the end of
exten[].  CONFIG_FORTIFY_SOURCE reports this as a field-spanning write
and, with panic_on_warn=1, the warning becomes a panic during boot.

The patch routes the three optional options through a common helper that
checks that the option, its 2-byte header and the END marker all fit,
and drops an option that does not fit.  The helper also rejects a length
that does not fit in the one-byte DHCP option length field.  With short
options the emitted bytes are unchanged.

Reproducer:

Build a kernel with CONFIG_IP_PNP=y, CONFIG_IP_PNP_DHCP=y,
CONFIG_IP_PNP_BOOTP=y and CONFIG_FORTIFY_SOURCE=y, then boot it in QEMU
with one NIC (e1000) and the crafted command line below.
ip_auto_config() runs from a late_initcall and builds the DHCPDISCOVER
packet before any server reply is needed, so no DHCP server is required.

  HOST=$(printf 'h%.0s' {1..64})
  CLASS=$(printf 'v%.0s' {1..252})
  qemu-system-x86_64 -m 2048 -smp 2 -nographic -no-reboot \
    -kernel arch/x86/boot/bzImage -initrd initramfs.cpio.gz \
    -append "console=ttyS0 panic_on_warn=1 oops=panic panic=1 \
             ip=::::${HOST}::dhcp dhcpclass=${CLASS}" \
    -nic user,model=e1000

We run the PoC in a 2 vCPU, 2 GB RAM x86 QEMU environment.  It is a
boot-time trigger: CONFIG_FORTIFY_SOURCE plus panic_on_warn=1 is what
turns the out-of-bounds write into the observed panic.

----BEGIN crash log----

[    2.349975] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
[    2.383902] Sending DHCP requests .
[    2.384513] DHCP: sending class identifier "vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv"
[    2.385144] ------------[ cut here ]------------
[    2.385241] memcpy: detected field-spanning write (size 252) of single field "e" at net/ipv4/ipconfig.c:736 (size 226)
[    2.385345] WARNING: net/ipv4/ipconfig.c:736 at ip_auto_config+0x924/0x1120, CPU#0: swapper/0/1
[    2.387029] Modules linked in:
[    2.387710] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.3.0-rc3-00339-g6c096bb08de9 #1 PREEMPT(lazy) 
[    2.388052] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-10.fc44 06/10/2025
[    2.388442] RIP: 0010:ip_auto_config+0x938/0x1120
[    2.388743] Code: 8d 4e 02 49 39 c7 73 35 4c 89 8d 50 ff ff ff 48 8d 3d bc 67 ac ff 48 c7 c2 a0 c0 4a 85 4c 89 f9 48 89 c6 48 89 85 58 ff ff ff <67> 48 0f b9 3a 4c 8b 8d 50 ff ff ff 48 8b 85 58 ff ff ff 48 c7 c6
[    2.389258] RSP: 0018:ffffb79f40013dd0 EFLAGS: 00010293
[    2.389478] RAX: 00000000000000fc RBX: ffff971101181000 RCX: 00000000000000e2
[    2.389664] RDX: ffffffff854ac0a0 RSI: 00000000000000fc RDI: ffffffff85913240
[    2.389847] RBP: ffffb79f40013e80 R08: 0000000000000000 R09: ffff971101dd316e
[    2.390026] R10: ffffb79f40013bc0 R11: ffffb79f40013bb8 R12: ffff971101d56000
[    2.390235] R13: ffff971101dd3010 R14: ffff971101dd316c R15: 00000000000000e2
[    2.390542] FS:  0000000000000000(0000) GS:ffff9711f7b6f000(0000) knlGS:0000000000000000
[    2.390755] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    2.390910] CR2: ffff97111d555000 CR3: 000000001ca30000 CR4: 00000000000006f0
[    2.391206] Call Trace:
[    2.391913]  <TASK>
[    2.392196]  ? __pfx_ip_auto_config+0x10/0x10
[    2.392453]  ? do_one_initcall+0x84/0x3c0
[    2.392580]  do_one_initcall+0x84/0x3c0
[    2.392800]  kernel_init_freeable+0x202/0x260
[    2.392955]  ? __pfx_kernel_init+0x10/0x10
[    2.393086]  kernel_init+0x1a/0x130
[    2.393204]  ret_from_fork+0x177/0x240
[    2.393328]  ? __pfx_kernel_init+0x10/0x10
[    2.393551]  ret_from_fork_asm+0x1a/0x30
[    2.393711]  </TASK>

-----END crash log-----

With the patch applied the same command line boots without the
field-spanning warning and without a panic; a normal configuration with
short options still sends the class identifier as before.

Best regards,
Yuqi Xu


Yuqi Xu (1):
  net: ipconfig: bound DHCP option construction

 net/ipv4/ipconfig.c | 45 ++++++++++++++++++++++++++-------------------
 1 file changed, 26 insertions(+), 19 deletions(-)


base-commit: 6c096bb08de97cdca051fecddad22cac6a1fd275
-- 
2.55.0
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help