Bug 2536803 (CVE-2026-90222) - CVE-2026-90222 kernel: nfc: pn533: hold a reference to the request skb during send_frame
Summary: CVE-2026-90222 kernel: nfc: pn533: hold a reference to the request skb during...
Keywords:
Status: NEW
Alias: CVE-2026-90222
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-09-17 19:34 UTC by OSIDB Bzimport
Modified: 2026-10-13 13:20 UTC (History)
17 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-09-17 19:34:58 UTC
In the Linux kernel, the following vulnerability has been resolved:

nfc: pn533: hold a reference to the request skb during send_frame

__pn533_send_async() publishes the command and then calls
dev->phy_ops->send_frame(). Once dev->cmd is set, an incoming frame
can be matched to this command: the I2C threaded IRQ runs
pn533_recv_frame(), which queues cmd_complete_work, and
pn533_send_async_complete() frees cmd->req with consume_skb().

On the I2C transport, pn533_i2c_send_frame() still dereferences the same
skb after i2c_master_send() returns, so a completion that races the
send can free the skb while the transport is still using it.

The request skb is owned by the command object and may be freed by
command completion at any time after dev->cmd is published, so the
transport send path must not assume it stays alive. Hold a temporary
reference to the request skb across the send_frame() call so the
transport always sees a live skb even if completion races the send.
Add a pn533_send_cmd_frame() helper and use it from all three send
paths.


Note You need to log in before you can comment on or make changes to this bug.