linux-kernel - [BUG] net: plip: a possible race in plip

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

Message-ID: <5724b1b3-05c2-41fe-8f5c-879b3e6fd318@gmail.com>
Date: Wed, 17 Sep 2025 16:19:25 +0800
From: Tuo Li <islituo@...il.com>
To: andrew+netdev@...n.ch, "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>,
 boehm.jakub@...il.com
Cc: netdev@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: [BUG] net: plip: a possible race in plip_preempt() leading to UAF

Hello,

While analyzing Linux 6.16 with a static analysis tool, I noticed a
potential data race in plip_preempt() that may lead to a use-after-free.

Consider the following execution sequence in drivers/net/plip.c:

1. In plip_preempt(), nl->connection is checked to be not PLIP_CN_NONE and
nl->port_owner is set to 0 at Line 1184, indicating that the bus can be
released.

2. Before returning, an interrupt occurs and plip_interrupt() is invoked.

3. Inside plip_interrupt(), rcv->state is set to PLIP_PK_TRIGGER at Line
949 and nl->connection is updated to PLIP_CN_RECEIVE. Then plip_bh() is
scheduled at Line 952.

4. If plip_bh() runs and the parport bus has been preempted by another
device, the subsequent call to plip_receive_packet() at Line 376 may access
released resources, leading to a potential UAF.

One possible way to prevent this race is to hold nl->lock while updating
nl->port_owner in plip_preempt():

  static int
  plip_preempt(void *handle)
  {
    struct net_device *dev = (struct net_device *)handle;
    struct net_local *nl = netdev_priv(dev);
    unsigned long flags;

    spin_lock_irqsave (&nl->lock, flags);

    /* Stand our ground if a datagram is on the wire */
    if (nl->connection != PLIP_CN_NONE) {
        nl->should_relinquish = 1;
        spin_unlock_irqrestore(&nl->lock, flags);
        return 1;
    }

    nl->port_owner = 0; /* Remember that we released the bus */
    spin_unlock_irqrestore(&nl->lock, flags);
    return 0;
  }

Additionally, plip_receive_packet() (Line 376) may need to verify that
nl->port_owner is still valid before accessing the bus.

However, I am unsure how to proceed once nl->port_owner is found to be 0,
so I am reporting this as a possible bug.

I am also not sure whether this possible data race is real. Any feedback
would be appreciated, thanks!

Best wishes,
Tuo Li