Re: Kernel oops with 6.14 when enabling TLS

[Matthew Wilcox <willy@infradead.org>]

On Mon, Mar 03, 2025 at 08:48:09AM +0100, Hannes Reinecke wrote:
> On 2/28/25 11:47, Hannes Reinecke wrote:
> > Hi Sagi,
> > 
> > enabling TLS on latest linus tree reliably crashes my system:
> > 
> > [  487.018058] ------------[ cut here ]------------
> > [  487.024046] WARNING: CPU: 9 PID: 6159 at mm/slub.c:4719
> > free_large_kmalloc+0x15/0xa0

That's:

        if (WARN_ON_ONCE(order == 0))
                pr_warn_once("object pointer: 0x%p\n", object);

And while the object pointer is obfuscated (hashed pointers), this
wouldn't be helpful in trying to track down the problem.  Perhaps
we could make this a VM_WARN_ON_ONCE_FOLIO() so we get the dump_page()?

I'm tempted to believe this is a double-free, but then I'm not sure why
it'd be triggered by this patch.

> > [  487.296801]  kfree+0x234/0x320
> > [  487.332084]  nvmf_connect_admin_queue+0x105/0x1a0 [nvme_fabrics
> > 34d997d53c805aa2fae8e8baee6a736e8da38358]
> > [  487.332093]  nvme_tcp_start_queue+0x18f/0x310 [nvme_tcp
> > 68f6be106f52ac467179f8a0922f02aeb6fa1f1c]
> > [  487.332102]  nvme_tcp_setup_ctrl+0xf8/0x700 [nvme_tcp
> > 68f6be106f52ac467179f8a0922f02aeb6fa1f1c]
> > [  487.394495]  nvme_tcp_create_ctrl+0x2e3/0x4d0 [nvme_tcp
> > 68f6be106f52ac467179f8a0922f02aeb6fa1f1c]
> > [  487.394503]  nvmf_dev_write+0x323/0x3d0 [nvme_fabrics
> > 34d997d53c805aa2fae8e8baee6a736e8da38358]
> > [  487.394514]  vfs_write+0xd9/0x430
> > [  487.551642] object pointer: 0x00000000346cb6fc

Oh, wait, that's not the crash!

We continue to free the folio.  Even though we hit the "can't happen"
case.  That's dangerous.

> > [  489.405197] Oops: general protection fault, probably for non-
> > canonical address 0xdead000000000100: 0000 [#1] PREEMPT SMP NOPTI

I think we all recognise that as list poison.  I bet this is a double-free.

Or it could be a wild-free.  I mean, look at kfree():

        folio = virt_to_folio(object);
        if (unlikely(!folio_test_slab(folio))) {
                free_large_kmalloc(folio, (void *)object);
                return;
        }

So if you call kfree() on a random pointer, chances are it's not part
of slab, and we jump into the free_large_kmalloc() path.

We have a _lot_ of page types available.  We should mark large kmallocs
as such.  I'll send a patch to do that.