netdev - Re: [PATCH net-next v15 14/15] net: homa: create homa

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6efc1a99-b5b1-4a22-9655-fb9193e02a7f@redhat.com>
Date: Tue, 2 Sep 2025 10:12:28 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: John Ousterhout <ouster@...stanford.edu>
Cc: netdev@...r.kernel.org, edumazet@...gle.com, horms@...nel.org,
 kuba@...nel.org
Subject: Re: [PATCH net-next v15 14/15] net: homa: create homa_plumbing.c

On 9/2/25 12:53 AM, John Ousterhout wrote:
> On Tue, Aug 26, 2025 at 9:17 AM Paolo Abeni <pabeni@...hat.com> wrote:
>>> +             header_offset = skb_transport_header(skb) - skb->data;
>>> +             if (header_offset)
>>> +                     __skb_pull(skb, header_offset);
>>> +
>>> +             /* Reject packets that are too short or have bogus types. */
>>> +             h = (struct homa_common_hdr *)skb->data;
>>> +             if (unlikely(skb->len < sizeof(struct homa_common_hdr) ||
>>> +                          h->type < DATA || h->type > MAX_OP ||
>>> +                          skb->len < header_lengths[h->type - DATA]))
>>> +                     goto discard;
>>> +
>>> +             /* Process the packet now if it is a control packet or
>>> +              * if it contains an entire short message.
>>> +              */
>>> +             if (h->type != DATA || ntohl(((struct homa_data_hdr *)h)
>>> +                             ->message_length) < 1400) {
>>
>> I could not fined where `message_length` is validated. AFAICS
>> data_hdr->message_length could be > skb->len.
>>
>> Also I don't see how the condition checked above ensures that the pkt
>> contains the whole message.
> 
> Long messages consist of multiple packets, so it is fine if
> data_hdr->message_length > skb->len. That said, Homa does not fragment
> a message into multiple packets unless necessary, so if the condition
> above is met, then the message is contained in a single packet (if for
> some reason a sender fragments a short message, that won't cause
> problems).

Let me rephrase: why 1400? is that MRU dependent, or just an arbitrary
threshold? What if the NIC can receive 8K frames (or max 1024 bytes long
one)? What if the stack adds a long encapsulation?

What if an evil/bugged peer set message_length to a random value (larger
than the amount of bytes actually sent or smaller than that)?

Cheers,

Paolo