The subroutine sl_compress_init(comp, max_state) in slcompress.c at least
implies, that the state table can be changed to any value dynamically if
called with some appropriate value for max_state.
This is not true, because the corresponding table is initialized by the
hardcoded MAX_STATES value in the header file slcompress.h.
Calling sl_compress_init() with a value greater than MAX_STATES will cause
cause writing outside the slcompress structure - bad things happen.
sl_compress_init() is currently used like this in the kernel PPP driver,
if (error = suser(p->p_ucred, &p->p_acflag))
s = splnet();
sl_compress_init(&sc->sc_comp, *(int *)data);
in this case, if this ioctl routine is ever issued with a value other
than -1 or with a value greater MAX_STATES, random writes into other
unknown data structures will occur!
Immediately disable the usage of any parameter for max_state other than
For the future, make the tstate and rstate structures in struct slcompress
resize dynamically so sl_compress_init() is able to do what it should be
able to do.
Call sl_compress_init() with a max_state value of i.e. 64. (Caution:
make a backup before doing this!).
> >Number: 7556
> >Category: kern
> >Synopsis: sl_compress_init() will fail if called anything else than -1 or >MAX_STATE
If anyone picks this up (I haven't the time to be involved with
pppd), there's an additional problem when a number of states is
negotiated that != MAX_STATES. Namely, it's possible that the peer
may agree on (say) 8 states, then proceed to send a header with a
slot id of (say) 10. The end result is that a zero'd slot entry is
``adjusted'' by the VJ deltas and will most likely cause a stack
scribble. We all know what happens to this in kernel mode :-/
This has been fixed in src/usr.sbin/ppp/slcompress.c - but I don't
know how compatible the sources are.
Brian <brian@Awfulhak.org>, <brian@FreeBSD.org>, <brian@OpenBSD.org>
Don't _EVER_ lose your sense of humour....
awaiting patch & committer
hm is a committer, let him decide whether his PR is still valid
Reassign to pool; maintainer is away from FreeBSD work due to press
of other issues these days.
sl(4) was removed from FreeBSD before 8.0-RELEASE.
This function is used in ng_vjc(4) and sppp(4). The issue described in this bug is still exist.