netdev - dev_queue_xmit() to now non-existing device

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>] [day] [month] [year] [list]

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