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:	Fri, 3 Jul 2015 07:27:54 +0000
From:	"Krzyzowski, Marek (Nokia - DE/Ulm)" <marek.krzyzowski@...ia.com>
To:	"Sverdlin, Alexander (Nokia - DE/Ulm)" <alexander.sverdlin@...ia.com>,
	ext David Miller <davem@...emloft.net>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"mporter@...nel.crashing.org" <mporter@...nel.crashing.org>,
	"alexandre.bounine@....com" <alexandre.bounine@....com>,
	"Kunz, Frank (Nokia - DE/Ulm)" <frank.kunz@...ia.com>
Subject: RE: [PATCH] rionet: Don't try to corrupt skbuff assigning data
 pointer directly

Hello,


I would prefer to replace this line of code with returning of value, where any non-negative value would indicate success, whereas negative values would indicate some errors. It would mean, of course, no returning of any pointers.

BR
Marek

-----Original Message-----
From: Alexander Sverdlin [mailto:alexander.sverdlin@...ia.com] 
Sent: Friday, July 03, 2015 9:24 AM
To: ext David Miller
Cc: netdev@...r.kernel.org; mporter@...nel.crashing.org; alexandre.bounine@....com; Kunz, Frank (Nokia - DE/Ulm); Krzyzowski, Marek (Nokia - DE/Ulm)
Subject: Re: [PATCH] rionet: Don't try to corrupt skbuff assigning data pointer directly

Hi David,

On 02/07/15 21:12, ext David Miller wrote:
>> It's not allowed to assign data pointer of skbuff directly, this makes no sense
>> > if the assigned pointer is the very same as already existing one, or it brakes
>> > all the pointer arithmetics in all other cases. We cannot do better as just
>> > compare them and report BUG() in case of mismatch.
>> > 
>> > Signed-off-by: Alexander Sverdlin <alexander.sverdlin@...ia.com>
> BUG takes the entire machine out, which is worse than corrupting the
> skb->data
> 
> If you really want to assert this condition, do it in a way that
> doesn't kill the entire machine.

In fact, the machine goes down, some milliseconds later, but because of the following
inconsistencies, which are misleading. The function has no way to signal an error and
this line of code is simply wrong. To prevent others from copying this error, we can
simply delete it. Would it be fine from your PoV?

-- 
Best regards,
Alexander Sverdlin.

Powered by blists - more mailing lists