Skip to content
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

Fix FTL crashes in ARP table parsing #723

Merged
merged 11 commits into from
Apr 2, 2020
Merged

Fix FTL crashes in ARP table parsing #723

merged 11 commits into from
Apr 2, 2020

Conversation

DL6ER
Copy link
Member

@DL6ER DL6ER commented Apr 2, 2020

By submitting this pull request, I confirm the following:

  • I have read and understood the contributors guide.
  • I have checked that another pull request for this purpose does not exist.
  • I have considered, and confirmed that this submission will be valuable to others.
  • I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
  • I give this submission freely, and claim no ownership to its content.

How familiar are you with the codebase?:

10


This PR fixes a bug in release/v5.0 reported in #718.

The underlying heap memory access violation occurred only when there are both, multiple addresses for the same devices in the ARP table, and only some of these addresses are already known to FTL (i.e., they sent DNS queries to the Pi-hole before).
If either all addresses of a device (or likely none) were already known to FTL because they made requests in the past, this bug doesn’t show up.
This is likely because users with IPv6 are much more likely to see this bug as there is a high likelihood that an interface has at least one address that has never been used to ask Pi-hole any questions. Multiple addresses on the same interface are rather seldom in the IPv4-world.

As a side-effect of my code review, I also found two small memory leaks which are now fixed. There is a small remaining leak in the system-provided function gethostbyaddr() but we cannot do anything about it. The worst seems to be leaking 110 bytes once during the first name resolution. This sounds perfectly acceptable.

DL6ER added 11 commits April 2, 2020 15:14
Signed-off-by: DL6ER <dl6er@dl6er.de>
Signed-off-by: DL6ER <dl6er@dl6er.de>
Signed-off-by: DL6ER <dl6er@dl6er.de>
…en leakage of more than 110 bytes)

Signed-off-by: DL6ER <dl6er@dl6er.de>
Signed-off-by: DL6ER <dl6er@dl6er.de>
…Skip otherwise.

Signed-off-by: DL6ER <dl6er@dl6er.de>
…t is not our job to care about them if they are not doing any DNS queries.

Signed-off-by: DL6ER <dl6er@dl6er.de>
Signed-off-by: DL6ER <dl6er@dl6er.de>
@DL6ER DL6ER added the Bugfix label Apr 2, 2020
@DL6ER DL6ER added this to the v5.0 milestone Apr 2, 2020
@DL6ER DL6ER requested review from PromoFaux and dschaper April 2, 2020 16:44
@DL6ER DL6ER merged commit 78e0332 into release/v5.0 Apr 2, 2020
@DL6ER DL6ER deleted the fix/arp_crash branch April 2, 2020 19:07
@DL6ER DL6ER linked an issue Apr 2, 2020 that may be closed by this pull request
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

FTL crashing while DHCP server is enabled
2 participants