[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8c7594bc-401f-4347-825a-7ab3e4568671@cs.ucla.edu>
Date: Thu, 12 Mar 2026 15:48:12 -0700
From: Paul Eggert <eggert@...ucla.edu>
To: Collin Funk <collin.funk1@...il.com>, Solar Designer <solar@...nwall.com>
Cc: oss-security@...ts.openwall.com,
Justin Swartz <justin.swartz@...ingedge.co.za>,
Adiel Sol <adiel@...amgroup.com>, bug-gnulib@....org
Subject: Re: Remote Pre-Auth Buffer Overflow in GNU Inetutils
telnetd (LINEMODE SLC)
On 2026-03-12 13:57, Collin Funk wrote:
> Solar Designer <solar@...nwall.com> writes:...
>> /* Do nothing if the entire triplet cannot fit in the buffer. */
>> if (slcbuf + sizeof slcbuf <= slcptr + 6)
>> return;
>> In "slcptr + 6", it appears to rely on pointer math working outside of
>> the object, but that's UB in C.
That's right.
> CC'ing bug-gnulib. Do we make any assumptions about this behavior in
> Gnulib?
No, we follow C's rules in this respect. Pointers can't point outside
the addressed object (except that that they can point to the very next
byte and this exceptional pointer cannot be dereferenced).
>> A proper check may be:
>>
>> if (slcbuf + sizeof slcbuf - 6 <= slcptr)
That assumes that sizeof slcbuf is at least 6. Although that may be true
here, a safer idiom in general is:
if (slcbuf + sizeof slcbuf - slcptr <= 6)
This cannot overflow, if slcptr points within the buffer and the buffer
size does not exceed PTRDIFF_MAX (which is a safe assumption at least
with GNU malloc-allocated buffers).
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
