From: Daehyeon Ko <4ncienth@gmail.com>
To: David Ahern <dsahern@kernel.org>, Ido Schimmel <idosch@nvidia.com>
Cc: "David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Hannes Frederic Sowa <hannes@stressinduktion.org>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Daehyeon Ko <4ncienth@gmail.com>
Subject: [PATCH net v4 0/4] ipv6: fix address publication races with addrconf_ifdown
Date: Thu, 15 Oct 2026 14:06:47 +0900 [thread overview]
Message-ID: <20261015050651.1841557-1-4ncienth@gmail.com> (raw)
The first patch removes each non-kept ifaddr from the address hash during
the per-device list cleanup. This prevents addrconf_ifdown() from freeing
a captured object that a late publisher left linked in the hash.
The second patch serializes hash and device-list publication with dead
device teardown. The cleanup patch is now first, so the newly atomic
publisher cannot create a captured-but-still-hashed intermediate state.
The third patch initializes a temporary address's public-ifaddr reference
and both timestamps before publication. No lifetime update can observe a
partially initialized relationship.
The fourth patch prevents stable-privacy DAD recovery from changing a
DEAD replacement address back to PREDAD and queueing work after teardown
has cleared its route.
The original deterministic test used a direct internal caller, kprobes and
atomic rendezvous at existing instruction boundaries. A real RA separately
reached ipv6_add_addr() with can_block=false. No new kernel build or
runtime test was run for v4. Validation used source review, strict
checkpatch and multi-tree apply tests.
Changes in v4:
- Reorder the first two patches so the hash cleanup precedes publication
serialization; retain all existing patch subjects.
- Describe the freed hash entry as a use-after-free and document the mutual
backport dependency in patches 1 and 2.
- Keep patch 2 scoped to idev->dead; drop the preliminary READ_ONCE()
conversions and the unrelated disable_ipv6 recheck.
- State which finding was triggered and which follow-ons came from source
review, including the observed device-teardown symptom.
- Initialize ifpub, cstamp and tstamp together in patch 3.
- Add patch 4 for the stable-privacy DAD recovery race.
Link: https://lore.kernel.org/r/20261009054042.272944-1-4ncienth@gmail.com
Link: https://lore.kernel.org/r/179161099408.434549.14449036924552933828@kernel.org
Link: https://lore.kernel.org/r/179161099539.434549.2238120015372268173@kernel.org
Link: https://lore.kernel.org/r/179161099665.434549.5858601179492551889@kernel.org
Link: https://lore.kernel.org/r/20261012145306.GB779501@shredder
Link: https://lore.kernel.org/r/20261012151316.GA798355@shredder
Link: https://lore.kernel.org/r/20261012145240.GA779501@shredder
Link: https://lore.kernel.org/r/179152464915.2527009.3889155025831898857@kernel.org
Daehyeon Ko (4):
ipv6: remove ifaddr from hash during ifdown list cleanup
ipv6: serialize address publication with device teardown
ipv6: initialize temporary ifaddr before publication
ipv6: do not restart DAD for a dead ifaddr
include/net/addrconf.h | 3 +++
net/ipv6/addrconf.c | 46 +++++++++++++++++++++++++++++++++-------------
2 files changed, 36 insertions(+), 13 deletions(-)
base-commit: 513444cc62e231a11c9b15ea88de0890da9b2b4f
--
2.55.0
next reply other threads:[~2026-10-15 5:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-15 5:06 Daehyeon Ko [this message]
2026-10-15 5:06 ` [PATCH net v4 1/4] ipv6: remove ifaddr from hash during ifdown list cleanup Daehyeon Ko
2026-10-15 14:31 ` Ido Schimmel
2026-10-15 5:06 ` [PATCH net v4 2/4] ipv6: serialize address publication with device teardown Daehyeon Ko
2026-10-15 14:32 ` Ido Schimmel
2026-10-15 5:06 ` [PATCH net v4 3/4] ipv6: initialize temporary ifaddr before publication Daehyeon Ko
2026-10-15 14:32 ` Ido Schimmel
2026-10-15 5:06 ` [PATCH net v4 4/4] ipv6: do not restart DAD for a dead ifaddr Daehyeon Ko
2026-10-15 14:32 ` Ido Schimmel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261015050651.1841557-1-4ncienth@gmail.com \
--to=4ncienth@gmail.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@kernel.org \
--cc=hannes@stressinduktion.org \
--cc=horms@kernel.org \
--cc=idosch@nvidia.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.