[PATCH] ipv4: Serialize netconf GET requests with RTNL

[PATCH] ipv4: Serialize netconf GET requests with RTNL

[Cen Zhang]

An in_device returned by in_dev_get() must stay alive until
inet_netconf_get_devconf() finishes reading its cnf. However, the helper
samples dev->ip_ptr under RCU and unconditionally increments refcnt,
then returns the pointer outside RCU without checking whether the count
was already zero. The net_device reference held by the request does not
retain the separately allocated in_device.

A down interface without IPv4 addresses or multicast owners can have
only the ip_ptr publication reference. Lowering its MTU below
IPV4_MIN_MTU invokes inetdev_destroy() through the RTNL-held
NETDEV_CHANGEMTU notifier. RTM_GETNETCONF runs without RTNL, allowing
the final put to follow its pointer sample but precede its increment:

  RTM_GETNETCONF                   MTU change (RTNL held)
  in_dev_get():
    rcu_read_lock()
    sample dev->ip_ptr
                                  inetdev_destroy():
                                    clear dev->ip_ptr
                                    in_dev_put(): refcnt -> 0
                                    call_rcu(in_dev_free_rcu)
    refcount_inc() from zero
    rcu_read_unlock()
                                  in_dev_free_rcu(): kfree()
  inet_netconf_fill_devconf():
    read in_dev->cnf

The zero-count increment warns and saturates the refcount, but cannot
cancel the queued free. Once the request leaves RCU, the callback can
free the attachment before the configuration read, causing a
use-after-free. Restoring a valid MTU can publish a new attachment on
the same device while the request still holds the old pointer.

Drop RTNL_FLAG_DOIT_UNLOCKED so rtnetlink holds RTNL from lookup through
reply construction and reference release. This serializes the request
with inetdev_destroy(), preventing the publication reference from being
dropped during acquisition or use. The dump handler already holds RCU
through its configuration reads and keeps RTNL_FLAG_DUMP_UNLOCKED.

KASAN report as below:

    BUG: KASAN: slab-use-after-free in inet_netconf_fill_devconf+0x748/0x790
    Read of size 4 at addr ffff88811d70b958 by task ip_core_fixture/498

    CPU: 1 UID: 0 PID: 498 Comm: ip_core_fixture Tainted: G        W           7.2.0-rc5-pmb-bt-functional-v1+ #1 PREEMPT(lazy)
    Tainted: [W]=WARN
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
    Call Trace:
     <TASK>
     dump_stack_lvl+0x93/0xd0
     print_report+0xce/0x630
     ? inet_netconf_fill_devconf+0x748/0x790
     ? srso_alias_return_thunk+0x5/0xfbef5
     ? __virt_addr_valid+0x20d/0x410
     ? inet_netconf_fill_devconf+0x748/0x790
     kasan_report+0xe0/0x110
     ? inet_netconf_fill_devconf+0x748/0x790
     inet_netconf_fill_devconf+0x748/0x790
     ? __pfx_inet_netconf_fill_devconf+0x10/0x10
     ? inet_netconf_get_devconf+0xaef/0xe40
     inet_netconf_get_devconf+0x41c/0xe40
     ? __pfx_inet_netconf_get_devconf+0x10/0x10
     ? __pfx_inet_netconf_get_devconf+0x10/0x10
     ? rtnetlink_rcv_msg+0x795/0xce0
     ? srso_alias_return_thunk+0x5/0xfbef5
     ? lock_release+0xc8/0x280
     ? __pfx_inet_netconf_get_devconf+0x10/0x10
     rtnetlink_rcv_msg+0x7b9/0xce0
     ? __pfx_rtnetlink_rcv_msg+0x10/0x10
     ? srso_alias_return_thunk+0x5/0xfbef5
     ? __lock_acquire+0x466/0x2260
     ? lock_acquire+0x17b/0x2f0
     netlink_rcv_skb+0x133/0x390
     ? __pfx_rtnetlink_rcv_msg+0x10/0x10
     ? __pfx_netlink_rcv_skb+0x10/0x10
     ? netlink_deliver_tap+0xdf/0xbd0
     ? srso_alias_return_thunk+0x5/0xfbef5
     ? netlink_deliver_tap+0x173/0xbd0
     netlink_unicast+0x504/0x840
     ? __pfx_netlink_unicast+0x10/0x10
     netlink_sendmsg+0x7f7/0xcf0
     ? __pfx_netlink_sendmsg+0x10/0x10
     ? srso_alias_return_thunk+0x5/0xfbef5
     ? selinux_socket_sendmsg+0x160/0x280
     ? __pfx_netlink_sendmsg+0x10/0x10
     ____sys_sendmsg+0x88b/0x9d0
     ? __pfx_____sys_sendmsg+0x10/0x10
     ___sys_sendmsg+0x125/0x1d0
     ? srso_alias_return_thunk+0x5/0xfbef5
     ? __pfx____sys_sendmsg+0x10/0x10
     ? srso_alias_return_thunk+0x5/0xfbef5
     ? lock_release+0xc8/0x280
     ? srso_alias_return_thunk+0x5/0xfbef5
     ? netlink_bind+0x518/0x900
     ? srso_alias_return_thunk+0x5/0xfbef5
     __sys_sendmsg+0x13e/0x1e0
     ? __pfx___sys_sendmsg+0x10/0x10
     do_syscall_64+0x115/0x6a0
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    RIP: 0033:0x7f8ea8b31687
    Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff
    RSP: 002b:00007fff83200d90 EFLAGS: 00000202 ORIG_RAX: 000000000000002e
    RAX: ffffffffffffffda RBX: 00007f8ea8a9f780 RCX: 00007f8ea8b31687
    RDX: 0000000000000000 RSI: 00007fff83200e50 RDI: 0000000000000003
    RBP: 00007fff83202ed0 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000
    R13: 00007fff83203070 R14: 00007f8ea8cdd000 R15: 0000559d62722c80
     </TASK>

    Allocated by task 496:
     kasan_save_stack+0x33/0x60
     kasan_save_track+0x14/0x30
     __kasan_kmalloc+0xaa/0xb0
     __kmalloc_cache_noprof+0x251/0x630
     inetdev_init+0x60/0x550
     inetdev_event+0x71e/0x1780
     notifier_call_chain+0xbb/0x330
     call_netdevice_notifiers_info+0xa2/0xf0
     register_netdevice+0x17b0/0x2090
     rtnl_newlink+0x1a30/0x1f40
     rtnetlink_rcv_msg+0x7b9/0xce0
     netlink_rcv_skb+0x133/0x390
     netlink_unicast+0x504/0x840
     netlink_sendmsg+0x7f7/0xcf0
     ____sys_sendmsg+0x88b/0x9d0
     ___sys_sendmsg+0x125/0x1d0
     __sys_sendmsg+0x13e/0x1e0
     do_syscall_64+0x115/0x6a0
     entry_SYSCALL_64_after_hwframe+0x77/0x7f

    Freed by task 0:
     kasan_save_stack+0x33/0x60
     kasan_save_track+0x14/0x30
     kasan_save_free_info+0x3b/0x60
     __kasan_slab_free+0x5f/0x80
     kfree+0x12b/0x530
     in_dev_free_rcu+0x51/0x90
     rcu_core+0x661/0x1d10
     handle_softirqs+0x201/0x930
     __irq_exit_rcu+0x110/0x1e0
     irq_exit_rcu+0xe/0x20
     sysvec_apic_timer_interrupt+0x6c/0x80
     asm_sysvec_apic_timer_interrupt+0x1a/0x20

    Last potentially related work creation:
     kasan_save_stack+0x33/0x60
     kasan_record_aux_stack+0xa7/0xc0
     __call_rcu_common.constprop.0+0x76/0xbd0
     in_dev_finish_destroy+0x12e/0x190
     inetdev_event+0xa37/0x1780
     notifier_call_chain+0xbb/0x330
     call_netdevice_notifiers_info+0xa2/0xf0
     netif_set_mtu_ext+0x47d/0x6a0
     netif_set_mtu+0x8b/0x120
     dev_set_mtu+0xb9/0x180
     dev_ifsioc+0x3b8/0x1820
     dev_ioctl+0x301/0xf80
     sock_do_ioctl+0x1dc/0x2b0
     sock_ioctl+0x41b/0x670
     __x64_sys_ioctl+0x163/0x1d0
     do_syscall_64+0x115/0x6a0
     entry_SYSCALL_64_after_hwframe+0x77/0x7f

    The buggy address belongs to the object at ffff88811d70b800
     which belongs to the cache kmalloc-512 of size 512
    The buggy address is located 344 bytes inside of
     freed 512-byte region [ffff88811d70b800, ffff88811d70ba00)

    The buggy address belongs to the physical page:
    page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x11d70b
    flags: 0x200000000000000(node=0|zone=2)
    page_type: f5(slab)
    raw: 0200000000000000 ffff888100042780 dead000000000122 0000000000000000
    raw: 0000000000000000 0000000000040004 00000000f5000000 0000000000000000
    page dumped because: kasan: bad access detected

    Memory state around the buggy address:
     ffff88811d70b800: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff88811d70b880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    >ffff88811d70b900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                        ^
     ffff88811d70b980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff88811d70ba00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    ==================================================================

Fixes: bbcf91053bb6 ("inet: do not use RTNL in inet_netconf_get_devconf()")
Assisted-by: LLM
Signed-off-by: Cen Zhang <zzzccc427@gmail.com>
---

diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 5b6b11c943e453742b4893f1c9bd9e70d3d37a6f..4e9de0c6b2c1426c4b4c8638a0a6da4be9c2034d 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -2958,7 +2958,7 @@ static const struct rtnl_msg_handler devinet_rtnl_msg_handlers[] __initconst = {
 	 .flags = RTNL_FLAG_DUMP_UNLOCKED | RTNL_FLAG_DUMP_SPLIT_NLM_DONE},
 	{.protocol = PF_INET, .msgtype = RTM_GETNETCONF,
 	 .doit = inet_netconf_get_devconf, .dumpit = inet_netconf_dump_devconf,
-	 .flags = RTNL_FLAG_DOIT_UNLOCKED | RTNL_FLAG_DUMP_UNLOCKED},
+	 .flags = RTNL_FLAG_DUMP_UNLOCKED},
 	{.owner = THIS_MODULE, .protocol = PF_INET, .msgtype = RTM_GETMULTICAST,
 	 .dumpit = inet_dump_ifmcaddr, .flags = RTNL_FLAG_DUMP_UNLOCKED},
 };

Re: [PATCH] ipv4: Serialize netconf GET requests with RTNL

[Ido Schimmel]

On Thu, Oct 08, 2026 at 02:32:18PM +0800, Cen Zhang wrote:
> An in_device returned by in_dev_get() must stay alive until
> inet_netconf_get_devconf() finishes reading its cnf. However, the helper
> samples dev->ip_ptr under RCU and unconditionally increments refcnt,
> then returns the pointer outside RCU without checking whether the count
> was already zero. The net_device reference held by the request does not
> retain the separately allocated in_device.
> 
> A down interface without IPv4 addresses or multicast owners can have
> only the ip_ptr publication reference. Lowering its MTU below
> IPV4_MIN_MTU invokes inetdev_destroy() through the RTNL-held
> NETDEV_CHANGEMTU notifier. RTM_GETNETCONF runs without RTNL, allowing
> the final put to follow its pointer sample but precede its increment:
> 
>   RTM_GETNETCONF                   MTU change (RTNL held)
>   in_dev_get():
>     rcu_read_lock()
>     sample dev->ip_ptr
>                                   inetdev_destroy():
>                                     clear dev->ip_ptr
>                                     in_dev_put(): refcnt -> 0
>                                     call_rcu(in_dev_free_rcu)
>     refcount_inc() from zero
>     rcu_read_unlock()
>                                   in_dev_free_rcu(): kfree()
>   inet_netconf_fill_devconf():
>     read in_dev->cnf
> 
> The zero-count increment warns and saturates the refcount, but cannot
> cancel the queued free. Once the request leaves RCU, the callback can
> free the attachment before the configuration read, causing a
> use-after-free. Restoring a valid MTU can publish a new attachment on
> the same device while the request still holds the old pointer.
> 
> Drop RTNL_FLAG_DOIT_UNLOCKED so rtnetlink holds RTNL from lookup through
> reply construction and reference release. This serializes the request
> with inetdev_destroy(), preventing the publication reference from being
> dropped during acquisition or use. The dump handler already holds RCU
> through its configuration reads and keeps RTNL_FLAG_DUMP_UNLOCKED.
> 
> KASAN report as below:

[...]

> 
> Fixes: bbcf91053bb6 ("inet: do not use RTNL in inet_netconf_get_devconf()")
> Assisted-by: LLM
> Signed-off-by: Cen Zhang <zzzccc427@gmail.com>

The correct fix is to use refcount_inc_not_zero() in in_dev_get(), in a
similar fashion to commit 0e243671bc7b ("ipv6: prevent in6_dev_get()
from resurrecting inet6_dev"). Please base your v2 on the following
submission and the feedback I provided:

https://lore.kernel.org/netdev/20260815172032.79740-1-baul.lee@xbow.com/

And please read:

https://docs.kernel.org/next/process/maintainer-netdev.html

Notably:

1. "designate your patch to a tree - [PATCH net] or [PATCH net-next]"
2. "don’t repost your patches within one 24h period"

Also, trim the traces (preferably decoded) to what is actually useful:

https://docs.kernel.org/next/process/submitting-patches.html#backtraces-in-commit-messages

Re: [PATCH] ipv4: Serialize netconf GET requests with RTNL

[Cen Zhang]

Hi Ido,

> The correct fix is to use refcount_inc_not_zero() in in_dev_get(), in a
> similar fashion to commit 0e243671bc7b ("ipv6: prevent in6_dev_get()
> from resurrecting inet6_dev"). Please base your v2 on the following
> submission and the feedback I provided:
>
> https://lore.kernel.org/netdev/20260815172032.79740-1-baul.lee@xbow.com/
>
> And please read:
>
> https://docs.kernel.org/next/process/maintainer-netdev.html
>
> Notably:
>
> 1. "designate your patch to a tree - [PATCH net] or [PATCH net-next]"
> 2. "don’t repost your patches within one 24h period"
>
> Also, trim the traces (preferably decoded) to what is actually useful:
>
> https://docs.kernel.org/next/process/submitting-patches.html#backtraces-in-commit-messages

Thanks for the review. I'll fix the reference acquisition in
in_dev_get(), returning NULL if refcount_inc_not_zero() fails, and
keep RTM_GETNETCONF unlocked.

I'll review the linked submission and your feedback before preparing
v2. I'll base it on net, use the appropriate subject prefix, trim the
traces to the relevant paths, and allow at least 24 hours between
patch postings.

Best regards,
Cen Zhang