mirror of https://github.com/mkerrisk/man-pages
2f37aeb620
From a conversation with Jann Horn:
[[
>>>> struct seccomp_notif_resp *resp = malloc(sizes.seccomp_notif_resp);
>>>
>>> This should probably do something like max(sizes.seccomp_notif_resp,
>>> sizeof(struct seccomp_notif_resp)) in case the program was built
>>> against new UAPI headers that make struct seccomp_notif_resp big, but
>>> is running under an old kernel where that struct is still smaller?
>>
>> I'm confused. Why? I mean, if the running kernel says that it expects
>> a buffer of a certain size, and we allocate a buffer of that size,
>> what's the problem?
>
> Because in userspace, we cast the result of malloc() to a "struct
> seccomp_notif_resp *". If the kernel tells us that it expects a size
> smaller than sizeof(struct seccomp_notif_resp), then we end up with a
> pointer to a struct that consists partly of allocated memory, partly
> of out-of-bounds memory, which is generally a bad idea - I'm not sure
> whether the C standard permits that. And if userspace then e.g.
> decides to access some member of that struct that is beyond what the
> kernel thinks is the struct size, we get actual OOB memory accesses.
Got it. (But gosh, this seems like a fragile API mess.)
I added the following to the code:
/* When allocating the response buffer, we must allow for the fact
that the user-space binary may have been built with user-space
headers where 'struct seccomp_notif_resp' is bigger than the
response buffer expected by the (older) kernel. Therefore, we
allocate a buffer that is the maximum of the two sizes. This
ensures that if the supervisor places bytes into the response
structure that are past the response size that the kernel expects,
then the supervisor is not touching an invalid memory location. */
size_t resp_size = sizes.seccomp_notif_resp;
if (sizeof(struct seccomp_notif_resp) > resp_size)
resp_size = sizeof(struct seccomp_notif_resp);
struct seccomp_notif_resp *resp = malloc(resp_size);
]]
Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
|
||
|---|---|---|
| man1 | ||
| man2 | ||
| man3 | ||
| man4 | ||
| man5 | ||
| man6 | ||
| man7 | ||
| man8 | ||
| scripts | ||
| .gitignore | ||
| CONTRIBUTING | ||
| Changes | ||
| Changes.old | ||
| MAINTAINER_NOTES | ||
| Makefile | ||
| README | ||
| man-pages-5.12.Announce | ||
| man-pages-5.12.lsm | ||
README
This package contains Linux man pages for sections 1 through 8. Some more information is given in the 'man-pages-x.y.Announce' file. Homepage ======== For information about the Linux man-pages project, see http://www.kernel.org/doc/man-pages/index.html. Bug reports and contributing ============================ If you have corrections and additions to suggest, see http://www.kernel.org/doc/man-pages/contributing.html (Although there is a mirror of this repository on GitHub, please don't report issues via the GitHub issue tracker!) For further information on contributing, see the CONTRIBUTING file. Installing and uninstalling =========================== "make install" will copy these man pages to /usr/local/share/man/man[1-8]. To install to a path different from /usr/local, use "make install prefix=/install/path". "make remove" or "make uninstall" will remove any man page in this distribution from its destination. Use with caution, and remember to use "prefix" if desired, as with the "install" target. To install only a specific man section (mandir) such as man3, use "make install-man3". Similar syntax can be used to uninstall a specific man section, such as man7: "make uninstall-man7". "make" or "make all" will perform "make uninstall" followed by "make install". Consider using multiple threads (at least 2) when installing these man pages, as the Makefile is optimized for multiple threads: "make -j install". Copyrights ========== See the 'man-pages-x.y.Announce' file.