Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
t field is larger than bytes_allocated field, then it may trigger the out-of-bounds read bug(reported as use-after-free bug) in ntfs_attr_find(), when kernel tries to access the corresponding mft record's attribute. This patch solves it by adding the sanity check between attrs_offset field and bytes_allocated field, after loading the first mft record. References: - https://git.kernel.org/stable/c/79f3ac7dcd12c05b7539239a4c6fa229a50d786c - https://git.kernel.org/stable/c/fb2004bafd1932e08d21ca604ee5844f2b7f212d - https://git.kernel.org/stable/c/d0006d739738a658a9c29b438444259d9f71dfa0 - https://git.kernel.org/stable/c/266bd5306286316758e6246ea0345133427b0f62 - https://git.kernel.org/stable/c/
9d9f71dfa0 - https://git.kernel.org/stable/c/266bd5306286316758e6246ea0345133427b0f62 - https://git.kernel.org/stable/c/b825bfbbaafbe8da2037e3a778ad660c59f9e054 - https://git.kernel.org/stable/c/5330c423b86263ac7883fef0260b9e2229cb531e - https://git.kernel.org/stable/c/4863f815463034f588a035cfd99cdca97a4f1069 - https://git.kernel.org/stable/c/d85a1bec8e8d552ab13163ca1874dcd82f3d1550
CVE ID: CVE-2022-49764 State: PUBLISHED Published: 2025-05-01T14:09:04.252Z Last Updated: 2025-05-04T08:44:52.825Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Prevent bpf program recursion for raw tracepoint probes We got report from sysbot [1] about warnings that were caused by bpf program attached to contention_begin raw tracepoint triggering the same tracepoint by using bpf_trace_printk helper that takes trace_printk_lock lock. Call Trace: <TASK> ? trace_event_raw_event_bpf_trace_printk+0x5f/0x90 bpf_trace_printk+0x2b/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowp
f_trace_printk+0x2b/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 __unfreeze_partial
pf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 __unfreeze_partials+0x5b/0x160 ... The can be reproduced by attaching bpf program as raw tracepoint on contention_begin tracepoint. The bpf prog calls bpf_trace_printk helper. Then by running perf bench the spin lock code is forced to take slow path and call contention_begin tracepoint. Fixing this by skipping execution of the bpf program if it's already running, Using bpf prog 'active' field, which is being currently used by trampoline programs for the same reason. Moving bpf_prog_inc_misses_counter to syscall.c because trampoline.c is compiled in just for CONFIG_BPF_JIT option. [1] https:/
bpf_prog_inc_misses_counter to syscall.c because trampoline.c is compiled in just for CONFIG_BPF_JIT option. [1] https://lore.kernel.org/bpf/YxhFe3EwqchC%2FfYf@krava/T/#t References: - https://git.kernel.org/stable/c/2e5399879024fedd6cdc41f73fbf9bbe7208f899 - https://git.kernel.org/stable/c/05b24ff9b2cfabfcfd951daaa915a036ab53c9e1
CVE ID: CVE-2022-49765 State: PUBLISHED Published: 2025-05-01T14:09:04.896Z Last Updated: 2025-05-04T08:44:53.892Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/9p: use a dedicated spinlock for trans_fd Shamelessly copying the explanation from Tetsuo Handa's suggested patch[1] (slightly reworded): syzbot is reporting inconsistent lock state in p9_req_put()[2], for p9_tag_remove() from p9_req_put() from IRQ context is using spin_lock_irqsave() on "struct p9_client"->lock but trans_fd (not from IRQ context) is using spin_lock(). Since the locks actually protect different things in client.c and in trans_fd.c, just replace tra
is using spin_lock(). Since the locks actually protect different things in client.c and in trans_fd.c, just replace trans_fd.c's lock by a new one specific to the transport (client.c's protect the idr for fid/tag allocations, while trans_fd.c's protects its own req list and request status field that acts as the transport's state machine) References: - https://git.kernel.org/stable/c/43bbadb7e4636dc02f6a283c2a39e6438e6173cd - https://git.kernel.org/stable/c/717b9b4f38703d7f5293059e3a242d16f76fa045 - https://git.kernel.org/stable/c/296ab4a813841ba1d5f40b03190fd1bd8f25aab0
CVE ID: CVE-2022-49766 State: PUBLISHED Published: 2025-05-01T14:09:05.569Z Last Updated: 2025-05-04T08:44:55.198Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netlink: Bounds-check struct nlmsgerr creation In preparation for FORTIFY_SOURCE doing bounds-check on memcpy(), switch from __nlmsg_put to nlmsg_put(), and explain the bounds check for dealing with the memcpy() across a composite flexible array struct. Avoids this future run-time warning: memcpy: detected field-spanning write (size 32) of single field "&errmsg->msg" at net/netlink/af_netlink.c:2447 (size 16) References: - https://git.kernel.org/stable/c/aff4eb16f589c3
d "&errmsg->msg" at net/netlink/af_netlink.c:2447 (size 16) References: - https://git.kernel.org/stable/c/aff4eb16f589c3af322a2582044bca365381fcd6 - https://git.kernel.org/stable/c/710d21fdff9a98d621cd4e64167f3ef8af4e2fd1
CVE ID: CVE-2022-49767 State: PUBLISHED Published: 2025-05-01T14:09:06.183Z Last Updated: 2025-05-04T08:44:56.452Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: 9p/trans_fd: always use O_NONBLOCK read/write syzbot is reporting hung task at p9_fd_close() [1], for p9_mux_poll_stop() from p9_conn_destroy() from p9_fd_close() is failing to interrupt already started kernel_read() from p9_fd_read() from p9_read_work() and/or kernel_write() from p9_fd_write() from p9_write_work() requests. Since p9_socket_open() sets O_NONBLOCK flag, p9_mux_poll_stop() does not need to interrupt kernel_read()/kernel_write(). However, since p9_fd_open
s O_NONBLOCK flag, p9_mux_poll_stop() does not need to interrupt kernel_read()/kernel_write(). However, since p9_fd_open() does not set O_NONBLOCK flag, but pipe blocks unless signal is pending, p9_mux_poll_stop() needs to interrupt kernel_read()/kernel_write() when the file descriptor refers to a pipe. In other words, pipe file descriptor needs to be handled as if socket file descriptor. We somehow need to interrupt kernel_read()/kernel_write() on pipes. A minimal change, which this patch is doing, is to set O_NONBLOCK flag from p9_fd_open(), for O_NONBLOCK flag does not affect reading/writing of regular files. But this approach changes O_NONBLOCK flag on userspace- supplied file descriptor
ffect reading/writing of regular files. But this approach changes O_NONBLOCK flag on userspace- supplied file descriptors (which might break userspace programs), and O_NONBLOCK flag could be changed by userspace. It would be possible to set O_NONBLOCK flag every time p9_fd_read()/p9_fd_write() is invoked, but still remains small race window for clearing O_NONBLOCK flag. If we don't want to manipulate O_NONBLOCK flag, we might be able to surround kernel_read()/kernel_write() with set_thread_flag(TIF_SIGPENDING) and recalc_sigpending(). Since p9_read_work()/p9_write_work() works are processed by kernel threads which process global system_wq workqueue, signals could not be delivered from remote
rks are processed by kernel threads which process global system_wq workqueue, signals could not be delivered from remote threads when p9_mux_poll_stop() from p9_conn_destroy() from p9_fd_close() is called. Therefore, calling set_thread_flag(TIF_SIGPENDING)/recalc_sigpending() every time would be needed if we count on signals for making kernel_read()/kernel_write() non-blocking. [Dominique: add comment at Christian's suggestion] References: - https://git.kernel.org/stable/c/0b5e6bd72b8171364616841603a70e4ba9837063 - https://git.kernel.org/stable/c/9f8554615df668e4bf83294633ee9d232b28ce45 - https://git.kernel.org/stable/c/7abf40f06a76c0dff42eada10597917e9776fbd4 - https://git.kernel.org/stable
e9d232b28ce45 - https://git.kernel.org/stable/c/7abf40f06a76c0dff42eada10597917e9776fbd4 - https://git.kernel.org/stable/c/b1ad04da7fe4515e2ce2d5f2dcab3b5b6d45614b - https://git.kernel.org/stable/c/a8e2fc8f7b41fa9d9ca5f624f4e4d34fce5b40a9 - https://git.kernel.org/stable/c/0e07032b4b4724b8ad1003698cb81083c1818999 - https://git.kernel.org/stable/c/5af16182c5639349415118e9e9aecd8355f7a08b - https://git.kernel.org/stable/c/ef575281b21e9a34dfae544a187c6aac2ae424a9
CVE ID: CVE-2022-49768 State: PUBLISHED Published: 2025-05-01T14:09:06.864Z Last Updated: 2025-09-03T12:58:55.173Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: 9p: trans_fd/p9_conn_cancel: drop client lock earlier syzbot reported a double-lock here and we no longer need this lock after requests have been moved off to local list: just drop the lock earlier. References: - https://git.kernel.org/stable/c/82825dbf393f7c7979d462f9609a15bde8092b3f - https://git.kernel.org/stable/c/e3031280fe4eaf61a09e60823331f81f321be8e1 - https://git.kernel.org/stable/c/fec1406f5e7ab20b71f6d231792b0040e3300aaf - https://git.kernel.org/stable/c/967
21be8e1 - https://git.kernel.org/stable/c/fec1406f5e7ab20b71f6d231792b0040e3300aaf - https://git.kernel.org/stable/c/96760723aae1b45f733f702abb4333137143909f - https://git.kernel.org/stable/c/f14858bc77c567e089965962877ee726ffad0556 - https://git.kernel.org/stable/c/a4f1a01b2e81378fce9ca528d4d8a049e4b58fcd - https://git.kernel.org/stable/c/612c977f5d481f551d03d83d0aef588845c1300c - https://git.kernel.org/stable/c/52f1c45dde9136f964d63a77d19826c8a74e2c7f
CVE ID: CVE-2022-49769 State: PUBLISHED Published: 2025-05-01T14:09:07.526Z Last Updated: 2025-05-04T08:44:58.736Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: gfs2: Check sb_bsize_shift after reading superblock Fuzzers like to scribble over sb_bsize_shift but in reality it's very unlikely that this field would be corrupted on its own. Nevertheless it should be checked to avoid the possibility of messy mount errors due to bad calculations. It's always a fixed value based on the block size so we can just check that it's the expected value. Tested with: mkfs.gfs2 -O -p lock_nolock /dev/vdb for i in 0 -1 64 65 32 33; do gfs2_edi
k that it's the expected value. Tested with: mkfs.gfs2 -O -p lock_nolock /dev/vdb for i in 0 -1 64 65 32 33; do gfs2_edit -p sb field sb_bsize_shift $i /dev/vdb mount /dev/vdb /mnt/test && umount /mnt/test done Before this patch we get a withdraw after [ 76.413681] gfs2: fsid=loop0.0: fatal: invalid metadata block [ 76.413681] bh = 19 (type: exp=5, found=4) [ 76.413681] function = gfs2_meta_buffer, file = fs/gfs2/meta_io.c, line = 492 and with UBSAN configured we also get complaints like [ 76.373395] UBSAN: shift-out-of-bounds in fs/gfs2/ops_fstype.c:295:19 [ 76.373815] shift exponent 4294967287 is too large for 64-bit type 'long unsigned int' After the patch, these complaints don't appear,
ft exponent 4294967287 is too large for 64-bit type 'long unsigned int' After the patch, these complaints don't appear, mount fails immediately and we get an explanation in dmesg. References: - https://git.kernel.org/stable/c/d6b1e8ea6f3418c3b461ad5a35cdc93c996b2c87 - https://git.kernel.org/stable/c/1ad197097343568066a8ffaa27ee7d0ae6d9f476 - https://git.kernel.org/stable/c/15c83fa0fd659dd9fbdc940a560b61236e876a80 - https://git.kernel.org/stable/c/8b6534c9ae9dba5489703a19d8ba6c8f2cfa33c2 - https://git.kernel.org/stable/c/5fa30be7ba81191b0a0c7239a89befc0c94286d5 - https://git.kernel.org/stable/c/28275a7c84d21c55ab3282d897f284d8d527173c - https://git.kernel.org/stable/c/16670534c7cff1acd918a6a5
.kernel.org/stable/c/28275a7c84d21c55ab3282d897f284d8d527173c - https://git.kernel.org/stable/c/16670534c7cff1acd918a6a5ec751b14e7436b76 - https://git.kernel.org/stable/c/670f8ce56dd0632dc29a0322e188cc73ce3c6b92
CVE ID: CVE-2022-49770 State: PUBLISHED Published: 2025-05-01T14:09:08.173Z Last Updated: 2025-10-02T07:04:13.532Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ceph: avoid putting the realm twice when decoding snaps fails When decoding the snaps fails it maybe leaving the 'first_realm' and 'realm' pointing to the same snaprealm memory. And then it'll put it twice and could cause random use-after-free, BUG_ON, etc issues. References: - https://git.kernel.org/stable/c/274e4c79a3a2a24fba7cfe0e41113f1138785c37 - https://git.kernel.org/stable/c/cb7495fe957526555782ce0723f79ce92a6db22e - https://git.kernel.org/stable/c/044bc6d3c2c0
https://git.kernel.org/stable/c/cb7495fe957526555782ce0723f79ce92a6db22e - https://git.kernel.org/stable/c/044bc6d3c2c0e9090b0841e7b723875756534b45 - https://git.kernel.org/stable/c/2f6e2de3a5289004650118b61f138fe7c28e1905 - https://git.kernel.org/stable/c/fd879c83e87735ab8f00ef7755752cf0cbae24b2 - https://git.kernel.org/stable/c/51884d153f7ec85e18d607b2467820a90e0f4359
CVE ID: CVE-2022-49771 State: PUBLISHED Published: 2025-05-01T14:09:08.813Z Last Updated: 2025-05-04T08:45:01.509Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dm ioctl: fix misbehavior if list_versions races with module loading __list_versions will first estimate the required space using the "dm_target_iterate(list_version_get_needed, &needed)" call and then will fill the space using the "dm_target_iterate(list_version_get_info, &iter_info)" call. Each of these calls locks the targets using the "down_read(&_lock)" and "up_read(&_lock)" calls, however between the first and second "dm_target_iterate" there is no lock held and
_lock)" and "up_read(&_lock)" calls, however between the first and second "dm_target_iterate" there is no lock held and the target modules can be loaded at this point, so the second "dm_target_iterate" call may need more space than what was the first "dm_target_iterate" returned. The code tries to handle this overflow (see the beginning of list_version_get_info), however this handling is incorrect. The code sets "param->data_size = param->data_start + needed" and "iter_info.end = (char *)vers+len" - "needed" is the size returned by the first dm_target_iterate call; "len" is the size of the buffer allocated by userspace. "len" may be greater than "needed"; in this case, the code will write up
the size of the buffer allocated by userspace. "len" may be greater than "needed"; in this case, the code will write up to "len" bytes into the buffer, however param->data_size is set to "needed", so it may write data past the param->data_size value. The ioctl interface copies only up to param->data_size into userspace, thus part of the result will be truncated. Fix this bug by setting "iter_info.end = (char *)vers + needed;" - this guarantees that the second "dm_target_iterate" call will write only up to the "needed" buffer and it will exit with "DM_BUFFER_FULL_FLAG" if it overflows the "needed" space - in this case, userspace will allocate a larger buffer and retry. Note that there is als
t overflows the "needed" space - in this case, userspace will allocate a larger buffer and retry. Note that there is also a bug in list_version_get_needed - we need to add "strlen(tt->name) + 1" to the needed size, not "strlen(tt->name)". References: - https://git.kernel.org/stable/c/0c8d4112df329bf3dfbf27693f918c3b08676538 - https://git.kernel.org/stable/c/6a818db0d5aecf80d4ba9e10ac153f60adc629ca - https://git.kernel.org/stable/c/3a1c35d72dc0b34d1e746ed705790c0f630aa427 - https://git.kernel.org/stable/c/b545c0e1e4094d4de2bdfe9a3823f9154b0c0005 - https://git.kernel.org/stable/c/f59f5a269ca5e43c567aca7f1f52500a0186e9b7 - https://git.kernel.org/stable/c/6ffce7a92ef5c68f7e5d6f4d722c2f96280c064b
le/c/f59f5a269ca5e43c567aca7f1f52500a0186e9b7 - https://git.kernel.org/stable/c/6ffce7a92ef5c68f7e5d6f4d722c2f96280c064b - https://git.kernel.org/stable/c/5398b8e275bf81a2517b327d216c0f37ac9ac5ae - https://git.kernel.org/stable/c/4fe1ec995483737f3d2a14c3fe1d8fe634972979
CVE ID: CVE-2022-49772 State: PUBLISHED Published: 2025-05-01T14:09:09.697Z Last Updated: 2025-05-04T08:45:03.190Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Drop snd_BUG_ON() from snd_usbmidi_output_open() snd_usbmidi_output_open() has a check of the NULL port with snd_BUG_ON(). snd_BUG_ON() was used as this shouldn't have happened, but in reality, the NULL port may be seen when the device gives an invalid endpoint setup at the descriptor, hence the driver skips the allocation. That is, the check itself is valid and snd_BUG_ON() should be dropped from there. Otherwise it's confusing as if it were a real bu
he check itself is valid and snd_BUG_ON() should be dropped from there. Otherwise it's confusing as if it were a real bug, as recently syzbot stumbled on it. References: - https://git.kernel.org/stable/c/872c9314769e89d8bda74ff3ac584756a45ee752 - https://git.kernel.org/stable/c/368a01e5064c13946d032ab1d65ba95020a39cc5 - https://git.kernel.org/stable/c/c43991065f36f7628cd124e037b8750c4617a7a7 - https://git.kernel.org/stable/c/e7dc436aea80308a9268e6d2d85f910ff107de9b - https://git.kernel.org/stable/c/a80369c8ca50bc885d14386087a834659ec54a54 - https://git.kernel.org/stable/c/02b94885b2fdf1808b1874e009bfb90753f8f4db - https://git.kernel.org/stable/c/00f5f1bbf815a39e9eecb468d12ca55d3360eb10 - htt
2b94885b2fdf1808b1874e009bfb90753f8f4db - https://git.kernel.org/stable/c/00f5f1bbf815a39e9eecb468d12ca55d3360eb10 - https://git.kernel.org/stable/c/ad72c3c3f6eb81d2cb189ec71e888316adada5df
CVE ID: CVE-2022-49773 State: PUBLISHED Published: 2025-05-01T14:09:10.511Z Last Updated: 2025-06-19T12:56:24.227Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix optc2_configure warning on dcn314 [Why] dcn314 uses optc2_configure_crc() that wraps optc1_configure_crc() + set additional registers not applicable to dcn314. It's not critical but when used leads to warning like: WARNING: drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c Call Trace: <TASK> generic_reg_set_ex+0x6d/0xe0 [amdgpu] optc2_configure_crc+0x60/0x80 [amdgpu] dc_stream_configure_crc+0x129/0x150 [amdgpu] amdgpu_dm_crtc_configure_crc_sourc
] optc2_configure_crc+0x60/0x80 [amdgpu] dc_stream_configure_crc+0x129/0x150 [amdgpu] amdgpu_dm_crtc_configure_crc_source+0x5d/0xe0 [amdgpu] [How] Use optc1_configure_crc() directly References: - https://git.kernel.org/stable/c/f67ef5aa88e3db0a13ae3befab2ddf14ac00a91c - https://git.kernel.org/stable/c/e7e4f77c991c9abf90924929a9d55f90b0bb78de
CVE ID: CVE-2022-49774 State: PUBLISHED Published: 2025-05-01T14:09:11.188Z Last Updated: 2025-05-04T08:45:05.378Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: KVM: x86/xen: Fix eventfd error handling in kvm_xen_eventfd_assign() Should not call eventfd_ctx_put() in case of error. [Introduce new goto target instead. - Paolo] References: - https://git.kernel.org/stable/c/d76f46f47dfde220712d1420ee5dbc546c8fc674 - https://git.kernel.org/stable/c/7353633814f6e5b4899fb9ee1483709d6bb0e1cd
CVE ID: CVE-2022-49775 State: PUBLISHED Published: 2025-05-01T14:09:11.827Z Last Updated: 2025-05-04T08:45:06.546Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tcp: cdg: allow tcp_cdg_release() to be called multiple times Apparently, mptcp is able to call tcp_disconnect() on an already disconnected flow. This is generally fine, unless current congestion control is CDG, because it might trigger a double-free [1] Instead of fixing MPTCP, and future bugs, we can make tcp_disconnect() more resilient. [1] BUG: KASAN: double-free in slab_free mm/slub.c:3539 [inline] BUG: KASAN: double-free in kfree+0xe2/0x580 mm/slub.c:4567 CPU: 0
SAN: double-free in slab_free mm/slub.c:3539 [inline] BUG: KASAN: double-free in kfree+0xe2/0x580 mm/slub.c:4567 CPU: 0 PID: 3645 Comm: kworker/0:7 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Workqueue: events mptcp_worker Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x719 mm/kasan/report.c:433 kasan_report_invalid_free+0x81/0x190 mm/kasan/report.c:462 ____kasan_slab_free+0x18b/0x1c0 mm/kasan/common.c:356 kasan_slab_free include/linux/kasan.h:200 [inline]
an/report.c:462 ____kasan_slab_free+0x18b/0x1c0 mm/kasan/common.c:356 kasan_slab_free include/linux/kasan.h:200 [inline] slab_free_hook mm/slub.c:1759 [inline] slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1785 slab_free mm/slub.c:3539 [inline] kfree+0xe2/0x580 mm/slub.c:4567 tcp_disconnect+0x980/0x1e20 net/ipv4/tcp.c:3145 __mptcp_close_ssk+0x5ca/0x7e0 net/mptcp/protocol.c:2327 mptcp_do_fastclose net/mptcp/protocol.c:2592 [inline] mptcp_worker+0x78c/0xff0 net/mptcp/protocol.c:2627 process_one_work+0x991/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> Allocat
ue.c:2436 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> Allocated by task 3671: kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:45 [inline] set_alloc_info mm/kasan/common.c:437 [inline] ____kasan_kmalloc mm/kasan/common.c:516 [inline] ____kasan_kmalloc mm/kasan/common.c:475 [inline] __kasan_kmalloc+0xa9/0xd0 mm/kasan/common.c:525 kmalloc_array include/linux/slab.h:640 [inline] kcalloc include/linux/slab.h:671 [inline] tcp_cdg_init+0x10d/0x170 net/ipv4/tcp_cdg.c:380 tcp_init_congestion_control+0xab/0x550 net/ipv4/tcp_cong.c:193 tcp_reinit_congestion_control net/ipv4/tcp_cong.c:217 [inline] tcp_set_conge
_control+0xab/0x550 net/ipv4/tcp_cong.c:193 tcp_reinit_congestion_control net/ipv4/tcp_cong.c:217 [inline] tcp_set_congestion_control+0x96c/0xaa0 net/ipv4/tcp_cong.c:391 do_tcp_setsockopt+0x505/0x2320 net/ipv4/tcp.c:3513 tcp_setsockopt+0xd4/0x100 net/ipv4/tcp.c:3801 mptcp_setsockopt+0x35f/0x2570 net/mptcp/sockopt.c:844 __sys_setsockopt+0x2d6/0x690 net/socket.c:2252 __do_sys_setsockopt net/socket.c:2263 [inline] __se_sys_setsockopt net/socket.c:2260 [inline] __x64_sys_setsockopt+0xba/0x150 net/socket.c:2260 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Freed by task 16: kasan_save_stack+0x1e/0x40
5/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Freed by task 16: kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track+0x21/0x30 mm/kasan/common.c:45 kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370 ____kasan_slab_free mm/kasan/common.c:367 [inline] ____kasan_slab_free+0x166/0x1c0 mm/kasan/common.c:329 kasan_slab_free include/linux/kasan.h:200 [inline] slab_free_hook mm/slub.c:1759 [inline] slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1785 slab_free mm/slub.c:3539 [inline] kfree+0xe2/0x580 mm/slub.c:4567 tcp_cleanup_congestion_control+0x70/0x120 net/ipv4/tcp_cong.c:226 tcp_v4_destroy_sock+0xdd/0x750 net/ipv4/tcp_ipv4.c:2254 tcp_v6_destroy_sock+0x11/0