]> git.ipfire.org Git - thirdparty/pdns.git/commit
Fix incorrect length check in `DNSName` when extracting qtype or qclass 4739/head
authorRemi Gacogne <remi.gacogne@powerdns.com>
Thu, 1 Dec 2016 12:00:13 +0000 (13:00 +0100)
committerRemi Gacogne <remi.gacogne@powerdns.com>
Mon, 5 Dec 2016 10:20:20 +0000 (11:20 +0100)
commit400e28d3c958068a6bc2903cf1a89443bb6e078e
treebbeea316aadf2181866de0893e6a81fcf66e2787
parent1dde8cc822a529fa2e440fe94c875cded0df71ee
Fix incorrect length check in `DNSName` when extracting qtype or qclass

In `DNSName::packetParser()`, the length check might have been incorrect
when the caller asked for the `qtype` and/or the `qclass` to be extracted.
The `pos + labellen + 2 > end` check was wrong because `pos` might have already
been incremented by `labellen`. There are 3 ways to exit the main loop:

* `labellen` is 0, the most common case, and in that case the check is valid
* `pos >= end`, meaning that `pos + labellen + 2 > end` will be true regardless
of the value of `labellen` since it cannot be negative
* if `uncompress` is set and a compressed label is found, the main loop is
broken out of, and `labellen` still holds a now irrelevant, possibly non-zero value
corresponding to the first byte of the compressed label length & ~0xc0.

In that last case, if the compressed label points to a position > 255 the check
is wrong and might have rejected a valid packet.
A quick look throught the code didn't show any place where we request decompression
and ask for `qtype` and/or `qclass` in a response, but I might have missed one.

Reported by Houssam El Hajoui (thanks!).

(cherry picked from commit 7b9c052c617d02e1870195d0f216732047d56e22)
pdns/dnsname.cc
pdns/test-dnsname_cc.cc