Re: [PATCH v2 08/19] PCI/TSM: Add "evidence" support

[Dan Williams <dan.j.williams@intel.com>]

Lukas Wunner wrote:
> On Mon, Mar 16, 2026 at 04:02:22PM -0700, Dan Williams wrote:
> > Dan Williams wrote:
> > > Lukas Wunner wrote:
> > > > This doesn't look like it's ever been tested, so at the very least
> > > > it should be marked RFC in the subject to convey that it's not yet
> > > > in a cut-and-dried state.
> > > 
> > > The 16MB limit has indeed not been tested, the test script in this set
> > > was using smaller than 64K payloads to check out the interface.
> > 
> > So 16MB works ok, slow, but works. A given attribute in this
> > implementation never exceeds the limit
> 
> Famous last words.

I am not convinced you have found the "gotcha" you think you have...

> If you look at netlink_dump(), it sizes the skb based on
> nlk->max_recvmsg_len.  If that's larger than 64k, you'll
> try to fill as much as possible of that space with a single
> netlink attribute.  The computation of "available" in your
> patch doesn't take the 65531 bytes limit for a netlink attribute
> into account so it looks like you'll end up overflowing the length
> of the netlink attribute.

The @len to nla_put() should not overflow because it is based on the
available tailroom in the skb minus netlink overhead. The "inventive"
hack that Jakub is reacting to is that this scheme requires a receiver
that assumes repeating the attribute in the receive stream must be
handled as concatenation.

> Unfortunately nla_put() doesn't prevent such overflows, it does
> all the size calculations with an int, not a u16.

Are we looking at the same capacity calculation?

    len = min(available - overhead, object_len - ctx->offset);