Hi Willy,

Thanks for response and correcting the mistake.

Its OK for you to fix this.
marking this as MEDIUM is also fine :).

Regards,
Nikhil Agrawal



On Fri, Dec 21, 2018 at 2:58 PM Willy Tarreau <w...@1wt.eu> wrote:

> Hi,
>
> On Fri, Dec 21, 2018 at 11:02:24AM +0530, Nikhil Agrawal wrote:
> > Dear Haproxy Maintainers,
> >
> > In dns_read_name() when dns name is used with name compression and start
> > position of name is greater than 255, name is read from incorrect
> position
> > ( actual position%256). This causes "Invalid dns error" and backend is
> > marked as down permanently.
> > eg: hexadecimal value at start of dns "0xc1 1b". "0xc" specifies name
> > compression being used. in this scenario only "1b" (27) is taken as the
> > start of the name but actual name starts from "11b" (283).
> >
> >
> > This is a regression scenario starting from version 1.7.0 and is present
> in
> > current version.
> >
> > Resolution:
> > Include nibble from byte used for checking compression. i.e take "11b" as
> > start position of dns name.
> >
> > i am attaching patch to fix this bug.
>
> It's indeed a bug, however after checking RFC1035, your patch is still
> bogus as it only includes 4 of the 6 bits :
>
>   https://tools.ietf.org/html/rfc1035#section-4.1.4
>
>     The pointer takes the form of a two octet sequence:
>
>     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>     | 1  1|                OFFSET                   |
>     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>             ^     ^
>             |     |
>             |     +----- your patch starts here
>             +----------- the standard says the length starts here
>
> If you're OK with this I can simply fix it, just let me know. Also I'd
> relabel it as medium, as it's an annoyance that requires some efforts to
> be worked around, but not a major loss of functionality.
>
> Thanks for the test case by the way ;-)
>
> Willy
>

Reply via email to