linux-kernel - Re: [PATCH net v4] nfc: ... device_is

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]

Message-ID: <6ad27014.42f6.1807072bb39.Coremail.linma@zju.edu.cn>
Date:   Thu, 28 Apr 2022 21:53:28 +0800 (GMT+08:00)
From:   "Lin Ma" <linma@....edu.cn>
To:     "Greg KH" <gregkh@...uxfoundation.org>
Cc:     "Duoming Zhou" <duoming@....edu.cn>,
        krzysztof.kozlowski@...aro.org, pabeni@...hat.com,
        linux-kernel@...r.kernel.org, davem@...emloft.net,
        alexander.deucher@....com, akpm@...ux-foundation.org,
        broonie@...nel.org, netdev@...r.kernel.org,
        "Jakub Kicinski" <kuba@...nel.org>
Subject: Re: [PATCH net v4] nfc: ... device_is_registered() is data
 race-able

Hello there

> 
> How do you physically remove a NFC device from a system?  What types of
> busses are they on?  If non-removable one, then odds are there's not
> going to be many races so this is a low-priority thing.  If they can be
> on removable busses (USB, PCI, etc.), then that's a bigger thing.

Well, these are great questions we didn't even touch to yet.
For the BT, HAMRADIO, and NFC/NCI code, we simply use pseudo-terminal + line
discipline to emulate a malicious device from user-space (CAP_NET_ADMIN required).

We will then survey the actual physical bus for the IRL used NFC device.

> 
> But again, the NFC bus code should handle all of this for the drivers,
> there's nothing special about NFC that should warrant a special need for
> this type of thing.
> 

Agree, but in my opinion, every layer besides the bus code has to handle this race.

The cleanup routine is from
"down" to "up" like ... -> TTY -> NFCMRVL -> NCI -> NFC core
while the other routines, like netlink command is from "up" to "down"
user space -> netlink -> NFC -> NCI -> NFCMRVL -> ...

Their directions are totally reversed hence only each layer of the stack perform good
synchronization can the code be race free.

For example, this detaching event awake code in bus, the running task in higher layer
is not aware of this. The cleanup of each layer has to make sure any running code won't
cause use-after-free. 

> thanks,
> 
> greg k-h

Thanks
Lin Ma