netdev - Re: [PATCH net] sctp: jsctp_sf_eat_sack: fix kernel NULL ptr dereference

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 14 Dec 2012 22:49:55 +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 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.
--
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