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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 21 Oct 2008 16:41:21 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	avillaci@...bo.fiec.espol.edu.ec
Cc:	netdev@...r.kernel.org, jarkao2@...il.com, jussi.kivilinna@...et.fi
Subject: Re: Regression: Recent networking (qdisc?) patches break
 irda_get_next_speed()

From: Alex Villací­s Lasso <avillaci@...bo.fiec.espol.edu.ec>
Date: Tue, 21 Oct 2008 18:37:56 -0500

> So then, the bug is that the cb field in the struct sk_buff is being
> interpreted as both a struct qdisc_skb_cb and an struct irda_skb_cb,
> for the same instance of struct sk_buff. I have just started to
> review the suggested patch, but it seems that 'struct qdisc_skb_cb'
> was meant to be aliased against the data for other layers (as
> suggested by the presence of a 'char data[]' field). If so, how come
> only IrDA is affected? How come UDP, TCP, etc. not affected by this?
> On the other hand, if qdisc_skb_cb was not meant to be aliased, then
> the IrDA case was left out while converting the rest of the layers
> so that they will skip over the member 'pkt_len' of the 'struct
> qdisc_skb_cb'.

The SKB control block is not aliased.

Once the packet is given to dev_queue_xmit() the packet scheduler
"owns" the control block of the SKB.

What IRDA is doing is illegal, and breaks in other ways without the
commit in question.

IRDA cannot depend upon the SKB control block not changing across
the dev_queue_xmit() call.
--
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