CVE-2024-40974

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/pseries: Enforce hcall result buffer validity and size<br /> <br /> plpar_hcall(), plpar_hcall9(), and related functions expect callers to<br /> provide valid result buffers of certain minimum size. Currently this<br /> is communicated only through comments in the code and the compiler has<br /> no idea.<br /> <br /> For example, if I write a bug like this:<br /> <br /> long retbuf[PLPAR_HCALL_BUFSIZE]; // should be PLPAR_HCALL9_BUFSIZE<br /> plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...);<br /> <br /> This compiles with no diagnostics emitted, but likely results in stack<br /> corruption at runtime when plpar_hcall9() stores results past the end<br /> of the array. (To be clear this is a contrived example and I have not<br /> found a real instance yet.)<br /> <br /> To make this class of error less likely, we can use explicitly-sized<br /> array parameters instead of pointers in the declarations for the hcall<br /> APIs. When compiled with -Warray-bounds[1], the code above now<br /> provokes a diagnostic like this:<br /> <br /> error: array argument is too small;<br /> is of size 32, callee requires at least 72 [-Werror,-Warray-bounds]<br /> 60 | plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf,<br /> | ^ ~~~~~~<br /> <br /> [1] Enabled for LLVM builds but not GCC for now. See commit<br /> 0da6e5fd6c37 ("gcc: disable &amp;#39;-Warray-bounds&amp;#39; for gcc-13 too") and<br /> related changes.