linux-kernel - Re: [PATCH v6 22/26] rust: alloc: implement `Cmalloc` in module allocator

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bf158e23-4123-419b-a2ce-a27c4ea51219@proton.me>
Date: Wed, 11 Sep 2024 13:32:31 +0000
From: Benno Lossin <benno.lossin@...ton.me>
To: Danilo Krummrich <dakr@...nel.org>
Cc: ojeda@...nel.org, alex.gaynor@...il.com, wedsonaf@...il.com, boqun.feng@...il.com, gary@...yguo.net, bjorn3_gh@...tonmail.com, a.hindborg@...sung.com, aliceryhl@...gle.com, akpm@...ux-foundation.org, daniel.almeida@...labora.com, faith.ekstrand@...labora.com, boris.brezillon@...labora.com, lina@...hilina.net, mcanal@...lia.com, zhiw@...dia.com, cjia@...dia.com, jhubbard@...dia.com, airlied@...hat.com, ajanulgu@...hat.com, lyude@...hat.com, linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH v6 22/26] rust: alloc: implement `Cmalloc` in module allocator_test

On 11.09.24 14:31, Danilo Krummrich wrote:
> On Fri, Aug 30, 2024 at 12:25:27AM +0200, Danilo Krummrich wrote:
>> On Thu, Aug 29, 2024 at 07:14:18PM +0000, Benno Lossin wrote:
>>> On 16.08.24 02:11, Danilo Krummrich wrote:
>>>> +
>>>> +        if layout.size() == 0 {
>>>> +            // SAFETY: `src` has been created by `Self::alloc_store_data`.
>>>
>>> This is not true, consider:
>>>
>>>     let ptr = alloc(size = 0);
>>>     free(ptr)
>>>
>>> Alloc will return a dangling pointer due to the first if statement and
>>> then this function will pass it to `free_read_data`, even though it
>>> wasn't created by `alloc_store_data`.
>>> This isn't forbidden by the `Allocator` trait function's safety
>>> requirements.
>>>
>>>> +            unsafe { Self::free_read_data(src) };
>>>> +
>>>> +            return Ok(NonNull::slice_from_raw_parts(NonNull::dangling(), 0));
>>>> +        }
>>>> +
>>>> +        let dst = Self::alloc(layout, flags)?;
>>>> +
>>>> +        // SAFETY: `src` has been created by `Self::alloc_store_data`.
>>>> +        let data = unsafe { Self::data(src) };
>>>
>>> Same issue here, if the allocation passed in is zero size. I think you
>>> have no other choice than to allocate even for zero size requests...
>>> Otherwise how would you know that they are zero-sized.
>>
>> Good catch - gonna fix it.
> 
> Almost got me. :) I think the code is fine, callers are not allowed to pass
> pointers to `realloc` and `free`, which haven't been allocated with the same
> corresponding allocator or are dangling.

But what about the example above (ie the `alloc(size = 0)` and then
`free`)? I guess this all depends on how one interprets the term
"existing, valid memory allocation". To me that describes anything an
`Allocator` returns via `alloc` and `realloc`, including zero-sized
allocations.
But if you argue that those are not valid allocations from that
allocator, then that is not properly documented in the safety
requirements of `Allocator`. 

---
Cheers,
Benno