netdev - Re: [PATCH 2/3] sctp_diag: export timer value only if it is active

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: <20160803194652.GD2954@localhost.localdomain>
Date:	Wed, 3 Aug 2016 16:46:52 -0300
From:	Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
To:	Phil Sutter <phil@....cc>, Xin Long <lucien.xin@...il.com>,
	David Miller <davem@...emloft.net>,
	network dev <netdev@...r.kernel.org>
Subject: Re: [PATCH 2/3] sctp_diag: export timer value only if it is active

On Wed, Aug 03, 2016 at 09:28:13PM +0200, Phil Sutter wrote:
> Hi,
> 
> On Sat, Jul 30, 2016 at 09:25:42PM +0800, Xin Long wrote:
> [...]
> > Now for the transport's info,  we only choose primary_path to dump.
> > It means we should fix this by getting the left time to expire from
> > primary transport t->T3_rtx_timer. like:
> > 
> >         r->idiag_expires = jiffies_to_msecs(
> > -               asoc->timeouts[SCTP_EVENT_TIMEOUT_T3_RTX] - jiffies);
> > +               asoc->peer.primary_path->T3_rtx_timer.expires - jiffies);
> > 
> > but yes, need to check with timer_pending firstly.
> 
> I have changed the code to this:
> 
> | struct timer_list *t3_rtx = &asoc->peer.primary_path->T3_rtx_timer;
> | 
> | [...]
> | 
> | if (timer_pending(t3_rtx)) {
> | 	r->idiag_timer = SCTP_EVENT_TIMEOUT_T3_RTX;
> | 	r->idiag_retrans = asoc->rtx_data_chunks;
> | 	r->idiag_expires = jiffies_to_msecs(t3_rtx->expires - jiffies);
> | }
> 
> And I'm still getting what appears to be negative values sometimes. Here
> are some of the common values in hex when busy looping sctp_diag
> requests:
> 
> 0
> 7530
> 1000000
> 3000000
> 6000000
> 14000000
> 94000000
> ed690000
> ffffea00

Are these for the same asoc? I wouldn't expect it to vary that much.
Even the 1000000 it's already just too big to be reasonable. That's
16777 seconds. Only 0x7530 is reasonable, 30 seconds.

> 
> While I wonder a bit about the zero, the last two seem to be unsigned
> underruns. Do I still have to check for 't3_rtx->expires > jiffies' or
> am I missing something?

You shouldn't have to because then the timer wouldn't be pending. 

I don't know what can be wrong in there. Could it be the application not
checking if the timer was exported or not before dumping it? </longshot>

  Marcelo