On Wed, Aug 13, 2025 at 03:37:03PM +0200, Pratyush Yadav 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()? If panic_on_warn is set, this will cause the machine to crash/reboot, which is considered a "vulnerability" by the CVE.org definition. If a user can trigger this, it gets a CVE assigned to it. hope this helps, greg k-h
