> ...
> long is always the same or bigger then a pointer
> (A pointer must always fit in a long)
> ...
Linux may make that assumption, but it doesn't have
to be true. 64bit windows still has 32bit long.
C99 inttypes.h defines [u]intptr_t to be an integral type
that is large enough to hold a pointe
On Wed, Oct 17, 2012 at 01:59:39PM -0400, Sasha Levin wrote:
> On Wed, Jul 18, 2012 at 1:39 PM, J. Bruce Fields wrote:
> > On Tue, Jul 17, 2012 at 12:01:26AM +0200, Sasha Levin wrote:
> >> The buffer size in read_flush() is too small for the longest possible
> >> values
> >> for it. This can lead
On 07/18/2012 01:55 PM, Jim Rees wrote:
> Dave Jones wrote:
>
>
> Unsigned long isn't necessarily 32 bits.
> On 64-bit systems %lu can be up to 18446744073709551615
>
> Thanks. You caught me thinking "Intel." How embarrassing.
What? why even on Intel-64 long is 64bit. long is always the
On Wed, Jul 18, 2012 at 1:39 PM, J. Bruce Fields wrote:
> On Tue, Jul 17, 2012 at 12:01:26AM +0200, Sasha Levin wrote:
>> The buffer size in read_flush() is too small for the longest possible values
>> for it. This can lead to a kernel stack corruption:
>
> Thanks!
I've just stumbled on this cras
Sasha Levin wrote:
> Learning from what happened in this specific case, there are actually 2
issues here:
>
> - Array size was constant and too small, which is solved by the patch
above.
> - We were blindly trying to sprintf() into that array, this issue may pop
back up if someone de
On 07/18/2012 11:33 PM, Sasha Levin wrote:
> On 07/18/2012 11:08 PM, J. Bruce Fields wrote:
>> On Wed, Jul 18, 2012 at 04:00:49PM -0400, Jim Rees wrote:
>>> J. Bruce Fields wrote:
>>>
>>> On Tue, Jul 17, 2012 at 12:01:26AM +0200, Sasha Levin wrote:
>>> > The buffer size in read_flush() is too s
On Wed, Jul 18, 2012 at 04:00:49PM -0400, Jim Rees wrote:
> J. Bruce Fields wrote:
>
> On Tue, Jul 17, 2012 at 12:01:26AM +0200, Sasha Levin wrote:
> > The buffer size in read_flush() is too small for the longest possible
> values
> > for it. This can lead to a kernel stack corruption:
>
Dave Jones wrote:
On Wed, Jul 18, 2012 at 04:00:49PM -0400, Jim Rees wrote:
> You could use something like:
>
> char tbuf[sizeof (unsigned long) * 24 / 10 + 1 + 2]; /* + 2 for final
"\n\0" */
>
> since there are roughly 10 bits for every 3 decimal digits.
>
> But
On Wed, Jul 18, 2012 at 04:00:49PM -0400, Jim Rees wrote:
> You could use something like:
>
> char tbuf[sizeof (unsigned long) * 24 / 10 + 1 + 2]; /* + 2 for final
> "\n\0" */
>
> since there are roughly 10 bits for every 3 decimal digits.
>
> But I'm obviously confused, because I
J. Bruce Fields wrote:
On Tue, Jul 17, 2012 at 12:01:26AM +0200, Sasha Levin wrote:
> The buffer size in read_flush() is too small for the longest possible values
> for it. This can lead to a kernel stack corruption:
Thanks!
>
> diff --git a/net/sunrpc/cache.c b/net/sunrpc/cache
On Tue, Jul 17, 2012 at 12:01:26AM +0200, Sasha Levin wrote:
> The buffer size in read_flush() is too small for the longest possible values
> for it. This can lead to a kernel stack corruption:
Thanks!
>
> diff --git a/net/sunrpc/cache.c b/net/sunrpc/cache.c
> index 2afd2a8..f86d95e 100644
> ---
The buffer size in read_flush() is too small for the longest possible values
for it. This can lead to a kernel stack corruption:
[ 43.047329] Kernel panic - not syncing: stack-protector: Kernel stack is
corrupted in: 833e64b4
[ 43.047329]
[ 43.049030] Pid: 6015, comm: trinity-child1
12 matches
Mail list logo
