On Wed, Aug 13, 2025 at 01:41:51PM +0000, Pasha Tatashin wrote: > 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(?). Yes, and so is a unreliable one :)
