Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix null-ptr-deref in f2fs_submit_page_bio()<br /> <br /> There&amp;#39;s issue as follows when concurrently installing the f2fs.ko<br /> module and mounting the f2fs file system:<br /> KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]<br /> RIP: 0010:__bio_alloc+0x2fb/0x6c0 [f2fs]<br /> Call Trace:<br /> <br /> f2fs_submit_page_bio+0x126/0x8b0 [f2fs]<br /> __get_meta_page+0x1d4/0x920 [f2fs]<br /> get_checkpoint_version.constprop.0+0x2b/0x3c0 [f2fs]<br /> validate_checkpoint+0xac/0x290 [f2fs]<br /> f2fs_get_valid_checkpoint+0x207/0x950 [f2fs]<br /> f2fs_fill_super+0x1007/0x39b0 [f2fs]<br /> mount_bdev+0x183/0x250<br /> legacy_get_tree+0xf4/0x1e0<br /> vfs_get_tree+0x88/0x340<br /> do_new_mount+0x283/0x5e0<br /> path_mount+0x2b2/0x15b0<br /> __x64_sys_mount+0x1fe/0x270<br /> do_syscall_64+0x5f/0x170<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Above issue happens as the biset of the f2fs file system is not<br /> initialized before register "f2fs_fs_type".<br /> To address above issue just register "f2fs_fs_type" at the last in<br /> init_f2fs_fs(). Ensure that all f2fs file system resources are<br /> initialized.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> zram: fix NULL pointer in comp_algorithm_show()<br /> <br /> LTP reported a NULL pointer dereference as followed:<br /> <br /> CPU: 7 UID: 0 PID: 5995 Comm: cat Kdump: loaded Not tainted 6.12.0-rc6+ #3<br /> Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015<br /> pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : __pi_strcmp+0x24/0x140<br /> lr : zcomp_available_show+0x60/0x100 [zram]<br /> sp : ffff800088b93b90<br /> x29: ffff800088b93b90 x28: 0000000000000001 x27: 0000000000400cc0<br /> x26: 0000000000000ffe x25: ffff80007b3e2388 x24: 0000000000000000<br /> x23: ffff80007b3e2390 x22: ffff0004041a9000 x21: ffff80007b3e2900<br /> x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000<br /> x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000<br /> x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> x11: 0000000000000000 x10: ffff80007b3e2900 x9 : ffff80007b3cb280<br /> x8 : 0101010101010101 x7 : 0000000000000000 x6 : 0000000000000000<br /> x5 : 0000000000000040 x4 : 0000000000000000 x3 : 00656c722d6f7a6c<br /> x2 : 0000000000000000 x1 : ffff80007b3e2900 x0 : 0000000000000000<br /> Call trace:<br /> __pi_strcmp+0x24/0x140<br /> comp_algorithm_show+0x40/0x70 [zram]<br /> dev_attr_show+0x28/0x80<br /> sysfs_kf_seq_show+0x90/0x140<br /> kernfs_seq_show+0x34/0x48<br /> seq_read_iter+0x1d4/0x4e8<br /> kernfs_fop_read_iter+0x40/0x58<br /> new_sync_read+0x9c/0x168<br /> vfs_read+0x1a8/0x1f8<br /> ksys_read+0x74/0x108<br /> __arm64_sys_read+0x24/0x38<br /> invoke_syscall+0x50/0x120<br /> el0_svc_common.constprop.0+0xc8/0xf0<br /> do_el0_svc+0x24/0x38<br /> el0_svc+0x38/0x138<br /> el0t_64_sync_handler+0xc0/0xc8<br /> el0t_64_sync+0x188/0x190<br /> <br /> The zram-&gt;comp_algs[ZRAM_PRIMARY_COMP] can be NULL in zram_add() if<br /> comp_algorithm_set() has not been called. User can access the zram device<br /> by sysfs after device_add_disk(), so there is a time window to trigger the<br /> NULL pointer dereference. Move it ahead device_add_disk() to make sure<br /> when user can access the zram device, it is ready. comp_algorithm_set()<br /> is protected by zram-&gt;init_lock in other places and no such problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: ralink: mtmips: fix clocks probe order in oldest ralink SoCs<br /> <br /> Base clocks are the first in being probed and are real dependencies of the<br /> rest of fixed, factor and peripheral clocks. For old ralink SoCs RT2880,<br /> RT305x and RT3883 &amp;#39;xtal&amp;#39; must be defined first since in any other case,<br /> when fixed clocks are probed they are delayed until &amp;#39;xtal&amp;#39; is probed so the<br /> following warning appears:<br /> <br /> WARNING: CPU: 0 PID: 0 at drivers/clk/ralink/clk-mtmips.c:499 rt3883_bus_recalc_rate+0x98/0x138<br /> Modules linked in:<br /> CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.43 #0<br /> Stack : 805e58d0 00000000 00000004 8004f950 00000000 00000004 00000000 00000000<br /> 80669c54 80830000 80700000 805ae570 80670068 00000001 80669bf8 00000000<br /> 00000000 00000000 805ae570 80669b38 00000020 804db7dc 00000000 00000000<br /> 203a6d6d 80669b78 80669e48 70617773 00000000 805ae570 00000000 00000009<br /> 00000000 00000001 00000004 00000001 00000000 00000000 83fe43b0 00000000<br /> ...<br /> Call Trace:<br /> [] show_stack+0x64/0xf4<br /> [] dump_stack_lvl+0x38/0x60<br /> [] __warn+0x94/0xe4<br /> [] warn_slowpath_fmt+0x60/0x94<br /> [] rt3883_bus_recalc_rate+0x98/0x138<br /> [] __clk_register+0x568/0x688<br /> [] of_clk_hw_register+0x18/0x2c<br /> [] rt2880_clk_of_clk_init_driver+0x18c/0x594<br /> [] of_clk_init+0x1c0/0x23c<br /> [] plat_time_init+0x58/0x18c<br /> [] time_init+0x10/0x6c<br /> [] start_kernel+0x458/0x67c<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> <br /> When this driver was mainlined we could not find any active users of old<br /> ralink SoCs so we cannot perform any real tests for them. Now, one user<br /> of a Belkin f9k1109 version 1 device which uses RT3883 SoC appeared and<br /> reported some issues in openWRT:<br /> - https://github.com/openwrt/openwrt/issues/16054<br /> <br /> Thus, define a &amp;#39;rt2880_xtal_recalc_rate()&amp;#39; just returning the expected<br /> frequency 40Mhz and use it along the old ralink SoCs to have a correct<br /> boot trace with no warnings and a working clock plan from the beggining.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Move events notifier registration to be after device registration<br /> <br /> Move pkey change work initialization and cleanup from device resources<br /> stage to notifier stage, since this is the stage which handles this work<br /> events.<br /> <br /> Fix a race between the device deregistration and pkey change work by moving<br /> MLX5_IB_STAGE_DEVICE_NOTIFIER to be after MLX5_IB_STAGE_IB_REG in order to<br /> ensure that the notifier is deregistered before the device during cleanup.<br /> Which ensures there are no works that are being executed after the<br /> device has already unregistered which can cause the panic below.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 1 PID: 630071 Comm: kworker/1:2 Kdump: loaded Tainted: G W OE --------- --- 5.14.0-162.6.1.el9_1.x86_64 #1<br /> Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008 02/27/2023<br /> Workqueue: events pkey_change_handler [mlx5_ib]<br /> RIP: 0010:setup_qp+0x38/0x1f0 [mlx5_ib]<br /> Code: ee 41 54 45 31 e4 55 89 f5 53 48 89 fb 48 83 ec 20 8b 77 08 65 48 8b 04 25 28 00 00 00 48 89 44 24 18 48 8b 07 48 8d 4c 24 16 8b 38 49 8b 87 80 0b 00 00 4c 89 ff 48 8b 80 08 05 00 00 8b 40<br /> RSP: 0018:ffffbcc54068be20 EFLAGS: 00010282<br /> RAX: 0000000000000000 RBX: ffff954054494128 RCX: ffffbcc54068be36<br /> RDX: ffff954004934000 RSI: 0000000000000001 RDI: ffff954054494128<br /> RBP: 0000000000000023 R08: ffff954001be2c20 R09: 0000000000000001<br /> R10: ffff954001be2c20 R11: ffff9540260133c0 R12: 0000000000000000<br /> R13: 0000000000000023 R14: 0000000000000000 R15: ffff9540ffcb0905<br /> FS: 0000000000000000(0000) GS:ffff9540ffc80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 000000010625c001 CR4: 00000000003706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> mlx5_ib_gsi_pkey_change+0x20/0x40 [mlx5_ib]<br /> process_one_work+0x1e8/0x3c0<br /> worker_thread+0x50/0x3b0<br /> ? rescuer_thread+0x380/0x380<br /> kthread+0x149/0x170<br /> ? set_kthread_struct+0x50/0x50<br /> ret_from_fork+0x22/0x30<br /> Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) mlx5_fwctl(OE) fwctl(OE) ib_uverbs(OE) mlx5_core(OE) mlxdevm(OE) ib_core(OE) mlx_compat(OE) psample mlxfw(OE) tls knem(OE) netconsole nfsv3 nfs_acl nfs lockd grace fscache netfs qrtr rfkill sunrpc intel_rapl_msr intel_rapl_common rapl hv_balloon hv_utils i2c_piix4 pcspkr joydev fuse ext4 mbcache jbd2 sr_mod sd_mod cdrom t10_pi sg ata_generic pci_hyperv pci_hyperv_intf hyperv_drm drm_shmem_helper drm_kms_helper hv_storvsc syscopyarea hv_netvsc sysfillrect sysimgblt hid_hyperv fb_sys_fops scsi_transport_fc hyperv_keyboard drm ata_piix crct10dif_pclmul crc32_pclmul crc32c_intel libata ghash_clmulni_intel hv_vmbus serio_raw [last unloaded: ib_core]<br /> CR2: 0000000000000000<br /> ---[ end trace f6f8be4eae12f7bc ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/tegra241-cmdqv: Fix alignment failure at max_n_shift<br /> <br /> When configuring a kernel with PAGE_SIZE=4KB, depending on its setting of<br /> CONFIG_CMA_ALIGNMENT, VCMDQ_LOG2SIZE_MAX=19 could fail the alignment test<br /> and trigger a WARN_ON:<br /> WARNING: at drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:3646<br /> Call trace:<br /> arm_smmu_init_one_queue+0x15c/0x210<br /> tegra241_cmdqv_init_structures+0x114/0x338<br /> arm_smmu_device_probe+0xb48/0x1d90<br /> <br /> Fix it by capping max_n_shift to CMDQ_MAX_SZ_SHIFT as SMMUv3 CMDQ does.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/hns: Fix NULL pointer derefernce in hns_roce_map_mr_sg()<br /> <br /> ib_map_mr_sg() allows ULPs to specify NULL as the sg_offset argument.<br /> The driver needs to check whether it is a NULL pointer before<br /> dereferencing it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: bfa: Fix use-after-free in bfad_im_module_exit()<br /> <br /> BUG: KASAN: slab-use-after-free in __lock_acquire+0x2aca/0x3a20<br /> Read of size 8 at addr ffff8881082d80c8 by task modprobe/25303<br /> <br /> Call Trace:<br /> <br /> dump_stack_lvl+0x95/0xe0<br /> print_report+0xcb/0x620<br /> kasan_report+0xbd/0xf0<br /> __lock_acquire+0x2aca/0x3a20<br /> lock_acquire+0x19b/0x520<br /> _raw_spin_lock+0x2b/0x40<br /> attribute_container_unregister+0x30/0x160<br /> fc_release_transport+0x19/0x90 [scsi_transport_fc]<br /> bfad_im_module_exit+0x23/0x60 [bfa]<br /> bfad_init+0xdb/0xff0 [bfa]<br /> do_one_initcall+0xdc/0x550<br /> do_init_module+0x22d/0x6b0<br /> load_module+0x4e96/0x5ff0<br /> init_module_from_file+0xcd/0x130<br /> idempotent_init_module+0x330/0x620<br /> __x64_sys_finit_module+0xb3/0x110<br /> do_syscall_64+0xc1/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> <br /> Allocated by task 25303:<br /> kasan_save_stack+0x24/0x50<br /> kasan_save_track+0x14/0x30<br /> __kasan_kmalloc+0x7f/0x90<br /> fc_attach_transport+0x4f/0x4740 [scsi_transport_fc]<br /> bfad_im_module_init+0x17/0x80 [bfa]<br /> bfad_init+0x23/0xff0 [bfa]<br /> do_one_initcall+0xdc/0x550<br /> do_init_module+0x22d/0x6b0<br /> load_module+0x4e96/0x5ff0<br /> init_module_from_file+0xcd/0x130<br /> idempotent_init_module+0x330/0x620<br /> __x64_sys_finit_module+0xb3/0x110<br /> do_syscall_64+0xc1/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Freed by task 25303:<br /> kasan_save_stack+0x24/0x50<br /> kasan_save_track+0x14/0x30<br /> kasan_save_free_info+0x3b/0x60<br /> __kasan_slab_free+0x38/0x50<br /> kfree+0x212/0x480<br /> bfad_im_module_init+0x7e/0x80 [bfa]<br /> bfad_init+0x23/0xff0 [bfa]<br /> do_one_initcall+0xdc/0x550<br /> do_init_module+0x22d/0x6b0<br /> load_module+0x4e96/0x5ff0<br /> init_module_from_file+0xcd/0x130<br /> idempotent_init_module+0x330/0x620<br /> __x64_sys_finit_module+0xb3/0x110<br /> do_syscall_64+0xc1/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Above issue happens as follows:<br /> <br /> bfad_init<br /> error = bfad_im_module_init()<br /> fc_release_transport(bfad_im_scsi_transport_template);<br /> if (error)<br /> goto ext;<br /> <br /> ext:<br /> bfad_im_module_exit();<br /> fc_release_transport(bfad_im_scsi_transport_template);<br /> --&gt; Trigger double release<br /> <br /> Don&amp;#39;t call bfad_im_module_exit() if bfad_im_module_init() failed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/l2tp: fix warning in l2tp_exit_net found by syzbot<br /> <br /> In l2tp&amp;#39;s net exit handler, we check that an IDR is empty before<br /> destroying it:<br /> <br /> WARN_ON_ONCE(!idr_is_empty(&amp;pn-&gt;l2tp_tunnel_idr));<br /> idr_destroy(&amp;pn-&gt;l2tp_tunnel_idr);<br /> <br /> By forcing memory allocation failures in idr_alloc_32, syzbot is able<br /> to provoke a condition where idr_is_empty returns false despite there<br /> being no items in the IDR. This turns out to be because the radix tree<br /> of the IDR contains only internal radix-tree nodes and it is this that<br /> causes idr_is_empty to return false. The internal nodes are cleaned by<br /> idr_destroy.<br /> <br /> Use idr_for_each to check that the IDR is empty instead of<br /> idr_is_empty to avoid the problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netlink: fix false positive warning in extack during dumps<br /> <br /> Commit under fixes extended extack reporting to dumps.<br /> It works under normal conditions, because extack errors are<br /> usually reported during -&gt;start() or the first -&gt;dump(),<br /> it&amp;#39;s quite rare that the dump starts okay but fails later.<br /> If the dump does fail later, however, the input skb will<br /> already have the initiating message pulled, so checking<br /> if bad attr falls within skb-&gt;data will fail.<br /> <br /> Switch the check to using nlh, which is always valid.<br /> <br /> syzbot found a way to hit that scenario by filling up<br /> the receive queue. In this case we initiate a dump<br /> but don&amp;#39;t call -&gt;dump() until there is read space for<br /> an skb.<br /> <br /> WARNING: CPU: 1 PID: 5845 at net/netlink/af_netlink.c:2210 netlink_ack_tlv_fill+0x1a8/0x560 net/netlink/af_netlink.c:2209<br /> RIP: 0010:netlink_ack_tlv_fill+0x1a8/0x560 net/netlink/af_netlink.c:2209<br /> Call Trace:<br /> <br /> netlink_dump_done+0x513/0x970 net/netlink/af_netlink.c:2250<br /> netlink_dump+0x91f/0xe10 net/netlink/af_netlink.c:2351<br /> netlink_recvmsg+0x6bb/0x11d0 net/netlink/af_netlink.c:1983<br /> sock_recvmsg_nosec net/socket.c:1051 [inline]<br /> sock_recvmsg+0x22f/0x280 net/socket.c:1073<br /> __sys_recvfrom+0x246/0x3d0 net/socket.c:2267<br /> __do_sys_recvfrom net/socket.c:2285 [inline]<br /> __se_sys_recvfrom net/socket.c:2281 [inline]<br /> __x64_sys_recvfrom+0xde/0x100 net/socket.c:2281<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7ff37dd17a79

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: lan78xx: Fix double free issue with interrupt buffer allocation<br /> <br /> In lan78xx_probe(), the buffer `buf` was being freed twice: once<br /> implicitly through `usb_free_urb(dev-&gt;urb_intr)` with the<br /> `URB_FREE_BUFFER` flag and again explicitly by `kfree(buf)`. This caused<br /> a double free issue.<br /> <br /> To resolve this, reordered `kmalloc()` and `usb_alloc_urb()` calls to<br /> simplify the initialization sequence and removed the redundant<br /> `kfree(buf)`. Now, `buf` is allocated after `usb_alloc_urb()`, ensuring<br /> it is correctly managed by `usb_fill_int_urb()` and freed by<br /> `usb_free_urb()` as intended.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio/pci: Properly hide first-in-list PCIe extended capability<br /> <br /> There are cases where a PCIe extended capability should be hidden from<br /> the user. For example, an unknown capability (i.e., capability with ID<br /> greater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionally<br /> chosen to be hidden from the user.<br /> <br /> Hiding a capability is done by virtualizing and modifying the &amp;#39;Next<br /> Capability Offset&amp;#39; field of the previous capability so it points to the<br /> capability after the one that should be hidden.<br /> <br /> The special case where the first capability in the list should be hidden<br /> is handled differently because there is no previous capability that can<br /> be modified. In this case, the capability ID and version are zeroed<br /> while leaving the next pointer intact. This hides the capability and<br /> leaves an anchor for the rest of the capability list.<br /> <br /> However, today, hiding the first capability in the list is not done<br /> properly if the capability is unknown, as struct<br /> vfio_pci_core_device-&gt;pci_config_map is set to the capability ID during<br /> initialization but the capability ID is not properly checked later when<br /> used in vfio_config_do_rw(). This leads to the following warning [1] and<br /> to an out-of-bounds access to ecap_perms array.<br /> <br /> Fix it by checking cap_id in vfio_config_do_rw(), and if it is greater<br /> than PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for direct<br /> read only access instead of the ecap_perms array.<br /> <br /> Note that this is safe since the above is the only case where cap_id can<br /> exceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, which<br /> are already checked before).<br /> <br /> [1]<br /> <br /> WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]<br /> CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1<br /> (snip)<br /> Call Trace:<br /> <br /> ? show_regs+0x69/0x80<br /> ? __warn+0x8d/0x140<br /> ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]<br /> ? report_bug+0x18f/0x1a0<br /> ? handle_bug+0x63/0xa0<br /> ? exc_invalid_op+0x19/0x70<br /> ? asm_exc_invalid_op+0x1b/0x20<br /> ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]<br /> ? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core]<br /> vfio_pci_rw+0x101/0x1b0 [vfio_pci_core]<br /> vfio_pci_core_read+0x1d/0x30 [vfio_pci_core]<br /> vfio_device_fops_read+0x27/0x40 [vfio]<br /> vfs_read+0xbd/0x340<br /> ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio]<br /> ? __rseq_handle_notify_resume+0xa4/0x4b0<br /> __x64_sys_pread64+0x96/0xc0<br /> x64_sys_call+0x1c3d/0x20d0<br /> do_syscall_64+0x4d/0x120<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> svcrdma: fix miss destroy percpu_counter in svc_rdma_proc_init()<br /> <br /> There&amp;#39;s issue as follows:<br /> RPC: Registered rdma transport module.<br /> RPC: Registered rdma backchannel transport module.<br /> RPC: Unregistered rdma transport module.<br /> RPC: Unregistered rdma backchannel transport module.<br /> BUG: unable to handle page fault for address: fffffbfff80c609a<br /> PGD 123fee067 P4D 123fee067 PUD 123fea067 PMD 10c624067 PTE 0<br /> Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> RIP: 0010:percpu_counter_destroy_many+0xf7/0x2a0<br /> Call Trace:<br /> <br /> __die+0x1f/0x70<br /> page_fault_oops+0x2cd/0x860<br /> spurious_kernel_fault+0x36/0x450<br /> do_kern_addr_fault+0xca/0x100<br /> exc_page_fault+0x128/0x150<br /> asm_exc_page_fault+0x26/0x30<br /> percpu_counter_destroy_many+0xf7/0x2a0<br /> mmdrop+0x209/0x350<br /> finish_task_switch.isra.0+0x481/0x840<br /> schedule_tail+0xe/0xd0<br /> ret_from_fork+0x23/0x80<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> If register_sysctl() return NULL, then svc_rdma_proc_cleanup() will not<br /> destroy the percpu counters which init in svc_rdma_proc_init().<br /> If CONFIG_HOTPLUG_CPU is enabled, residual nodes may be in the<br /> &amp;#39;percpu_counters&amp;#39; list. The above issue may occur once the module is<br /> removed. If the CONFIG_HOTPLUG_CPU configuration is not enabled, memory<br /> leakage occurs.<br /> To solve above issue just destroy all percpu counters when<br /> register_sysctl() return NULL.