Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipvlan: Fix use-after-free in ipvlan_get_iflink().<br /> <br /> syzbot presented an use-after-free report [0] regarding ipvlan and<br /> linkwatch.<br /> <br /> ipvlan does not hold a refcnt of the lower device unlike vlan and<br /> macvlan.<br /> <br /> If the linkwatch work is triggered for the ipvlan dev, the lower dev<br /> might have already been freed, resulting in UAF of ipvlan-&gt;phy_dev in<br /> ipvlan_get_iflink().<br /> <br /> We can delay the lower dev unregistration like vlan and macvlan by<br /> holding the lower dev&amp;#39;s refcnt in dev-&gt;netdev_ops-&gt;ndo_init() and<br /> releasing it in dev-&gt;priv_destructor().<br /> <br /> Jakub pointed out calling .ndo_XXX after unregister_netdevice() has<br /> returned is error prone and suggested [1] addressing this UAF in the<br /> core by taking commit 750e51603395 ("net: avoid potential UAF in<br /> default_operstate()") further.<br /> <br /> Let&amp;#39;s assume unregistering devices DOWN and use RCU protection in<br /> default_operstate() not to race with the device unregistration.<br /> <br /> [0]:<br /> BUG: KASAN: slab-use-after-free in ipvlan_get_iflink+0x84/0x88 drivers/net/ipvlan/ipvlan_main.c:353<br /> Read of size 4 at addr ffff0000d768c0e0 by task kworker/u8:35/6944<br /> <br /> CPU: 0 UID: 0 PID: 6944 Comm: kworker/u8:35 Not tainted 6.13.0-rc2-g9bc5c9515b48 #12 4c3cb9e8b4565456f6a355f312ff91f4f29b3c47<br /> Hardware name: linux,dummy-virt (DT)<br /> Workqueue: events_unbound linkwatch_event<br /> Call trace:<br /> show_stack+0x38/0x50 arch/arm64/kernel/stacktrace.c:484 (C)<br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0xbc/0x108 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0x16c/0x6f0 mm/kasan/report.c:489<br /> kasan_report+0xc0/0x120 mm/kasan/report.c:602<br /> __asan_report_load4_noabort+0x20/0x30 mm/kasan/report_generic.c:380<br /> ipvlan_get_iflink+0x84/0x88 drivers/net/ipvlan/ipvlan_main.c:353<br /> dev_get_iflink+0x7c/0xd8 net/core/dev.c:674<br /> default_operstate net/core/link_watch.c:45 [inline]<br /> rfc2863_policy+0x144/0x360 net/core/link_watch.c:72<br /> linkwatch_do_dev+0x60/0x228 net/core/link_watch.c:175<br /> __linkwatch_run_queue+0x2f4/0x5b8 net/core/link_watch.c:239<br /> linkwatch_event+0x64/0xa8 net/core/link_watch.c:282<br /> process_one_work+0x700/0x1398 kernel/workqueue.c:3229<br /> process_scheduled_works kernel/workqueue.c:3310 [inline]<br /> worker_thread+0x8c4/0xe10 kernel/workqueue.c:3391<br /> kthread+0x2b0/0x360 kernel/kthread.c:389<br /> ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:862<br /> <br /> Allocated by task 9303:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x30/0x68 mm/kasan/common.c:68<br /> kasan_save_alloc_info+0x44/0x58 mm/kasan/generic.c:568<br /> poison_kmalloc_redzone mm/kasan/common.c:377 [inline]<br /> __kasan_kmalloc+0x84/0xa0 mm/kasan/common.c:394<br /> kasan_kmalloc include/linux/kasan.h:260 [inline]<br /> __do_kmalloc_node mm/slub.c:4283 [inline]<br /> __kmalloc_node_noprof+0x2a0/0x560 mm/slub.c:4289<br /> __kvmalloc_node_noprof+0x9c/0x230 mm/util.c:650<br /> alloc_netdev_mqs+0xb4/0x1118 net/core/dev.c:11209<br /> rtnl_create_link+0x2b8/0xb60 net/core/rtnetlink.c:3595<br /> rtnl_newlink_create+0x19c/0x868 net/core/rtnetlink.c:3771<br /> __rtnl_newlink net/core/rtnetlink.c:3896 [inline]<br /> rtnl_newlink+0x122c/0x15c0 net/core/rtnetlink.c:4011<br /> rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6901<br /> netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2542<br /> rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6928<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline]<br /> netlink_unicast+0x618/0x838 net/netlink/af_netlink.c:1347<br /> netlink_sendmsg+0x5fc/0x8b0 net/netlink/af_netlink.c:1891<br /> sock_sendmsg_nosec net/socket.c:711 [inline]<br /> __sock_sendmsg net/socket.c:726 [inline]<br /> __sys_sendto+0x2ec/0x438 net/socket.c:2197<br /> __do_sys_sendto net/socket.c:2204 [inline]<br /> __se_sys_sendto net/socket.c:2200 [inline]<br /> __arm64_sys_sendto+0xe4/0x110 net/socket.c:2200<br /> __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]<br /> invoke_syscall+0x90/0x278 arch/arm64/kernel/syscall.c:49<br /> el0_svc_common+0x13c/0x250 arch/arm64/kernel/syscall.c:132<br /> do_el0_svc+0x54/0x70 arch/arm64/kernel/syscall.c:151<br /> el<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> afs: Fix the maximum cell name length<br /> <br /> The kafs filesystem limits the maximum length of a cell to 256 bytes, but a<br /> problem occurs if someone actually does that: kafs tries to create a<br /> directory under /proc/net/afs/ with the name of the cell, but that fails<br /> with a warning:<br /> <br /> WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:405<br /> <br /> because procfs limits the maximum filename length to 255.<br /> <br /> However, the DNS limits the maximum lookup length and, by extension, the<br /> maximum cell name, to 255 less two (length count and trailing NUL).<br /> <br /> Fix this by limiting the maximum acceptable cellname length to 253. This<br /> also allows us to be sure we can create the "/afs/./" mountpoint too.<br /> <br /> Further, split the YFS VL record cell name maximum to be the 256 allowed by<br /> the protocol and ignore the record retrieved by YFSVL.GetCellName if it<br /> exceeds 253.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched: sch_cake: add bounds checks to host bulk flow fairness counts<br /> <br /> Even though we fixed a logic error in the commit cited below, syzbot<br /> still managed to trigger an underflow of the per-host bulk flow<br /> counters, leading to an out of bounds memory access.<br /> <br /> To avoid any such logic errors causing out of bounds memory accesses,<br /> this commit factors out all accesses to the per-host bulk flow counters<br /> to a series of helpers that perform bounds-checking before any<br /> increments and decrements. This also has the benefit of improving<br /> readability by moving the conditional checks for the flow mode into<br /> these helpers, instead of having them spread out throughout the<br /> code (which was the cause of the original logic error).<br /> <br /> As part of this change, the flow quantum calculation is consolidated<br /> into a helper function, which means that the dithering applied to the<br /> ost load scaling is now applied both in the DRR rotation and when a<br /> sparse flow&amp;#39;s quantum is first initiated. The only user-visible effect<br /> of this is that the maximum packet size that can be sent while a flow<br /> stays sparse will now vary with +/- one byte in some cases. This should<br /> not make a noticeable difference in practice, and thus it&amp;#39;s not worth<br /> complicating the code to preserve the old behaviour.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: conntrack: clamp maximum hashtable size to INT_MAX<br /> <br /> Use INT_MAX as maximum size for the conntrack hashtable. Otherwise, it<br /> is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() when<br /> resizing hashtable because __GFP_NOWARN is unset. See:<br /> <br /> 0708a0afe291 ("mm: Consider __GFP_NOWARN flag for oversized kvmalloc() calls")<br /> <br /> Note: hashtable resize is only possible from init_netns.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net_sched: cls_flow: validate TCA_FLOW_RSHIFT attribute<br /> <br /> syzbot found that TCA_FLOW_RSHIFT attribute was not validated.<br /> Right shitfing a 32bit integer is undefined for large shift values.<br /> <br /> UBSAN: shift-out-of-bounds in net/sched/cls_flow.c:329:23<br /> shift exponent 9445 is too large for 32-bit type &amp;#39;u32&amp;#39; (aka &amp;#39;unsigned int&amp;#39;)<br /> CPU: 1 UID: 0 PID: 54 Comm: kworker/u8:3 Not tainted 6.13.0-rc3-syzkaller-00180-g4f619d518db9 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024<br /> Workqueue: ipv6_addrconf addrconf_dad_work<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120<br /> ubsan_epilogue lib/ubsan.c:231 [inline]<br /> __ubsan_handle_shift_out_of_bounds+0x3c8/0x420 lib/ubsan.c:468<br /> flow_classify+0x24d5/0x25b0 net/sched/cls_flow.c:329<br /> tc_classify include/net/tc_wrapper.h:197 [inline]<br /> __tcf_classify net/sched/cls_api.c:1771 [inline]<br /> tcf_classify+0x420/0x1160 net/sched/cls_api.c:1867<br /> sfb_classify net/sched/sch_sfb.c:260 [inline]<br /> sfb_enqueue+0x3ad/0x18b0 net/sched/sch_sfb.c:318<br /> dev_qdisc_enqueue+0x4b/0x290 net/core/dev.c:3793<br /> __dev_xmit_skb net/core/dev.c:3889 [inline]<br /> __dev_queue_xmit+0xf0e/0x3f50 net/core/dev.c:4400<br /> dev_queue_xmit include/linux/netdevice.h:3168 [inline]<br /> neigh_hh_output include/net/neighbour.h:523 [inline]<br /> neigh_output include/net/neighbour.h:537 [inline]<br /> ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236<br /> iptunnel_xmit+0x55d/0x9b0 net/ipv4/ip_tunnel_core.c:82<br /> udp_tunnel_xmit_skb+0x262/0x3b0 net/ipv4/udp_tunnel_core.c:173<br /> geneve_xmit_skb drivers/net/geneve.c:916 [inline]<br /> geneve_xmit+0x21dc/0x2d00 drivers/net/geneve.c:1039<br /> __netdev_start_xmit include/linux/netdevice.h:5002 [inline]<br /> netdev_start_xmit include/linux/netdevice.h:5011 [inline]<br /> xmit_one net/core/dev.c:3590 [inline]<br /> dev_hard_start_xmit+0x27a/0x7d0 net/core/dev.c:3606<br /> __dev_queue_xmit+0x1b73/0x3f50 net/core/dev.c:4434

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86/amd/pmc: Only disable IRQ1 wakeup where i8042 actually enabled it<br /> <br /> Wakeup for IRQ1 should be disabled only in cases where i8042 had<br /> actually enabled it, otherwise "wake_depth" for this IRQ will try to<br /> drop below zero and there will be an unpleasant WARN() logged:<br /> <br /> kernel: atkbd serio0: Disabling IRQ1 wakeup source to avoid platform firmware bug<br /> kernel: ------------[ cut here ]------------<br /> kernel: Unbalanced IRQ 1 wake disable<br /> kernel: WARNING: CPU: 10 PID: 6431 at kernel/irq/manage.c:920 irq_set_irq_wake+0x147/0x1a0<br /> <br /> The PMC driver uses DEFINE_SIMPLE_DEV_PM_OPS() to define its dev_pm_ops<br /> which sets amd_pmc_suspend_handler() to the .suspend, .freeze, and<br /> .poweroff handlers. i8042_pm_suspend(), however, is only set as<br /> the .suspend handler.<br /> <br /> Fix the issue by call PMC suspend handler only from the same set of<br /> dev_pm_ops handlers as i8042_pm_suspend(), which currently means just<br /> the .suspend handler.<br /> <br /> To reproduce this issue try hibernating (S4) the machine after a fresh boot<br /> without putting it into s2idle first.<br /> <br /> [ij: edited the commit message.]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rds: sysctl: rds_tcp_{rcv,snd}buf: avoid using current-&gt;nsproxy<br /> <br /> As mentioned in a previous commit of this series, using the &amp;#39;net&amp;#39;<br /> structure via &amp;#39;current&amp;#39; is not recommended for different reasons:<br /> <br /> - Inconsistency: getting info from the reader&amp;#39;s/writer&amp;#39;s netns vs only<br /> from the opener&amp;#39;s netns.<br /> <br /> - current-&gt;nsproxy can be NULL in some cases, resulting in an &amp;#39;Oops&amp;#39;<br /> (null-ptr-deref), e.g. when the current task is exiting, as spotted by<br /> syzbot [1] using acct(2).<br /> <br /> The per-netns structure can be obtained from the table-&gt;data using<br /> container_of(), then the &amp;#39;net&amp;#39; one can be retrieved from the listen<br /> socket (if available).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: sysctl: blackhole timeout: avoid using current-&gt;nsproxy<br /> <br /> As mentioned in the previous commit, using the &amp;#39;net&amp;#39; structure via<br /> &amp;#39;current&amp;#39; is not recommended for different reasons:<br /> <br /> - Inconsistency: getting info from the reader&amp;#39;s/writer&amp;#39;s netns vs only<br /> from the opener&amp;#39;s netns.<br /> <br /> - current-&gt;nsproxy can be NULL in some cases, resulting in an &amp;#39;Oops&amp;#39;<br /> (null-ptr-deref), e.g. when the current task is exiting, as spotted by<br /> syzbot [1] using acct(2).<br /> <br /> The &amp;#39;pernet&amp;#39; structure can be obtained from the table-&gt;data using<br /> container_of().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: sysctl: sched: avoid using current-&gt;nsproxy<br /> <br /> Using the &amp;#39;net&amp;#39; structure via &amp;#39;current&amp;#39; is not recommended for different<br /> reasons.<br /> <br /> First, if the goal is to use it to read or write per-netns data, this is<br /> inconsistent with how the "generic" sysctl entries are doing: directly<br /> by only using pointers set to the table entry, e.g. table-&gt;data. Linked<br /> to that, the per-netns data should always be obtained from the table<br /> linked to the netns it had been created for, which may not coincide with<br /> the reader&amp;#39;s or writer&amp;#39;s netns.<br /> <br /> Another reason is that access to current-&gt;nsproxy-&gt;netns can oops if<br /> attempted when current-&gt;nsproxy had been dropped when the current task<br /> is exiting. This is what syzbot found, when using acct(2):<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN PTI<br /> KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]<br /> CPU: 1 UID: 0 PID: 5924 Comm: syz-executor Not tainted 6.13.0-rc5-syzkaller-00004-gccb98ccef0e5 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024<br /> RIP: 0010:proc_scheduler+0xc6/0x3c0 net/mptcp/ctrl.c:125<br /> Code: 03 42 80 3c 38 00 0f 85 fe 02 00 00 4d 8b a4 24 08 09 00 00 48 b8 00 00 00 00 00 fc ff df 49 8d 7c 24 28 48 89 fa 48 c1 ea 03 3c 02 00 0f 85 cc 02 00 00 4d 8b 7c 24 28 48 8d 84 24 c8 00 00<br /> RSP: 0018:ffffc900034774e8 EFLAGS: 00010206<br /> <br /> RAX: dffffc0000000000 RBX: 1ffff9200068ee9e RCX: ffffc90003477620<br /> RDX: 0000000000000005 RSI: ffffffff8b08f91e RDI: 0000000000000028<br /> RBP: 0000000000000001 R08: ffffc90003477710 R09: 0000000000000040<br /> R10: 0000000000000040 R11: 00000000726f7475 R12: 0000000000000000<br /> R13: ffffc90003477620 R14: ffffc90003477710 R15: dffffc0000000000<br /> FS: 0000000000000000(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fee3cd452d8 CR3: 000000007d116000 CR4: 00000000003526f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> proc_sys_call_handler+0x403/0x5d0 fs/proc/proc_sysctl.c:601<br /> __kernel_write_iter+0x318/0xa80 fs/read_write.c:612<br /> __kernel_write+0xf6/0x140 fs/read_write.c:632<br /> do_acct_process+0xcb0/0x14a0 kernel/acct.c:539<br /> acct_pin_kill+0x2d/0x100 kernel/acct.c:192<br /> pin_kill+0x194/0x7c0 fs/fs_pin.c:44<br /> mnt_pin_kill+0x61/0x1e0 fs/fs_pin.c:81<br /> cleanup_mnt+0x3ac/0x450 fs/namespace.c:1366<br /> task_work_run+0x14e/0x250 kernel/task_work.c:239<br /> exit_task_work include/linux/task_work.h:43 [inline]<br /> do_exit+0xad8/0x2d70 kernel/exit.c:938<br /> do_group_exit+0xd3/0x2a0 kernel/exit.c:1087<br /> get_signal+0x2576/0x2610 kernel/signal.c:3017<br /> arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337<br /> exit_to_user_mode_loop kernel/entry/common.c:111 [inline]<br /> exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]<br /> __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]<br /> syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218<br /> do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7fee3cb87a6a<br /> Code: Unable to access opcode bytes at 0x7fee3cb87a40.<br /> RSP: 002b:00007fffcccac688 EFLAGS: 00000202 ORIG_RAX: 0000000000000037<br /> RAX: 0000000000000000 RBX: 00007fffcccac710 RCX: 00007fee3cb87a6a<br /> RDX: 0000000000000041 RSI: 0000000000000000 RDI: 0000000000000003<br /> RBP: 0000000000000003 R08: 00007fffcccac6ac R09: 00007fffcccacac7<br /> R10: 00007fffcccac710 R11: 0000000000000202 R12: 00007fee3cd49500<br /> R13: 00007fffcccac6ac R14: 0000000000000000 R15: 00007fee3cd4b000<br /> <br /> Modules linked in:<br /> ---[ end trace 0000000000000000 ]---<br /> RIP: 0010:proc_scheduler+0xc6/0x3c0 net/mptcp/ctrl.c:125<br /> Code: 03 42 80 3c 38 00 0f 85 fe 02 00 00 4d 8b a4 24 08 09 00 00 48 b8 00 00 00 00 00 fc<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix kernel async DIO<br /> <br /> Netfslib needs to be able to handle kernel-initiated asynchronous DIO that<br /> is supplied with a bio_vec[] array. Currently, because of the async flag,<br /> this gets passed to netfs_extract_user_iter() which throws a warning and<br /> fails because it only handles IOVEC and UBUF iterators. This can be<br /> triggered through a combination of cifs and a loopback blockdev with<br /> something like:<br /> <br /> mount //my/cifs/share /foo<br /> dd if=/dev/zero of=/foo/m0 bs=4K count=1K<br /> losetup --sector-size 4096 --direct-io=on /dev/loop2046 /foo/m0<br /> echo hello &gt;/dev/loop2046<br /> <br /> This causes the following to appear in syslog:<br /> <br /> WARNING: CPU: 2 PID: 109 at fs/netfs/iterator.c:50 netfs_extract_user_iter+0x170/0x250 [netfs]<br /> <br /> and the write to fail.<br /> <br /> Fix this by removing the check in netfs_unbuffered_write_iter_locked() that<br /> causes async kernel DIO writes to be handled as userspace writes. Note<br /> that this change relies on the kernel caller maintaining the existence of<br /> the bio_vec array (or kvec[] or folio_queue) until the op is complete.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Fix tlb invalidation when wedging<br /> <br /> If GuC fails to load, the driver wedges, but in the process it tries to<br /> do stuff that may not be initialized yet. This moves the<br /> xe_gt_tlb_invalidation_init() to be done earlier: as its own doc says,<br /> it&amp;#39;s a software-only initialization and should had been named with the<br /> _early() suffix.<br /> <br /> Move it to be called by xe_gt_init_early(), so the locks and seqno are<br /> initialized, avoiding a NULL ptr deref when wedging:<br /> <br /> xe 0000:03:00.0: [drm] *ERROR* GT0: load failed: status: Reset = 0, BootROM = 0x50, UKernel = 0x00, MIA = 0x00, Auth = 0x01<br /> xe 0000:03:00.0: [drm] *ERROR* GT0: firmware signature verification failed<br /> xe 0000:03:00.0: [drm] *ERROR* CRITICAL: Xe has declared device 0000:03:00.0 as wedged.<br /> ...<br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 9 UID: 0 PID: 3908 Comm: modprobe Tainted: G U W 6.13.0-rc4-xe+ #3<br /> Tainted: [U]=USER, [W]=WARN<br /> Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-S ADP-S DDR5 UDIMM CRB, BIOS ADLSFWI1.R00.3275.A00.2207010640 07/01/2022<br /> RIP: 0010:xe_gt_tlb_invalidation_reset+0x75/0x110 [xe]<br /> <br /> This can be easily triggered by poking the GuC binary to force a<br /> signature failure. There will still be an extra message,<br /> <br /> xe 0000:03:00.0: [drm] *ERROR* GT0: GuC mmio request 0x4100: no reply 0x4100<br /> <br /> but that&amp;#39;s better than a NULL ptr deref.<br /> <br /> (cherry picked from commit 5001ef3af8f2c972d6fd9c5221a8457556f8bea6)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: sysctl: plpmtud_probe_interval: avoid using current-&gt;nsproxy<br /> <br /> As mentioned in a previous commit of this series, using the &amp;#39;net&amp;#39;<br /> structure via &amp;#39;current&amp;#39; is not recommended for different reasons:<br /> <br /> - Inconsistency: getting info from the reader&amp;#39;s/writer&amp;#39;s netns vs only<br /> from the opener&amp;#39;s netns.<br /> <br /> - current-&gt;nsproxy can be NULL in some cases, resulting in an &amp;#39;Oops&amp;#39;<br /> (null-ptr-deref), e.g. when the current task is exiting, as spotted by<br /> syzbot [1] using acct(2).<br /> <br /> The &amp;#39;net&amp;#39; structure can be obtained from the table-&gt;data using<br /> container_of().<br /> <br /> Note that table-&gt;data could also be used directly, as this is the only<br /> member needed from the &amp;#39;net&amp;#39; structure, but that would increase the size<br /> of this fix, to use &amp;#39;*data&amp;#39; everywhere &amp;#39;net-&gt;sctp.probe_interval&amp;#39; is<br /> used.