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-next>] [day] [month] [year] [list]
Message-Id: <20080803083248.0b9dc284.ipng@69706e6720323030352d30312d31340a.nosense.org>
Date:	Sun, 3 Aug 2008 08:32:48 +0930
From:	Mark Smith <ipng@...06e6720323030352d30312d31340a.nosense.org>
To:	netdev@...r.kernel.org
Subject: Fw: dev_queue_xmit() to now non-existing device (text wrapped now)

A mail client upgrade must have dropped that setting :-|

Begin forwarded message:

Date: Sat, 2 Aug 2008 21:38:28 +0930
From: Mark Smith <ipng@...06e6720323030352d30312d31340a.nosense.org>
To: netdev@...r.kernel.org
Subject: dev_queue_xmit() to now non-existing device


Hi,

I've been working on a simple request/reply protocol implementation,
which can queue replies to requests for up to 30 seconds. I've used a
private SKB queue to hold the pending replies, and kernel timers to
send them off. This has all been working fine under normal
circumstances. I've been developing against my Arch Linux 2.6.25 kernel.

I've now been thinking about how to deal with queued SKB replies that
when dev_queue_xmit() is called for them, the outgoing skb->dev has
gone, as the network card driver has been removed. With a delay of up
to 30 seconds, I think the likelyhood of this happening could be fairly
high, compared to other users of dev_queue_xmit() in the kernel.

My initial thought was that dev_queue_xmit() would check if the
outgoing device exists when it is called, however, at least in 2.6.25,
that doesn't seem to be the case. In the source, I can't seem to see a
check to see if the supplied skb->dev is currently valid.

The other thing I tried was to have a routine called as part of the
NETDEV_UNREGISTER notifier event that would delete any pending replies
for the device that has now been removed. I failed at that (with a
corresponding kernel panic of course), however it might have been
because I hadn't shutdown any kernel timers that would be servicing the
outgoing queue. However, thinking about it more, I realised that I'd
probably need to wait until after the next firing of the kernel timer
(even if I bring it forward), and that kernel timer function would call
dev_queue_xmit() for a now non-existing outgoing device anyway. So I
don't think it really fully solves the problem.

I've looked around the source a fair bit, and can't seem to find an
examples where this problem has been solved. There seem to be a lot of
users of dev_queue_xmit(), however they all seem to just assume the
device the SKB will use exists when it is called. For the examples of
private SKB queues I've found, none of them seem to have any routines
that deal with queued SKBs for interfaces that have now disappeared.

Has anybody got any suggestions or pointers to where this problem has
been solved? 

ps. please CC me, as I'm not subscribed to netdev.

Thanks very much,
Mark.


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