netdev - Re: [PATCH v3 0/2] Fix uevent race in register

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, 20 May 2011 15:08:58 +0300
From:	Kalle Valo <kvalo@...rom.com>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org, linux-wireless@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 0/2] Fix uevent race in register_netdevice()

David Miller <davem@...emloft.net> writes:

> From: Kalle Valo <kvalo@...rom.com>
> Date: Mon, 16 May 2011 17:46:30 +0300
>
>> I'm trying to fix a race in register_netdevice(). The problem is that
>> there's a uevent to userspace before the netdevice is ready for use. The
>> problem is described here:
>> 
>> https://bugzilla.kernel.org/show_bug.cgi?id=15606
>> 
>> I have sent few different ways to fix this, but none of them have been
>> really usable. Now I came up with a way which changes the driver core
>> to make it possible send the uevent in a separate call. This is a clean
>> and safe way to fix the race. Downside is that two new functions are
>> added to the driver core interface.
>> 
>> Please comment.
>
> This doesn't work.
>
> The sysfs file will still be there before the uevent, so any
> process can go in there, and see the inconsistent state.

I considered that user space would not notice the device until the
uevent is emitted so that wouldn't matter that much.

But it's back to the drawing board again. I'm running out of options
how to do this in a not so intrusive way. Do you have any tips how to
fix the race for good?

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