<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/net/xfrm, branch v7.2-rc1</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v7.2-rc1</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v7.2-rc1'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-06-23T23:22:24+00:00</updated>
<entry>
<title>Merge tag 'ipsec-2026-06-22' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec</title>
<updated>2026-06-23T23:22:24+00:00</updated>
<author>
<name>Jakub Kicinski</name>
<email>kuba@kernel.org</email>
</author>
<published>2026-06-23T23:22:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e9deb406c10f5a73bcfd62f42ca1187b220bc188'/>
<id>urn:sha1:e9deb406c10f5a73bcfd62f42ca1187b220bc188</id>
<content type='text'>
Steffen Klassert says:

====================
pull request (net): ipsec 2026-06-22

1) xfrm: use compat translator only for u64 alignment mismatch
   Gate the XFRM_USER_COMPAT translator on COMPAT_FOR_U64_ALIGNMENT
   so 32-bit compat tasks on arches whose 32-bit ABI already matches
   the native 64-bit layout are no longer rejected with -EOPNOTSUPP.
   From Sanman Pradhan.

2) net: af_key: initialize alg_key_len for IPComp states
   Initialize the alg_key_len to 0 in the IPComp branch of
   pfkey_msg2xfrm_state() so an uninitialized value cannot drive
   xfrm_alg_len() into a slab-out-of-bounds kmemdup during
   XFRM_MSG_MIGRATE. From Zijing Yin.

3) xfrm: Fix dev use-after-free in xfrm async resumption
   Stash the original skb-&gt;dev and extend the RCU critical section
   across xfrm_rcv_cb() and transport_finish() to prevent a
   tunnel-device UAF and original-device refcount leak when a
   callback replaces skb-&gt;dev. From Dong Chenchen.

4) xfrm: Fix xfrm state cache insertion race
   Move the state-validity check inside xfrm_state_lock in the
   input state cache insertion path so a state cannot be killed
   between the check and the insert. From Herbert Xu.

5) xfrm: annotate data-races around xfrm_policy_count[] and xfrm_policy_default[]
   Add READ_ONCE()/WRITE_ONCE() annotations on xfrm_policy_count
   and xfrm_policy_default to silence the KCSAN data race reported
   on net-&gt;xfrm.policy_count. From Eric Dumazet.

6) espintcp: use sk_msg_free_partial to fix partial send
   Replace the manual skmsg accounting in espintcp with
   sk_msg_free_partial() so the skmsg stays consistent on every
   iteration and the partial-send accounting bugs go away.
   From Sabrina Dubroca.

7) xfrm: validate selector family and prefixlen during match
   Reject mismatched address families in xfrm_selector_match() and
   bound prefixlen in addr4_match()/addr_match() to prevent the
   shift-out-of-bounds syzbot reported when an AF_UNSPEC selector
   with a large prefixlen is matched against an IPv4 flow.
   From Eric Dumazet.

* tag 'ipsec-2026-06-22' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec:
  xfrm: validate selector family and prefixlen during match
  espintcp: use sk_msg_free_partial to fix partial send
  xfrm: annotate data-races around xfrm_policy_count[] and xfrm_policy_default[]
  xfrm: Fix xfrm state cache insertion race
  xfrm: Fix dev use-after-free in xfrm async resumption
  net: af_key: initialize alg_key_len for IPComp states
  xfrm: use compat translator only for u64 alignment mismatch
====================

Link: https://patch.msgid.link/20260622075726.29685-1-steffen.klassert@secunet.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>xfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for changelink</title>
<updated>2026-06-17T23:01:53+00:00</updated>
<author>
<name>Maoyi Xie</name>
<email>maoyixie.tju@gmail.com</email>
</author>
<published>2026-06-12T08:59:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=095515d89b19b6cc19dfcdc846f97403ed1ebce3'/>
<id>urn:sha1:095515d89b19b6cc19dfcdc846f97403ed1ebce3</id>
<content type='text'>
xfrmi_changelink() operates on at most two netns, dev_net(dev) and the
interface link netns xi-&gt;net. They differ once the device is created in
or moved to a netns other than the one the request runs in. The rtnl
changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a
caller privileged there but not in xi-&gt;net can rewrite an interface that
lives in xi-&gt;net.

Gate xfrmi_changelink() on rtnl_dev_link_net_capable() at its top,
before any attribute is parsed.

Reported-by: Xiao Liang &lt;shaw.leon@gmail.com&gt;
Closes: https://lore.kernel.org/netdev/CABAhCOSzP1vaThGV35_VnsRCb=87_CPjPVsTHbq905k8A+BuUg@mail.gmail.com/
Fixes: f203b76d7809 ("xfrm: Add virtual xfrm interfaces")
Cc: stable@vger.kernel.org
Signed-off-by: Maoyi Xie &lt;maoyixie.tju@gmail.com&gt;
Reviewed-by: Kuniyuki Iwashima &lt;kuniyu@google.com&gt;
Link: https://patch.msgid.link/20260612085941.3158249-8-maoyixie.tju@gmail.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>xfrm: validate selector family and prefixlen during match</title>
<updated>2026-06-17T09:17:27+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2026-06-15T09:02:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=40f0b1047918539f0b0f795ac65e35336b4c2c78'/>
<id>urn:sha1:40f0b1047918539f0b0f795ac65e35336b4c2c78</id>
<content type='text'>
syzbot reported a shift-out-of-bounds in xfrm_selector_match()
due to AF_UNSPEC selector with large prefixlen (e.g. 128) matched
against IPv4 flow (when XFRM_STATE_AF_UNSPEC is set).

Fix this by:

- Rejecting mismatched families in xfrm_selector_match.
- Returning false in addr4_match if prefixlen &gt; 32.
- Returning false in addr_match if prefixlen &gt; 128 (prevents overflow).

Fixes: 3f0ab59e6537 ("xfrm: validate new SA's prefixlen using SA family when sel.family is unset")
Reported-by: syzbot+9383b1ff0df4b29ca5e6@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/6a2fbe35.be3f099c.2836ae.0018.GAE@google.com/T/#u
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: Steffen Klassert &lt;steffen.klassert@secunet.com&gt;
</content>
</entry>
<entry>
<title>espintcp: use sk_msg_free_partial to fix partial send</title>
<updated>2026-06-17T09:17:27+00:00</updated>
<author>
<name>Sabrina Dubroca</name>
<email>sd@queasysnail.net</email>
</author>
<published>2026-06-12T14:11:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=007800408002d871f5699bdb944f985896730b8f'/>
<id>urn:sha1:007800408002d871f5699bdb944f985896730b8f</id>
<content type='text'>
sk_msg_free_partial() ensures consistency of the skmsg at every
iteration, without having to manually handle uncharges and offsets.
This simplifies the code, and fixes some bugs in skmsg accounting when
we don't send the full contents.

Cc: stable@vger.kernel.org
Fixes: e27cca96cd68 ("xfrm: add espintcp (RFC 8229)")
Reported-by: Aaron Esau &lt;aaron1esau@gmail.com&gt;
Reported-by: Yiming Qian &lt;yimingqian591@gmail.com&gt;
Signed-off-by: Sabrina Dubroca &lt;sd@queasysnail.net&gt;
Signed-off-by: Steffen Klassert &lt;steffen.klassert@secunet.com&gt;
</content>
</entry>
<entry>
<title>xfrm: annotate data-races around xfrm_policy_count[] and xfrm_policy_default[]</title>
<updated>2026-06-17T09:17:26+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2026-06-12T05:56:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=68de007d5ac9df0e3f4f187a179c5c842bb5a2be'/>
<id>urn:sha1:68de007d5ac9df0e3f4f187a179c5c842bb5a2be</id>
<content type='text'>
KCSAN reported a data race involving net-&gt;xfrm.policy_count access.

Add missing READ_ONCE()/WRITE_ONCE() annotations on
xfrm_policy_count and xfrm_policy_default.

Fixes: 2518c7c2b3d7 ("[XFRM]: Hash policies when non-prefixed.")
Reported-by: syzbot+d85ba1c732720b9a4097@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/6a2b9e96.99669fcc.12a77b.0006.GAE@google.com/T/#u
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: Steffen Klassert &lt;steffen.klassert@secunet.com&gt;
</content>
</entry>
<entry>
<title>xfrm: Fix xfrm state cache insertion race</title>
<updated>2026-06-17T09:17:17+00:00</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2026-06-12T04:58:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ddd3d0132920319ac426e12456013eadbae67e15'/>
<id>urn:sha1:ddd3d0132920319ac426e12456013eadbae67e15</id>
<content type='text'>
The xfrm input state cache insertion code checks the validity of
the state before acquiring the global xfrm_state_lock.  Thus it's
possible for someone else to kill the state after it passed the
validity check, and then the insertion will add the dead state
to the cache.

Fix this by moving the validity check inside the lock.

This entire function is called on the input path, where BH must
be off (e.g., the caller of this function xfrm_input acquires
its spinlocks without disabling BH).

So there is no need to disable BH here or take the RCU read lock.
Remove both and replace them with an assertion that trips if BH
is accidentally enabled on some future calling path.

Fixes: 81a331a0e72d ("xfrm: Add an inbound percpu state cache.")
Reported-by: Zero Day Initiative &lt;zdi-disclosures@trendmicro.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Reviewed-by: Simon Horman &lt;horms@kernel.org&gt;
Signed-off-by: Steffen Klassert &lt;steffen.klassert@secunet.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'ipsec-next-2026-06-12' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next</title>
<updated>2026-06-13T20:16:39+00:00</updated>
<author>
<name>Jakub Kicinski</name>
<email>kuba@kernel.org</email>
</author>
<published>2026-06-13T20:16:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=431662b642c7f1312612e6f53e8583625d51c125'/>
<id>urn:sha1:431662b642c7f1312612e6f53e8583625d51c125</id>
<content type='text'>
Steffen Klassert says:

====================
pull request (net-next): ipsec-next 2026-06-12

1) Replace the open-coded manual cleanup in xfrm_add_policy() error
   path with xfrm_policy_destroy() for consistency with
   xfrm_policy_construct().
   From Deepanshu Kartikey.

2) Limit XFRMA_TFCPAD to a sensible maximum (max IP length, 64k) since
   u32 is excessive for traffic flow confidentiality padding.
   From David Ahern.

3) Add a new netlink message XFRM_MSG_MIGRATE_STATE that
   allows migrating individual IPsec SAs independently of
   their policies. The existing XFRM_MSG_MIGRATE is tightly coupled
   to policy+SA migration, lacks SPI for unique SA identification,
   and cannot express reqid changes or migrate Transport mode
   selectors. The new interface identifies the SA via SPI and mark,
   supports reqid changes, address family changes, encap removal,
   and uses an atomic create+install flow under x-&gt;lock to prevent
   SN/IV reuse during AEAD SA migration.
   From Antony Antony.

* tag 'ipsec-next-2026-06-12' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next:
  xfrm: add documentation for XFRM_MSG_MIGRATE_STATE
  xfrm: restrict netlink attributes for XFRM_MSG_MIGRATE_STATE
  xfrm: add XFRM_MSG_MIGRATE_STATE for single SA migration
  xfrm: make xfrm_dev_state_add xuo parameter const
  xfrm: extract address family and selector validation helpers
  xfrm: refactor XFRMA_MTIMER_THRESH validation into a helper
  xfrm: move encap and xuo into struct xfrm_migrate
  xfrm: add error messages to state migration
  xfrm: add state synchronization after migration
  xfrm: check family before comparing addresses in migrate
  xfrm: split xfrm_state_migrate into create and install functions
  xfrm: rename reqid in xfrm_migrate
  xfrm: fix NAT-related field inheritance in SA migration
  xfrm: allow migration from UDP encapsulated to non-encapsulated ESP
  xfrm: add extack to xfrm_init_state
  xfrm: remove redundant assignments
  xfrm: Reject excessive values for XFRMA_TFCPAD
  xfrm: cleanup error path in xfrm_add_policy()
====================

Link: https://patch.msgid.link/20260612074725.1760473-1-steffen.klassert@secunet.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>xfrm: Fix dev use-after-free in xfrm async resumption</title>
<updated>2026-06-12T06:39:59+00:00</updated>
<author>
<name>Dong Chenchen</name>
<email>dongchenchen2@huawei.com</email>
</author>
<published>2026-06-09T09:21:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8045c0df98d4f14c54e5cb875f1c9c0ce89fe4ff'/>
<id>urn:sha1:8045c0df98d4f14c54e5cb875f1c9c0ce89fe4ff</id>
<content type='text'>
xfrm async resumption hold skb-&gt;dev refcnt until after transport_finish.
However, xfrm_rcv_cb may modify skb-&gt;dev to tunnel dev without taking
device reference, such as vti_rcv_cb. The subsequent async resumption
will decrement the tunnel device's reference count, which lead to uaf
of tunnel dev and refcnt leak of orig dev as below:

unregister_netdevice: waiting for vti1 to become free. Usage count = -2

Stash the original skb-&gt;dev to fix refcnt imbalance. The new skb-&gt;dev set
by xfrm_rcv_cb can race with device teardown. Extend rcu protection over
xfrm_rcv_cb and transport_finish to prevent races.

Fixes: 1c428b038400 ("xfrm: hold dev ref until after transport_finish NF_HOOK")
Reported-by: Xu Chunxiao &lt;xuchunxiao3@huawei.com&gt;
Signed-off-by: Dong Chenchen &lt;dongchenchen2@huawei.com&gt;
Signed-off-by: Steffen Klassert &lt;steffen.klassert@secunet.com&gt;
</content>
</entry>
<entry>
<title>xfrm: use compat translator only for u64 alignment mismatch</title>
<updated>2026-06-12T06:38:48+00:00</updated>
<author>
<name>Sanman Pradhan</name>
<email>psanman@juniper.net</email>
</author>
<published>2026-06-07T16:47:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=355fbcbdc2539cca7890b0d0914d4ce0f985ad74'/>
<id>urn:sha1:355fbcbdc2539cca7890b0d0914d4ce0f985ad74</id>
<content type='text'>
The XFRM compat layer (CONFIG_XFRM_USER_COMPAT) translates 32-bit xfrm
netlink and setsockopt messages into the native 64-bit layout. It is
only needed on architectures where the 32-bit and 64-bit ABIs disagree
on u64 alignment, which the kernel encodes as COMPAT_FOR_U64_ALIGNMENT.

That symbol is defined only by arch/x86. XFRM_USER_COMPAT depends on it,
so the translator can never be built on any other architecture,
including arm64, which still provides a 32-bit compat ABI (CONFIG_COMPAT)
for AArch32 EL0 userspace. On arm64 the AArch32 EABI already aligns u64
to 8 bytes, identical to the AArch64 ABI, so no translation is required
and the native code path is correct for 32-bit tasks.

However, xfrm_user_rcv_msg() and xfrm_user_policy() gate on
in_compat_syscall() alone and then call xfrm_get_translator(), which
returns NULL when no translator is registered. On arm64 that is always
the case, so every xfrm netlink message and the XFRM_POLICY setsockopt
issued by a 32-bit task returns -EOPNOTSUPP. A 32-bit userspace process
on arm64 (and on any other arch with CONFIG_COMPAT but without
COMPAT_FOR_U64_ALIGNMENT) therefore cannot configure XFRM state or
policy through the XFRM_USER netlink API, and cannot use the XFRM_POLICY
setsockopt path, because both fail before reaching the native parser.

The translator series replaced the blanket compat rejection with a
translator lookup. That made the path usable on x86 when the translator
is available, but left architectures that cannot build the translator
permanently rejected even when their compat layout already matches the
native layout. Let those architectures use the native parser instead.

Gate the translator requirement on COMPAT_FOR_U64_ALIGNMENT instead of
on in_compat_syscall() alone. Gating on the ABI property rather than on
CONFIG_XFRM_USER_COMPAT is deliberate: on x86 with IA32_EMULATION=y but
XFRM_USER_COMPAT=n, a 32-bit task must still be rejected rather than
routed through the native parser, which would misread genuinely
4-byte-aligned x86-32 messages. COMPAT_FOR_U64_ALIGNMENT is the ABI
property that makes the XFRM translator mandatory.

Only the receive/input direction needs the guard. The send, dump and
notification paths already call the translator as "if (xtr) { ... }"
with no error on NULL, so on arches without a translator they no-op and
the kernel emits native 64-bit-layout messages, which is what an AArch32
task expects.

Tested on Juniper SRX hardware: with the fix, 32-bit IPsec userspace
netlink and XFRM_POLICY setsockopt operations that previously failed
with -EOPNOTSUPP now succeed; x86 behaviour is unchanged by inspection.

Fixes: 5106f4a8acff ("xfrm/compat: Add 32=&gt;64-bit messages translator")
Fixes: 96392ee5a13b ("xfrm/compat: Translate 32-bit user_policy from sockptr")
Cc: stable@vger.kernel.org
Signed-off-by: Sanman Pradhan &lt;psanman@juniper.net&gt;
Signed-off-by: Steffen Klassert &lt;steffen.klassert@secunet.com&gt;
</content>
</entry>
<entry>
<title>xfrm: espintcp: do not reuse an in-progress partial send</title>
<updated>2026-06-05T11:20:03+00:00</updated>
<author>
<name>Wyatt Feng</name>
<email>bronzed_45_vested@icloud.com</email>
</author>
<published>2026-06-02T16:46:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c381039ade2e161ab08c0eda73c4f8b9a7115928'/>
<id>urn:sha1:c381039ade2e161ab08c0eda73c4f8b9a7115928</id>
<content type='text'>
espintcp keeps a single in-flight transmit in ctx-&gt;partial.
Before building a new sk_msg, espintcp_sendmsg() first tries to flush
that state through espintcp_push_msgs().

For blocking callers, espintcp_push_msgs() may return success even when
the previous partial send is still pending. espintcp_sendmsg() would
then reinitialize emsg-&gt;skmsg and reuse ctx-&gt;partial while the old
transfer still owns that state.

Do not rebuild the send message when ctx-&gt;partial is still in progress.
If espintcp_push_msgs() returns with emsg-&gt;len still set, fail the new
send instead of overwriting the live partial state.

This is a memory-safety fix: reusing the live partial-send state can
leave a stale offset attached to a new sk_msg and lead to an out-of-
bounds read in the send path.

tcp_sendmsg_locked() already handles waiting for send buffer memory, so
the fix here is just to preserve espintcp's one-message-at-a-time
transmit state.

Fixes: e27cca96cd68 ("xfrm: add espintcp (RFC 8229)")
Cc: stable@kernel.org
Reported-by: Yuan Tan &lt;yuantan098@gmail.com&gt;
Reported-by: Yifan Wu &lt;yifanwucs@gmail.com&gt;
Reported-by: Juefei Pu &lt;tomapufckgml@gmail.com&gt;
Reported-by: Zhengchuan Liang &lt;zcliangcn@gmail.com&gt;
Reported-by: Xin Liu &lt;bird@lzu.edu.cn&gt;
Assisted-by: Codex:GPT-5.4
Signed-off-by: Wyatt Feng &lt;bronzed_45_vested@icloud.com&gt;
Signed-off-by: Ren Wei &lt;n05ec@lzu.edu.cn&gt;
Signed-off-by: Steffen Klassert &lt;steffen.klassert@secunet.com&gt;
</content>
</entry>
</feed>
