Re: Double SCTP_INP_RUNLOCK() in SCTP result in KP

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);

Double SCTP_INP_RUNLOCK() in SCTP result in KP

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 ke

Re: logging _rtld errors

Hi, 2011/12/19 Xin LI : > Hi, > > On Mon, Dec 19, 2011 at 11:41 AM, Mike Tancsa wrote: >> Are there any security reasons as to why Dont know but the ld_printerror != '\0' in the patch should be *ld_printerror != '\0', no? ~clem ___ freebsd-security@fr

Re: turtle rootkit

hunter or/and chkrootkit. Best regards, -- Clément LECIGNE, "In Python, how do you create a string of random characters? Read a Perl file!" ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security T

Re: Vulnerability in vixie cron?

Hi, Oliver Fromme wrote: Hi, (...) Any information would be appreciated. This issue was already discussed few weeks ago on this list. http://lists.freebsd.org/pipermail/freebsd-hackers/2006-June/016729.html In default configuration, this issue is not exploitable because a call to setu