Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: filter out EXT4_FC_REPLAY from on-disk superblock field s_state<br /> <br /> The EXT4_FC_REPLAY bit in sbi-&gt;s_mount_state is used to indicate that<br /> we are in the middle of replay the fast commit journal. This was<br /> actually a mistake, since the sbi-&gt;s_mount_info is initialized from<br /> es-&gt;s_state. Arguably s_mount_state is misleadingly named, but the<br /> name is historical --- s_mount_state and s_state dates back to ext2.<br /> <br /> What should have been used is the ext4_{set,clear,test}_mount_flag()<br /> inline functions, which sets EXT4_MF_* bits in sbi-&gt;s_mount_flags.<br /> <br /> The problem with using EXT4_FC_REPLAY is that a maliciously corrupted<br /> superblock could result in EXT4_FC_REPLAY getting set in<br /> s_mount_state. This bypasses some sanity checks, and this can trigger<br /> a BUG() in ext4_es_cache_extent(). As a easy-to-backport-fix, filter<br /> out the EXT4_FC_REPLAY bit for now. We should eventually transition<br /> away from EXT4_FC_REPLAY to something like EXT4_MF_REPLAY.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mdio: unexport __init-annotated mdio_bus_init()<br /> <br /> EXPORT_SYMBOL and __init is a bad combination because the .init.text<br /> section is freed up after the initialization. Hence, modules cannot<br /> use symbols annotated __init. The access to a freed symbol may end up<br /> with kernel panic.<br /> <br /> modpost used to detect it, but it has been broken for a decade.<br /> <br /> Recently, I fixed modpost so it started to warn it again, then this<br /> showed up in linux-next builds.<br /> <br /> There are two ways to fix it:<br /> <br /> - Remove __init<br /> - Remove EXPORT_SYMBOL<br /> <br /> I chose the latter for this case because the only in-tree call-site,<br /> drivers/net/phy/phy_device.c is never compiled as modular.<br /> (CONFIG_PHYLIB is boolean)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: altera: Fix refcount leak in altera_tse_mdio_create<br /> <br /> Every iteration of for_each_child_of_node() decrements<br /> the reference count of the previous node.<br /> When break from a for_each_child_of_node() loop,<br /> we need to explicitly call of_node_put() on the child node when<br /> not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix warning in ext4_handle_inode_extension<br /> <br /> We got issue as follows:<br /> EXT4-fs error (device loop0) in ext4_reserve_inode_write:5741: Out of memory<br /> EXT4-fs error (device loop0): ext4_setattr:5462: inode #13: comm syz-executor.0: mark_inode_dirty error<br /> EXT4-fs error (device loop0) in ext4_setattr:5519: Out of memory<br /> EXT4-fs error (device loop0): ext4_ind_map_blocks:595: inode #13: comm syz-executor.0: Can&amp;#39;t allocate blocks for non-extent mapped inodes with bigalloc<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 1 PID: 4361 at fs/ext4/file.c:301 ext4_file_write_iter+0x11c9/0x1220<br /> Modules linked in:<br /> CPU: 1 PID: 4361 Comm: syz-executor.0 Not tainted 5.10.0+ #1<br /> RIP: 0010:ext4_file_write_iter+0x11c9/0x1220<br /> RSP: 0018:ffff924d80b27c00 EFLAGS: 00010282<br /> RAX: ffffffff815a3379 RBX: 0000000000000000 RCX: 000000003b000000<br /> RDX: ffff924d81601000 RSI: 00000000000009cc RDI: 00000000000009cd<br /> RBP: 000000000000000d R08: ffffffffbc5a2c6b R09: 0000902e0e52a96f<br /> R10: ffff902e2b7c1b40 R11: ffff902e2b7c1b40 R12: 000000000000000a<br /> R13: 0000000000000001 R14: ffff902e0e52aa10 R15: ffffffffffffff8b<br /> FS: 00007f81a7f65700(0000) GS:ffff902e3bc80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffffffff600400 CR3: 000000012db88001 CR4: 00000000003706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> do_iter_readv_writev+0x2e5/0x360<br /> do_iter_write+0x112/0x4c0<br /> do_pwritev+0x1e5/0x390<br /> __x64_sys_pwritev2+0x7e/0xa0<br /> do_syscall_64+0x37/0x50<br /> entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> <br /> Above issue may happen as follows:<br /> Assume<br /> inode.i_size=4096<br /> EXT4_I(inode)-&gt;i_disksize=4096<br /> <br /> step 1: set inode-&gt;i_isize = 8192<br /> ext4_setattr<br /> if (attr-&gt;ia_size != inode-&gt;i_size)<br /> EXT4_I(inode)-&gt;i_disksize = attr-&gt;ia_size;<br /> rc = ext4_mark_inode_dirty<br /> ext4_reserve_inode_write<br /> ext4_get_inode_loc<br /> __ext4_get_inode_loc<br /> sb_getblk --&gt; return -ENOMEM<br /> ...<br /> if (!error) -&gt;will not update i_size<br /> i_size_write(inode, attr-&gt;ia_size);<br /> Now:<br /> inode.i_size=4096<br /> EXT4_I(inode)-&gt;i_disksize=8192<br /> <br /> step 2: Direct write 4096 bytes<br /> ext4_file_write_iter<br /> ext4_dio_write_iter<br /> iomap_dio_rw -&gt;return error<br /> if (extend)<br /> ext4_handle_inode_extension<br /> WARN_ON_ONCE(i_size_read(inode) i_disksize);<br /> -&gt;Then trigger warning.<br /> <br /> To solve above issue, if mark inode dirty failed in ext4_setattr just<br /> set &amp;#39;EXT4_I(inode)-&gt;i_disksize&amp;#39; with old value.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/huge_memory: Fix xarray node memory leak<br /> <br /> If xas_split_alloc() fails to allocate the necessary nodes to complete the<br /> xarray entry split, it sets the xa_state to -ENOMEM, which xas_nomem()<br /> then interprets as "Please allocate more memory", not as "Please free<br /> any unnecessary memory" (which was the intended outcome). It&amp;#39;s confusing<br /> to use xas_nomem() to free memory in this context, so call xas_destroy()<br /> instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/cs: make commands with 0 chunks illegal behaviour.<br /> <br /> Submitting a cs with 0 chunks, causes an oops later, found trying<br /> to execute the wrong userspace driver.<br /> <br /> MESA_LOADER_DRIVER_OVERRIDE=v3d glxinfo<br /> <br /> [172536.665184] BUG: kernel NULL pointer dereference, address: 00000000000001d8<br /> [172536.665188] #PF: supervisor read access in kernel mode<br /> [172536.665189] #PF: error_code(0x0000) - not-present page<br /> [172536.665191] PGD 6712a0067 P4D 6712a0067 PUD 5af9ff067 PMD 0<br /> [172536.665195] Oops: 0000 [#1] SMP NOPTI<br /> [172536.665197] CPU: 7 PID: 2769838 Comm: glxinfo Tainted: P O 5.10.81 #1-NixOS<br /> [172536.665199] Hardware name: To be filled by O.E.M. To be filled by O.E.M./CROSSHAIR V FORMULA-Z, BIOS 2201 03/23/2015<br /> [172536.665272] RIP: 0010:amdgpu_cs_ioctl+0x96/0x1ce0 [amdgpu]<br /> [172536.665274] Code: 75 18 00 00 4c 8b b2 88 00 00 00 8b 46 08 48 89 54 24 68 49 89 f7 4c 89 5c 24 60 31 d2 4c 89 74 24 30 85 c0 0f 85 c0 01 00 00 83 ba d8 01 00 00 00 48 8b b4 24 90 00 00 00 74 16 48 8b 46 10<br /> [172536.665276] RSP: 0018:ffffb47c0e81bbe0 EFLAGS: 00010246<br /> [172536.665277] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000<br /> [172536.665278] RDX: 0000000000000000 RSI: ffffb47c0e81be28 RDI: ffffb47c0e81bd68<br /> [172536.665279] RBP: ffff936524080010 R08: 0000000000000000 R09: ffffb47c0e81be38<br /> [172536.665281] R10: ffff936524080010 R11: ffff936524080000 R12: ffffb47c0e81bc40<br /> [172536.665282] R13: ffffb47c0e81be28 R14: ffff9367bc410000 R15: ffffb47c0e81be28<br /> [172536.665283] FS: 00007fe35e05d740(0000) GS:ffff936c1edc0000(0000) knlGS:0000000000000000<br /> [172536.665284] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [172536.665286] CR2: 00000000000001d8 CR3: 0000000532e46000 CR4: 00000000000406e0<br /> [172536.665287] Call Trace:<br /> [172536.665322] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu]<br /> [172536.665332] drm_ioctl_kernel+0xaa/0xf0 [drm]<br /> [172536.665338] drm_ioctl+0x201/0x3b0 [drm]<br /> [172536.665369] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu]<br /> [172536.665372] ? selinux_file_ioctl+0x135/0x230<br /> [172536.665399] amdgpu_drm_ioctl+0x49/0x80 [amdgpu]<br /> [172536.665403] __x64_sys_ioctl+0x83/0xb0<br /> [172536.665406] do_syscall_64+0x33/0x40<br /> [172536.665409] entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> <br /> Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2018

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: bgmac: Fix refcount leak in bcma_mdio_mii_register<br /> <br /> of_get_child_by_name() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: E-Switch, pair only capable devices<br /> <br /> OFFLOADS paring using devcom is possible only on devices<br /> that support LAG. Filter based on lag capabilities.<br /> <br /> This fixes an issue where mlx5_get_next_phys_dev() was<br /> called without holding the interface lock.<br /> <br /> This issue was found when commit<br /> bc4c2f2e0179 ("net/mlx5: Lag, filter non compatible devices")<br /> added an assert that verifies the interface lock is held.<br /> <br /> WARNING: CPU: 9 PID: 1706 at drivers/net/ethernet/mellanox/mlx5/core/dev.c:642 mlx5_get_next_phys_dev+0xd2/0x100 [mlx5_core]<br /> Modules linked in: mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_umad ib_ipoib ib_cm ib_uverbs ib_core overlay fuse [last unloaded: mlx5_core]<br /> CPU: 9 PID: 1706 Comm: devlink Not tainted 5.18.0-rc7+ #11<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:mlx5_get_next_phys_dev+0xd2/0x100 [mlx5_core]<br /> Code: 02 00 75 48 48 8b 85 80 04 00 00 5d c3 31 c0 5d c3 be ff ff ff ff 48 c7 c7 08 41 5b a0 e8 36 87 28 e3 85 c0 0f 85 6f ff ff ff 0b e9 68 ff ff ff 48 c7 c7 0c 91 cc 84 e8 cb 36 6f e1 e9 4d ff<br /> RSP: 0018:ffff88811bf47458 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff88811b398000 RCX: 0000000000000001<br /> RDX: 0000000080000000 RSI: ffffffffa05b4108 RDI: ffff88812daaaa78<br /> RBP: ffff88812d050380 R08: 0000000000000001 R09: ffff88811d6b3437<br /> R10: 0000000000000001 R11: 00000000fddd3581 R12: ffff88815238c000<br /> R13: ffff88812d050380 R14: ffff8881018aa7e0 R15: ffff88811d6b3428<br /> FS: 00007fc82e18ae80(0000) GS:ffff88842e080000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f9630d1b421 CR3: 0000000149802004 CR4: 0000000000370ea0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> mlx5_esw_offloads_devcom_event+0x99/0x3b0 [mlx5_core]<br /> mlx5_devcom_send_event+0x167/0x1d0 [mlx5_core]<br /> esw_offloads_enable+0x1153/0x1500 [mlx5_core]<br /> ? mlx5_esw_offloads_controller_valid+0x170/0x170 [mlx5_core]<br /> ? wait_for_completion_io_timeout+0x20/0x20<br /> ? mlx5_rescan_drivers_locked+0x318/0x810 [mlx5_core]<br /> mlx5_eswitch_enable_locked+0x586/0xc50 [mlx5_core]<br /> ? mlx5_eswitch_disable_pf_vf_vports+0x1d0/0x1d0 [mlx5_core]<br /> ? mlx5_esw_try_lock+0x1b/0xb0 [mlx5_core]<br /> ? mlx5_eswitch_enable+0x270/0x270 [mlx5_core]<br /> ? __debugfs_create_file+0x260/0x3e0<br /> mlx5_devlink_eswitch_mode_set+0x27e/0x870 [mlx5_core]<br /> ? mutex_lock_io_nested+0x12c0/0x12c0<br /> ? esw_offloads_disable+0x250/0x250 [mlx5_core]<br /> ? devlink_nl_cmd_trap_get_dumpit+0x470/0x470<br /> ? rcu_read_lock_sched_held+0x3f/0x70<br /> devlink_nl_cmd_eswitch_set_doit+0x217/0x620

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/etnaviv: check for reaped mapping in etnaviv_iommu_unmap_gem<br /> <br /> When the mapping is already reaped the unmap must be a no-op, as we<br /> would otherwise try to remove the mapping twice, corrupting the involved<br /> data structures.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: dlmfs: fix error handling of user_dlm_destroy_lock<br /> <br /> When user_dlm_destroy_lock failed, it didn&amp;#39;t clean up the flags it set<br /> before exit. For USER_LOCK_IN_TEARDOWN, if this function fails because of<br /> lock is still in used, next time when unlink invokes this function, it<br /> will return succeed, and then unlink will remove inode and dentry if lock<br /> is not in used(file closed), but the dlm lock is still linked in dlm lock<br /> resource, then when bast come in, it will trigger a panic due to<br /> user-after-free. See the following panic call trace. To fix this,<br /> USER_LOCK_IN_TEARDOWN should be reverted if fail. And also error should<br /> be returned if USER_LOCK_IN_TEARDOWN is set to let user know that unlink<br /> fail.<br /> <br /> For the case of ocfs2_dlm_unlock failure, besides USER_LOCK_IN_TEARDOWN,<br /> USER_LOCK_BUSY is also required to be cleared. Even though spin lock is<br /> released in between, but USER_LOCK_IN_TEARDOWN is still set, for<br /> USER_LOCK_BUSY, if before every place that waits on this flag,<br /> USER_LOCK_IN_TEARDOWN is checked to bail out, that will make sure no flow<br /> waits on the busy flag set by user_dlm_destroy_lock(), then we can<br /> simplely revert USER_LOCK_BUSY when ocfs2_dlm_unlock fails. Fix<br /> user_dlm_cluster_lock() which is the only function not following this.<br /> <br /> [ 941.336392] (python,26174,16):dlmfs_unlink:562 ERROR: unlink<br /> 004fb0000060000b5a90b8c847b72e1, error -16 from destroy<br /> [ 989.757536] ------------[ cut here ]------------<br /> [ 989.757709] kernel BUG at fs/ocfs2/dlmfs/userdlm.c:173!<br /> [ 989.757876] invalid opcode: 0000 [#1] SMP<br /> [ 989.758027] Modules linked in: ksplice_2zhuk2jr_ib_ipoib_new(O)<br /> ksplice_2zhuk2jr(O) mptctl mptbase xen_netback xen_blkback xen_gntalloc<br /> xen_gntdev xen_evtchn cdc_ether usbnet mii ocfs2 jbd2 rpcsec_gss_krb5<br /> auth_rpcgss nfsv4 nfsv3 nfs_acl nfs fscache lockd grace ocfs2_dlmfs<br /> ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs bnx2fc<br /> fcoe libfcoe libfc scsi_transport_fc sunrpc ipmi_devintf bridge stp llc<br /> rds_rdma rds bonding ib_sdp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad<br /> rdma_cm ib_cm iw_cm falcon_lsm_serviceable(PE) falcon_nf_netcontain(PE)<br /> mlx4_vnic falcon_kal(E) falcon_lsm_pinned_13402(E) mlx4_ib ib_sa ib_mad<br /> ib_core ib_addr xenfs xen_privcmd dm_multipath iTCO_wdt iTCO_vendor_support<br /> pcspkr sb_edac edac_core i2c_i801 lpc_ich mfd_core ipmi_ssif i2c_core ipmi_si<br /> ipmi_msghandler<br /> [ 989.760686] ioatdma sg ext3 jbd mbcache sd_mod ahci libahci ixgbe dca ptp<br /> pps_core vxlan udp_tunnel ip6_udp_tunnel megaraid_sas mlx4_core crc32c_intel<br /> be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi ipv6 cxgb3 mdio<br /> libiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi wmi<br /> dm_mirror dm_region_hash dm_log dm_mod [last unloaded:<br /> ksplice_2zhuk2jr_ib_ipoib_old]<br /> [ 989.761987] CPU: 10 PID: 19102 Comm: dlm_thread Tainted: P OE<br /> 4.1.12-124.57.1.el6uek.x86_64 #2<br /> [ 989.762290] Hardware name: Oracle Corporation ORACLE SERVER<br /> X5-2/ASM,MOTHERBOARD,1U, BIOS 30350100 06/17/2021<br /> [ 989.762599] task: ffff880178af6200 ti: ffff88017f7c8000 task.ti:<br /> ffff88017f7c8000<br /> [ 989.762848] RIP: e030:[] []<br /> __user_dlm_queue_lockres.part.4+0x76/0x80 [ocfs2_dlmfs]<br /> [ 989.763185] RSP: e02b:ffff88017f7cbcb8 EFLAGS: 00010246<br /> [ 989.763353] RAX: 0000000000000000 RBX: ffff880174d48008 RCX:<br /> 0000000000000003<br /> [ 989.763565] RDX: 0000000000120012 RSI: 0000000000000003 RDI:<br /> ffff880174d48170<br /> [ 989.763778] RBP: ffff88017f7cbcc8 R08: ffff88021f4293b0 R09:<br /> 0000000000000000<br /> [ 989.763991] R10: ffff880179c8c000 R11: 0000000000000003 R12:<br /> ffff880174d48008<br /> [ 989.764204] R13: 0000000000000003 R14: ffff880179c8c000 R15:<br /> ffff88021db7a000<br /> [ 989.764422] FS: 0000000000000000(0000) GS:ffff880247480000(0000)<br /> knlGS:ffff880247480000<br /> [ 989.764685] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 989.764865] CR2: ffff8000007f6800 CR3: 0000000001ae0000 CR4:<br /> 0000000000042660<br /> [ 989.765081] Stack:<br /> [ 989.765167] 00000000000<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: CT: Fix cleanup of CT before cleanup of TC ct rules<br /> <br /> CT cleanup assumes that all tc rules were deleted first, and so<br /> is free to delete the CT shared resources (e.g the dr_action<br /> fwd_action which is shared for all tuples). But currently for<br /> uplink, this is happens in reverse, causing the below trace.<br /> <br /> CT cleanup is called from:<br /> mlx5e_cleanup_rep_tx()-&gt;mlx5e_cleanup_uplink_rep_tx()-&gt;<br /> mlx5e_rep_tc_cleanup()-&gt;mlx5e_tc_esw_cleanup()-&gt;<br /> mlx5_tc_ct_clean()<br /> <br /> Only afterwards, tc cleanup is called from:<br /> mlx5e_cleanup_rep_tx()-&gt;mlx5e_tc_ht_cleanup()<br /> which would have deleted all the tc ct rules, and so delete<br /> all the offloaded tuples.<br /> <br /> Fix this reversing the order of init and on cleanup, which<br /> will result in tc cleanup then ct cleanup.<br /> <br /> [ 9443.593347] WARNING: CPU: 2 PID: 206774 at drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c:1882 mlx5dr_action_destroy+0x188/0x1a0 [mlx5_core]<br /> [ 9443.593349] Modules linked in: act_ct nf_flow_table rdma_ucm(O) rdma_cm(O) iw_cm(O) ib_ipoib(O) ib_cm(O) ib_umad(O) mlx5_core(O-) mlxfw(O) mlxdevm(O) auxiliary(O) ib_uverbs(O) psample ib_core(O) mlx_compat(O) ip_gre gre ip_tunnel act_vlan bonding geneve esp6_offload esp6 esp4_offload esp4 act_tunnel_key vxlan ip6_udp_tunnel udp_tunnel act_mirred act_skbedit act_gact cls_flower sch_ingress nfnetlink_cttimeout nfnetlink xfrm_user xfrm_algo 8021q garp stp ipmi_devintf mrp ipmi_msghandler llc openvswitch nsh nf_conncount nf_nat mst_pciconf(O) dm_multipath sbsa_gwdt uio_pdrv_genirq uio mlxbf_pmc mlxbf_pka mlx_trio mlx_bootctl(O) bluefield_edac sch_fq_codel ip_tables ipv6 crc_ccitt btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor xor_neon raid6_pq raid1 raid0 crct10dif_ce i2c_mlxbf gpio_mlxbf2 mlxbf_gige aes_neon_bs aes_neon_blk [last unloaded: mlx5_ib]<br /> [ 9443.593419] CPU: 2 PID: 206774 Comm: modprobe Tainted: G O 5.4.0-1023.24.gc14613d-bluefield #1<br /> [ 9443.593422] Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS BlueField:143ebaf Jan 11 2022<br /> [ 9443.593424] pstate: 20000005 (nzCv daif -PAN -UAO)<br /> [ 9443.593489] pc : mlx5dr_action_destroy+0x188/0x1a0 [mlx5_core]<br /> [ 9443.593545] lr : mlx5_ct_fs_smfs_destroy+0x24/0x30 [mlx5_core]<br /> [ 9443.593546] sp : ffff8000135dbab0<br /> [ 9443.593548] x29: ffff8000135dbab0 x28: ffff0003a6ab8e80<br /> [ 9443.593550] x27: 0000000000000000 x26: ffff0003e07d7000<br /> [ 9443.593552] x25: ffff800009609de0 x24: ffff000397fb2120<br /> [ 9443.593554] x23: ffff0003975c0000 x22: 0000000000000000<br /> [ 9443.593556] x21: ffff0003975f08c0 x20: ffff800009609de0<br /> [ 9443.593558] x19: ffff0003c8a13380 x18: 0000000000000014<br /> [ 9443.593560] x17: 0000000067f5f125 x16: 000000006529c620<br /> [ 9443.593561] x15: 000000000000000b x14: 0000000000000000<br /> [ 9443.593563] x13: 0000000000000002 x12: 0000000000000001<br /> [ 9443.593565] x11: ffff800011108868 x10: 0000000000000000<br /> [ 9443.593567] x9 : 0000000000000000 x8 : ffff8000117fb270<br /> [ 9443.593569] x7 : ffff0003ebc01288 x6 : 0000000000000000<br /> [ 9443.593571] x5 : ffff800009591ab8 x4 : fffffe000f6d9a20<br /> [ 9443.593572] x3 : 0000000080040001 x2 : fffffe000f6d9a20<br /> [ 9443.593574] x1 : ffff8000095901d8 x0 : 0000000000000025<br /> [ 9443.593577] Call trace:<br /> [ 9443.593634] mlx5dr_action_destroy+0x188/0x1a0 [mlx5_core]<br /> [ 9443.593688] mlx5_ct_fs_smfs_destroy+0x24/0x30 [mlx5_core]<br /> [ 9443.593743] mlx5_tc_ct_clean+0x34/0xa8 [mlx5_core]<br /> [ 9443.593797] mlx5e_tc_esw_cleanup+0x58/0x88 [mlx5_core]<br /> [ 9443.593851] mlx5e_rep_tc_cleanup+0x24/0x30 [mlx5_core]<br /> [ 9443.593905] mlx5e_cleanup_rep_tx+0x6c/0x78 [mlx5_core]<br /> [ 9443.593959] mlx5e_detach_netdev+0x74/0x98 [mlx5_core]<br /> [ 9443.594013] mlx5e_netdev_change_profile+0x70/0x180 [mlx5_core]<br /> [ 9443.594067] mlx5e_netdev_attach_nic_profile+0x34/0x40 [mlx5_core]<br /> [ 9443.594122] mlx5e_vport_rep_unload+0x15c/0x1a8 [mlx5_core]<br /> [ 9443.594177] mlx5_eswitch_unregister_vport_reps+0x228/0x298 [mlx5_core]<br /> [ 9443.594231] mlx5e_rep_remove+0x2c/0x38<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ipv6: unexport __init-annotated seg6_hmac_init()<br /> <br /> EXPORT_SYMBOL and __init is a bad combination because the .init.text<br /> section is freed up after the initialization. Hence, modules cannot<br /> use symbols annotated __init. The access to a freed symbol may end up<br /> with kernel panic.<br /> <br /> modpost used to detect it, but it has been broken for a decade.<br /> <br /> Recently, I fixed modpost so it started to warn it again, then this<br /> showed up in linux-next builds.<br /> <br /> There are two ways to fix it:<br /> <br /> - Remove __init<br /> - Remove EXPORT_SYMBOL<br /> <br /> I chose the latter for this case because the caller (net/ipv6/seg6.c)<br /> and the callee (net/ipv6/seg6_hmac.c) belong to the same module.<br /> It seems an internal function call in ipv6.ko.