lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 13 Aug 2020 13:36:09 -0400
From:   Josef Bacik <>
To:     Al Viro <>
Cc:     Christoph Hellwig <>,,,,
Subject: Re: [PATCH][v2] proc: use vmalloc for our kernel buffer

On 8/13/20 1:31 PM, Al Viro wrote:
> On Thu, Aug 13, 2020 at 01:19:18PM -0400, Josef Bacik wrote:
>>> in sunrpc proc_dodebug() turns into
>>> 		left -= snprintf(buffer, left, "0x%04x\n",
> 					 ^^^^
> 					 left + 1, that is.
>>> 				 *(unsigned int *) table->data);
>>> and that's not the only example.
>> We wouldn't even need the extra +1 part, since we're only copying in how
>> much the user wants anyway, we could just go ahead and convert this to
>> left -= snprintf(buffer, left, "0x%04x\n", *(unsigned int *) table->data);
>> and be fine, right?  Or am I misunderstanding what you're looking for?  Thanks,
> snprintf() always produces a NUL-terminated string.  And if you are passing 7 as
> len, you want 0xf0ad\n to be copied to user.  For that you need 8 passed to
> snprintf, and 8-byte buffer given to it.

Right, gotcha.  I'll rig that up and see how it looks.  I'd recommend looking 
through what I do with a fine tooth comb, I'm obviously not batting 1000 today. 


Powered by blists - more mailing lists