On Mon 19-08-24 23:57:29, David Hildenbrand wrote: > On 19.08.24 22:35, Linus Torvalds wrote: > > On Mon, 19 Aug 2024 at 13:24, David Hildenbrand <da...@redhat.com> wrote: > > > > > > Right, "warn + loop forever" is one alternative where you could at least > > > keep the system alive to some degree. > > > > Maybe. Or it might just lock up the machine. > > Yes, regarding the security concerns it might be a bit better that way. (no > security expert, so I cannot judge ...)
Would it make sense to simply enforce and oops? We do expect that an incorrect usage would trigger one but we have no guarantee because the actual user could be array = kvmalloc(unsupported_size_provided_from_userspace, GFP_NOFAIL) which might be actually a valid usecase because that the normaly requested size is large, yet reasonable. A lack of user input checks is just a sad reality we have to live with. While those bugs absolutely _need_ to be fixed it is better to not just allow them to array[large_index] = payload and make them easier to exploit the kernel. Sure you will get a warning but your machine has been compromised. BUG_ON will shoot the whole machine down which I do understand is just too drastic of a measure. Making the allocation loop for ever with cond_resched() or a short sleep is slightly better because it contains the bad user but the process context is still not killabale that way which is a problem on its own. I am not aware of OOPS_ON that would kill the calling user process. Yes, this could still be leaving locks behind but still better than a compromised system. WDYT? -- Michal Hocko SUSE Labs
