go.mod: bump insomniacslk/dhcp past the nclient4 ReadFrom panic fix - #1548
Open
thc1006 wants to merge 1 commit into
Open
go.mod: bump insomniacslk/dhcp past the nclient4 ReadFrom panic fix#1548thc1006 wants to merge 1 commit into
thc1006 wants to merge 1 commit into
Conversation
|
|
The DHCPv4 client in pkg/nmlite/jetdhcpc builds its nclient4 client with nclient4.New in pkg/nmlite/jetdhcpc/dhcp4.go, without WithUnicast, so it uses the default broadcast raw-socket connection. Replies for both client.Request and client.Renew come back through nclient4's BroadcastRawUDPConn.ReadFrom. The pin this repo was on, v0.0.0-20250919081422-f80a1952f48e, predates the fix for that read path. There ReadFrom subtracted the 8-byte UDP header from the IPv4 payload length without first checking that the payload was at least 8 bytes long, so a short or malformed reply gave a negative slice bound and panicked. That is insomniacslk/dhcp#583, which I wrote and which merged upstream on 2026-07-19. This moves the module to v0.0.0-20260719225207-c76316d4aa82, the pseudo-version at the jetkvm#583 merge commit. The fixed ReadFrom path drops the malformed frame and continues reading, instead of passing a negative length to buf.Consume. Only go.mod and go.sum change. I have not reproduced this against a running JetKVM. Whether a hostile reply can reach the client depends on the DHCP setup on the link, so this is defense in depth for the lease request and renew path rather than a confirmed remote crash. Verified with go build ./pkg/... and go vet ./pkg/nmlite/jetdhcpc/... on the new pin. A full go build ./... additionally needs the RK native libraries and the generated frontend assets, which are unrelated to this change. No CVE or GHSA is currently assigned to insomniacslk/dhcp#583 as of 2026-08-16. This PR picks up an upstream malformed-frame panic fix. I verified that this repository reaches the affected raw receive path, but I have not independently demonstrated project-specific exploitability or wide impact. Signed-off-by: thc1006 <84045975+thc1006@users.noreply.github.com>
thc1006
force-pushed
the
bump-insomniacslk-dhcp-583
branch
from
August 16, 2026 16:25
d5842f6 to
0bb01c7
Compare
thc1006
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The DHCPv4 client in
pkg/nmlite/jetdhcpcbuilds its nclient4 client withnclient4.New(dhcp4.go), withoutWithUnicast, so bothclient.Requestandclient.Renewread replies throughBroadcastRawUDPConn.ReadFrom.The pin here (
v0.0.0-20250919081422-f80a1952f48e) predates the fix. ThereReadFromsubtracted the 8-byte UDP header from the IPv4 payload length without checking the payload was at least 8 bytes, so a short or malformed reply gave a negative slice bound and panicked. That's insomniacslk/dhcp#583, which I wrote (merged 2026-07-19). The fixed path drops the malformed frame and keeps reading instead of passing a negative length tobuf.Consume.This moves the module to the #583 merge commit; only go.mod and go.sum change. I haven't reproduced this against a running JetKVM, and whether a hostile reply reaches the client depends on the DHCP setup on the link, so it's defense in depth for the lease and renew path rather than a confirmed remote crash. Verified with
go build ./pkg/...andgo vet ./pkg/nmlite/jetdhcpc/...; a fullgo build ./...also needs the RK native libraries and generated frontend assets, which are unrelated to this change.