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:32:33PM +0100, Simon Horman wrote:
> 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")

AI review flags that this patch moved the code, rather than
adding the bug. It suggests the bug has been present since the
beginning of git history, so:

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")

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

Actually, that's not right either.
I will try one more time:

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: bound decode() reads against the compressed packet length
     https://lore.kernel.org/netdev/20260416100147.531855-5-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.