Add support for RFC 2132 Message option in NAK handling

[ColinMcInnes]

If the dhcpcd server sends Option 56 (message) as part of a DHCPv4 NAK, pass it on to the exit hook environment so it can be acted on if necessary.

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: fe15969d-4b70-45b8-a346-86232c291577

📥 Commits

Reviewing files that changed from the base of the PR and between 860739c and 5905b2b.

📒 Files selected for processing (2)

• src/dhcp.h
• src/script.c

Included review availability: This review used your included allowance. Your plan provides up to 2 included reviews per hour; 1 remain after this review.

---

Walkthrough

DHCP NAK handling now stores RFC 2132 option 56 text in DHCP state. For NAK events, make_env exports the text as message and clears the stored value. The hook documentation describes this variable.

Changes

DHCP NAK message export

Layer / File(s)	Summary
Capture and manage NAK messages src/dhcp.h, src/dhcp.c	DHCP state stores the NAK message. NAK handling captures the DHO_MESSAGE option, and DHCP cleanup frees the stored text.
Export and document the message src/script.c, hooks/dhcpcd-run-hooks.8.in	For NAK events, make_env exports the stored message as message=<value> and clears it. The hook documentation describes the variable.

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Feature

Sequence Diagram(s)

sequenceDiagram
  participant DHCP_Server as DHCP server
  participant dhcp_handledhcp
  participant dhcp_state as DHCP state
  participant make_env
  participant Script_Hook as Script hook
  DHCP_Server->>dhcp_handledhcp: Send NAK with DHO_MESSAGE
  dhcp_handledhcp->>dhcp_state: Store message text
  dhcp_handledhcp->>dhcp_state: Drop lease
  make_env->>dhcp_state: Read message text
  make_env->>Script_Hook: Export message=<value>
  make_env->>dhcp_state: Free and clear message

Loading

Suggested reviewers: rsmarples

Merge Risk: ⚪ Minimal · up to 5905b

The optional DHCP NAK message reaches the hook environment, with retained memory cleaned up appropriately. No actionable merge-blocking risk remains.

Security Architecture Review

Security architecture risk: 🔵 Low · up to 5905b

Server-controlled text now reaches local hooks, but it remains environment data rather than executable code and does not change hook privileges. Deployment-specific hooks must still treat the value as untrusted input; their behavior was not verified.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — A server, or an attacker able to submit an accepted NAK, can supply message text to the affected interface's hook environment and existing listeners. The message slot is interface-local, but downstream effects depend on the authority and behavior of configured hooks.

Trust Boundaries and Controls

• observed — Option text crosses from the network into hook data through OT_ESCSTRING conversion and NUL-delimited serialization. Hook execution uses the configured executable and existing privileged dispatch. Printable shell metacharacters are not generally removed by this encoding, so it is not a guarantee of safety if a downstream hook deliberately evaluates the value.

Resilience and Maintainability Implications

• observed — Subsequent accepted NAKs replace the pending allocation, successful serialization clears it, and teardown frees any remainder. This bounds ownership to one interface-state slot rather than accumulating messages across events.

Hardening Proposals

• proposed — Document $message as untrusted server-supplied data and discourage evaluating it as shell code or using its text alone as authorization for privileged actions. This is preventive guidance, not an observed downstream vulnerability.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 4 functions across 3 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description check	✅ Passed	The description accurately states that DHCPv4 Option 56 is passed from a DHCP NAK to the exit hook environment.
Title check	✅ Passed	The title clearly identifies the main change: support for the RFC 2132 Message option during NAK handling.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

• Fix all pre-merge checks with AI

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[ColinMcInnes]

recheck