On Mon 19-08-24 23:57:29, David Hildenbrand wrote:

On 19.08.24 22:35, Linus Torvalds wrote:

quoted

On Mon, 19 Aug 2024 at 13:24, David Hildenbrand [off-list ref] wrote:

quoted

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