On Wed, Aug 13, 2025 at 1:37 PM Pratyush Yadav <pratyush@xxxxxxxxxx> wrote: > > On Wed, Aug 13 2025, Greg KH wrote: > > > On Wed, Aug 13, 2025 at 09:41:40AM -0300, Jason Gunthorpe wrote: > [...] > >> Use the warn ons. Make sure they can't be triggered by userspace. Use > >> them to detect corruption/malfunction in the kernel. > >> > >> In this case if kho_unpreserve_folio() fails in this call chain it > >> means some error unwind is wrongly happening out of sequence, and we > >> are now forced to leak memory. Unwind is not something that userspace > >> should be controlling, so of course we want a WARN_ON here. > > > > "should be" is the key here. And it's not obvious from this patch if > > that's true or not, which is why I mentioned it. > > > > I will keep bringing this up, given the HUGE number of CVEs I keep > > assigning each week for when userspace hits WARN_ON() calls until that > > flow starts to die out either because we don't keep adding new calls, OR > > we finally fix them all. Both would be good... > > Out of curiosity, why is hitting a WARN_ON() considered a vulnerability? > I'd guess one reason is overwhelming system console which can cause a > denial of service, but what about WARN_ON_ONCE() or WARN_RATELIMIT()? My understanding that it is vulnerability only if it can be triggered from userspace, otherwise it is a preferred method to give a notice that something is very wrong. Given the large number of machines that have panic_on_warn, a reliable kernel crash that is triggered from userspace is a vulnerability(?). Pasha > > -- > Regards, > Pratyush Yadav
