Re: [PATCH net] slip: fix slab-out-of-bounds write in slhc_uncompress()

[Simon Horman <horms@kernel.org>]

On Thu, Apr 16, 2026 at 05:34:00AM +0800, Weiming Shi wrote:
> sl_bump() reserves only 80 bytes of expansion headroom before calling
> slhc_uncompress(), but the reconstructed IP + TCP header is up to
> ip->ihl*4 + thp->doff*4 bytes. IHL and TCP doff are 4-bit fields and
> both can legitimately reach 15, so the header can grow to 2*15*4 =
> 120 bytes. A VJ-uncompressed primer with ihl=15, doff=15 followed by
> a compressed frame of size buffsize - 80 therefore writes up to
> 33 bytes past the kmalloc(buffsize + 4) rbuff allocation, with
> attacker-controlled content:
> 
>  BUG: KASAN: slab-out-of-bounds in slhc_uncompress
>  Write of size 1069 at addr ffff88800ba93078 by task kworker/u8:1/32
>  Workqueue: events_unbound flush_to_ldisc
>  Call Trace:
>   __asan_memmove+0x3f/0x70
>   slhc_uncompress (drivers/net/slip/slhc.c:614)
>   slip_receive_buf (drivers/net/slip/slip.c:342)
>   tty_ldisc_receive_buf
>   flush_to_ldisc
> 
> Raise the reservation to match the real worst case. The ppp_generic
> receive path already enforces skb_tailroom >= 124 and is unaffected.
> 
> Fixes: b5451d783ade ("slip: Move the SLIP drivers")
> Reported-by: Simon Horman <horms@kernel.org>

FTR, I was mainly passing on information flagged by Sashiko.

> Signed-off-by: Weiming Shi <bestswngs@gmail.com>

Reviewed-by: Simon Horman <horms@kernel.org>

Let me summarise my understanding of Sashiko's review of this patch.

TL;DR: I don't think that review should block progress of this patch.

1. The issue wrt concurrent MTU changes appears to be a separate,
   pre-existing problem. Maybe you've looked into it already,
   if not, you may wish to.

2. The bounds checking problems are addressed by other patches in flight.

   - [PATCH net v2] slip: reject VJ receive packets on instances with no rstate array
     https://lore.kernel.org/netdev/20260415204130.258866-2-bestswngs@gmail.com/

   - [PATCH net] slip: fix slab-out-of-bounds write in slhc_uncompress()
     https://lore.kernel.org/netdev/20260415213359.335657-2-bestswngs@gmail.com/

   In future you might want to consider creating patch sets for related
   patches. But I think it's too late in the case of these patches.

...