From: Dan Carpenter
Date: Tue, 1 Apr 2014 15:35:34 +0300
> I don't understand what you think the point of strlcpy() is, if it's not
> to deal with source strings which aren't NUL terminated.
If strlcpy() is meant to handle non-NULL terminated strings, then it's
kernel doc needs to be adjusted.
On Tue, Apr 01, 2014 at 01:02:55PM +0200, Hannes Frederic Sowa wrote:
> On Tue, Apr 01, 2014 at 12:46:37PM +0200, Vegard Nossum wrote:
> > On 04/01/2014 12:30 PM, Hannes Frederic Sowa wrote:
> > >Looking down the problem, it seems the problem is that the strlen in
> > >strlcpy
> > >could read
Vegard Nossum wrote:
> Both the in-kernel and BSD strlcpy() require that the source string is
> NUL terminated. We could use strncpy() + explicitly terminate the result,
> but this relies on src and dest having the same size, so the safest thing
> to do seems to explicitly terminate the source
On Tue, Apr 01, 2014 at 12:46:37PM +0200, Vegard Nossum wrote:
> On 04/01/2014 12:30 PM, Hannes Frederic Sowa wrote:
> >Looking down the problem, it seems the problem is that the strlen in
> >strlcpy
> >could read beyond the input buffer?
> >
> >To prevent this problem in other parts of the
On 04/01/2014 12:30 PM, Hannes Frederic Sowa wrote:
On Tue, Apr 01, 2014 at 12:08:18PM +0200, Vegard Nossum wrote:
Both the in-kernel and BSD strlcpy() require that the source string is
NUL terminated. We could use strncpy() + explicitly terminate the result,
but this relies on src and dest
On Tue, Apr 01, 2014 at 12:08:18PM +0200, Vegard Nossum wrote:
> Both the in-kernel and BSD strlcpy() require that the source string is
> NUL terminated. We could use strncpy() + explicitly terminate the result,
> but this relies on src and dest having the same size, so the safest thing
> to do
Both the in-kernel and BSD strlcpy() require that the source string is
NUL terminated. We could use strncpy() + explicitly terminate the result,
but this relies on src and dest having the same size, so the safest thing
to do seems to explicitly terminate the source string before doing the
Both the in-kernel and BSD strlcpy() require that the source string is
NUL terminated. We could use strncpy() + explicitly terminate the result,
but this relies on src and dest having the same size, so the safest thing
to do seems to explicitly terminate the source string before doing the
On Tue, Apr 01, 2014 at 12:08:18PM +0200, Vegard Nossum wrote:
Both the in-kernel and BSD strlcpy() require that the source string is
NUL terminated. We could use strncpy() + explicitly terminate the result,
but this relies on src and dest having the same size, so the safest thing
to do seems
On 04/01/2014 12:30 PM, Hannes Frederic Sowa wrote:
On Tue, Apr 01, 2014 at 12:08:18PM +0200, Vegard Nossum wrote:
Both the in-kernel and BSD strlcpy() require that the source string is
NUL terminated. We could use strncpy() + explicitly terminate the result,
but this relies on src and dest
On Tue, Apr 01, 2014 at 12:46:37PM +0200, Vegard Nossum wrote:
On 04/01/2014 12:30 PM, Hannes Frederic Sowa wrote:
Looking down the problem, it seems the problem is that the strlen in
strlcpy
could read beyond the input buffer?
To prevent this problem in other parts of the kernel wouldn't
Vegard Nossum wrote:
Both the in-kernel and BSD strlcpy() require that the source string is
NUL terminated. We could use strncpy() + explicitly terminate the result,
but this relies on src and dest having the same size, so the safest thing
to do seems to explicitly terminate the source string
On Tue, Apr 01, 2014 at 01:02:55PM +0200, Hannes Frederic Sowa wrote:
On Tue, Apr 01, 2014 at 12:46:37PM +0200, Vegard Nossum wrote:
On 04/01/2014 12:30 PM, Hannes Frederic Sowa wrote:
Looking down the problem, it seems the problem is that the strlen in
strlcpy
could read beyond the
From: Dan Carpenter dan.carpen...@oracle.com
Date: Tue, 1 Apr 2014 15:35:34 +0300
I don't understand what you think the point of strlcpy() is, if it's not
to deal with source strings which aren't NUL terminated.
If strlcpy() is meant to handle non-NULL terminated strings, then it's
kernel doc
From: Vegard Nossum
Date: Mon, 31 Mar 2014 14:56:07 +0200
> Ping, Dave? Just making sure this doesn't fall through the cracks. I
> don't see the patch applied anywhere yet and without this patch we
> still have a valid security concern IMO.
If it's not sent to netdev, it's not in my queue.
--
On 31 March 2014 15:36, Dan Carpenter wrote:
> On Mon, Mar 31, 2014 at 02:56:07PM +0200, Vegard Nossum wrote:
>> Ping, Dave? Just making sure this doesn't fall through the cracks. I
>> don't see the patch applied anywhere yet and without this patch we
>> still have a valid security concern IMO.
>
On Mon, Mar 31, 2014 at 02:56:07PM +0200, Vegard Nossum wrote:
> Ping, Dave? Just making sure this doesn't fall through the cracks. I
> don't see the patch applied anywhere yet and without this patch we
> still have a valid security concern IMO.
Gar. No... To recap:
> On 7 March 2014 11:56,
On 7 March 2014 11:56, Vegard Nossum wrote:
> Both the in-kernel and BSD strlcpy() require that the source string is
> NUL terminated. We could use strncpy() + explicitly terminate the result,
> but this relies on src and dest having the same size, so the safest thing
> to do seems to explicitly
On 7 March 2014 11:56, Vegard Nossum vegard.nos...@oracle.com wrote:
Both the in-kernel and BSD strlcpy() require that the source string is
NUL terminated. We could use strncpy() + explicitly terminate the result,
but this relies on src and dest having the same size, so the safest thing
to do
On Mon, Mar 31, 2014 at 02:56:07PM +0200, Vegard Nossum wrote:
Ping, Dave? Just making sure this doesn't fall through the cracks. I
don't see the patch applied anywhere yet and without this patch we
still have a valid security concern IMO.
Gar. No... To recap:
On 7 March 2014 11:56, Vegard
On 31 March 2014 15:36, Dan Carpenter dan.carpen...@oracle.com wrote:
On Mon, Mar 31, 2014 at 02:56:07PM +0200, Vegard Nossum wrote:
Ping, Dave? Just making sure this doesn't fall through the cracks. I
don't see the patch applied anywhere yet and without this patch we
still have a valid
From: Vegard Nossum vegard.nos...@gmail.com
Date: Mon, 31 Mar 2014 14:56:07 +0200
Ping, Dave? Just making sure this doesn't fall through the cracks. I
don't see the patch applied anywhere yet and without this patch we
still have a valid security concern IMO.
If it's not sent to netdev, it's
On Fri, Mar 07, 2014 at 01:44:17PM +0100, Vegard Nossum wrote:
> On 03/07/2014 12:52 PM, Dan Carpenter wrote:
> >On Fri, Mar 07, 2014 at 12:42:12PM +0100, Vegard Nossum wrote:
> >>On 03/07/2014 12:26 PM, Dan Carpenter wrote:
> >>>On Fri, Mar 07, 2014 at 11:56:04AM +0100, Vegard Nossum wrote:
>
On 03/07/2014 12:52 PM, Dan Carpenter wrote:
On Fri, Mar 07, 2014 at 12:42:12PM +0100, Vegard Nossum wrote:
On 03/07/2014 12:26 PM, Dan Carpenter wrote:
On Fri, Mar 07, 2014 at 11:56:04AM +0100, Vegard Nossum wrote:
Both the in-kernel and BSD strlcpy() require that the source string is
NUL
On Fri, Mar 07, 2014 at 12:42:12PM +0100, Vegard Nossum wrote:
> On 03/07/2014 12:26 PM, Dan Carpenter wrote:
> >On Fri, Mar 07, 2014 at 11:56:04AM +0100, Vegard Nossum wrote:
> >>Both the in-kernel and BSD strlcpy() require that the source string is
> >>NUL terminated.
> >
> >No. You're
On 03/07/2014 12:26 PM, Dan Carpenter wrote:
On Fri, Mar 07, 2014 at 11:56:04AM +0100, Vegard Nossum wrote:
Both the in-kernel and BSD strlcpy() require that the source string is
NUL terminated.
No. You're obviously wrong. What on earth?
Well, from lib/string.c:
size_t strlcpy(char
On Fri, Mar 07, 2014 at 11:56:04AM +0100, Vegard Nossum wrote:
> Both the in-kernel and BSD strlcpy() require that the source string is
> NUL terminated.
No. You're obviously wrong. What on earth?
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe
Both the in-kernel and BSD strlcpy() require that the source string is
NUL terminated. We could use strncpy() + explicitly terminate the result,
but this relies on src and dest having the same size, so the safest thing
to do seems to explicitly terminate the source string before doing the
Both the in-kernel and BSD strlcpy() require that the source string is
NUL terminated. We could use strncpy() + explicitly terminate the result,
but this relies on src and dest having the same size, so the safest thing
to do seems to explicitly terminate the source string before doing the
On Fri, Mar 07, 2014 at 11:56:04AM +0100, Vegard Nossum wrote:
Both the in-kernel and BSD strlcpy() require that the source string is
NUL terminated.
No. You're obviously wrong. What on earth?
regards,
dan carpenter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
On 03/07/2014 12:26 PM, Dan Carpenter wrote:
On Fri, Mar 07, 2014 at 11:56:04AM +0100, Vegard Nossum wrote:
Both the in-kernel and BSD strlcpy() require that the source string is
NUL terminated.
No. You're obviously wrong. What on earth?
Well, from lib/string.c:
size_t strlcpy(char
On Fri, Mar 07, 2014 at 12:42:12PM +0100, Vegard Nossum wrote:
On 03/07/2014 12:26 PM, Dan Carpenter wrote:
On Fri, Mar 07, 2014 at 11:56:04AM +0100, Vegard Nossum wrote:
Both the in-kernel and BSD strlcpy() require that the source string is
NUL terminated.
No. You're obviously wrong.
On 03/07/2014 12:52 PM, Dan Carpenter wrote:
On Fri, Mar 07, 2014 at 12:42:12PM +0100, Vegard Nossum wrote:
On 03/07/2014 12:26 PM, Dan Carpenter wrote:
On Fri, Mar 07, 2014 at 11:56:04AM +0100, Vegard Nossum wrote:
Both the in-kernel and BSD strlcpy() require that the source string is
NUL
On Fri, Mar 07, 2014 at 01:44:17PM +0100, Vegard Nossum wrote:
On 03/07/2014 12:52 PM, Dan Carpenter wrote:
On Fri, Mar 07, 2014 at 12:42:12PM +0100, Vegard Nossum wrote:
On 03/07/2014 12:26 PM, Dan Carpenter wrote:
On Fri, Mar 07, 2014 at 11:56:04AM +0100, Vegard Nossum wrote:
Both the
34 matches
Mail list logo
