Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add alloc_size markers to memory allocation functions #5

Closed
kees opened this issue Sep 26, 2019 · 3 comments
Closed

Add alloc_size markers to memory allocation functions #5

kees opened this issue Sep 26, 2019 · 3 comments
Assignees
Labels
[Linux] v5.16 Released in Linux kernel v5.16

Comments

@kees
Copy link

kees commented Sep 26, 2019

In order to improve compile-time object size overflow detection (for things like CONFIG_FORTIFY_SOURCE), add the alloc_size attribute to memory allocation functions. This is complicated by the fact that kmalloc* family may have a usable size greater than the requested size (see ksize()).

For example, see:

anthraxx/linux-hardened@7466f84
anthraxx/linux-hardened@3299e78
anthraxx/linux-hardened@a2aa805
anthraxx/linux-hardened@41d33dc
anthraxx/linux-hardened@a413687

@kees kees added the [PATCH] Exists A patch exists to address the issue label Sep 26, 2019
@kees
Copy link
Author

kees commented Feb 26, 2020

Capturing a review note from the recent patch series:

https://lore.kernel.org/lkml/20200120074344.504-1-dja@axtens.net/#r

Kees Cook <keescook@chromium.org> writes:
> On Fri, Feb 07, 2020 at 03:38:22PM -0500, Daniel Micay wrote:
>> There are some uses of ksize in the kernel making use of the real
>> usable size of memory allocations rather than only the requested
>> amount. It's incorrect when mixed with alloc_size markers, since if a
>> number like 14 is passed that's used as the upper bound, rather than a
>> rounded size like 16 returned by ksize. It's unlikely to trigger any
>> issues with only CONFIG_FORTIFY_SOURCE, but it becomes more likely
>> with -fsanitize=object-size or other library-based usage of
>> __builtin_object_size.
>
> I think the solution here is to use a macro that does the per-bucket
> rounding and applies them to the attributes. Keep the bucket size lists
> in sync will likely need some BUILD_BUG_ON()s or similar.

@kees kees added [PATCH] Accepted A submitted patch has been accepted upstream and removed [PATCH] Exists A patch exists to address the issue labels Sep 1, 2021
@kees
Copy link
Author

kees commented Sep 1, 2021

@kees kees added the [Linux] -next Present in linux-next; expected for next Linux release label Sep 1, 2021
@kees kees self-assigned this Sep 11, 2021
@kees
Copy link
Author

kees commented Apr 7, 2022

Commit c37495d (v5.16)

@kees kees closed this as completed Apr 7, 2022
@kees kees added [Linux] v5.16 Released in Linux kernel v5.16 and removed [PATCH] Accepted A submitted patch has been accepted upstream [Linux] -next Present in linux-next; expected for next Linux release labels Apr 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Linux] v5.16 Released in Linux kernel v5.16
Projects
None yet
Development

No branches or pull requests

1 participant