In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix warning in 'ext4_da_release_space'\n\nSyzkaller report issue as follows:\nEXT4-fs (loop0): Free/Dirty block details\nEXT4-fs (loop0): free_blocks=0\nEXT4-fs (loop0): dirty_blocks=0\nEXT4-fs (loop0): Block reservation details\nEXT4-fs (loop0): i_reserved_data_blocks=0\nEXT4-fs warning (device loop0): ext4_da_release_space:1527: ext4_da_release_space: ino 18, to_free 1 with only 0 reserved data blocks\n------------[ cut here ]------------\nWARNING: CPU: 0 PID: 92 at fs/ext4/inode.c:1528 ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1524\nModules linked in:\nCPU: 0 PID: 92 Comm: kworker/u4:4 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022\nWorkqueue: writeback wb_workfn (flush-7:0)\nRIP: 0010:ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1528\nRSP: 0018:ffffc900015f6c90 EFLAGS: 00010296\nRAX: 42215896cd52ea00 RBX: 0000000000000000 RCX: 42215896cd52ea00\nRDX: 0000000000000000 RSI: 0000000080000001 RDI: 0000000000000000\nRBP: 1ffff1100e907d96 R08: ffffffff816aa79d R09: fffff520002bece5\nR10: fffff520002bece5 R11: 1ffff920002bece4 R12: ffff888021fd2000\nR13: ffff88807483ecb0 R14: 0000000000000001 R15: ffff88807483e740\nFS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00005555569ba628 CR3: 000000000c88e000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \n ext4_es_remove_extent+0x1ab/0x260 fs/ext4/extents_status.c:1461\n mpage_release_unused_pages+0x24d/0xef0 fs/ext4/inode.c:1589\n ext4_writepages+0x12eb/0x3be0 fs/ext4/inode.c:2852\n do_writepages+0x3c3/0x680 mm/page-writeback.c:2469\n \__writeback_single_inode+0xd1/0x670 fs/fs-writeback.c:1587\n writeback_sb_inodes+0xb3b/0x18f0 fs/fs-writeback.c:1870\n wb_writeback+0x41f/0x7b0 fs/fs-writeback.c:2044\n wb_do_writeback fs/fs-writeback.c:2187 [inline]\n wb_workfn+0x3cb/0xef0 fs/fs-writeback.c:2227\n process_one_work+0x877/0xdb0 kernel/workqueue.c:2289\n worker_thread+0xb14/0x1330 kernel/workqueue.c:2436\n kthread+0x266/0x300 kernel/kthread.c:376\n ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306\n \n\nAbove issue may happens as follows:\next4_da_write_begin\n ext4_create_inline_data\n ext4_clear_inode_flag(inode, EXT4_INODE_EXTENTS);\n ext4_set_inode_flag(inode, EXT4_INODE_INLINE_DATA);\n__ext4_ioctl\n ext4_ext_migrate -> will lead to eh->eh_entries not zero, and set extent flag\next4_da_write_begin\n ext4_da_convert_inline_data_to_extent\n ext4_da_write_inline_data_begin\n ext4_da_map_blocks\n ext4_insert_delayed_block\n if (!ext4_es_scan_clu(inode, &ext4_es_is_delonly, lblk))\n if (!ext4_es_scan_clu(inode, &ext4_es_is_mapped, lblk))\n ext4_clu_mapped(inode, EXT4_B2C(sbi, lblk)); -> will return 1\n allocated = true;\n ext4_es_insert_delayed_block(inode, lblk, allocated);\next4_writepages\n mpage_map_and_submit_extent(handle, &mpd, &give_up_on_write); -> return -ENOSPC\n mpage_release_unused_pages(&mpd, give_up_on_write); -> give_up_on_write == 1\n ext4_es_remove_extent\n ext4_da_release_space(inode, reserved);\n if (unlikely(to_free > ei->i_reserved_data_blocks))\n -> to_free == 1 but ei->i_reserved_data_blocks == 0\n -> then trigger warning as above\n\nTo solve above issue, forbid inode do migrate which has inline data.

In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix BUG_ON() when directory entry has invalid rec_len\n\nThe rec_len field in the directory entry has to be a multiple of 4. A\ncorrupted filesystem image can be used to hit a BUG() in\next4_rec_len_to_disk(), called from make_indexed_dir().\n\n ------------[ cut here ]------------\n kernel BUG at fs/ext4/ext4.h:2413!\n ...\n RIP: 0010:make_indexed_dir+0x53f/0x5f0\n ...\n Call Trace:\n \n ? add_dirent_to_buf+0x1b2/0x200\n ext4_add_entry+0x36e/0x480\n ext4_add_nondir+0x2b/0xc0\n ext4_create+0x163/0x200\n path_openat+0x635/0xe90\n do_filp_open+0xb4/0x160\n ? \__create_object.isra.0+0x1de/0x3b0\n ? _raw_spin_unlock+0x12/0x30\n do_sys_openat2+0x91/0x150\n \__x64_sys_open+0x6c/0xa0\n do_syscall_64+0x3c/0x80\n entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nThe fix simply adds a call to ext4_check_dir_entry() to validate the\ndirectory entry, returning -EFSCORRUPTED if the entry is invalid.

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, verifier: Fix memory leak in array reallocation for stack state\n\nIf an error (NULL) is returned by krealloc(), callers of realloc_array()\nwere setting their allocation pointers to NULL, but on error krealloc()\ndoes not touch the original allocation. This would result in a memory\nresource leak. Instead, free the old allocation on the error handling\npath.\n\nThe memory leak information is as follows as also reported by Zhengchao:\n\n unreferenced object 0xffff888019801800 (size 256):\n comm "bpf_repo", pid 6490, jiffies 4294959200 (age 17.170s)\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace:\n [<00000000b211474b>] \__kmalloc_node_track_caller+0x45/0xc0\n [<0000000086712a0b>] krealloc+0x83/0xd0\n [<00000000139aab02>] realloc_array+0x82/0xe2\n [<00000000b1ca41d1>] grow_stack_state+0xfb/0x186\n [<00000000cd6f36d2>] check_mem_access.cold+0x141/0x1341\n [<0000000081780455>] do_check_common+0x5358/0xb350\n [<0000000015f6b091>] bpf_check.cold+0xc3/0x29d\n [<000000002973c690>] bpf_prog_load+0x13db/0x2240\n [<00000000028d1644>] \__sys_bpf+0x1605/0x4ce0\n [<00000000053f29bd>] \__x64_sys_bpf+0x75/0xb0\n [<0000000056fedaf5>] do_syscall_64+0x35/0x80\n [<000000002bd58261>] entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Fix the sk->sk_forward_alloc warning of sk_stream_kill_queues\n\nWhen running `test_sockmap` selftests, the following warning appears:\n\n WARNING: CPU: 2 PID: 197 at net/core/stream.c:205 sk_stream_kill_queues+0xd3/0xf0\n Call Trace:\n \n inet_csk_destroy_sock+0x55/0x110\n tcp_rcv_state_process+0xd28/0x1380\n ? tcp_v4_do_rcv+0x77/0x2c0\n tcp_v4_do_rcv+0x77/0x2c0\n \__release_sock+0x106/0x130\n \__tcp_close+0x1a7/0x4e0\n tcp_close+0x20/0x70\n inet_release+0x3c/0x80\n \__sock_release+0x3a/0xb0\n sock_close+0x14/0x20\n \__fput+0xa3/0x260\n task_work_run+0x59/0xb0\n exit_to_user_mode_prepare+0x1b3/0x1c0\n syscall_exit_to_user_mode+0x19/0x50\n do_syscall_64+0x48/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nThe root case is in commit 84472b436e76 ("bpf, sockmap: Fix more uncharged\nwhile msg has more_data"), where I used msg->sg.size to replace the tosend,\ncausing breakage:\n\n if (msg->apply_bytes && msg->apply_bytes < tosend)\n tosend = psock->apply_bytes;

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: fix general-protection-fault in ieee80211_subif_start_xmit()\n\nWhen device is running and the interface status is changed, the gpf issue\nis triggered. The problem triggering process is as follows:\nThread A: Thread B\nieee80211_runtime_change_iftype() process_one_work()\n ... ...\n ieee80211_do_stop() ...\n ... ...\n sdata->bss = NULL ...\n ... ieee80211_subif_start_xmit()\n ieee80211_multicast_to_unicast\n //!sdata->bss->multicast_to_unicast\n cause gpf issue\n\nWhen the interface status is changed, the sending queue continues to send\npackets. After the bss is set to NULL, the bss is accessed. As a result,\nthis causes a general-protection-fault issue.\n\nThe following is the stack information:\ngeneral protection fault, probably for non-canonical address\n0xdffffc000000002f: 0000 [#1] PREEMPT SMP KASAN\nKASAN: null-ptr-deref in range [0x0000000000000178-0x000000000000017f]\nWorkqueue: mld mld_ifc_work\nRIP: 0010:ieee80211_subif_start_xmit+0x25b/0x1310\nCall Trace:\n\ndev_hard_start_xmit+0x1be/0x990\n__dev_queue_xmit+0x2c9a/0x3b60\nip6_finish_output2+0xf92/0x1520\nip6_finish_output+0x6af/0x11e0\nip6_output+0x1ed/0x540\nmld_sendpack+0xa09/0xe70\nmld_ifc_work+0x71c/0xdb0\nprocess_one_work+0x9bf/0x1710\nworker_thread+0x665/0x1080\nkthread+0x2e4/0x3a0\nret_from_fork+0x1f/0x30\n

In the Linux kernel, the following vulnerability has been resolved:\n\nbpftool: Fix NULL pointer dereference when pin {PROG, MAP, LINK} without FILE\n\nWhen using bpftool to pin {PROG, MAP, LINK} without FILE,\nsegmentation fault will occur. The reson is that the lack\nof FILE will cause strlen to trigger NULL pointer dereference.\nThe corresponding stacktrace is shown below:\n\ndo_pin\n do_pin_any\n do_pin_fd\n mount_bpffs_for_pin\n strlen(name) <- NULL pointer dereference\n\nFix it by adding validation to the common process.

In the Linux kernel, the following vulnerability has been resolved:\n\nHID: hyperv: fix possible memory leak in mousevsc_probe()\n\nIf hid_add_device() returns error, it should call hid_destroy_device()\nto free hid_dev which is allocated in hid_allocate_device().

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix wrong reg type conversion in release_reference()\n\nSome helper functions will allocate memory. To avoid memory leaks, the\nverifier requires the eBPF program to release these memories by calling\nthe corresponding helper functions.\n\nWhen a resource is released, all pointer registers corresponding to the\nresource should be invalidated. The verifier use release_references() to\ndo this job, by apply \__mark_reg_unknown() to each relevant register.\n\nIt will give these registers the type of SCALAR_VALUE. A register that\nwill contain a pointer value at runtime, but of type SCALAR_VALUE, which\nmay allow the unprivileged user to get a kernel pointer by storing this\nregister into a map.\n\nUsing \__mark_reg_not_init() while NOT allow_ptr_leaks can mitigate this\nproblem.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: gso: fix panic on frag_list with mixed head alloc types\n\nSince commit 3dcbdb134f32 ("net: gso: Fix skb_segment splat when\nsplitting gso_size mangled skb having linear-headed frag_list"), it is\nallowed to change gso_size of a GRO packet. However, that commit assumes\nthat "checking the first list_skb member suffices; i.e if either of the\nlist_skb members have non head_frag head, then the first one has too".\n\nIt turns out this assumption does not hold. We've seen BUG_ON being hit\nin skb_segment when skbs on the frag_list had differing head_frag with\nthe vmxnet3 driver. This happens because \__netdev_alloc_skb and\n__napi_alloc_skb can return a skb that is page backed or kmalloced\ndepending on the requested size. As the result, the last small skb in\nthe GRO packet can be kmalloced.\n\nThere are three different locations where this can be fixed:\n\n(1) We could check head_frag in GRO and not allow GROing skbs with\n different head_frag. However, that would lead to performance\n regression on normal forward paths with unmodified gso_size, where\n !head_frag in the last packet is not a problem.\n\n(2) Set a flag in bpf_skb_net_grow and bpf_skb_net_shrink indicating\n that NETIF_F_SG is undesirable. That would need to eat a bit in\n sk_buff. Furthermore, that flag can be unset when all skbs on the\n frag_list are page backed. To retain good performance,\n bpf_skb_net_grow/shrink would have to walk the frag_list.\n\n(3) Walk the frag_list in skb_segment when determining whether\n NETIF_F_SG should be cleared. This of course slows things down.\n\nThis patch implements (3). To limit the performance impact in\nskb_segment, the list is walked only for skbs with SKB_GSO_DODGY set\nthat have gso_size changed. Normal paths thus will not hit it.\n\nWe could check only the last skb but since we need to walk the whole\nlist anyway, let's stay on the safe side.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: tun: Fix memory leaks of napi_get_frags\n\nkmemleak reports after running test_progs:\n\nunreferenced object 0xffff8881b1672dc0 (size 232):\n comm "test_progs", pid 394388, jiffies 4354712116 (age 841.975s)\n hex dump (first 32 bytes):\n e0 84 d7 a8 81 88 ff ff 80 2c 67 b1 81 88 ff ff .........,g.....\n 00 40 c5 9b 81 88 ff ff 00 00 00 00 00 00 00 00 .@..............\n backtrace:\n [<00000000c8f01748>] napi_skb_cache_get+0xd4/0x150\n [<0000000041c7fc09>] \__napi_build_skb+0x15/0x50\n [<00000000431c7079>] \__napi_alloc_skb+0x26e/0x540\n [<000000003ecfa30e>] napi_get_frags+0x59/0x140\n [<0000000099b2199e>] tun_get_user+0x183d/0x3bb0 [tun]\n [<000000008a5adef0>] tun_chr_write_iter+0xc0/0x1b1 [tun]\n [<0000000049993ff4>] do_iter_readv_writev+0x19f/0x320\n [<000000008f338ea2>] do_iter_write+0x135/0x630\n [<000000008a3377a4>] vfs_writev+0x12e/0x440\n [<00000000a6b5639a>] do_writev+0x104/0x280\n [<00000000ccf065d8>] do_syscall_64+0x3b/0x90\n [<00000000d776e329>] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThe issue occurs in the following scenarios:\ntun_get_user()\n napi_gro_frags()\n napi_frags_finish()\n case GRO_NORMAL:\n gro_normal_one()\n list_add_tail(&skb->list, &napi->rx_list);\n <-- While napi->rx_count < READ_ONCE(gro_normal_batch),\n <-- gro_normal_list() is not called, napi->rx_list is not empty\n <-- not ask to complete the gro work, will cause memory leaks in\n <-- following tun_napi_del()\n...\ntun_napi_del()\n netif_napi_del()\n \__netif_napi_del()\n <-- &napi->rx_list is not empty, which caused memory leaks\n\nTo fix, add napi_complete() after napi_gro_frags().

In the Linux kernel, the following vulnerability has been resolved:\n\ncapabilities: fix undefined behavior in bit shift for CAP_TO_MASK\n\nShifting signed 32-bit value by 31 bits is undefined, so changing\nsignificant bit to unsigned. The UBSAN warning calltrace like below:\n\nUBSAN: shift-out-of-bounds in security/commoncap.c:1252:2\nleft shift of 1 by 31 places cannot be represented in type 'int'\nCall Trace:\n \n dump_stack_lvl+0x7d/0xa5\n dump_stack+0x15/0x1b\n ubsan_epilogue+0xe/0x4e\n \__ubsan_handle_shift_out_of_bounds+0x1e7/0x20c\n cap_task_prctl+0x561/0x6f0\n security_task_prctl+0x5a/0xb0\n \__x64_sys_prctl+0x61/0x8f0\n do_syscall_64+0x58/0x80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n

In the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_en: Fix possible crash in bnxt_hwrm_set_coal()\n\nDuring the error recovery sequence, the rtnl_lock is not held for the\nentire duration and some datastructures may be freed during the sequence.\nCheck for the BNXT_STATE_OPEN flag instead of netif_running() to ensure\nthat the device is fully operational before proceeding to reconfigure\nthe coalescing settings.\n\nThis will fix a possible crash like this:\n\nBUG: unable to handle kernel NULL pointer dereference at 0000000000000000\nPGD 0 P4D 0\nOops: 0000 [#1] SMP NOPTI\nCPU: 10 PID: 181276 Comm: ethtool Kdump: loaded Tainted: G IOE --------- - - 4.18.0-348.el8.x86_64 #1\nHardware name: Dell Inc. PowerEdge R740/0F9N89, BIOS 2.3.10 08/15/2019\nRIP: 0010:bnxt_hwrm_set_coal+0x1fb/0x2a0 [bnxt_en]\nCode: c2 66 83 4e 22 08 66 89 46 1c e8 10 cb 00 00 41 83 c6 01 44 39 b3 68 01 00 00 0f 8e a3 00 00 00 48 8b 93 c8 00 00 00 49 63 c6 <48> 8b 2c c2 48 8b 85 b8 02 00 00 48 85 c0 74 2e 48 8b 74 24 08 f6\nRSP: 0018:ffffb11c8dcaba50 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff8d168a8b0ac0 RCX: 00000000000000c5\nRDX: 0000000000000000 RSI: ffff8d162f72c000 RDI: ffff8d168a8b0b28\nRBP: 0000000000000000 R08: b6e1f68a12e9a7eb R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000037 R12: ffff8d168a8b109c\nR13: ffff8d168a8b10aa R14: 0000000000000000 R15: ffffffffc01ac4e0\nFS: 00007f3852e4c740(0000) GS:ffff8d24c0080000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000000 CR3: 000000041b3ee003 CR4: 00000000007706e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n ethnl_set_coalesce+0x3ce/0x4c0\n genl_family_rcv_msg_doit.isra.15+0x10f/0x150\n genl_family_rcv_msg+0xb3/0x160\n ? coalesce_fill_reply+0x480/0x480\n genl_rcv_msg+0x47/0x90\n ? genl_family_rcv_msg+0x160/0x160\n netlink_rcv_skb+0x4c/0x120\n genl_rcv+0x24/0x40\n netlink_unicast+0x196/0x230\n netlink_sendmsg+0x204/0x3d0\n sock_sendmsg+0x4c/0x50\n \__sys_sendto+0xee/0x160\n ? syscall_trace_enter+0x1d3/0x2c0\n ? \__audit_syscall_exit+0x249/0x2a0\n \__x64_sys_sendto+0x24/0x30\n do_syscall_64+0x5b/0x1a0\n entry_SYSCALL_64_after_hwframe+0x65/0xca\nRIP: 0033:0x7f38524163bb

In the Linux kernel, the following vulnerability has been resolved:\n\nphy: ralink: mt7621-pci: add sentinel to quirks table\n\nWith mt7621 soc_dev_attr fixed to register the soc as a device,\nkernel will experience an oops in soc_device_match_attr\n\nThis quirk test was introduced in the staging driver in\ncommit 9445ccb3714c ("staging: mt7621-pci-phy: add quirks for 'E2'\nrevision using 'soc_device_attribute'"). The staging driver was removed,\nand later re-added in commit d87da32372a0 ("phy: ralink: Add PHY driver\nfor MT7621 PCIe PHY") for kernel 5.11

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: wwan: iosm: fix memory leak in ipc_wwan_dellink\n\nIOSM driver registers network device without setting the\nneeds_free_netdev flag, and does NOT call free_netdev() when\nunregisters network device, which causes a memory leak.\n\nThis patch sets needs_free_netdev to true when registers\nnetwork device, which makes netdev subsystem call free_netdev()\nautomatically after unregister_netdevice().

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: wwan: mhi: fix memory leak in mhi_mbim_dellink\n\nMHI driver registers network device without setting the\nneeds_free_netdev flag, and does NOT call free_netdev() when\nunregisters network device, which causes a memory leak.\n\nThis patch sets needs_free_netdev to true when registers\nnetwork device, which makes netdev subsystem call free_netdev()\nautomatically after unregister_netdevice().

In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: addrlabel: fix infoleak when sending struct ifaddrlblmsg to network\n\nWhen copying a `struct ifaddrlblmsg` to the network, \__ifal_reserved\nremained uninitialized, resulting in a 1-byte infoleak:\n\n BUG: KMSAN: kernel-network-infoleak in \__netdev_start_xmit ./include/linux/netdevice.h:4841\n \__netdev_start_xmit ./include/linux/netdevice.h:4841\n netdev_start_xmit ./include/linux/netdevice.h:4857\n xmit_one net/core/dev.c:3590\n dev_hard_start_xmit+0x1dc/0x800 net/core/dev.c:3606\n \__dev_queue_xmit+0x17e8/0x4350 net/core/dev.c:4256\n dev_queue_xmit ./include/linux/netdevice.h:3009\n \__netlink_deliver_tap_skb net/netlink/af_netlink.c:307\n \__netlink_deliver_tap+0x728/0xad0 net/netlink/af_netlink.c:325\n netlink_deliver_tap net/netlink/af_netlink.c:338\n \__netlink_sendskb net/netlink/af_netlink.c:1263\n netlink_sendskb+0x1d9/0x200 net/netlink/af_netlink.c:1272\n netlink_unicast+0x56d/0xf50 net/netlink/af_netlink.c:1360\n nlmsg_unicast ./include/net/netlink.h:1061\n rtnl_unicast+0x5a/0x80 net/core/rtnetlink.c:758\n ip6addrlbl_get+0xfad/0x10f0 net/ipv6/addrlabel.c:628\n rtnetlink_rcv_msg+0xb33/0x1570 net/core/rtnetlink.c:6082\n ...\n Uninit was created at:\n slab_post_alloc_hook+0x118/0xb00 mm/slab.h:742\n slab_alloc_node mm/slub.c:3398\n \__kmem_cache_alloc_node+0x4f2/0x930 mm/slub.c:3437\n \__do_kmalloc_node mm/slab_common.c:954\n \__kmalloc_node_track_caller+0x117/0x3d0 mm/slab_common.c:975\n kmalloc_reserve net/core/skbuff.c:437\n \__alloc_skb+0x27a/0xab0 net/core/skbuff.c:509\n alloc_skb ./include/linux/skbuff.h:1267\n nlmsg_new ./include/net/netlink.h:964\n ip6addrlbl_get+0x490/0x10f0 net/ipv6/addrlabel.c:608\n rtnetlink_rcv_msg+0xb33/0x1570 net/core/rtnetlink.c:6082\n netlink_rcv_skb+0x299/0x550 net/netlink/af_netlink.c:2540\n rtnetlink_rcv+0x26/0x30 net/core/rtnetlink.c:6109\n netlink_unicast_kernel net/netlink/af_netlink.c:1319\n netlink_unicast+0x9ab/0xf50 net/netlink/af_netlink.c:1345\n netlink_sendmsg+0xebc/0x10f0 net/netlink/af_netlink.c:1921\n ...\n\nThis patch ensures that the reserved field is always initialized.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Fix NULL pointer dereference in svm_migrate_to_ram()\n\n./drivers/gpu/drm/amd/amdkfd/kfd_migrate.c:985:58-62: ERROR: p is NULL but dereferenced.

In the Linux kernel, the following vulnerability has been resolved:\n\ncan: af_can: fix NULL pointer dereference in can_rx_register()\n\nIt causes NULL pointer dereference when testing as following:\n(a) use syscall(__NR_socket, 0x10ul, 3ul, 0) to create netlink socket.\n(b) use syscall(__NR_sendmsg, ...) to create bond link device and vxcan\n link device, and bind vxcan device to bond device (can also use\n ifenslave command to bind vxcan device to bond device).\n(c) use syscall(__NR_socket, 0x1dul, 3ul, 1) to create CAN socket.\n(d) use syscall(__NR_bind, ...) to bind the bond device to CAN socket.\n\nThe bond device invokes the can-raw protocol registration interface to\nreceive CAN packets. However, ml_priv is not allocated to the dev,\ndev_rcv_lists is assigned to NULL in can_rx_register(). In this case,\nit will occur the NULL pointer dereference issue.\n\nThe following is the stack information:\nBUG: kernel NULL pointer dereference, address: 0000000000000008\nPGD 122a4067 P4D 122a4067 PUD 1223c067 PMD 0\nOops: 0000 [#1] PREEMPT SMP\nRIP: 0010:can_rx_register+0x12d/0x1e0\nCall Trace:\n\nraw_enable_filters+0x8d/0x120\nraw_enable_allfilters+0x3b/0x130\nraw_bind+0x118/0x4f0\n__sys_bind+0x163/0x1a0\n__x64_sys_bind+0x1e/0x30\ndo_syscall_64+0x35/0x80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\n

In the Linux kernel, the following vulnerability has been resolved:\n\ntipc: fix the msg->req tlv len check in tipc_nl_compat_name_table_dump_header\n\nThis is a follow-up for commit 974cb0e3e7c9 ("tipc: fix uninit-value\nin tipc_nl_compat_name_table_dump") where it should have type casted\nsizeof(..) to int to work when TLV_GET_DATA_LEN() returns a negative\nvalue.\n\nsyzbot reported a call trace because of it:\n\n BUG: KMSAN: uninit-value in ...\n tipc_nl_compat_name_table_dump+0x841/0xea0 net/tipc/netlink_compat.c:934\n \__tipc_nl_compat_dumpit+0xab2/0x1320 net/tipc/netlink_compat.c:238\n tipc_nl_compat_dumpit+0x991/0xb50 net/tipc/netlink_compat.c:321\n tipc_nl_compat_recv+0xb6e/0x1640 net/tipc/netlink_compat.c:1324\n genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline]\n genl_family_rcv_msg net/netlink/genetlink.c:775 [inline]\n genl_rcv_msg+0x103f/0x1260 net/netlink/genetlink.c:792\n netlink_rcv_skb+0x3a5/0x6c0 net/netlink/af_netlink.c:2501\n genl_rcv+0x3c/0x50 net/netlink/genetlink.c:803\n netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]\n netlink_unicast+0xf3b/0x1270 net/netlink/af_netlink.c:1345\n netlink_sendmsg+0x1288/0x1440 net/netlink/af_netlink.c:1921\n sock_sendmsg_nosec net/socket.c:714 [inline]\n sock_sendmsg net/socket.c:734 [inline]

In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: mv_xor_v2: Fix a resource leak in mv_xor_v2_remove()\n\nA clk_prepare_enable() call in the probe is not balanced by a corresponding\nclk_disable_unprepare() in the remove function.\n\nAdd the missing call.

In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: ti: k3-udma-glue: fix memory leak when register device fail\n\nIf device_register() fails, it should call put_device() to give\nup reference, the name allocated in dev_set_name() can be freed\nin callback function kobject_cleanup().

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: lapbether: fix issue of invalid opcode in lapbeth_open()\n\nIf lapb_register() failed when lapb device goes to up for the first time,\nthe NAPI is not disabled. As a result, the invalid opcode issue is\nreported when the lapb device goes to up for the second time.\n\nThe stack info is as follows:\n[ 1958.311422][T11356] kernel BUG at net/core/dev.c:6442!\n[ 1958.312206][T11356] invalid opcode: 0000 [#1] PREEMPT SMP KASAN\n[ 1958.315979][T11356] RIP: 0010:napi_enable+0x16a/0x1f0\n[ 1958.332310][T11356] Call Trace:\n[ 1958.332817][T11356] \n[ 1958.336135][T11356] lapbeth_open+0x18/0x90\n[ 1958.337446][T11356] \__dev_open+0x258/0x490\n[ 1958.341672][T11356] \__dev_change_flags+0x4d4/0x6a0\n[ 1958.345325][T11356] dev_change_flags+0x93/0x160\n[ 1958.346027][T11356] devinet_ioctl+0x1276/0x1bf0\n[ 1958.346738][T11356] inet_ioctl+0x1c8/0x2d0\n[ 1958.349638][T11356] sock_ioctl+0x5d1/0x750\n[ 1958.356059][T11356] \__x64_sys_ioctl+0x3ec/0x1790\n[ 1958.365594][T11356] do_syscall_64+0x35/0x80\n[ 1958.366239][T11356] entry_SYSCALL_64_after_hwframe+0x46/0xb0\n[ 1958.377381][T11356]

In the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: Fix SQE threshold checking\n\nCurrent way of checking available SQE count which is based on\nHW updated SQB count could result in driver submitting an SQE\neven before CQE for the previously transmitted SQE at the same\nindex is processed in NAPI resulting losing SKB pointers,\nhence a leak. Fix this by checking a consumer index which\nis updated once CQE is processed.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: marvell: prestera: fix memory leak in prestera_rxtx_switch_init()\n\nWhen prestera_sdma_switch_init() failed, the memory pointed to by\nsw->rxtx isn't released. Fix it. Only be compiled, not be tested.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: wwan: iosm: fix memory leak in ipc_pcie_read_bios_cfg\n\nipc_pcie_read_bios_cfg() is using the acpi_evaluate_dsm() to\nobtain the wwan power state configuration from BIOS but is\nnot freeing the acpi_object. The acpi_evaluate_dsm() returned\nacpi_object to be freed.\n\nFree the acpi_object after use.

In the Linux kernel, the following vulnerability has been resolved:\n\nmctp: Fix an error handling path in mctp_init()\n\nIf mctp_neigh_init() return error, the routes resources should\nbe released in the error handling path. Otherwise some resources\nleak.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: macvlan: fix memory leaks of macvlan_common_newlink\n\nkmemleak reports memory leaks in macvlan_common_newlink, as follows:\n\n ip link add link eth0 name .. type macvlan mode source macaddr add\n \n\nkmemleak reports:\n\nunreferenced object 0xffff8880109bb140 (size 64):\n comm "ip", pid 284, jiffies 4294986150 (age 430.108s)\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 b8 aa 5a 12 80 88 ff ff ..........Z.....\n 80 1b fa 0d 80 88 ff ff 1e ff ac af c7 c1 6b 6b ..............kk\n backtrace:\n [] kmem_cache_alloc_trace+0x1c7/0x300\n [] macvlan_hash_add_source+0x45/0xc0\n [] macvlan_changelink_sources+0xd7/0x170\n [] macvlan_common_newlink+0x38c/0x5a0\n [] macvlan_newlink+0xe/0x20\n [] \__rtnl_newlink+0x7af/0xa50\n [] rtnl_newlink+0x48/0x70\n ...\n\nIn the scenario where the macvlan mode is configured as 'source',\nmacvlan_changelink_sources() will be execured to reconfigure list of\nremote source mac addresses, at the same time, if register_netdevice()\nreturn an error, the resource generated by macvlan_changelink_sources()\nis not cleaned up.\n\nUsing this patch, in the case of an error, it will execute\nmacvlan_flush_sources() to ensure that the resource is cleaned up.

In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: process: fix kernel info leakage\n\nthread_struct's s[12] may contain random kernel memory content, which\nmay be finally leaked to userspace. This is a security hole. Fix it\nby clearing the s[12] array in thread_struct when fork.\n\nAs for kthread case, it's better to clear the s[12] array as well.

In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: fix reserved memory setup\n\nCurrently, RISC-V sets up reserved memory using the "early" copy of the\ndevice tree. As a result, when trying to get a reserved memory region\nusing of_reserved_mem_lookup(), the pointer to reserved memory regions\nis using the early, pre-virtual-memory address which causes a kernel\npanic when trying to use the buffer's name:\n\n Unable to handle kernel paging request at virtual address 00000000401c31ac\n Oops [#1]\n Modules linked in:\n CPU: 0 PID: 0 Comm: swapper Not tainted 6.0.0-rc1-00001-g0d9d6953d834 #1\n Hardware name: Microchip PolarFire-SoC Icicle Kit (DT)\n epc : string+0x4a/0xea\n ra : vsnprintf+0x1e4/0x336\n epc : ffffffff80335ea0 ra : ffffffff80338936 sp : ffffffff81203be0\n gp : ffffffff812e0a98 tp : ffffffff8120de40 t0 : 0000000000000000\n t1 : ffffffff81203e28 t2 : 7265736572203a46 s0 : ffffffff81203c20\n s1 : ffffffff81203e28 a0 : ffffffff81203d22 a1 : 0000000000000000\n a2 : ffffffff81203d08 a3 : 0000000081203d21 a4 : ffffffffffffffff\n a5 : 00000000401c31ac a6 : ffff0a00ffffff04 a7 : ffffffffffffffff\n s2 : ffffffff81203d08 s3 : ffffffff81203d00 s4 : 0000000000000008\n s5 : ffffffff000000ff s6 : 0000000000ffffff s7 : 00000000ffffff00\n s8 : ffffffff80d9821a s9 : ffffffff81203d22 s10: 0000000000000002\n s11: ffffffff80d9821c t3 : ffffffff812f3617 t4 : ffffffff812f3617\n t5 : ffffffff812f3618 t6 : ffffffff81203d08\n status: 0000000200000100 badaddr: 00000000401c31ac cause: 000000000000000d\n [] vsnprintf+0x1e4/0x336\n [] vprintk_store+0xf6/0x344\n [] vprintk_emit+0x56/0x192\n [] vprintk_default+0x16/0x1e\n [] vprintk+0x72/0x80\n [] \_printk+0x36/0x50\n [] print_reserved_mem+0x1c/0x24\n [] paging_init+0x528/0x5bc\n [] setup_arch+0xd0/0x592\n [] start_kernel+0x82/0x73c\n\nearly_init_fdt_scan_reserved_mem() takes no arguments as it operates on\ninitial_boot_params, which is populated by early_init_dt_verify(). On\nRISC-V, early_init_dt_verify() is called twice. Once, directly, in\nsetup_arch() if CONFIG_BUILTIN_DTB is not enabled and once indirectly,\nvery early in the boot process, by parse_dtb() when it calls\nearly_init_dt_scan_nodes().\n\nThis first call uses dtb_early_va to set initial_boot_params, which is\nnot usable later in the boot process when\nearly_init_fdt_scan_reserved_mem() is called. On arm64 for example, the\ncorresponding call to early_init_dt_scan_nodes() uses fixmap addresses\nand doesn't suffer the same fate.\n\nMove early_init_fdt_scan_reserved_mem() further along the boot sequence,\nafter the direct call to early_init_dt_verify() in setup_arch() so that\nthe names use the correct virtual memory addresses. The above supposed\nthat CONFIG_BUILTIN_DTB was not set, but should work equally in the case\nwhere it is - unflatted_and_copy_device_tree() also updates\ninitial_boot_params.

In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix deadlock in nilfs_count_free_blocks()\n\nA semaphore deadlock can occur if nilfs_get_block() detects metadata\ncorruption while locating data blocks and a superblock writeback occurs at\nthe same time:\n\ntask 1 task 2\n------ ------\n\* A file operation \*\nnilfs_truncate()\n nilfs_get_block()\n down_read(rwsem A) <--\n nilfs_bmap_lookup_contig()\n ... generic_shutdown_super()\n nilfs_put_super()\n * Prepare to write superblock \*\n down_write(rwsem B) <--\n nilfs_cleanup_super()\n * Detect b-tree corruption * nilfs_set_log_cursor()\n nilfs_bmap_convert_error() nilfs_count_free_blocks()\n \__nilfs_error() down_read(rwsem A) <--\n nilfs_set_error()\n down_write(rwsem B) <--\n\n \*** DEADLOCK **\*\n\nHere, nilfs_get_block() readlocks rwsem A (= NILFS_MDT(dat_inode)->mi_sem)\nand then calls nilfs_bmap_lookup_contig(), but if it fails due to metadata\ncorruption, \__nilfs_error() is called from nilfs_bmap_convert_error()\ninside the lock section.\n\nSince \__nilfs_error() calls nilfs_set_error() unless the filesystem is\nread-only and nilfs_set_error() attempts to writelock rwsem B (=\nnilfs->ns_sem) to write back superblock exclusively, hierarchical lock\nacquisition occurs in the order rwsem A -> rwsem B.\n\nNow, if another task starts updating the superblock, it may writelock\nrwsem B during the lock sequence above, and can deadlock trying to\nreadlock rwsem A in nilfs_count_free_blocks().\n\nHowever, there is actually no need to take rwsem A in\nnilfs_count_free_blocks() because it, within the lock section, only reads\na single integer data on a shared struct with\nnilfs_sufile_get_ncleansegs(). This has been the case after commit\naa474a220180 ("nilfs2: add local variable to cache the number of clean\nsegments"), that is, even before this bug was introduced.\n\nSo, this resolves the deadlock problem by just not taking the semaphore in\nnilfs_count_free_blocks().

In the Linux kernel, the following vulnerability has been resolved:\n\nphy: qcom-qmp-combo: fix NULL-deref on runtime resume\n\nCommit fc64623637da ("phy: qcom-qmp-combo,usb: add support for separate\nPCS_USB region") started treating the PCS_USB registers as potentially\nseparate from the PCS registers but used the wrong base when no PCS_USB\noffset has been provided.\n\nFix the PCS_USB base used at runtime resume to prevent dereferencing a\nNULL pointer on platforms that do not provide a PCS_USB offset (e.g.\nSC7180).

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ethernet: ti: am65-cpsw: Fix segmentation fault at module unload\n\nMove am65_cpsw_nuss_phylink_cleanup() call to after\nam65_cpsw_nuss_cleanup_ndev() so phylink is still valid\nto prevent the below Segmentation fault on module remove when\nfirst slave link is up.\n\n[ 31.652944] Unable to handle kernel paging request at virtual address 00040008000005f4\n[ 31.684627] Mem abort info:\n[ 31.687446] ESR = 0x0000000096000004\n[ 31.704614] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 31.720663] SET = 0, FnV = 0\n[ 31.723729] EA = 0, S1PTW = 0\n[ 31.740617] FSC = 0x04: level 0 translation fault\n[ 31.756624] Data abort info:\n[ 31.759508] ISV = 0, ISS = 0x00000004\n[ 31.776705] CM = 0, WnR = 0\n[ 31.779695] [00040008000005f4] address between user and kernel address ranges\n[ 31.808644] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n[ 31.814928] Modules linked in: wlcore_sdio wl18xx wlcore mac80211 libarc4 cfg80211 rfkill crct10dif_ce phy_gmii_sel ti_am65_cpsw_nuss(-) sch_fq_codel ipv6\n[ 31.828776] CPU: 0 PID: 1026 Comm: modprobe Not tainted 6.1.0-rc2-00012-gfabfcf7dafdb-dirty #160\n[ 31.837547] Hardware name: Texas Instruments AM625 (DT)\n[ 31.842760] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 31.849709] pc : phy_stop+0x18/0xf8\n[ 31.853202] lr : phylink_stop+0x38/0xf8\n[ 31.857031] sp : ffff80000a0839f0\n[ 31.860335] x29: ffff80000a0839f0 x28: ffff000000de1c80 x27: 0000000000000000\n[ 31.867462] x26: 0000000000000000 x25: 0000000000000000 x24: ffff80000a083b98\n[ 31.874589] x23: 0000000000000800 x22: 0000000000000001 x21: ffff000001bfba90\n[ 31.881715] x20: ffff0000015ee000 x19: 0004000800000200 x18: 0000000000000000\n[ 31.888842] x17: ffff800076c45000 x16: ffff800008004000 x15: 000058e39660b106\n[ 31.895969] x14: 0000000000000144 x13: 0000000000000144 x12: 0000000000000000\n[ 31.903095] x11: 000000000000275f x10: 00000000000009e0 x9 : ffff80000a0837d0\n[ 31.910222] x8 : ffff000000de26c0 x7 : ffff00007fbd6540 x6 : ffff00007fbd64c0\n[ 31.917349] x5 : ffff00007fbd0b10 x4 : ffff00007fbd0b10 x3 : ffff00007fbd3920\n[ 31.924476] x2 : d0a07fcff8b8d500 x1 : 0000000000000000 x0 : 0004000800000200\n[ 31.931603] Call trace:\n[ 31.934042] phy_stop+0x18/0xf8\n[ 31.937177] phylink_stop+0x38/0xf8\n[ 31.940657] am65_cpsw_nuss_ndo_slave_stop+0x28/0x1e0 [ti_am65_cpsw_nuss]\n[ 31.947452] \__dev_close_many+0xa4/0x140\n[ 31.951371] dev_close_many+0x84/0x128\n[ 31.955115] unregister_netdevice_many+0x130/0x6d0\n[ 31.959897] unregister_netdevice_queue+0x94/0xd8\n[ 31.964591] unregister_netdev+0x24/0x38\n[ 31.968504] am65_cpsw_nuss_cleanup_ndev.isra.0+0x48/0x70 [ti_am65_cpsw_nuss]\n[ 31.975637] am65_cpsw_nuss_remove+0x58/0xf8 [ti_am65_cpsw_nuss]

In the Linux kernel, the following vulnerability has been resolved:\n\ncan: j1939: j1939_send_one(): fix missing CAN header initialization\n\nThe read access to struct canxl_frame::len inside of a j1939 created\nskbuff revealed a missing initialization of reserved and later filled\nelements in struct can_frame.\n\nThis patch initializes the 8 byte CAN header with zero.

In the Linux kernel, the following vulnerability has been resolved:\n\ncan: dev: fix skb drop check\n\nIn commit a6d190f8c767 ("can: skb: drop tx skb if in listen only\nmode") the priv->ctrlmode element is read even on virtual CAN\ninterfaces that do not create the struct can_priv at startup. This\nout-of-bounds read may lead to CAN frame drops for virtual CAN\ninterfaces like vcan and vxcan.\n\nThis patch mainly reverts the original commit and adds a new helper\nfor CAN interface drivers that provide the required information in\nstruct can_priv.\n\n[mkl: patch pch_can, too]

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: core: Fix use-after-free in snd_soc_exit()\n\nKASAN reports a use-after-free:\n\nBUG: KASAN: use-after-free in device_del+0xb5b/0xc60\nRead of size 8 at addr ffff888008655050 by task rmmod/387\nCPU: 2 PID: 387 Comm: rmmod\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nCall Trace:\n\ndump_stack_lvl+0x79/0x9a\nprint_report+0x17f/0x47b\nkasan_report+0xbb/0xf0\ndevice_del+0xb5b/0xc60\nplatform_device_del.part.0+0x24/0x200\nplatform_device_unregister+0x2e/0x40\nsnd_soc_exit+0xa/0x22 [snd_soc_core]\n__do_sys_delete_module.constprop.0+0x34f/0x5b0\ndo_syscall_64+0x3a/0x90\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\n...\n\n\nIt's bacause in snd_soc_init(), snd_soc_util_init() is possble to fail,\nbut its ret is ignored, which makes soc_dummy_dev unregistered twice.\n\nsnd_soc_init()\n snd_soc_util_init()\n platform_device_register_simple(soc_dummy_dev)\n platform_driver_register() # fail\n platform_device_unregister(soc_dummy_dev)\n platform_driver_register() # success\n...\nsnd_soc_exit()\n snd_soc_util_exit()\n # soc_dummy_dev will be unregistered for second time\n\nTo fix it, handle error and stop snd_soc_init() when util_init() fail.\nAlso clean debugfs when util_init() or driver_register() fail.

In the Linux kernel, the following vulnerability has been resolved:\n\nserial: imx: Add missing .thaw_noirq hook\n\nThe following warning is seen with non-console UART instance when\nsystem hibernates.\n\n[ 37.371969] ------------[ cut here ]------------\n[ 37.376599] uart3_root_clk already disabled\n[ 37.380810] WARNING: CPU: 0 PID: 296 at drivers/clk/clk.c:952 clk_core_disable+0xa4/0xb0\n...\n[ 37.506986] Call trace:\n[ 37.509432] clk_core_disable+0xa4/0xb0\n[ 37.513270] clk_disable+0x34/0x50\n[ 37.516672] imx_uart_thaw+0x38/0x5c\n[ 37.520250] platform_pm_thaw+0x30/0x6c\n[ 37.524089] dpm_run_callback.constprop.0+0x3c/0xd4\n[ 37.528972] device_resume+0x7c/0x160\n[ 37.532633] dpm_resume+0xe8/0x230\n[ 37.536036] hibernation_snapshot+0x288/0x430\n[ 37.540397] hibernate+0x10c/0x2e0\n[ 37.543798] state_store+0xc4/0xd0\n[ 37.547203] kobj_attr_store+0x1c/0x30\n[ 37.550953] sysfs_kf_write+0x48/0x60\n[ 37.554619] kernfs_fop_write_iter+0x118/0x1ac\n[ 37.559063] new_sync_write+0xe8/0x184\n[ 37.562812] vfs_write+0x230/0x290\n[ 37.566214] ksys_write+0x68/0xf4\n[ 37.569529] \__arm64_sys_write+0x20/0x2c\n[ 37.573452] invoke_syscall.constprop.0+0x50/0xf0\n[ 37.578156] do_el0_svc+0x11c/0x150\n[ 37.581648] el0_svc+0x30/0x140\n[ 37.584792] el0t_64_sync_handler+0xe8/0xf0\n[ 37.588976] el0t_64_sync+0x1a0/0x1a4\n[ 37.592639] ---[ end trace 56e22eec54676d75 ]---\n\nOn hibernating, pm core calls into related hooks in sequence like:\n\n .freeze\n .freeze_noirq\n .thaw_noirq\n .thaw\n\nWith .thaw_noirq hook being absent, the clock will be disabled in a\nunbalanced call which results the warning above.\n\n imx_uart_freeze()\n clk_prepare_enable()\n imx_uart_suspend_noirq()\n clk_disable()\n imx_uart_thaw\n clk_disable_unprepare()\n\nAdding the missing .thaw_noirq hook as imx_uart_resume_noirq() will have\nthe call sequence corrected as below and thus fix the warning.\n\n imx_uart_freeze()\n clk_prepare_enable()\n imx_uart_suspend_noirq()\n clk_disable()\n imx_uart_resume_noirq()\n clk_enable()\n imx_uart_thaw\n clk_disable_unprepare()

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, test_run: Fix alignment problem in bpf_prog_test_run_skb()\n\nWe got a syzkaller problem because of aarch64 alignment fault\nif KFENCE enabled. When the size from user bpf program is an odd\nnumber, like 399, 407, etc, it will cause the struct skb_shared_info's\nunaligned access. As seen below:\n\n BUG: KFENCE: use-after-free read in \__skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032\n\n Use-after-free read at 0xffff6254fffac077 (in kfence-#213):\n \__lse_atomic_add arch/arm64/include/asm/atomic_lse.h:26 [inline]\n arch_atomic_add arch/arm64/include/asm/atomic.h:28 [inline]\n arch_atomic_inc include/linux/atomic-arch-fallback.h:270 [inline]\n atomic_inc include/asm-generic/atomic-instrumented.h:241 [inline]\n \__skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032\n skb_clone+0xf4/0x214 net/core/skbuff.c:1481\n \____bpf_clone_redirect net/core/filter.c:2433 [inline]\n bpf_clone_redirect+0x78/0x1c0 net/core/filter.c:2420\n bpf_prog_d3839dd9068ceb51+0x80/0x330\n bpf_dispatcher_nop_func include/linux/bpf.h:728 [inline]\n bpf_test_run+0x3c0/0x6c0 net/bpf/test_run.c:53\n bpf_prog_test_run_skb+0x638/0xa7c net/bpf/test_run.c:594\n bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline]\n \__do_sys_bpf kernel/bpf/syscall.c:4441 [inline]\n \__se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381\n\n kfence-#213: 0xffff6254fffac000-0xffff6254fffac196, size=407, cache=kmalloc-512\n\n allocated by task 15074 on cpu 0 at 1342.585390s:\n kmalloc include/linux/slab.h:568 [inline]\n kzalloc include/linux/slab.h:675 [inline]\n bpf_test_init.isra.0+0xac/0x290 net/bpf/test_run.c:191\n bpf_prog_test_run_skb+0x11c/0xa7c net/bpf/test_run.c:512\n bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline]\n \__do_sys_bpf kernel/bpf/syscall.c:4441 [inline]\n \__se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381\n \__arm64_sys_bpf+0x50/0x60 kernel/bpf/syscall.c:4381\n\nTo fix the problem, we adjust @size so that (@size + @hearoom) is a\nmultiple of SMP_CACHE_BYTES. So we make sure the struct skb_shared_info\nis aligned to a cache line.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: scsi_transport_sas: Fix error handling in sas_phy_add()\n\nIf transport_add_device() fails in sas_phy_add(), the kernel will crash\ntrying to delete the device in transport_remove_device() called from\nsas_remove_host().\n\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000108\nCPU: 61 PID: 42829 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc1+ #173\npstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : device_del+0x54/0x3d0\nlr : device_del+0x37c/0x3d0\nCall trace:\n device_del+0x54/0x3d0\n attribute_container_class_device_del+0x28/0x38\n transport_remove_classdev+0x6c/0x80\n attribute_container_device_trigger+0x108/0x110\n transport_remove_device+0x28/0x38\n sas_phy_delete+0x30/0x60 [scsi_transport_sas]\n do_sas_phy_delete+0x6c/0x80 [scsi_transport_sas]\n device_for_each_child+0x68/0xb0\n sas_remove_children+0x40/0x50 [scsi_transport_sas]\n sas_remove_host+0x20/0x38 [scsi_transport_sas]\n hisi_sas_remove+0x40/0x68 [hisi_sas_main]\n hisi_sas_v2_remove+0x20/0x30 [hisi_sas_v2_hw]\n platform_remove+0x2c/0x60\n\nFix this by checking and handling return value of transport_add_device()\nin sas_phy_add().

In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: clear out_curr if all frag chunks of current msg are pruned\n\nA crash was reported by Zhen Chen:\n\n list_del corruption, ffffa035ddf01c18->next is NULL\n WARNING: CPU: 1 PID: 250682 at lib/list_debug.c:49 \__list_del_entry_valid+0x59/0xe0\n RIP: 0010:\__list_del_entry_valid+0x59/0xe0\n Call Trace:\n sctp_sched_dequeue_common+0x17/0x70 [sctp]\n sctp_sched_fcfs_dequeue+0x37/0x50 [sctp]\n sctp_outq_flush_data+0x85/0x360 [sctp]\n sctp_outq_uncork+0x77/0xa0 [sctp]\n sctp_cmd_interpreter.constprop.0+0x164/0x1450 [sctp]\n sctp_side_effects+0x37/0xe0 [sctp]\n sctp_do_sm+0xd0/0x230 [sctp]\n sctp_primitive_SEND+0x2f/0x40 [sctp]\n sctp_sendmsg_to_asoc+0x3fa/0x5c0 [sctp]\n sctp_sendmsg+0x3d5/0x440 [sctp]\n sock_sendmsg+0x5b/0x70\n\nand in sctp_sched_fcfs_dequeue() it dequeued a chunk from stream\nout_curr outq while this outq was empty.\n\nNormally stream->out_curr must be set to NULL once all frag chunks of\ncurrent msg are dequeued, as we can see in sctp_sched_dequeue_done().\nHowever, in sctp_prsctp_prune_unsent() as it is not a proper dequeue,\nsctp_sched_dequeue_done() is not called to do this.\n\nThis patch is to fix it by simply setting out_curr to NULL when the\nlast frag chunk of current msg is dequeued from out_curr stream in\nsctp_prsctp_prune_unsent().

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix memory leaks in \__check_func_call\n\nkmemleak reports this issue:\n\nunreferenced object 0xffff88817139d000 (size 2048):\n comm "test_progs", pid 33246, jiffies 4307381979 (age 45851.820s)\n hex dump (first 32 bytes):\n 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace:\n [<0000000045f075f0>] kmalloc_trace+0x27/0xa0\n [<0000000098b7c90a>] \__check_func_call+0x316/0x1230\n [<00000000b4c3c403>] check_helper_call+0x172e/0x4700\n [<00000000aa3875b7>] do_check+0x21d8/0x45e0\n [<000000001147357b>] do_check_common+0x767/0xaf0\n [<00000000b5a595b4>] bpf_check+0x43e3/0x5bc0\n [<0000000011e391b1>] bpf_prog_load+0xf26/0x1940\n [<0000000007f765c0>] \__sys_bpf+0xd2c/0x3650\n [<00000000839815d6>] \__x64_sys_bpf+0x75/0xc0\n [<00000000946ee250>] do_syscall_64+0x3b/0x90\n [<0000000000506b7f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThe root case here is: In function prepare_func_exit(), the callee is\nnot released in the abnormal scenario after "state->curframe--;". To\nfix, move "state->curframe--;" to the very bottom of the function,\nright when we free callee and reset frame[] pointer to NULL, as Andrii\nsuggested.\n\nIn addition, function \__check_func_call() has a similar problem. In\nthe abnormal scenario before "state->curframe++;", the callee also\nshould be released by free_func_state().

In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: hda: fix potential memleak in 'add_widget_node'\n\nAs 'kobject_add' may allocated memory for 'kobject->name' when return error.\nAnd in this function, if call 'kobject_add' failed didn't free kobject.\nSo call 'kobject_put' to recycling resources.

In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix use-after-free bug of ns_writer on remount\n\nIf a nilfs2 filesystem is downgraded to read-only due to metadata\ncorruption on disk and is remounted read/write, or if emergency read-only\nremount is performed, detaching a log writer and synchronizing the\nfilesystem can be done at the same time.\n\nIn these cases, use-after-free of the log writer (hereinafter\nnilfs->ns_writer) can happen as shown in the scenario below:\n\n Task1 Task2\n -------------------------------- ------------------------------\n nilfs_construct_segment\n nilfs_segctor_sync\n init_wait\n init_waitqueue_entry\n add_wait_queue\n schedule\n nilfs_remount (R/W remount case)\n nilfs_attach_log_writer\n nilfs_detach_log_writer\n nilfs_segctor_destroy\n kfree\n finish_wait\n \_raw_spin_lock_irqsave\n \__raw_spin_lock_irqsave\n do_raw_spin_lock\n debug_spin_lock_before <-- use-after-free\n\nWhile Task1 is sleeping, nilfs->ns_writer is freed by Task2. After Task1\nwaked up, Task1 accesses nilfs->ns_writer which is already freed. This\nscenario diagram is based on the Shigeru Yoshida's post [1].\n\nThis patch fixes the issue by not detaching nilfs->ns_writer on remount so\nthat this UAF race doesn't happen. Along with this change, this patch\nalso inserts a few necessary read-only checks with superblock instance\nwhere only the ns_writer pointer was used to check if the filesystem is\nread-only.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: zoned: clone zoned device info when cloning a device\n\nWhen cloning a btrfs_device, we're not cloning the associated\nbtrfs_zoned_device_info structure of the device in case of a zoned\nfilesystem.\n\nLater on this leads to a NULL pointer dereference when accessing the\ndevice's zone_info for instance when setting a zone as active.\n\nThis was uncovered by fstests' testcase btrfs/161.

In the Linux kernel, the following vulnerability has been resolved:\n\npinctrl: devicetree: fix null pointer dereferencing in pinctrl_dt_to_map\n\nHere is the BUG report by KASAN about null pointer dereference:\n\nBUG: KASAN: null-ptr-deref in strcmp+0x2e/0x50\nRead of size 1 at addr 0000000000000000 by task python3/2640\nCall Trace:\n strcmp\n \__of_find_property\n of_find_property\n pinctrl_dt_to_map\n\nkasprintf() would return NULL pointer when kmalloc() fail to allocate.\nSo directly return ENOMEM, if kasprintf() return NULL pointer.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: zoned: initialize device's zone info for seeding\n\nWhen performing seeding on a zoned filesystem it is necessary to\ninitialize each zoned device's btrfs_zoned_device_info structure,\notherwise mounting the filesystem will cause a NULL pointer dereference.\n\nThis was uncovered by fstests' testcase btrfs/163.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/drv: Fix potential memory leak in drm_dev_init()\n\ndrm_dev_init() will add drm_dev_init_release() as a callback. When\ndrmm_add_action() failed, the release function won't be added. As the\nresult, the ref cnt added by device_get() in drm_dev_init() won't be put\nby drm_dev_init_release(), which leads to the memleak. Use\ndrmm_add_action_or_reset() instead of drmm_add_action() to prevent\nmemleak.\n\nunreferenced object 0xffff88810bc0c800 (size 2048):\n comm "modprobe", pid 8322, jiffies 4305809845 (age 15.292s)\n hex dump (first 32 bytes):\n e8 cc c0 0b 81 88 ff ff ff ff ff ff 00 00 00 00 ................\n 20 24 3c 0c 81 88 ff ff 18 c8 c0 0b 81 88 ff ff $<.............\n backtrace:\n [<000000007251f72d>] \__kmalloc+0x4b/0x1c0\n [<0000000045f21f26>] platform_device_alloc+0x2d/0xe0\n [<000000004452a479>] platform_device_register_full+0x24/0x1c0\n [<0000000089f4ea61>] 0xffffffffa0736051\n [<00000000235b2441>] do_one_initcall+0x7a/0x380\n [<0000000001a4a177>] do_init_module+0x5c/0x230\n [<000000002bf8a8e2>] load_module+0x227d/0x2420\n [<00000000637d6d0a>] \__do_sys_finit_module+0xd5/0x140\n [<00000000c99fc324>] do_syscall_64+0x3f/0x90\n [<000000004d85aa77>] entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/scheduler: fix fence ref counting\n\nWe leaked dependency fences when processes were beeing killed.\n\nAdditional to that grab a reference to the last scheduled fence.

In the Linux kernel, the following vulnerability has been resolved:\n\nhugetlbfs: don't delete error page from pagecache\n\nThis change is very similar to the change that was made for shmem [1], and\nit solves the same problem but for HugeTLBFS instead.\n\nCurrently, when poison is found in a HugeTLB page, the page is removed\nfrom the page cache. That means that attempting to map or read that\nhugepage in the future will result in a new hugepage being allocated\ninstead of notifying the user that the page was poisoned. As [1] states,\nthis is effectively memory corruption.\n\nThe fix is to leave the page in the page cache. If the user attempts to\nuse a poisoned HugeTLB page with a syscall, the syscall will fail with\nEIO, the same error code that shmem uses. For attempts to map the page,\nthe thread will get a BUS_MCEERR_AR SIGBUS.\n\n[1]: commit a76054266661 ("mm: shmem: don't truncate page if memory failure happens")

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm: Fix potential null-ptr-deref in drm_vblank_destroy_worker()\n\ndrm_vblank_init() call drmm_add_action_or_reset() with\ndrm_vblank_init_release() as action. If \__drmm_add_action() failed, will\ndirectly call drm_vblank_init_release() with the vblank whose worker is\nNULL. As the resule, a null-ptr-deref will happen in\nkthread_destroy_worker(). Add the NULL check before calling\ndrm_vblank_destroy_worker().\n\nBUG: null-ptr-deref\nKASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f]\nCPU: 5 PID: 961 Comm: modprobe Not tainted 6.0.0-11331-gd465bff130bf-dirty\nRIP: 0010:kthread_destroy_worker+0x25/0xb0\n Call Trace:\n \n drm_vblank_init_release+0x124/0x220 [drm]\n ? drm_crtc_vblank_restore+0x8b0/0x8b0 [drm]\n \__drmm_add_action_or_reset+0x41/0x50 [drm]\n drm_vblank_init+0x282/0x310 [drm]\n vkms_init+0x35f/0x1000 [vkms]\n ? 0xffffffffc4508000\n ? lock_is_held_type+0xd7/0x130\n ? \__kmem_cache_alloc_node+0x1c2/0x2b0\n ? lock_is_held_type+0xd7/0x130\n ? 0xffffffffc4508000\n do_one_initcall+0xd0/0x4f0\n ...\n do_syscall_64+0x35/0x80\n entry_SYSCALL_64_after_hwframe+0x46/0xb0

In the Linux kernel, the following vulnerability has been resolved:\n\nata: libata-transport: fix double ata_host_put() in ata_tport_add()\n\nIn the error path in ata_tport_add(), when calling put_device(),\nata_tport_release() is called, it will put the refcount of 'ap->host'.\n\nAnd then ata_host_put() is called again, the refcount is decreased\nto 0, ata_host_release() is called, all ports are freed and set to\nnull.\n\nWhen unbinding the device after failure, ata_host_stop() is called\nto release the resources, it leads a null-ptr-deref(), because all\nthe ports all freed and null.\n\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000008\nCPU: 7 PID: 18671 Comm: modprobe Kdump: loaded Tainted: G E 6.1.0-rc3+ #8\npstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : ata_host_stop+0x3c/0x84 [libata]\nlr : release_nodes+0x64/0xd0\nCall trace:\n ata_host_stop+0x3c/0x84 [libata]\n release_nodes+0x64/0xd0\n devres_release_all+0xbc/0x1b0\n device_unbind_cleanup+0x20/0x70\n really_probe+0x158/0x320\n \__driver_probe_device+0x84/0x120\n driver_probe_device+0x44/0x120\n \__driver_attach+0xb4/0x220\n bus_for_each_dev+0x78/0xdc\n driver_attach+0x2c/0x40\n bus_add_driver+0x184/0x240\n driver_register+0x80/0x13c\n \__pci_register_driver+0x4c/0x60\n ahci_pci_driver_init+0x30/0x1000 [ahci]\n\nFix this by removing redundant ata_host_put() in the error path.

In the Linux kernel, the following vulnerability has been resolved:\n\nata: libata-transport: fix error handling in ata_tport_add()\n\nIn ata_tport_add(), the return value of transport_add_device() is\nnot checked. As a result, it causes null-ptr-deref while removing\nthe module, because transport_remove_device() is called to remove\nthe device that was not added.\n\nUnable to handle kernel NULL pointer dereference at virtual address 00000000000000d0\nCPU: 12 PID: 13605 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc3+ #8\npstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : device_del+0x48/0x39c\nlr : device_del+0x44/0x39c\nCall trace:\n device_del+0x48/0x39c\n attribute_container_class_device_del+0x28/0x40\n transport_remove_classdev+0x60/0x7c\n attribute_container_device_trigger+0x118/0x120\n transport_remove_device+0x20/0x30\n ata_tport_delete+0x34/0x60 [libata]\n ata_port_detach+0x148/0x1b0 [libata]\n ata_pci_remove_one+0x50/0x80 [libata]\n ahci_remove_one+0x4c/0x8c [ahci]\n\nFix this by checking and handling return value of transport_add_device()\nin ata_tport_add().

In the Linux kernel, the following vulnerability has been resolved:\n\nata: libata-transport: fix error handling in ata_tlink_add()\n\nIn ata_tlink_add(), the return value of transport_add_device() is\nnot checked. As a result, it causes null-ptr-deref while removing\nthe module, because transport_remove_device() is called to remove\nthe device that was not added.\n\nUnable to handle kernel NULL pointer dereference at virtual address 00000000000000d0\nCPU: 33 PID: 13850 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc3+ #12\npstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : device_del+0x48/0x39c\nlr : device_del+0x44/0x39c\nCall trace:\n device_del+0x48/0x39c\n attribute_container_class_device_del+0x28/0x40\n transport_remove_classdev+0x60/0x7c\n attribute_container_device_trigger+0x118/0x120\n transport_remove_device+0x20/0x30\n ata_tlink_delete+0x88/0xb0 [libata]\n ata_tport_delete+0x2c/0x60 [libata]\n ata_port_detach+0x148/0x1b0 [libata]\n ata_pci_remove_one+0x50/0x80 [libata]\n ahci_remove_one+0x4c/0x8c [ahci]\n\nFix this by checking and handling return value of transport_add_device()\nin ata_tlink_add().

In the Linux kernel, the following vulnerability has been resolved:\n\nata: libata-transport: fix error handling in ata_tdev_add()\n\nIn ata_tdev_add(), the return value of transport_add_device() is\nnot checked. As a result, it causes null-ptr-deref while removing\nthe module, because transport_remove_device() is called to remove\nthe device that was not added.\n\nUnable to handle kernel NULL pointer dereference at virtual address 00000000000000d0\nCPU: 13 PID: 13603 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc3+ #36\npstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : device_del+0x48/0x3a0\nlr : device_del+0x44/0x3a0\nCall trace:\n device_del+0x48/0x3a0\n attribute_container_class_device_del+0x28/0x40\n transport_remove_classdev+0x60/0x7c\n attribute_container_device_trigger+0x118/0x120\n transport_remove_device+0x20/0x30\n ata_tdev_delete+0x24/0x50 [libata]\n ata_tlink_delete+0x40/0xa0 [libata]\n ata_tport_delete+0x2c/0x60 [libata]\n ata_port_detach+0x148/0x1b0 [libata]\n ata_pci_remove_one+0x50/0x80 [libata]\n ahci_remove_one+0x4c/0x8c [ahci]\n\nFix this by checking and handling return value of transport_add_device()\nin ata_tdev_add(). In the error path, device_del() is called to delete\nthe device which was added earlier in this function, and ata_tdev_free()\nis called to free ata_dev.

In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix connections leak when tlink setup failed\n\nIf the tlink setup failed, lost to put the connections, then\nthe module refcnt leak since the cifsd kthread not exit.\n\nAlso leak the fscache info, and for next mount with fsc, it will\nprint the follow errors:\n CIFS: Cache volume key already in use (cifs,127.0.0.1:445,TEST)\n\nLet's check the result of tlink setup, and do some cleanup.

In the Linux kernel, the following vulnerability has been resolved:\n\nmISDN: fix possible memory leak in mISDN_dsp_element_register()\n\nAfer commit 1fa5ae857bb1 ("driver core: get rid of struct device's\nbus_id string array"), the name of device is allocated dynamically,\nuse put_device() to give up the reference, so that the name can be\nfreed in kobject_cleanup() when the refcount is 0.\n\nThe 'entry' is going to be freed in mISDN_dsp_dev_release(), so the\nkfree() is removed. list_del() is called in mISDN_dsp_dev_release(),\nso it need be initialized.

In the Linux kernel, the following vulnerability has been resolved:\n\nmctp i2c: don't count unused / invalid keys for flow release\n\nWe're currently hitting the WARN_ON in mctp_i2c_flow_release:\n\n if (midev->release_count > midev->i2c_lock_count) {\n WARN_ONCE(1, "release count overflow");\n\nThis may be hit if we expire a flow before sending the first packet it\ncontains - as we will not be pairing the increment of release_count\n(performed on flow release) with the i2c lock operation (only\nperformed on actual TX).\n\nTo fix this, only release a flow if we've encountered it previously (ie,\ndev_flow_state does not indicate NEW), as we will mark the flow as\nACTIVE at the same time as accounting for the i2c lock operation. We\nalso need to add an INVALID flow state, to indicate when we've done the\nrelease.

In the Linux kernel, the following vulnerability has been resolved:\n\nocteon_ep: fix potential memory leak in octep_device_setup()\n\nWhen occur unsupported_dev and mbox init errors, it did not free oct->conf\nand iounmap() oct->mmio[i].hw_addr. That would trigger memory leak problem.\nAdd kfree() for oct->conf and iounmap() for oct->mmio[i].hw_addr under\nunsupported_dev and mbox init errors to fix the problem.

In the Linux kernel, the following vulnerability has been resolved:\n\nmISDN: fix misuse of put_device() in mISDN_register_device()\n\nWe should not release reference by put_device() before calling device_initialize().

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: mhi: Fix memory leak in mhi_net_dellink()\n\nMHI driver registers network device without setting the\nneeds_free_netdev flag, and does NOT call free_netdev() when\nunregisters network device, which causes a memory leak.\n\nThis patch calls free_netdev() to fix it since netdev_priv\nis used after unregister.

In the Linux kernel, the following vulnerability has been resolved:\n\nerofs: fix missing xas_retry() in fscache mode\n\nThe xarray iteration only holds the RCU read lock and thus may encounter\nXA_RETRY_ENTRY if there's process modifying the xarray concurrently.\nThis will cause oops when referring to the invalid entry.\n\nFix this by adding the missing xas_retry(), which will make the\niteration wind back to the root node if XA_RETRY_ENTRY is encountered.

In the Linux kernel, the following vulnerability has been resolved:\n\nkcm: close race conditions on sk_receive_queue\n\nsk->sk_receive_queue is protected by skb queue lock, but for KCM\nsockets its RX path takes mux->rx_lock to protect more than just\nskb queue. However, kcm_recvmsg() still only grabs the skb queue\nlock, so race conditions still exist.\n\nWe can teach kcm_recvmsg() to grab mux->rx_lock too but this would\nintroduce a potential performance regression as struct kcm_mux can\nbe shared by multiple KCM sockets.\n\nSo we have to enforce skb queue lock in requeue_rx_msgs() and handle\nskb peek case carefully in kcm_wait_data(). Fortunately,\nskb_recv_datagram() already handles it nicely and is widely used by\nother sockets, we can just switch to skb_recv_datagram() after\ngetting rid of the unnecessary sock lock in kcm_recvmsg() and\nkcm_splice_read(). Side note: SOCK_DONE is not used by KCM sockets,\nso it is safe to get rid of this check too.\n\nI ran the original syzbot reproducer for 30 min without seeing any\nissue.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ena: Fix error handling in ena_init()\n\nThe ena_init() won't destroy workqueue created by\ncreate_singlethread_workqueue() when pci_register_driver() failed.\nCall destroy_workqueue() when pci_register_driver() failed to prevent the\nresource leak.

In the Linux kernel, the following vulnerability has been resolved:\n\nbridge: switchdev: Fix memory leaks when changing VLAN protocol\n\nThe bridge driver can offload VLANs to the underlying hardware either\nvia switchdev or the 8021q driver. When the former is used, the VLAN is\nmarked in the bridge driver with the 'BR_VLFLAG_ADDED_BY_SWITCHDEV'\nprivate flag.\n\nTo avoid the memory leaks mentioned in the cited commit, the bridge\ndriver will try to delete a VLAN via the 8021q driver if the VLAN is not\nmarked with the previously mentioned flag.\n\nWhen the VLAN protocol of the bridge changes, switchdev drivers are\nnotified via the 'SWITCHDEV_ATTR_ID_BRIDGE_VLAN_PROTOCOL' attribute, but\nthe 8021q driver is also called to add the existing VLANs with the new\nprotocol and delete them with the old protocol.\n\nIn case the VLANs were offloaded via switchdev, the above behavior is\nboth redundant and buggy. Redundant because the VLANs are already\nprogrammed in hardware and drivers that support VLAN protocol change\n(currently only mlx5) change the protocol upon the switchdev attribute\nnotification. Buggy because the 8021q driver is called despite these\nVLANs being marked with 'BR_VLFLAG_ADDED_BY_SWITCHDEV'. This leads to\nmemory leaks [1] when the VLANs are deleted.\n\nFix by not calling the 8021q driver for VLANs that were already\nprogrammed via switchdev.\n\n[1]\nunreferenced object 0xffff8881f6771200 (size 256):\n comm "ip", pid 446855, jiffies 4298238841 (age 55.240s)\n hex dump (first 32 bytes):\n 00 00 7f 0e 83 88 ff ff 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace:\n [<00000000012819ac>] vlan_vid_add+0x437/0x750\n [<00000000f2281fad>] \__br_vlan_set_proto+0x289/0x920\n [<000000000632b56f>] br_changelink+0x3d6/0x13f0\n [<0000000089d25f04>] \__rtnl_newlink+0x8ae/0x14c0\n [<00000000f6276baf>] rtnl_newlink+0x5f/0x90\n [<00000000746dc902>] rtnetlink_rcv_msg+0x336/0xa00\n [<000000001c2241c0>] netlink_rcv_skb+0x11d/0x340\n [<0000000010588814>] netlink_unicast+0x438/0x710\n [<00000000e1a4cd5c>] netlink_sendmsg+0x788/0xc40\n [<00000000e8992d4e>] sock_sendmsg+0xb0/0xe0\n [<00000000621b8f91>] \____sys_sendmsg+0x4ff/0x6d0\n [<000000000ea26996>] \___sys_sendmsg+0x12e/0x1b0\n [<00000000684f7e25>] \__sys_sendmsg+0xab/0x130\n [<000000004538b104>] do_syscall_64+0x3d/0x90\n [<0000000091ed9678>] entry_SYSCALL_64_after_hwframe+0x46/0xb0

In the Linux kernel, the following vulnerability has been resolved:\n\ndrbd: use after free in drbd_create_device()\n\nThe drbd_destroy_connection() frees the "connection" so use the \_safe()\niterator to prevent a use after free.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/x25: Fix skb leak in x25_lapb_receive_frame()\n\nx25_lapb_receive_frame() using skb_copy() to get a private copy of\nskb, the new skb should be freed in the undersized/fragmented skb\nerror handling path. Otherwise there is a memory leak.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: don't leak tagger-owned storage on switch driver unbind\n\nIn the initial commit dc452a471dba ("net: dsa: introduce tagger-owned\nstorage for private and shared data"), we had a call to\ntag_ops->disconnect(dst) issued from dsa_tree_free(), which is called at\ntree teardown time.\n\nThere were problems with connecting to a switch tree as a whole, so this\ngot reworked to connecting to individual switches within the tree. In\nthis process, tag_ops->disconnect(ds) was made to be called only from\nswitch.c (cross-chip notifiers emitted as a result of dynamic tag proto\nchanges), but the normal driver teardown code path wasn't replaced with\nanything.\n\nSolve this problem by adding a function that does the opposite of\ndsa_switch_setup_tag_protocol(), which is called from the equivalent\nspot in dsa_switch_teardown(). The positioning here also ensures that we\nwon't have any use-after-free in tagging protocol (\*rcv) ops, since the\nteardown sequence is as follows:\n\ndsa_tree_teardown\n-> dsa_tree_teardown_master\n -> dsa_master_teardown\n -> unsets master->dsa_ptr, making no further packets match the\n ETH_P_XDSA packet type handler\n-> dsa_tree_teardown_ports\n -> dsa_port_teardown\n -> dsa_slave_destroy\n -> unregisters DSA net devices, there is even a synchronize_net()\n in unregister_netdevice_many()\n-> dsa_tree_teardown_switches\n -> dsa_switch_teardown\n -> dsa_switch_teardown_tag_protocol\n -> finally frees the tagger-owned storage

In the Linux kernel, the following vulnerability has been resolved:\n\nnvmet: fix a memory leak in nvmet_auth_set_key\n\nWhen changing dhchap secrets we need to release the old\nsecrets as well.\n\nkmemleak complaint:\n--\nunreferenced object 0xffff8c7f44ed8180 (size 64):\n comm "check", pid 7304, jiffies 4295686133 (age 72034.246s)\n hex dump (first 32 bytes):\n 44 48 48 43 2d 31 3a 30 30 3a 4c 64 4c 4f 64 71 DHHC-1:00:LdLOdq\n 79 56 69 67 77 48 55 32 6d 5a 59 4c 7a 35 59 38 yVigwHU2mZYLz5Y8\n backtrace:\n [<00000000b6fc5071>] kstrdup+0x2e/0x60\n [<00000000f0f4633f>] 0xffffffffc0e07ee6\n [<0000000053006c05>] 0xffffffffc0dff783\n [<00000000419ae922>] configfs_write_iter+0xb1/0x120\n [<000000008183c424>] vfs_write+0x2be/0x3c0\n [<000000009005a2a5>] ksys_write+0x5f/0xe0\n [<00000000cd495c89>] do_syscall_64+0x38/0x90\n [<00000000f2a84ac5>] entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: microchip: sparx5: Fix potential null-ptr-deref in sparx_stats_init() and sparx5_start()\n\nsparx_stats_init() calls create_singlethread_workqueue() and not\nchecked the ret value, which may return NULL. And a null-ptr-deref may\nhappen:\n\nsparx_stats_init()\n create_singlethread_workqueue() # failed, sparx5->stats_queue is NULL\n queue_delayed_work()\n queue_delayed_work_on()\n \__queue_delayed_work() # warning here, but continue\n \__queue_work() # access wq->flags, null-ptr-deref\n\nCheck the ret value and return -ENOMEM if it is NULL. So as\nsparx5_start().

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: lan966x: Fix potential null-ptr-deref in lan966x_stats_init()\n\nlan966x_stats_init() calls create_singlethread_workqueue() and not\nchecked the ret value, which may return NULL. And a null-ptr-deref may\nhappen:\n\nlan966x_stats_init()\n create_singlethread_workqueue() # failed, lan966x->stats_queue is NULL\n queue_delayed_work()\n queue_delayed_work_on()\n \__queue_delayed_work() # warning here, but continue\n \__queue_work() # access wq->flags, null-ptr-deref\n\nCheck the ret value and return -ENOMEM if it is NULL.

In the Linux kernel, the following vulnerability has been resolved:\n\ns390: avoid using global register for current_stack_pointer\n\nCommit 30de14b1884b ("s390: current_stack_pointer shouldn't be a\nfunction") made current_stack_pointer a global register variable like\non many other architectures. Unfortunately on s390 it uncovers old\ngcc bug which is fixed only since gcc-9.1 [gcc commit 3ad7fed1cc87\n("S/390: Fix PR89775. Stackpointer save/restore instructions removed")]\nand backported to gcc-8.4 and later. Due to this bug gcc versions prior\nto 8.4 generate broken code which leads to stack corruptions.\n\nCurrent minimal gcc version required to build the kernel is declared\nas 5.1. It is not possible to fix all old gcc versions, so work\naround this problem by avoiding using global register variable for\ncurrent_stack_pointer.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetdevsim: Fix memory leak of nsim_dev->fa_cookie\n\nkmemleak reports this issue:\n\nunreferenced object 0xffff8881bac872d0 (size 8):\n comm "sh", pid 58603, jiffies 4481524462 (age 68.065s)\n hex dump (first 8 bytes):\n 04 00 00 00 de ad be ef ........\n backtrace:\n [<00000000c80b8577>] \__kmalloc+0x49/0x150\n [<000000005292b8c6>] nsim_dev_trap_fa_cookie_write+0xc1/0x210 [netdevsim]\n [<0000000093d78e77>] full_proxy_write+0xf3/0x180\n [<000000005a662c16>] vfs_write+0x1c5/0xaf0\n [<000000007aabf84a>] ksys_write+0xed/0x1c0\n [<000000005f1d2e47>] do_syscall_64+0x3b/0x90\n [<000000006001c6ec>] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThe issue occurs in the following scenarios:\n\nnsim_dev_trap_fa_cookie_write()\n kmalloc() fa_cookie\n nsim_dev->fa_cookie = fa_cookie\n..\nnsim_drv_remove()\n\nThe fa_cookie allocked in nsim_dev_trap_fa_cookie_write() is not freed. To\nfix, add kfree(nsim_dev->fa_cookie) to nsim_drv_remove().

In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix memory leak in tracing_read_pipe()\n\nkmemleak reports this issue:\n\nunreferenced object 0xffff888105a18900 (size 128):\n comm "test_progs", pid 18933, jiffies 4336275356 (age 22801.766s)\n hex dump (first 32 bytes):\n 25 73 00 90 81 88 ff ff 26 05 00 00 42 01 58 04 %s......&...B.X.\n 03 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace:\n [<00000000560143a1>] \__kmalloc_node_track_caller+0x4a/0x140\n [<000000006af00822>] krealloc+0x8d/0xf0\n [<00000000c309be6a>] trace_iter_expand_format+0x99/0x150\n [<000000005a53bdb6>] trace_check_vprintf+0x1e0/0x11d0\n [<0000000065629d9d>] trace_event_printf+0xb6/0xf0\n [<000000009a690dc7>] trace_raw_output_bpf_trace_printk+0x89/0xc0\n [<00000000d22db172>] print_trace_line+0x73c/0x1480\n [<00000000cdba76ba>] tracing_read_pipe+0x45c/0x9f0\n [<0000000015b58459>] vfs_read+0x17b/0x7c0\n [<000000004aeee8ed>] ksys_read+0xed/0x1c0\n [<0000000063d3d898>] do_syscall_64+0x3b/0x90\n [<00000000a06dda7f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\niter->fmt alloced in\n tracing_read_pipe() -> .. ->trace_iter_expand_format(), but not\nfreed, to fix, add free in tracing_release_pipe()

In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix wild-memory-access in register_synth_event()\n\nIn register_synth_event(), if set_synth_event_print_fmt() failed, then\nboth trace_remove_event_call() and unregister_trace_event() will be\ncalled, which means the trace_event_call will call\n__unregister_trace_event() twice. As the result, the second unregister\nwill causes the wild-memory-access.\n\nregister_synth_event\n set_synth_event_print_fmt failed\n trace_remove_event_call\n event_remove\n if call->event.funcs then\n \__unregister_trace_event (first call)\n unregister_trace_event\n \__unregister_trace_event (second call)\n\nFix the bug by avoiding to call the second \__unregister_trace_event() by\nchecking if the first one is called.\n\ngeneral protection fault, probably for non-canonical address\n 0xfbd59c0000000024: 0000 [#1] SMP KASAN PTI\nKASAN: maybe wild-memory-access in range\n[0xdead000000000120-0xdead000000000127]\nCPU: 0 PID: 3807 Comm: modprobe Not tainted\n6.1.0-rc1-00186-g76f33a7eedb4 #299\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\nrel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014\nRIP: 0010:unregister_trace_event+0x6e/0x280\nCode: 00 fc ff df 4c 89 ea 48 c1 ea 03 80 3c 02 00 0f 85 0e 02 00 00 48\nb8 00 00 00 00 00 fc ff df 4c 8b 63 08 4c 89 e2 48 c1 ea 03 <80> 3c 02\n00 0f 85 e2 01 00 00 49 89 2c 24 48 85 ed 74 28 e8 7a 9b\nRSP: 0018:ffff88810413f370 EFLAGS: 00010a06\nRAX: dffffc0000000000 RBX: ffff888105d050b0 RCX: 0000000000000000\nRDX: 1bd5a00000000024 RSI: ffff888119e276e0 RDI: ffffffff835a8b20\nRBP: dead000000000100 R08: 0000000000000000 R09: fffffbfff0913481\nR10: ffffffff8489a407 R11: fffffbfff0913480 R12: dead000000000122\nR13: ffff888105d050b8 R14: 0000000000000000 R15: ffff888105d05028\nFS: 00007f7823e8d540(0000) GS:ffff888119e00000(0000)\nknlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f7823e7ebec CR3: 000000010a058002 CR4: 0000000000330ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \n \__create_synth_event+0x1e37/0x1eb0\n create_or_delete_synth_event+0x110/0x250\n synth_event_run_command+0x2f/0x110\n test_gen_synth_cmd+0x170/0x2eb [synth_event_gen_test]\n synth_event_gen_test_init+0x76/0x9bc [synth_event_gen_test]\n do_one_initcall+0xdb/0x480\n do_init_module+0x1cf/0x680\n load_module+0x6a50/0x70a0\n \__do_sys_finit_module+0x12f/0x1c0\n do_syscall_64+0x3f/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix race where eprobes can be called before the event\n\nThe flag that tells the event to call its triggers after reading the event\nis set for eprobes after the eprobe is enabled. This leads to a race where\nthe eprobe may be triggered at the beginning of the event where the record\ninformation is NULL. The eprobe then dereferences the NULL record causing\na NULL kernel pointer bug.\n\nTest for a NULL record to keep this from happening.

In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: kprobe: Fix potential null-ptr-deref on trace_event_file in kprobe_event_gen_test_exit()\n\nWhen trace_get_event_file() failed, gen_kretprobe_test will be assigned\nas the error code. If module kprobe_event_gen_test is removed now, the\nnull pointer dereference will happen in kprobe_event_gen_test_exit().\nCheck if gen_kprobe_test or gen_kretprobe_test is error code or NULL\nbefore dereference them.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000012\nPGD 0 P4D 0\nOops: 0000 [#1] SMP PTI\nCPU: 3 PID: 2210 Comm: modprobe Not tainted\n6.1.0-rc1-00171-g2159299a3b74-dirty #217\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\nrel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014\nRIP: 0010:kprobe_event_gen_test_exit+0x1c/0xb5 [kprobe_event_gen_test]\nCode: Unable to access opcode bytes at 0xffffffff9ffffff2.\nRSP: 0018:ffffc900015bfeb8 EFLAGS: 00010246\nRAX: ffffffffffffffea RBX: ffffffffa0002080 RCX: 0000000000000000\nRDX: ffffffffa0001054 RSI: ffffffffa0001064 RDI: ffffffffdfc6349c\nRBP: ffffffffa0000000 R08: 0000000000000004 R09: 00000000001e95c0\nR10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000800\nR13: ffffffffa0002420 R14: 0000000000000000 R15: 0000000000000000\nFS: 00007f56b75be540(0000) GS:ffff88813bc00000(0000)\nknlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffffff9ffffff2 CR3: 000000010874a006 CR4: 0000000000330ee0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \n \__x64_sys_delete_module+0x206/0x380\n ? lockdep_hardirqs_on_prepare+0xd8/0x190\n ? syscall_enter_from_user_mode+0x1c/0x50\n do_syscall_64+0x3f/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: kprobe: Fix potential null-ptr-deref on trace_array in kprobe_event_gen_test_exit()\n\nWhen test_gen_kprobe_cmd() failed after kprobe_event_gen_cmd_end(), it\nwill goto delete, which will call kprobe_event_delete() and release the\ncorresponding resource. However, the trace_array in gen_kretprobe_test\nwill point to the invalid resource. Set gen_kretprobe_test to NULL\nafter called kprobe_event_delete() to prevent null-ptr-deref.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000070\nPGD 0 P4D 0\nOops: 0000 [#1] SMP PTI\nCPU: 0 PID: 246 Comm: modprobe Tainted: G W\n6.1.0-rc1-00174-g9522dc5c87da-dirty #248\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\nrel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014\nRIP: 0010:__ftrace_set_clr_event_nolock+0x53/0x1b0\nCode: e8 82 26 fc ff 49 8b 1e c7 44 24 0c ea ff ff ff 49 39 de 0f 84 3c\n01 00 00 c7 44 24 18 00 00 00 00 e8 61 26 fc ff 48 8b 6b 10 <44> 8b 65\n70 4c 8b 6d 18 41 f7 c4 00 02 00 00 75 2f\nRSP: 0018:ffffc9000159fe00 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: ffff88810971d268 RCX: 0000000000000000\nRDX: ffff8881080be600 RSI: ffffffff811b48ff RDI: ffff88810971d058\nRBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001\nR10: ffffc9000159fe58 R11: 0000000000000001 R12: ffffffffa0001064\nR13: ffffffffa000106c R14: ffff88810971d238 R15: 0000000000000000\nFS: 00007f89eeff6540(0000) GS:ffff88813b600000(0000)\nknlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000070 CR3: 000000010599e004 CR4: 0000000000330ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \n \__ftrace_set_clr_event+0x3e/0x60\n trace_array_set_clr_event+0x35/0x50\n ? 0xffffffffa0000000\n kprobe_event_gen_test_exit+0xcd/0x10b [kprobe_event_gen_test]\n \__x64_sys_delete_module+0x206/0x380\n ? lockdep_hardirqs_on_prepare+0xd8/0x190\n ? syscall_enter_from_user_mode+0x1c/0x50\n do_syscall_64+0x3f/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\nRIP: 0033:0x7f89eeb061b7

In the Linux kernel, the following vulnerability has been resolved:\n\nrethook: fix a potential memleak in rethook_alloc()\n\nIn rethook_alloc(), the variable rh is not freed or passed out\nif handler is NULL, which could lead to a memleak, fix it.\n\n[Masami: Add "rethook:" tag to the title.]\n\nAcke-by: Masami Hiramatsu (Google)

In the Linux kernel, the following vulnerability has been resolved:\n\niio: adc: at91_adc: fix possible memory leak in at91_adc_allocate_trigger()\n\nIf iio_trigger_register() returns error, it should call iio_trigger_free()\nto give up the reference that hold in iio_trigger_alloc(), so that it can\ncall iio_trig_release() to free memory when the refcount hit to 0.

In the Linux kernel, the following vulnerability has been resolved:\n\niio: adc: mp2629: fix potential array out of bound access\n\nAdd sentinel at end of maps to avoid potential array out of\nbound access in iio core.

In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: fix multishot accept request leaks\n\nHaving REQ_F_POLLED set doesn't guarantee that the request is\nexecuted as a multishot from the polling path. Fortunately for us, if\nthe code thinks it's multishot issue when it's not, it can only ask to\nskip completion so leaking the request. Use issue_flags to mark\nmultipoll issues.

In the Linux kernel, the following vulnerability has been resolved:\n\nInput: iforce - invert valid length check when fetching device IDs\n\nsyzbot is reporting uninitialized value at iforce_init_device() [1], for\ncommit 6ac0aec6b0a6 ("Input: iforce - allow callers supply data buffer\nwhen fetching device IDs") is checking that valid length is shorter than\nbytes to read. Since iforce_get_id_packet() stores valid length when\nreturning 0, the caller needs to check that valid length is longer than or\nequals to bytes to read.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: zfcp: Fix double free of FSF request when qdio send fails\n\nWe used to use the wrong type of integer in 'zfcp_fsf_req_send()' to cache\nthe FSF request ID when sending a new FSF request. This is used in case the\nsending fails and we need to remove the request from our internal hash\ntable again (so we don't keep an invalid reference and use it when we free\nthe request again).\n\nIn 'zfcp_fsf_req_send()' we used to cache the ID as 'int' (signed and 32\nbit wide), but the rest of the zfcp code (and the firmware specification)\nhandles the ID as 'unsigned long'/'u64' (unsigned and 64 bit wide [s390x\nELF ABI]). For one this has the obvious problem that when the ID grows\npast 32 bit (this can happen reasonably fast) it is truncated to 32 bit\nwhen storing it in the cache variable and so doesn't match the original ID\nanymore. The second less obvious problem is that even when the original ID\nhas not yet grown past 32 bit, as soon as the 32nd bit is set in the\noriginal ID (0x80000000 = 2'147'483'648) we will have a mismatch when we\ncast it back to 'unsigned long'. As the cached variable is of a signed\ntype, the compiler will choose a sign-extending instruction to load the 32\nbit variable into a 64 bit register (e.g.: 'lgf %r11,188(%r15)'). So once\nwe pass the cached variable into 'zfcp_reqlist_find_rm()' to remove the\nrequest again all the leading zeros will be flipped to ones to extend the\nsign and won't match the original ID anymore (this has been observed in\npractice).\n\nIf we can't successfully remove the request from the hash table again after\n'zfcp_qdio_send()' fails (this happens regularly when zfcp cannot notify\nthe adapter about new work because the adapter is already gone during\ne.g. a ChpID toggle) we will end up with a double free. We unconditionally\nfree the request in the calling function when 'zfcp_fsf_req_send()' fails,\nbut because the request is still in the hash table we end up with a stale\nmemory reference, and once the zfcp adapter is either reset during recovery\nor shutdown we end up freeing the same memory twice.\n\nThe resulting stack traces vary depending on the kernel and have no direct\ncorrelation to the place where the bug occurs. Here are three examples that\nhave been seen in practice:\n\n list_del corruption. next->prev should be 00000001b9d13800, but was 00000000dead4ead. (next=00000001bd131a00)\n ------------[ cut here ]------------\n kernel BUG at lib/list_debug.c:62!\n monitor event: 0040 ilc:2 [#1] PREEMPT SMP\n Modules linked in: ...\n CPU: 9 PID: 1617 Comm: zfcperp0.0.1740 Kdump: loaded\n Hardware name: ...\n Krnl PSW : 0704d00180000000 00000003cbeea1f8 (\__list_del_entry_valid+0x98/0x140)\n R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3\n Krnl GPRS: 00000000916d12f1 0000000080000000 000000000000006d 00000003cb665cd6\n 0000000000000001 0000000000000000 0000000000000000 00000000d28d21e8\n 00000000d3844000 00000380099efd28 00000001bd131a00 00000001b9d13800\n 00000000d3290100 0000000000000000 00000003cbeea1f4 00000380099efc70\n Krnl Code: 00000003cbeea1e8: c020004f68a7 larl %r2,00000003cc8d7336\n 00000003cbeea1ee: c0e50027fd65 brasl %r14,00000003cc3e9cb8\n #00000003cbeea1f4: af000000 mc 0,0\n >00000003cbeea1f8: c02000920440 larl %r2,00000003cd12aa78\n 00000003cbeea1fe: c0e500289c25 brasl %r14,00000003cc3fda48\n 00000003cbeea204: b9040043 lgr %r4,%r3\n 00000003cbeea208: b9040051 lgr %r5,%r1\n 00000003cbeea20c: b9040032 lgr %r3,%r2\n Call Trace:\n [<00000003cbeea1f8>] \__list_del_entry_valid+0x98/0x140\n ([<00000003cbeea1f4>] \__list_del_entry_valid+0x94/0x140)\n [<000003ff7ff502fe>] zfcp_fsf_req_dismiss_all+0xde/0x150 [zfcp]\n [<000003ff7ff49cd0>] zfcp_erp_strategy_do_action+0x160/0x280 [zfcp]\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\n\nmisc/vmw_vmci: fix an infoleak in vmci_host_do_receive_datagram()\n\n`struct vmci_event_qp` allocated by qp_notify_peer() contains padding,\nwhich may carry uninitialized data to the userspace, as observed by\nKMSAN:\n\n BUG: KMSAN: kernel-infoleak in instrument_copy_to_user ./include/linux/instrumented.h:121\n instrument_copy_to_user ./include/linux/instrumented.h:121\n \_copy_to_user+0x5f/0xb0 lib/usercopy.c:33\n copy_to_user ./include/linux/uaccess.h:169\n vmci_host_do_receive_datagram drivers/misc/vmw_vmci/vmci_host.c:431\n vmci_host_unlocked_ioctl+0x33d/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:925\n vfs_ioctl fs/ioctl.c:51\n ...\n\n Uninit was stored to memory at:\n kmemdup+0x74/0xb0 mm/util.c:131\n dg_dispatch_as_host drivers/misc/vmw_vmci/vmci_datagram.c:271\n vmci_datagram_dispatch+0x4f8/0xfc0 drivers/misc/vmw_vmci/vmci_datagram.c:339\n qp_notify_peer+0x19a/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1479\n qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662\n qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750\n vmci_qp_broker_alloc+0x96/0xd0 drivers/misc/vmw_vmci/vmci_queue_pair.c:1940\n vmci_host_do_alloc_queuepair drivers/misc/vmw_vmci/vmci_host.c:488\n vmci_host_unlocked_ioctl+0x24fd/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:927\n ...\n\n Local variable ev created at:\n qp_notify_peer+0x54/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1456\n qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662\n qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750\n\n Bytes 28-31 of 48 are uninitialized\n Memory access of size 48 starts at ffff888035155e00\n Data copied to user address 0000000020000100\n\nUse memset() to prevent the infoleaks.\n\nAlso speculatively fix qp_notify_peer_local(), which may suffer from the\nsame problem.

In the Linux kernel, the following vulnerability has been resolved:\n\nmmc: sdhci-pci: Fix possible memory leak caused by missing pci_dev_put()\n\npci_get_device() will increase the reference count for the returned\npci_dev. We need to use pci_dev_put() to decrease the reference count\nbefore amd_probe() returns. There is no problem for the 'smbus_dev ==\nNULL' branch because pci_dev_put() can also handle the NULL input\nparameter case.

In the Linux kernel, the following vulnerability has been resolved:\n\nblk-cgroup: properly pin the parent in blkcg_css_online\n\nblkcg_css_online is supposed to pin the blkcg of the parent, but\n397c9f46ee4d refactored things and along the way, changed it to pin the\ncss instead. This results in extra pins, and we end up leaking blkcgs\nand cgroups.

In the Linux kernel, the following vulnerability has been resolved:\n\nx86/sgx: Add overflow check in sgx_validate_offset_length()\n\nsgx_validate_offset_length() function verifies "offset" and "length"\narguments provided by userspace, but was missing an overflow check on\ntheir addition. Add it.

In the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/amd/uncore: Fix memory leak for events array\n\nWhen a CPU comes online, the per-CPU NB and LLC uncore contexts are\nfreed but not the events array within the context structure. This\ncauses a memory leak as identified by the kmemleak detector.\n\n [...]\n unreferenced object 0xffff8c5944b8e320 (size 32):\n comm "swapper/0", pid 1, jiffies 4294670387 (age 151.072s)\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace:\n [<000000000759fb79>] amd_uncore_cpu_up_prepare+0xaf/0x230\n [<00000000ddc9e126>] cpuhp_invoke_callback+0x2cf/0x470\n [<0000000093e727d4>] cpuhp_issue_call+0x14d/0x170\n [<0000000045464d54>] \__cpuhp_setup_state_cpuslocked+0x11e/0x330\n [<0000000069f67cbd>] \__cpuhp_setup_state+0x6b/0x110\n [<0000000015365e0f>] amd_uncore_init+0x260/0x321\n [<00000000089152d2>] do_one_initcall+0x3f/0x1f0\n [<000000002d0bd18d>] kernel_init_freeable+0x1ca/0x212\n [<0000000030be8dde>] kernel_init+0x11/0x120\n [<0000000059709e59>] ret_from_fork+0x22/0x30\n unreferenced object 0xffff8c5944b8dd40 (size 64):\n comm "swapper/0", pid 1, jiffies 4294670387 (age 151.072s)\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace:\n [<00000000306efe8b>] amd_uncore_cpu_up_prepare+0x183/0x230\n [<00000000ddc9e126>] cpuhp_invoke_callback+0x2cf/0x470\n [<0000000093e727d4>] cpuhp_issue_call+0x14d/0x170\n [<0000000045464d54>] \__cpuhp_setup_state_cpuslocked+0x11e/0x330\n [<0000000069f67cbd>] \__cpuhp_setup_state+0x6b/0x110\n [<0000000015365e0f>] amd_uncore_init+0x260/0x321\n [<00000000089152d2>] do_one_initcall+0x3f/0x1f0\n [<000000002d0bd18d>] kernel_init_freeable+0x1ca/0x212\n [<0000000030be8dde>] kernel_init+0x11/0x120\n [<0000000059709e59>] ret_from_fork+0x22/0x30\n [...]\n\nFix the problem by freeing the events array before freeing the uncore\ncontext.

In the Linux kernel, the following vulnerability has been resolved:\n\nx86/fpu: Drop fpregs lock before inheriting FPU permissions\n\nMike Galbraith reported the following against an old fork of preempt-rt\nbut the same issue also applies to the current preempt-rt tree.\n\n BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46\n in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: systemd\n preempt_count: 1, expected: 0\n RCU nest depth: 0, expected: 0\n Preemption disabled at:\n fpu_clone\n CPU: 6 PID: 1 Comm: systemd Tainted: G E (unreleased)\n Call Trace:\n \n dump_stack_lvl\n ? fpu_clone\n \__might_resched\n rt_spin_lock\n fpu_clone\n ? copy_thread\n ? copy_process\n ? shmem_alloc_inode\n ? kmem_cache_alloc\n ? kernel_clone\n ? \__do_sys_clone\n ? do_syscall_64\n ? \__x64_sys_rt_sigprocmask\n ? syscall_exit_to_user_mode\n ? do_syscall_64\n ? syscall_exit_to_user_mode\n ? do_syscall_64\n ? syscall_exit_to_user_mode\n ? do_syscall_64\n ? exc_page_fault\n ? entry_SYSCALL_64_after_hwframe\n \n\nMike says:\n\n The splat comes from fpu_inherit_perms() being called under fpregs_lock(),\n and us reaching the spin_lock_irq() therein due to fpu_state_size_dynamic()\n returning true despite static key \__fpu_state_size_dynamic having never\n been enabled.\n\nMike's assessment looks correct. fpregs_lock on a PREEMPT_RT kernel disables\npreemption so calling spin_lock_irq() in fpu_inherit_perms() is unsafe. This\nproblem exists since commit\n\n 9e798e9aa14c ("x86/fpu: Prepare fpu_clone() for dynamically enabled features").\n\nEven though the original bug report should not have enabled the paths at\nall, the bug still exists.\n\nfpregs_lock is necessary when editing the FPU registers or a task's FP\nstate but it is not necessary for fpu_inherit_perms(). The only write\nof any FP state in fpu_inherit_perms() is for the new child which is\nnot running yet and cannot context switch or be borrowed by a kernel\nthread yet. Hence, fpregs_lock is not protecting anything in the new\nchild until clone() completes and can be dropped earlier. The siglock\nstill needs to be acquired by fpu_inherit_perms() as the read of the\nparent's permissions has to be serialised.\n\n [ bp: Cleanup splat. ]

In the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/amd: Fix crash due to race between amd_pmu_enable_all, perf NMI and throttling\n\namd_pmu_enable_all() does:\n\n if (!test_bit(idx, cpuc->active_mask))\n continue;\n\n amd_pmu_enable_event(cpuc->events[idx]);\n\nA perf NMI of another event can come between these two steps. Perf NMI\nhandler internally disables and enables _all_ events, including the one\nwhich nmi-intercepted amd_pmu_enable_all() was in process of enabling.\nIf that unintentionally enabled event has very low sampling period and\ncauses immediate successive NMI, causing the event to be throttled,\ncpuc->events[idx] and cpuc->active_mask gets cleared by x86_pmu_stop().\nThis will result in amd_pmu_enable_event() getting called with event=NULL\nwhen amd_pmu_enable_all() resumes after handling the NMIs. This causes a\nkernel crash:\n\n BUG: kernel NULL pointer dereference, address: 0000000000000198\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n [...]\n Call Trace:\n \n amd_pmu_enable_all+0x68/0xb0\n ctx_resched+0xd9/0x150\n event_function+0xb8/0x130\n ? hrtimer_start_range_ns+0x141/0x4a0\n ? perf_duration_warn+0x30/0x30\n remote_function+0x4d/0x60\n \__flush_smp_call_function_queue+0xc4/0x500\n flush_smp_call_function_queue+0x11d/0x1b0\n do_idle+0x18f/0x2d0\n cpu_startup_entry+0x19/0x20\n start_secondary+0x121/0x160\n secondary_startup_64_no_verify+0xe5/0xeb\n \n\namd_pmu_disable_all()/amd_pmu_enable_all() calls inside perf NMI handler\nwere recently added as part of BRS enablement but I'm not sure whether\nwe really need them. We can just disable BRS in the beginning and enable\nit back while returning from NMI. This will solve the issue by not\nenabling those events whose active_masks are set but are not yet enabled\nin hw pmu.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: tcm_loop: Fix possible name leak in tcm_loop_setup_hba_bus()\n\nIf device_register() fails in tcm_loop_setup_hba_bus(), the name allocated\nby dev_set_name() need be freed. As comment of device_register() says, it\nshould use put_device() to give up the reference in the error path. So fix\nthis by calling put_device(), then the name can be freed in kobject_cleanup().\nThe 'tl_hba' will be freed in tcm_loop_release_adapter(), so it don't need\ngoto error label in this case.

In the Linux kernel, the following vulnerability has been resolved:\n\nkprobes: Skip clearing aggrprobe's post_handler in kprobe-on-ftrace case\n\nIn \__unregister_kprobe_top(), if the currently unregistered probe has\npost_handler but other child probes of the aggrprobe do not have\npost_handler, the post_handler of the aggrprobe is cleared. If this is\na ftrace-based probe, there is a problem. In later calls to\ndisarm_kprobe(), we will use kprobe_ftrace_ops because post_handler is\nNULL. But we're armed with kprobe_ipmodify_ops. This triggers a WARN in\n__disarm_kprobe_ftrace() and may even cause use-after-free:\n\n Failed to disarm kprobe-ftrace at kernel_clone+0x0/0x3c0 (error -2)\n WARNING: CPU: 5 PID: 137 at kernel/kprobes.c:1135 \__disarm_kprobe_ftrace.isra.21+0xcf/0xe0\n Modules linked in: testKprobe_007(-)\n CPU: 5 PID: 137 Comm: rmmod Not tainted 6.1.0-rc4-dirty #18\n [...]\n Call Trace:\n \n \__disable_kprobe+0xcd/0xe0\n \__unregister_kprobe_top+0x12/0x150\n ? mutex_lock+0xe/0x30\n unregister_kprobes.part.23+0x31/0xa0\n unregister_kprobe+0x32/0x40\n \__x64_sys_delete_module+0x15e/0x260\n ? do_user_addr_fault+0x2cd/0x6b0\n do_syscall_64+0x3a/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n [...]\n\nFor the kprobe-on-ftrace case, we keep the post_handler setting to\nidentify this aggrprobe armed with kprobe_ipmodify_ops. This way we\ncan disarm it correctly.

In the Linux kernel, the following vulnerability has been resolved:\n\narm64/mm: fix incorrect file_map_count for non-leaf pmd/pud\n\nThe page table check trigger BUG_ON() unexpectedly when collapse hugepage:\n\n ------------[ cut here ]------------\n kernel BUG at mm/page_table_check.c:82!\n Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n Dumping ftrace buffer:\n (ftrace buffer empty)\n Modules linked in:\n CPU: 6 PID: 68 Comm: khugepaged Not tainted 6.1.0-rc3+ #750\n Hardware name: linux,dummy-virt (DT)\n pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : page_table_check_clear.isra.0+0x258/0x3f0\n lr : page_table_check_clear.isra.0+0x240/0x3f0\n[...]\n Call trace:\n page_table_check_clear.isra.0+0x258/0x3f0\n \__page_table_check_pmd_clear+0xbc/0x108\n pmdp_collapse_flush+0xb0/0x160\n collapse_huge_page+0xa08/0x1080\n hpage_collapse_scan_pmd+0xf30/0x1590\n khugepaged_scan_mm_slot.constprop.0+0x52c/0xac8\n khugepaged+0x338/0x518\n kthread+0x278/0x2f8\n ret_from_fork+0x10/0x20\n[...]\n\nSince pmd_user_accessible_page() doesn't check if a pmd is leaf, it\ndecrease file_map_count for a non-leaf pmd comes from collapse_huge_page().\nand so trigger BUG_ON() unexpectedly.\n\nFix this problem by using pmd_leaf() insteal of pmd_present() in\npmd_user_accessible_page(). Moreover, use pud_leaf() for\npud_user_accessible_page() too.

In the Linux kernel, the following vulnerability has been resolved:\n\nInput: i8042 - fix leaking of platform device on module removal\n\nAvoid resetting the module-wide i8042_platform_device pointer in\ni8042_probe() or i8042_remove(), so that the device can be properly\ndestroyed by i8042_exit() on module unload.

In the Linux kernel, the following vulnerability has been resolved:\n\nmacvlan: enforce a consistent minimal mtu\n\nmacvlan should enforce a minimal mtu of 68, even at link creation.\n\nThis patch avoids the current behavior (which could lead to crashes\nin ipv6 stack if the link is brought up)\n\n$ ip link add macvlan1 link eno1 mtu 8 type macvlan # This should fail !\n$ ip link sh dev macvlan1\n5: macvlan1@eno1: mtu 8 qdisc noop\n state DOWN mode DEFAULT group default qlen 1000\n link/ether 02:47:6c:24:74:82 brd ff:ff:ff:ff:ff:ff\n$ ip link set macvlan1 mtu 67\nError: mtu less than device minimum.\n$ ip link set macvlan1 mtu 68\n$ ip link set macvlan1 mtu 8\nError: mtu less than device minimum.

In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: cdg: allow tcp_cdg_release() to be called multiple times\n\nApparently, mptcp is able to call tcp_disconnect() on an already\ndisconnected flow. This is generally fine, unless current congestion\ncontrol is CDG, because it might trigger a double-free [1]\n\nInstead of fixing MPTCP, and future bugs, we can make tcp_disconnect()\nmore resilient.\n\n[1]\nBUG: KASAN: double-free in slab_free mm/slub.c:3539 [inline]\nBUG: KASAN: double-free in kfree+0xe2/0x580 mm/slub.c:4567\n\nCPU: 0 PID: 3645 Comm: kworker/0:7 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022\nWorkqueue: events mptcp_worker\nCall Trace:\n\n__dump_stack lib/dump_stack.c:88 [inline]\ndump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106\nprint_address_description mm/kasan/report.c:317 [inline]\nprint_report.cold+0x2ba/0x719 mm/kasan/report.c:433\nkasan_report_invalid_free+0x81/0x190 mm/kasan/report.c:462\n____kasan_slab_free+0x18b/0x1c0 mm/kasan/common.c:356\nkasan_slab_free include/linux/kasan.h:200 [inline]\nslab_free_hook mm/slub.c:1759 [inline]\nslab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1785\nslab_free mm/slub.c:3539 [inline]\nkfree+0xe2/0x580 mm/slub.c:4567\ntcp_disconnect+0x980/0x1e20 net/ipv4/tcp.c:3145\n__mptcp_close_ssk+0x5ca/0x7e0 net/mptcp/protocol.c:2327\nmptcp_do_fastclose net/mptcp/protocol.c:2592 [inline]\nmptcp_worker+0x78c/0xff0 net/mptcp/protocol.c:2627\nprocess_one_work+0x991/0x1610 kernel/workqueue.c:2289\nworker_thread+0x665/0x1080 kernel/workqueue.c:2436\nkthread+0x2e4/0x3a0 kernel/kthread.c:376\nret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306\n\n\nAllocated by task 3671:\nkasan_save_stack+0x1e/0x40 mm/kasan/common.c:38\nkasan_set_track mm/kasan/common.c:45 [inline]\nset_alloc_info mm/kasan/common.c:437 [inline]\n____kasan_kmalloc mm/kasan/common.c:516 [inline]\n____kasan_kmalloc mm/kasan/common.c:475 [inline]\n__kasan_kmalloc+0xa9/0xd0 mm/kasan/common.c:525\nkmalloc_array include/linux/slab.h:640 [inline]\nkcalloc include/linux/slab.h:671 [inline]\ntcp_cdg_init+0x10d/0x170 net/ipv4/tcp_cdg.c:380\ntcp_init_congestion_control+0xab/0x550 net/ipv4/tcp_cong.c:193\ntcp_reinit_congestion_control net/ipv4/tcp_cong.c:217 [inline]\ntcp_set_congestion_control+0x96c/0xaa0 net/ipv4/tcp_cong.c:391\ndo_tcp_setsockopt+0x505/0x2320 net/ipv4/tcp.c:3513\ntcp_setsockopt+0xd4/0x100 net/ipv4/tcp.c:3801\nmptcp_setsockopt+0x35f/0x2570 net/mptcp/sockopt.c:844\n__sys_setsockopt+0x2d6/0x690 net/socket.c:2252\n__do_sys_setsockopt net/socket.c:2263 [inline]\n__se_sys_setsockopt net/socket.c:2260 [inline]\n__x64_sys_setsockopt+0xba/0x150 net/socket.c:2260\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nFreed by task 16:\nkasan_save_stack+0x1e/0x40 mm/kasan/common.c:38\nkasan_set_track+0x21/0x30 mm/kasan/common.c:45\nkasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370\n____kasan_slab_free mm/kasan/common.c:367 [inline]\n____kasan_slab_free+0x166/0x1c0 mm/kasan/common.c:329\nkasan_slab_free include/linux/kasan.h:200 [inline]\nslab_free_hook mm/slub.c:1759 [inline]\nslab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1785\nslab_free mm/slub.c:3539 [inline]\nkfree+0xe2/0x580 mm/slub.c:4567\ntcp_cleanup_congestion_control+0x70/0x120 net/ipv4/tcp_cong.c:226\ntcp_v4_destroy_sock+0xdd/0x750 net/ipv4/tcp_ipv4.c:2254\ntcp_v6_destroy_sock+0x11/0x20 net/ipv6/tcp_ipv6.c:1969\ninet_csk_destroy_sock+0x196/0x440 net/ipv4/inet_connection_sock.c:1157\ntcp_done+0x23b/0x340 net/ipv4/tcp.c:4649\ntcp_rcv_state_process+0x40e7/0x4990 net/ipv4/tcp_input.c:6624\ntcp_v6_do_rcv+0x3fc/0x13c0 net/ipv6/tcp_ipv6.c:1525\ntcp_v6_rcv+0x2e8e/0x3830 net/ipv6/tcp_ipv6.c:1759\nip6_protocol_deliver_rcu+0x2db/0x1950 net/ipv6/ip6_input.c:439\nip6_input_finish+0x14c/0x2c0 net/ipv6/ip6_input.c:484\nNF_HOOK include/linux/netfilter.h:302 [inline]\nNF_HOOK include/linux/netfilter.h:296 [inline]\nip6_input+0x9c/0xd\n---truncated---