[BUG] net: plip: a possible race in plip_preempt() leading to UAF

[Tuo Li <islituo@gmail.com>]

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