netdev - Re: [RFC PATCH 0/9] IrDA 2.6.28 bug fix

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:	Sun, 14 Dec 2008 23:08:37 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	samuel@...tiz.org
Cc:	netdev@...r.kernel.org, irda-users@...ts.sourceforge.net
Subject: Re: [RFC PATCH 0/9] IrDA 2.6.28 bug fix

From: Samuel Ortiz <samuel@...tiz.org>
Date: Mon, 15 Dec 2008 02:57:29 +0100

> This is a 9 patches series for IrDA, against your net-2.6 tree.
> This is an attempt to fix kernel.bugzilla.org bug #11795, where we noticed
> skb->cb could be altered once submitted to dev_queue_xmit. Since IrDA is using
> this callback to pass per-skb information, we are now stuffing it in front of
> skb->data, after allocating the right headroom.
> 
> Another solution would be to play with the IrDA physical header and skb_pull
> our skbs whenever we are physically transmitting the data.

Hi Sam.

I appreciate you working on this.

But I there are two issues here:

1) There is no way I can put a series of 9 invasive patches like these
   so late into 2.6.28

   If we need to fix it in 2.6.28 it'd need to be a 5 to 10 line
   change at most, even if hackish, before I could seriously consider
   it.

2) Just like you can't claim ownership to skb->cb after dev_queue_xmit(),
   you just as equally can't claim ownership to areas in front of
   skb->data either.

I'm pretty sure we discussed how #2 wouldn't work for this problem.

I understand you need a way to pass information, but you're trying to
do it using things the IRDA (nor any other) stack does not own across
a dev_queue_xmit() invocation.

Furthermore, device layer schemes that try to use some shared
part of the skb for their communication is frail, and a good
way to see how frail it is is to consider how encapsulation of
such device types within themselves might be made to work.

You can't do it with skb->cb[] private storage, and you doubly can't
do it by sneaking things in front of skb->data because that's where
the encapsulated protocol headers would go.
--
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