CVE-2024-50002

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> static_call: Handle module init failure correctly in static_call_del_module()<br /> <br /> Module insertion invokes static_call_add_module() to initialize the static<br /> calls in a module. static_call_add_module() invokes __static_call_init(),<br /> which allocates a struct static_call_mod to either encapsulate the built-in<br /> static call sites of the associated key into it so further modules can be<br /> added or to append the module to the module chain.<br /> <br /> If that allocation fails the function returns with an error code and the<br /> module core invokes static_call_del_module() to clean up eventually added<br /> static_call_mod entries.<br /> <br /> This works correctly, when all keys used by the module were converted over<br /> to a module chain before the failure. If not then static_call_del_module()<br /> causes a #GP as it blindly assumes that key::mods points to a valid struct<br /> static_call_mod.<br /> <br /> The problem is that key::mods is not a individual struct member of struct<br /> static_call_key, it&amp;#39;s part of a union to save space:<br /> <br /> union {<br /> /* bit 0: 0 = mods, 1 = sites */<br /> unsigned long type;<br /> struct static_call_mod *mods;<br /> struct static_call_site *sites;<br /> };<br /> <br /> key::sites is a pointer to the list of built-in usage sites of the static<br /> call. The type of the pointer is differentiated by bit 0. A mods pointer<br /> has the bit clear, the sites pointer has the bit set.<br /> <br /> As static_call_del_module() blidly assumes that the pointer is a valid<br /> static_call_mod type, it fails to check for this failure case and<br /> dereferences the pointer to the list of built-in call sites, which is<br /> obviously bogus.<br /> <br /> Cure it by checking whether the key has a sites or a mods pointer.<br /> <br /> If it&amp;#39;s a sites pointer then the key is not to be touched. As the sites are<br /> walked in the same order as in __static_call_init() the site walk can be<br /> terminated because all subsequent sites have not been touched by the init<br /> code due to the error exit.<br /> <br /> If it was converted before the allocation fail, then the inner loop which<br /> searches for a module match will find nothing.<br /> <br /> A fail in the second allocation in __static_call_init() is harmless and<br /> does not require special treatment. The first allocation succeeded and<br /> converted the key to a module chain. That first entry has mod::mod == NULL<br /> and mod::next == NULL, so the inner loop of static_call_del_module() will<br /> neither find a module match nor a module chain. The next site in the walk<br /> was either already converted, but can&amp;#39;t match the module, or it will exit<br /> the outer loop because it has a static_call_site pointer and not a<br /> static_call_mod pointer.