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

[Simon Horman <horms@kernel.org>]

On Sun, Apr 19, 2026 at 03:27:26PM +0100, Simon Horman wrote:
> 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>

I'm very sorry but the text below below was for a different,
albeit related, patch:

- [PATCH net] slip: bound decode() reads against the compressed packet length
  https://lore.kernel.org/netdev/20260416100147.531855-5-bestswngs@gmail.com/

The corresponding text relating to this patch was posted as:

https://lore.kernel.org/netdev/20260419142710.GI280379@horms.kernel.org/

Sorry for the mix up!

> 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.
> 
> ...