[BUG] net: ipvlan: failed newlink leaves shared port state changed

[Cheng Yongkang <teel4res@gmail.com>]

Hi all,

Two failure paths in creation of a new ipvlan slave mutate shared
ipvl_port state even though the requested device is not created.

1. ipvlan_link_new() publishes the new mode/flags and existing slaves'
   IFF_NOARP/L3S state.  A later do_set_master() failure deletes only
   the new device.  The existing slave keeps the port alive, so none of
   the shared changes are rolled back.

2. If L3S hook registration fails inside ipvlan_set_port_mode(), the
   per-slave IFF_NOARP change is reverted, but the newly written shared
   port->flags value is not.

Observed on Linux v7.3, commit
08ab31164c55f20c7a2653de3186ae333470e2c1.

For the first path, an RTM_NEWLINK requesting L3S+VEPA with a nonexistent
IFLA_MASTER returned -EINVAL and no second link was created.  The
pre-existing slave nevertheless changed from:

  mode=L2 flags=0 noarp=0

to:

  mode=L3S flags=VEPA noarp=1

For the second path, fault injection in nf_hook_entries_grow() made hook
registration return -ENOMEM.  The failed request left the existing
slave's shared port at mode=L2 flags=VEPA while correctly restoring
IFF_NOARP.

The newlink operation should be transactional: defer shared-port
publication until all generic netlink steps can no longer fail, or
restore the full previous mode, flags, NOARP, hook, and l3mdev state if
the outer path deletes the new device.

The 2026-10-01 ipvlan review thread notices the narrower flags-ordering
problem, but does not cover the later do_set_master() failure or the
complete L3S/mode rollback.

Candidate BR-011 and BR-012 reproduce the two distinct failure sizes;
they are presented as one transactional-state bug here.

The PoCs, failslab runner, and logs are available on request.

This was found with a multi-agent workflow; both state
transitions were reproduced under QEMU.

Thanks,
Cheng Yongkang