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:10PM +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 a review generated by Sashiko
> 
> > Signed-off-by: Weiming Shi <bestswngs@gmail.com>
> 
> Reviewed-by: Simon Horman <horms@kernel.org>
> 
> As usual I'll comment on the review of this patch by Sashiko.
> 
> TL;DR: I don't think it should block progress of this patch.
> 
> The review by Sashiko flags out of bounds errors. However,
> these are addressed by one of your other patches:
> 
> - [PATCH net] slip: bound decode() reads against the compressed packet length
>   https://lore.kernel.org/netdev/20260416100147.531855-5-bestswngs@gmail.com/
> 
> As noted in my review of that patch, while it seems too late for these
> patches, please consider bundling related patches in a patchset in future.

I'm very sorry but the text above results from me muddling
up my response to different slip patches.

I'll post the correct text for this patch elsewhere in this thread.