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] [day] [month] [year] [list]
Date:	Wed, 12 Nov 2008 23:12:47 +0200 (EET)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	kernel@...arici.cz
cc:	Netdev <netdev@...r.kernel.org>, bugme-daemon@...zilla.kernel.org,
	Stephen Hemminger <shemminger@...ux-foundation.org>
Subject: Re: Fw: [Bug 12014] New: Incorrect Urgent Pointer in outgoing packets

On Wed, 12 Nov 2008, Stephen Hemminger wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=12014
> 
>            Summary: Incorrect Urgent Pointer in outgoing packets
>            Product: Networking
>            Version: 2.5
>      KernelVersion: 2.6.27
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: IPV4
>         AssignedTo: shemminger@...ux-foundation.org
>         ReportedBy: kernel@...arici.cz
> 
> 
> Latest working kernel version: ??? (maybe never)
> Earliest failing kernel version: 2.6.27
> Distribution: kernel.org
> Hardware Environment: x86, x86_64
> Software Environment: Oracle, testcase
> Problem Description:
> 
> When urgent mode is initiated using send(..., MSG_OOB), and the current
> outgoing queue is longer than MTU, several packets are sent out with the URG
> flag set.

This urg flag in many segments is expected to happen (the urg pointer
might not point to the current segment but something that will follow)...

> However, the Urgent Pointer field in the TCP header is not updated
> correctly. Instead, it stays the same.

...but I've hard time believing that this true since the the only place
where urg_ptr is assigned is in tcp_output.c and that's done relative
to segments seqno:

	th->urg_ptr = htons(tp->snd_up - tcb->seq);

So if what you say is true, it means that snd_up should advance equally
to the segments seqno. Which means that writes would update it.

> The receiving end interprets this as a new urgent message inserted further in
> the stream, sends multiple SIGURGs to the server application and reads across
> the urgent data. This behaviour is correct.
> 
> Steps to reproduce:
> 
> 1. Initiate a TCP connection
> 2. Fill the outgoing queue with some (normal) data
> 3. Send an urgent message (with MSG_OOB)
> 4. Send some more non-urgent data.

Can you prove that your application is doing what you describe, I suspect 
that you e.g., forget to clear MSG_OOB... Can you strace the program 
please...  Getting a tcpdump at the same time wouldn't hurt either.

I've tried with this exact sequence recently (though after the rewrite of 
urg handling for 2.6.28), and did get a nicely working urg after fixing 
the bug that got introduced by the rewrite and just a single sigurg. It 
seems that I've lost that tcpdump somewhere though. I was using sendfile 
though for the normal data while you might not be doing the same.


-- 
 i.
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ