-
-
Notifications
You must be signed in to change notification settings - Fork 197
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update embedded dnsmasq to latest tag v2.91test2 #2136
Merged
Merged
Conversation
This file contains 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
Also applies to SetFilterAAAA. Thanks to Clayton Craft for spotting the issue. Signed-off-by: DL6ER <[email protected]>
In generalising the RR filter code, the Dbus methods controlling filtering A and AAAA records got severely broken. This, and the previous commit, fixes things. Signed-off-by: DL6ER <[email protected]>
Signed-off-by: renmingshuai <[email protected]> Signed-off-by: DL6ER <[email protected]>
CAP_NET_ADMIN is needed in the DHCPv4 code to place entries into the ARP cache. If it's configured to unconditionally broadcast to unconfigured clients, it never touches the ARP cache and doesn't need CAP_NET_ADMIN. Thanks to Martin Ivičič <[email protected]> for prompting this. Signed-off-by: DL6ER <[email protected]>
…ource problem and fail validation with suitable logging. Signed-off-by: DL6ER <[email protected]>
Confusion in the code to free old DHCP configuration when it's being reloaded causes invalid pointers to be followed and a crash. https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2024q4/017764.html has a more complete explanation of the problem. Signed-off-by: DL6ER <[email protected]>
The msg_controllen field passed to sendmsg is computed using the CMSG_SPACE(), which is correct, but CMSG_SPACE() can include padding bytes at the end of the passed structure if they are required to align subsequent structures in the buffer. Make sure these bytes are zeroed to avoid passing uninitiased memory to the kernel, even though it will never touch these bytes. Also tidy up the mashalling code in send_from to use pointers to the structure being filled out, rather than a temporary copy which then gets memcpy()'d into place. The DHCP sendmsg code has always worked like this. Thanks to Dominik Derigs for running Memcheck as submitting the initial patch. Signed-off-by: DL6ER <[email protected]>
Heretofore, when a validating the result of an external query triggers a DNSKEY or DS query and the result of that query is truncated, dnsmasq has forced the whole validation process to move to TCP by returning a truncated reply to the original requestor. This forces the original requestor to retry the query in TCP mode, and the DNSSEC subqueries also get made via TCP and everything works. Note that in general the actual answer being validated is not large enough to trigger truncation, and there's no reason not to return that answer via UDP if we can validate it successfully. It follows that a substandard client which can't do TCP queries will still work if the answer could be returned via UDP, but fails if it gets an artifically truncated answer and cannot move to TCP. This patch teaches dnsmasq to move to TCP for DNSSEC queries when validating UDP answers. That makes the substandard clients mentioned above work, and saves a round trip even for clients that can do TCP. Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
…P) retry once we've switched to TCP. Signed-off-by: DL6ER <[email protected]>
…ating. A relatively common situation is that the reply to a downstream query will fit in a UDP packet when no DNSSEC RRs are present, but overflows when the RRSIGS, NSEC ect are added. This extends the automatic move from UDP to TCP to downstream queries which get truncated replies, in the hope that once stripped of the DNSSEC RRs, the reply can be returned via UDP, nwithout making the downstream retry with TCP. If the downstream sets the DO bit, (ie it wants the DNSSEC RRs, then this path is not taken, since the downstream will have to get a truncated repsonse and retry to get a correct answer. Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
We do this in many cases anyway (DNSSEC, fast-retry) and doing it unconditionally allows much simplification of knarly code, to follow. Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
Now we're always saving the query, this is no longer necessary, and allows the removal of a lot of quite hairy code. Much more code removal to come, once the TCP code path is also purged. Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
They have smaller structs which don't include that field, so this is a buffer overlow. Error introduced in f5cdb007d8845dde8e5053229f47b46b1b756473 Signed-off-by: DL6ER <[email protected]>
We only need to order two server records on the ->serial field. Literal address records are smaller and don't have this field and don't need to be ordered on it. To actually provoke this bug seems to need the same server-literal to be repeated twice, eg --address=/a/1.1.1.1 --address-/a/1.1.1.1 which is clearly rare in the wild, but if it did exist it could provoke a SIGSEV. Thanks to Daniel Rhea for fuzzing this one. Signed-off-by: DL6ER <[email protected]>
…ong. Thanks to Daniel Rhea for finding this one. Signed-off-by: DL6ER <[email protected]>
The saved query includes all the modifications, made on first forwarding, which simplifies retries. Signed-off-by: DL6ER <[email protected]>
Analogous fix to 5a1f2c577db58ea47727f1b6900c0be25e6db205 for DHCPv6 relay. Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
Opening this as draft for now as there is an issue with 7572e59 which is currently under investigation in private communication. |
DL6ER
changed the title
Update embedded dnsmasq to latest tas v2.91test1
Update embedded dnsmasq to latest tag v2.91test1
Dec 20, 2024
Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
It's not t a thing of beauty, but it's less ugly than it was. Any bugs, I blame on what I started from.... Signed-off-by: DL6ER <[email protected]>
This reverts commit ddc4074. Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
This reverts commit aea70ef. Signed-off-by: DL6ER <[email protected]>
Thanks to Matthias Andree for pointing out this one. Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
Signed-off-by: DL6ER <[email protected]>
DL6ER
changed the title
Update embedded dnsmasq to latest tag v2.91test1
Update embedded dnsmasq to latest tag v2.91test2
Dec 21, 2024
yubiuser
reviewed
Dec 21, 2024
yubiuser
approved these changes
Dec 21, 2024
This was referenced Dec 22, 2024
This pull request has been mentioned on Pi-hole Userspace. There might be relevant details there: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What does this implement/fix?
See title.
CHANGELOG:
-Fix handling of EDNS0 UDP packet sizes. When talking upstream we always add a pseudoheader, and set the UDP packet size to --edns-packet-max. Answering queries from downstream, we get the answer (either from upstream or local data) If local data won't fit the advertised size (or 512 if there's not an EDNS0 header) return truncated. If upstream returns truncated, do likewise. If upstream is OK, but the answer is too big for downstream, truncate the answer.
Related issue or feature (if applicable): N/A
Pull request in docs with documentation (if applicable): N/A
By submitting this pull request, I confirm the following:
git rebase
)Checklist:
developmental
branch.