Skip to content

enhance memory safety in DNS parser by adding bounds checks#1576

Open
rootvector2 wants to merge 3 commits into
Moddable-OpenSource:publicfrom
rootvector2:dns-parser-memory-safety
Open

enhance memory safety in DNS parser by adding bounds checks#1576
rootvector2 wants to merge 3 commits into
Moddable-OpenSource:publicfrom
rootvector2:dns-parser-memory-safety

Conversation

@rootvector2

Copy link
Copy Markdown
Contributor

Fix memory-safety issues in DNS parsing (bounds checks, pointer validation, integer underflow) to prevent out-of-bounds reads and malformed packet handling issues.

@phoddie phoddie left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR to harden the DNS parsing. Very much appreciated. I left a few notes for changes. In particular, it is important to keep in mind that the garbage collector in the XS engine compacts memory, which can invalidate pointers held in C.

Before we can merge this PR, we need you to complete our Contributor License Agreement - choose either the Individual or corporate, as appropriate.

Comment thread modules/network/dns/moddnsparser.c
Comment thread modules/network/dns/moddnsparser.c
Comment thread modules/network/dns/moddnsparser.c Outdated
…ds checks

- Move xsNewArray() before getPacket() in parseQname so GC triggered
  by xsNewArray cannot invalidate the packetStart/packetEnd pointers
- Re-fetch packetStart and packetEnd after xsmcSetStringBuffer and
  xsCall1 in parseQname loop since both can trigger GC and move memory
- Consolidate inner name-label traversal from 'while (true)' with
  multiple early-return guards to 'while (position < packetEnd)' in
  both getQuestionByIndex and getAnswerByIndex, relying on the existing
  post-loop bounds check to catch malformed packets (per phoddie review)
@rootvector2

Copy link
Copy Markdown
Contributor Author

I’ve completed the CLA (individual). Please let me know where to send the signed copy.

@phoddie

phoddie commented Mar 23, 2026

Copy link
Copy Markdown
Collaborator

I’ve completed the CLA (individual). Please let me know where to send the signed copy.

Please send a scan (preferably PDF) by email to info@moddable.com. Thank you.

@rootvector2

Copy link
Copy Markdown
Contributor Author

I’ve completed the CLA (individual). Please let me know where to send the signed copy.

Please send a scan (preferably PDF) by email to info@moddable.com. Thank you.

ok Sent

@phoddie

phoddie commented Mar 25, 2026

Copy link
Copy Markdown
Collaborator

Thanks – we received the CLA.

There is an inconsistency. Most of the changes throw when invalid data is detected. I think that's the right behavior. The one exception is the txt parsing – which exits early without reporting an error. That means that the script is unaware that it is working with incomplete, possible corrupt, information. Is there a reason for the different behaviors? If not, my feeling is that the txt parsing should throw when it detects incorrect data.

@rootvector2

Copy link
Copy Markdown
Contributor Author

I agree that silently exiting in TXT parsing can lead to incomplete or misleading data being returned to the script. It should behave consistently with the rest of the parser and throw on invalid input.

I’ll update the TXT parsing to throw an error instead of breaking.

@phoddie

phoddie commented Mar 25, 2026

Copy link
Copy Markdown
Collaborator

Great, thank you. We should have everything needed to merge this as part of our upcoming April release.

@rootvector2

Copy link
Copy Markdown
Contributor Author

Thanks, really appreciate the review and guidance!

If there’s anything else I can help with or take up, feel free to let me know.

@phoddie

phoddie commented Mar 25, 2026

Copy link
Copy Markdown
Collaborator

Happy to have the help! I am curious... the parsing errors are real but a bit obscure. How did you stumble over them in the first place?

@rootvector2

Copy link
Copy Markdown
Contributor Author

Honestly, I was just going through the DNS parser with a focus on how it handles malformed inputs and memory safety. I noticed a few TODO comments and some places where bounds checks were missing, especially around label parsing and compression pointers.

That got me curious, so I followed those paths and tried to think through how malformed packets might behave, which is how I ended up spotting those cases.

@phoddie

phoddie commented Mar 26, 2026

Copy link
Copy Markdown
Collaborator

Very cool! If you are looking for a good challenge, staying within the DNS module the serializer (dnsserializer.js) takes a shortcut storing names that results in bigger packets and, I believe, may be strictly non-conforming. The names passed to add are supposed to appear in the serialized packet just once, with occurrences beyond the first pointing back to the original. The requires some additional bookkeeping during serialization. If you look at the way the DNS-SD code uses the serialized to construct packets, you can see how the same name will appear in several different parts of its packets.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants