linux-kernel - Re: [PATCH][v2] proc: use vmalloc for our kernel buffer

lists.openwall.net		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 linux-cve-announce 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 <josef@...icpanda.com>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     Christoph Hellwig <hch@....de>, linux-kernel@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, kernel-team@...com,
        willy@...radead.org
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. 
Thanks,

Josef