Path forward for NFC in the kernel

Path forward for NFC in the kernel

[Jakub Kicinski]

Hi folks!

We are struggling to keep up with the number of security reports and AI
generated patches in the kernel. NFC is infamous for being a huge CVE
magnet. We need someone to step up as a maintainer, create an NFC tree
and handle all the incoming submissions. Send us (or Linus if you
prefer) periodic PRs, like WiFi, Bluetooth etc. do. If that does not
happen I'm afraid we'll have to move the NFC code out of the tree, 
put it up on GH or some such, and let it accumulate CVEs there..

I'm planning to send a PR to Linus to shed the unmaintained code early
next week. We need to have a maintainer established by then.

Re: Path forward for NFC in the kernel

[Michael Walle]

[-- Attachment #1: Type: text/plain, Size: 881 bytes --]

Hi,

On Thu Apr 16, 2026 at 7:10 PM CEST, Jakub Kicinski wrote:
> Hi folks!
>
> We are struggling to keep up with the number of security reports and AI
> generated patches in the kernel. NFC is infamous for being a huge CVE
> magnet. We need someone to step up as a maintainer, create an NFC tree
> and handle all the incoming submissions. Send us (or Linus if you
> prefer) periodic PRs, like WiFi, Bluetooth etc. do. If that does not
> happen I'm afraid we'll have to move the NFC code out of the tree, 
> put it up on GH or some such, and let it accumulate CVEs there..
>
> I'm planning to send a PR to Linus to shed the unmaintained code early
> next week. We need to have a maintainer established by then.

Thanks for asking, but I'm busy renovating my house, sorry. I
couldn't put much work into that. The former is already stressful
enough :)

-michael

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]

Re: Path forward for NFC in the kernel

[Krzysztof Kozlowski]

On 16/04/2026 19:10, Jakub Kicinski wrote:
> Hi folks!
> 
> We are struggling to keep up with the number of security reports and AI
> generated patches in the kernel. NFC is infamous for being a huge CVE
> magnet. We need someone to step up as a maintainer, create an NFC tree
> and handle all the incoming submissions. Send us (or Linus if you
> prefer) periodic PRs, like WiFi, Bluetooth etc. do. If that does not
> happen I'm afraid we'll have to move the NFC code out of the tree, 
> put it up on GH or some such, and let it accumulate CVEs there..
> 
> I'm planning to send a PR to Linus to shed the unmaintained code early
> next week. We need to have a maintainer established by then.

+Cc David Heidelberg recently trying to use Linux NFC stack,

Just "collecting" patches is not a big deal, I could do this, but
actually reviewing the patches with necessary due diligence is the
effort I could not provide in a reasonable time frame. And picking up
patches without proper review feels risky...

NFC has a long history of issues, first mostly pointed out by syzbot but
now apparently by AI tools. The code base is quite old, with no major
improvements or testings happening but not in a way "oh, it's stable and
working like 'cp' command" but rather "no one knows how many bugs are on
top of each other and if it actually still works".

Syzbot and AI reported bugs encourage random drive-by fixes by people
not testing the code, thus particular bug report might be fixed, but for
example NFC stops working and no one knows that.

Does anyone knows if the NFC stack/drivers actually works fine? Did
anyone test actual devices?

If not, then moving to Github would be even more reasonable.

Another point is that AFAIU, most of real world devices, like
Android-based phones, don't use the Linux NFC stack but their custom
HAL/user-space based libraries and drivers. Some other non-Android
projects use libnfc userspace, which seems to be maintained only as
bugfix (https://github.com/nfc-tools/libnfc/commits/master/).

Best regards,
Krzysztof

Re: Path forward for NFC in the kernel

[David Heidelberg]

On 17/04/2026 09:18, Krzysztof Kozlowski wrote:
> On 16/04/2026 19:10, Jakub Kicinski wrote:
>> Hi folks!
>>
>> We are struggling to keep up with the number of security reports and AI
>> generated patches in the kernel. NFC is infamous for being a huge CVE
>> magnet. We need someone to step up as a maintainer, create an NFC tree
>> and handle all the incoming submissions. Send us (or Linus if you
>> prefer) periodic PRs, like WiFi, Bluetooth etc. do. If that does not
>> happen I'm afraid we'll have to move the NFC code out of the tree,
>> put it up on GH or some such, and let it accumulate CVEs there..
>>
>> I'm planning to send a PR to Linus to shed the unmaintained code early
>> next week. We need to have a maintainer established by then.
> 
> +Cc David Heidelberg recently trying to use Linux NFC stack,
> 
> Just "collecting" patches is not a big deal, I could do this, but
> actually reviewing the patches with necessary due diligence is the
> effort I could not provide in a reasonable time frame. And picking up
> patches without proper review feels risky...

Hello Krzystof, Jakub,

thanks for putting me into loop.

I can do limited reviews and basic maintenance. My knowledge about NFC is for 
now somehow limited (but I'm willing to invest my limited time into learning more).

As "I & LLM" wrote [1] userspace very basic reader for GNOME and planning to do 
more tight integration into GNOME, so would make sense to keep the kernel stack 
alive.

[1] https://gitlab.gnome.org/dh/gnfc/

> 
> NFC has a long history of issues, first mostly pointed out by syzbot but
> now apparently by AI tools. The code base is quite old, with no major
> improvements or testings happening but not in a way "oh, it's stable and
> working like 'cp' command" but rather "no one knows how many bugs are on
> top of each other and if it actually still works".
> 
> Syzbot and AI reported bugs encourage random drive-by fixes by people
> not testing the code, thus particular bug report might be fixed, but for
> example NFC stops working and no one knows that.

I think I could filter out nonsense, possibly with help of Sashiko [2].

[2] https://sashiko.dev/

> 
> Does anyone knows if the NFC stack/drivers actually works fine? Did
> anyone test actual devices?

Yes, nxp,pn553, nxp,pn557.

Other people did also test on some phones with different tags (I currently have 
only one tag with vCARD loaded on it).

David

> 
> If not, then moving to Github would be even more reasonable.
> 
> Another point is that AFAIU, most of real world devices, like
> Android-based phones, don't use the Linux NFC stack but their custom
> HAL/user-space based libraries and drivers. Some other non-Android
> projects use libnfc userspace, which seems to be maintained only as
> bugfix (https://github.com/nfc-tools/libnfc/commits/master/).
> 
> Best regards,
> Krzysztof

Re: Path forward for NFC in the kernel

[Michael Walle]

[-- Attachment #1: Type: text/plain, Size: 543 bytes --]

On Fri Apr 17, 2026 at 9:18 AM CEST, Krzysztof Kozlowski wrote:
> Does anyone knows if the NFC stack/drivers actually works fine? Did
> anyone test actual devices?

I was working on a product which used an NFC part from NXP. We
started with the upstream driver and libnfc and we did some
bugfixes, that's also probably the reason I'm in the loop here ;).

But eventually it was decided to switch to the libs provided by the
vendor, because that at least somehow worked reliably (and you'll
get support from the vendor).

-michael

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]

Re: Path forward for NFC in the kernel

[David Heidelberg]

On 17/04/2026 10:54, Michael Walle wrote:
> On Fri Apr 17, 2026 at 9:18 AM CEST, Krzysztof Kozlowski wrote:
>> Does anyone knows if the NFC stack/drivers actually works fine? Did
>> anyone test actual devices?
> 
> I was working on a product which used an NFC part from NXP. We
> started with the upstream driver and libnfc and we did some
> bugfixes, that's also probably the reason I'm in the loop here ;).
> 
> But eventually it was decided to switch to the libs provided by the
> vendor, because that at least somehow worked reliably (and you'll
> get support from the vendor).

So what we need is show vendor how wonderful Linux kernel is, thus he should 
contribute to it and then switch to it (when nVidia can understand it's 
beneficial to them, why not NXP).

David

> 
> -michael

-- 
David Heidelberg

Re: Path forward for NFC in the kernel

[David Heidelberg]

On 17/04/2026 09:18, Krzysztof Kozlowski wrote:
> On 16/04/2026 19:10, Jakub Kicinski wrote:
>> Hi folks!
>>
>> We are struggling to keep up with the number of security reports and AI
>> generated patches in the kernel. NFC is infamous for being a huge CVE
>> magnet. We need someone to step up as a maintainer, create an NFC tree
>> and handle all the incoming submissions. Send us (or Linus if you
>> prefer) periodic PRs, like WiFi, Bluetooth etc. do. If that does not
>> happen I'm afraid we'll have to move the NFC code out of the tree,
>> put it up on GH or some such, and let it accumulate CVEs there..
>>
>> I'm planning to send a PR to Linus to shed the unmaintained code early
>> next week. We need to have a maintainer established by then.
> 
> +Cc David Heidelberg recently trying to use Linux NFC stack,
> 
+Cc oe-linux-nfc@lists.linux.dev

For now we had NFC related discussion in our sdm845-next channel, but I brought 
Matrix channel [1] for the kernel, neard, user-space discussion, so people can 
share and interact in real-time (the chat content is public without needing to 
join the room).

David


[1] https://matrix.to/#/#linux-nfc:ixit.cz

...