Double SCTP_INP_RUNLOCK() in SCTP result in KP

2012-01-13 Thread Clément Lecigne
Hi,

In sctp_ussreq.c, lines are based from HEAD:

3041SCTP_INP_RUNLOCK(inp);
3042onoff = sctp_is_feature_on(inp, SCTP_PCB_FLAGS_RECVNXTINFO);
3043SCTP_INP_RUNLOCK(inp);

The SCTP_INP_RUNLOCK(in) on line 3043 must be SCTP_INP_LOCK(in), typo?
That results in an easily user triggerable kernel panic through
getsockopt(). I don't think user can do something evil with this
double unlock which result in a kernel panic due to a NULL dereference
in mtx_unlock() on my fresh FreeBSD 9.0.

Bests,
-clem1
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"


Re: Double SCTP_INP_RUNLOCK() in SCTP result in KP

2012-01-13 Thread Clément Lecigne
Oups mistake, the LOCK() should be on line 3041, same problem just
above on line 3021, UNLOCK() instead of LOCK().

-clem1

Le 14 janvier 2012 05:03, Clément Lecigne  a écrit :
> Hi,
>
> In sctp_ussreq.c, lines are based from HEAD:
>
> 3041    SCTP_INP_RUNLOCK(inp);
> 3042    onoff = sctp_is_feature_on(inp, SCTP_PCB_FLAGS_RECVNXTINFO);
> 3043    SCTP_INP_RUNLOCK(inp);
>
> The SCTP_INP_RUNLOCK(in) on line 3043 must be SCTP_INP_LOCK(in), typo?
> That results in an easily user triggerable kernel panic through
> getsockopt(). I don't think user can do something evil with this
> double unlock which result in a kernel panic due to a NULL dereference
> in mtx_unlock() on my fresh FreeBSD 9.0.
>
> Bests,
> -clem1



-- 
-clem1
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"