LibBSD | dhcpcd has broken memory handling (#8)

[Chris Johns (@chris)]

Chris Johns created an issue: https://gitlab.rtems.org/rtems/pkg/rtems-libbsd/-/issues/8

Assignee: Chris Johns

## Summary

Code sometimes crashes after `dhcpcd` starts but not always. It depends on the gap between the interface being assigned an address, something else requesting heap memory, how that memory is used and the configuration of the DHCP server.

I have a hard crash on an KR260 board with two interfaces mounting an NFSv4 export soon after `dhcpcd` as started and an interface being assigned an IP4 address.  Debugging the crash I discovered the location being changed was the upper 32bits of a XDR buffer pointer and the update correlated to index 324 of the `requiremask6` fields of the `struct if_options` that is allocated then `dhcpcd` first reads its configuration.

```
(gdb) p 0xa5010c - (int) &ifo->requiremask6                                                                                                                                                                                                                                                                                  
$26 = 324                                                                                                                                         
```

I have seen random failures and crashes on Zynq systems I could not track it down. I now believe those are related. `dhcpcd` frees the read options before it enters the event loop and there must be a reference some where.

## Steps to reproduce

1. Use an AARCH64 BSP and build `6-freebsd-12`
2. Configure 2 interfaces
3. Use the default `dhcpcd` configuration with the options of `--debug --nobackground --timeout 30`
4. Mount and NSFv4 export soon after the interfaces are assigned IP4 addresses

## Analysis

1. The `if_options` structure is allocated memory when the options are read.
2. Options are assigned to interfaces.
3. The global `if_options` variable is freed and set to `NULL` before the event loop runs.

My guess is the options pointer is being held in an interface (or somewhere else) and something related to the IP6 DHCP protocol handling updates an option setting in the `requiremask6` field. It could be related to the configuration of the DHCP server and an option given sets and option in `requiremask6` to `1`.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/pkg/rtems-libbsd/-/issues/8
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20240918/c802106f/attachment.htm>