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]

Message-ID: <50CB41F2.7040403@gmail.com>
Date:	Fri, 14 Dec 2012 10:12:50 -0500
From:	Vlad Yasevich <vyasevich@...il.com>
To:	Daniel Borkmann <dborkman@...hat.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 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.

-vlad
--
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