Skip to content

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

Open
rootvector2 wants to merge 3 commits intoModdable-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 intoModdable-OpenSource:publicfrom
rootvector2:dns-parser-memory-safety

Conversation

@rootvector2
Copy link
Copy Markdown

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

Copy link
Copy Markdown
Collaborator

@phoddie phoddie left a comment

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.

…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
Author

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

@phoddie
Copy link
Copy Markdown
Collaborator

phoddie commented Mar 23, 2026

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
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
Copy link
Copy Markdown
Collaborator

phoddie commented Mar 25, 2026

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
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
Copy link
Copy Markdown
Collaborator

phoddie commented Mar 25, 2026

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

@rootvector2
Copy link
Copy Markdown
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
Copy link
Copy Markdown
Collaborator

phoddie commented Mar 25, 2026

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
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
Copy link
Copy Markdown
Collaborator

phoddie commented Mar 26, 2026

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