lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAD6jFUTzpNGGjBhJiHugxOyrekdQKoRezrzwXkm7VOmMYnyguw@mail.gmail.com> Date: Sat, 15 Dec 2012 20:58:23 +0100 From: Daniel Borkmann <danborkmann@...earbox.net> To: Vlad Yasevich <vyasevich@...il.com> Cc: David Miller <davem@...emloft.net>, netdev@...r.kernel.org Subject: Re: [PATCH net] sctp: jsctp_sf_eat_sack: fix kernel NULL ptr dereference On Fri, Dec 14, 2012 at 10:49 PM, Daniel Borkmann <danborkmann@...earbox.net> wrote: > On Fri, Dec 14, 2012 at 5:57 PM, Daniel Borkmann <dborkman@...hat.com> wrote: >> On 12/14/2012 04:12 PM, Vlad Yasevich wrote: >>> On 12/14/2012 09:27 AM, Daniel Borkmann wrote: >>>> >>>> During debugging a sctp problem, I hit a kernel NULL pointer >>>> dereference in the jprobes callback jsctp_sf_eat_sack(). This >>>> small patch fixes the panic. >>>> >>>> Cc: Vlad Yasevich <vyasevich@...il.com> >>>> Signed-off-by: Daniel Borkmann <dborkman@...hat.com> >>>> --- >>>> net/sctp/probe.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/net/sctp/probe.c b/net/sctp/probe.c >>>> index bc6cd75..0a4e9d6 100644 >>>> --- a/net/sctp/probe.c >>>> +++ b/net/sctp/probe.c >>>> @@ -134,7 +134,7 @@ sctp_disposition_t jsctp_sf_eat_sack(const struct >>>> sctp_endpoint *ep, >>>> >>>> sp = asoc->peer.primary_path; >>>> >>>> - if ((full || sp->cwnd != lcwnd) && >>>> + if (sp && (full || sp->cwnd != lcwnd) && >>>> (!port || asoc->peer.port == port || >>>> ep->base.bind_addr.port == port)) { >>>> lcwnd = sp->cwnd; >>> >>> Sorry, but this patch isn't making much sense. @sp points to the primary >>> path of the association and that can not be null if we receiving >>> SACKs on this association. >>> >>> sctp_sf_eat_sack_6_2(), which we are probing, is only called while the >>> association is valid and all the transports still exist. It is also called >>> under lock, so the transports can not go away while processing of the SACK. >>> So unless there is some kind of jprobe issue, the pointer >>> you are looking at should always be valid. >> >> Okay, I'll dig a bit deeper into that over the weekend. > > That's just for the record, I'll do further tests / debugging tomorrow ... > > I compiled the net kernel with kprobes selftest / sanity test > (kernel/test_kprobes.c) and it passed: > > [ 2.978082] Kprobe smoke test started > [ 3.034014] Kprobe smoke test passed successfully > > There, also jprobes are tested. Found the problem, will send a new patch for the net tree in a couple of minutes. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists