Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, arm64: Clear prog-&gt;jited_len along prog-&gt;jited<br /> <br /> syzbot reported an illegal copy_to_user() attempt<br /> from bpf_prog_get_info_by_fd() [1]<br /> <br /> There was no repro yet on this bug, but I think<br /> that commit 0aef499f3172 ("mm/usercopy: Detect vmalloc overruns")<br /> is exposing a prior bug in bpf arm64.<br /> <br /> bpf_prog_get_info_by_fd() looks at prog-&gt;jited_len<br /> to determine if the JIT image can be copied out to user space.<br /> <br /> My theory is that syzbot managed to get a prog where prog-&gt;jited_len<br /> has been set to 43, while prog-&gt;bpf_func has ben cleared.<br /> <br /> It is not clear why copy_to_user(uinsns, NULL, ulen) is triggering<br /> this particular warning.<br /> <br /> I thought find_vma_area(NULL) would not find a vm_struct.<br /> As we do not hold vmap_area_lock spinlock, it might be possible<br /> that the found vm_struct was garbage.<br /> <br /> [1]<br /> usercopy: Kernel memory exposure attempt detected from vmalloc (offset 792633534417210172, size 43)!<br /> kernel BUG at mm/usercopy.c:101!<br /> Internal error: Oops - BUG: 0 [#1] PREEMPT SMP<br /> Modules linked in:<br /> CPU: 0 PID: 25002 Comm: syz-executor.1 Not tainted 5.18.0-syzkaller-10139-g8291eaafed36 #0<br /> Hardware name: linux,dummy-virt (DT)<br /> pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : usercopy_abort+0x90/0x94 mm/usercopy.c:101<br /> lr : usercopy_abort+0x90/0x94 mm/usercopy.c:89<br /> sp : ffff80000b773a20<br /> x29: ffff80000b773a30 x28: faff80000b745000 x27: ffff80000b773b48<br /> x26: 0000000000000000 x25: 000000000000002b x24: 0000000000000000<br /> x23: 00000000000000e0 x22: ffff80000b75db67 x21: 0000000000000001<br /> x20: 000000000000002b x19: ffff80000b75db3c x18: 00000000fffffffd<br /> x17: 2820636f6c6c616d x16: 76206d6f72662064 x15: 6574636574656420<br /> x14: 74706d6574746120 x13: 2129333420657a69 x12: 73202c3237313031<br /> x11: 3237313434333533 x10: 3336323937207465 x9 : 657275736f707865<br /> x8 : ffff80000a30c550 x7 : ffff80000b773830 x6 : ffff80000b773830<br /> x5 : 0000000000000000 x4 : ffff00007fbbaa10 x3 : 0000000000000000<br /> x2 : 0000000000000000 x1 : f7ff000028fc0000 x0 : 0000000000000064<br /> Call trace:<br /> usercopy_abort+0x90/0x94 mm/usercopy.c:89<br /> check_heap_object mm/usercopy.c:186 [inline]<br /> __check_object_size mm/usercopy.c:252 [inline]<br /> __check_object_size+0x198/0x36c mm/usercopy.c:214<br /> check_object_size include/linux/thread_info.h:199 [inline]<br /> check_copy_size include/linux/thread_info.h:235 [inline]<br /> copy_to_user include/linux/uaccess.h:159 [inline]<br /> bpf_prog_get_info_by_fd.isra.0+0xf14/0xfdc kernel/bpf/syscall.c:3993<br /> bpf_obj_get_info_by_fd+0x12c/0x510 kernel/bpf/syscall.c:4253<br /> __sys_bpf+0x900/0x2150 kernel/bpf/syscall.c:4956<br /> __do_sys_bpf kernel/bpf/syscall.c:5021 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:5019 [inline]<br /> __arm64_sys_bpf+0x28/0x40 kernel/bpf/syscall.c:5019<br /> __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]<br /> invoke_syscall+0x48/0x114 arch/arm64/kernel/syscall.c:52<br /> el0_svc_common.constprop.0+0x44/0xec arch/arm64/kernel/syscall.c:142<br /> do_el0_svc+0xa0/0xc0 arch/arm64/kernel/syscall.c:206<br /> el0_svc+0x44/0xb0 arch/arm64/kernel/entry-common.c:624<br /> el0t_64_sync_handler+0x1ac/0x1b0 arch/arm64/kernel/entry-common.c:642<br /> el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:581<br /> Code: aa0003e3 d00038c0 91248000 97fff65f (d4210000)

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix sleeping function called from invalid context on RT kernel<br /> <br /> When setting bootparams="trace_event=initcall:initcall_start tp_printk=1" in the<br /> cmdline, the output_printk() was called, and the spin_lock_irqsave() was called in the<br /> atomic and irq disable interrupt context suitation. On the PREEMPT_RT kernel,<br /> these locks are replaced with sleepable rt-spinlock, so the stack calltrace will<br /> be triggered.<br /> Fix it by raw_spin_lock_irqsave when PREEMPT_RT and "trace_event=initcall:initcall_start<br /> tp_printk=1" enabled.<br /> <br /> BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0<br /> preempt_count: 2, expected: 0<br /> RCU nest depth: 0, expected: 0<br /> Preemption disabled at:<br /> [] try_to_wake_up+0x7e/0xba0<br /> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.1-rt17+ #19 34c5812404187a875f32bee7977f7367f9679ea7<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x60/0x8c<br /> dump_stack+0x10/0x12<br /> __might_resched.cold+0x11d/0x155<br /> rt_spin_lock+0x40/0x70<br /> trace_event_buffer_commit+0x2fa/0x4c0<br /> ? map_vsyscall+0x93/0x93<br /> trace_event_raw_event_initcall_start+0xbe/0x110<br /> ? perf_trace_initcall_finish+0x210/0x210<br /> ? probe_sched_wakeup+0x34/0x40<br /> ? ttwu_do_wakeup+0xda/0x310<br /> ? trace_hardirqs_on+0x35/0x170<br /> ? map_vsyscall+0x93/0x93<br /> do_one_initcall+0x217/0x3c0<br /> ? trace_event_raw_event_initcall_level+0x170/0x170<br /> ? push_cpu_stop+0x400/0x400<br /> ? cblist_init_generic+0x241/0x290<br /> kernel_init_freeable+0x1ac/0x347<br /> ? _raw_spin_unlock_irq+0x65/0x80<br /> ? rest_init+0xf0/0xf0<br /> kernel_init+0x1e/0x150<br /> ret_from_fork+0x22/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/arm-smmu: fix possible null-ptr-deref in arm_smmu_device_probe()<br /> <br /> It will cause null-ptr-deref when using &amp;#39;res&amp;#39;, if platform_get_resource()<br /> returns NULL, so move using &amp;#39;res&amp;#39; after devm_ioremap_resource() that<br /> will check it to avoid null-ptr-deref.<br /> And use devm_platform_get_and_ioremap_resource() to simplify code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mips: cpc: Fix refcount leak in mips_cpc_default_phys_base<br /> <br /> Add the missing of_node_put() to release the refcount incremented<br /> by of_find_compatible_node().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: add accessors to read/set tp-&gt;snd_cwnd<br /> <br /> We had various bugs over the years with code<br /> breaking the assumption that tp-&gt;snd_cwnd is greater<br /> than zero.<br /> <br /> Lately, syzbot reported the WARN_ON_ONCE(!tp-&gt;prior_cwnd) added<br /> in commit 8b8a321ff72c ("tcp: fix zero cwnd in tcp_cwnd_reduction")<br /> can trigger, and without a repro we would have to spend<br /> considerable time finding the bug.<br /> <br /> Instead of complaining too late, we want to catch where<br /> and when tp-&gt;snd_cwnd is set to an illegal value.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rtl818x: Prevent using not initialized queues<br /> <br /> Using not existing queues can panic the kernel with rtl8180/rtl8185 cards.<br /> Ignore the skb priority for those cards, they only have one tx queue. Pierre<br /> Asselin (pa@panix.com) reported the kernel crash in the Gentoo forum:<br /> <br /> https://forums.gentoo.org/viewtopic-t-1147832-postdays-0-postorder-asc-start-25.html<br /> <br /> He also confirmed that this patch fixes the issue. In summary this happened:<br /> <br /> After updating wpa_supplicant from 2.9 to 2.10 the kernel crashed with a<br /> "divide error: 0000" when connecting to an AP. Control port tx now tries to<br /> use IEEE80211_AC_VO for the priority, which wpa_supplicants starts to use in<br /> 2.10.<br /> <br /> Since only the rtl8187se part of the driver supports QoS, the priority<br /> of the skb is set to IEEE80211_AC_BE (2) by mac80211 for rtl8180/rtl8185<br /> cards.<br /> <br /> rtl8180 is then unconditionally reading out the priority and finally crashes on<br /> drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c line 544 without this<br /> patch:<br /> idx = (ring-&gt;idx + skb_queue_len(&amp;ring-&gt;queue)) % ring-&gt;entries<br /> <br /> "ring-&gt;entries" is zero for rtl8180/rtl8185 cards, tx_ring[2] never got<br /> initialized.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bcache: avoid journal no-space deadlock by reserving 1 journal bucket<br /> <br /> The journal no-space deadlock was reported time to time. Such deadlock<br /> can happen in the following situation.<br /> <br /> When all journal buckets are fully filled by active jset with heavy<br /> write I/O load, the cache set registration (after a reboot) will load<br /> all active jsets and inserting them into the btree again (which is<br /> called journal replay). If a journaled bkey is inserted into a btree<br /> node and results btree node split, new journal request might be<br /> triggered. For example, the btree grows one more level after the node<br /> split, then the root node record in cache device super block will be<br /> upgrade by bch_journal_meta() from bch_btree_set_root(). But there is no<br /> space in journal buckets, the journal replay has to wait for new journal<br /> bucket to be reclaimed after at least one journal bucket replayed. This<br /> is one example that how the journal no-space deadlock happens.<br /> <br /> The solution to avoid the deadlock is to reserve 1 journal bucket in<br /> run time, and only permit the reserved journal bucket to be used during<br /> cache set registration procedure for things like journal replay. Then<br /> the journal space will never be fully filled, there is no chance for<br /> journal no-space deadlock to happen anymore.<br /> <br /> This patch adds a new member "bool do_reserve" in struct journal, it is<br /> inititalized to 0 (false) when struct journal is allocated, and set to<br /> 1 (true) by bch_journal_space_reserve() when all initialization done in<br /> run_cache_set(). In the run time when journal_reclaim() tries to<br /> allocate a new journal bucket, free_journal_buckets() is called to check<br /> whether there are enough free journal buckets to use. If there is only<br /> 1 free journal bucket and journal-&gt;do_reserve is 1 (true), the last<br /> bucket is reserved and free_journal_buckets() will return 0 to indicate<br /> no free journal bucket. Then journal_reclaim() will give up, and try<br /> next time to see whetheer there is free journal bucket to allocate. By<br /> this method, there is always 1 jouranl bucket reserved in run time.<br /> <br /> During the cache set registration, journal-&gt;do_reserve is 0 (false), so<br /> the reserved journal bucket can be used to avoid the no-space deadlock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mt76: fix use-after-free by removing a non-RCU wcid pointer<br /> <br /> Fixes an issue caught by KASAN about use-after-free in mt76_txq_schedule<br /> by protecting mtxq-&gt;wcid with rcu_lock between mt76_txq_schedule and<br /> sta_info_[alloc, free].<br /> <br /> [18853.876689] ==================================================================<br /> [18853.876751] BUG: KASAN: use-after-free in mt76_txq_schedule+0x204/0xaf8 [mt76]<br /> [18853.876773] Read of size 8 at addr ffffffaf989a2138 by task mt76-tx phy0/883<br /> [18853.876786]<br /> [18853.876810] CPU: 5 PID: 883 Comm: mt76-tx phy0 Not tainted 5.10.100-fix-510-56778d365941-kasan #5 0b01fbbcf41a530f52043508fec2e31a4215<br /> <br /> [18853.876840] Call trace:<br /> [18853.876861] dump_backtrace+0x0/0x3ec<br /> [18853.876878] show_stack+0x20/0x2c<br /> [18853.876899] dump_stack+0x11c/0x1ac<br /> [18853.876918] print_address_description+0x74/0x514<br /> [18853.876934] kasan_report+0x134/0x174<br /> [18853.876948] __asan_report_load8_noabort+0x44/0x50<br /> [18853.876976] mt76_txq_schedule+0x204/0xaf8 [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2]<br /> [18853.877002] mt76_txq_schedule_all+0x2c/0x48 [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2]<br /> [18853.877030] mt7921_tx_worker+0xa0/0x1cc [mt7921_common f0875ebac9d7b4754e1010549e7db50fbd90a047]<br /> [18853.877054] __mt76_worker_fn+0x190/0x22c [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2]<br /> [18853.877071] kthread+0x2f8/0x3b8<br /> [18853.877087] ret_from_fork+0x10/0x30<br /> [18853.877098]<br /> [18853.877112] Allocated by task 941:<br /> [18853.877131] kasan_save_stack+0x38/0x68<br /> [18853.877147] __kasan_kmalloc+0xd4/0xfc<br /> [18853.877163] kasan_kmalloc+0x10/0x1c<br /> [18853.877177] __kmalloc+0x264/0x3c4<br /> [18853.877294] sta_info_alloc+0x460/0xf88 [mac80211]<br /> [18853.877410] ieee80211_prep_connection+0x204/0x1ee0 [mac80211]<br /> [18853.877523] ieee80211_mgd_auth+0x6c4/0xa4c [mac80211]<br /> [18853.877635] ieee80211_auth+0x20/0x2c [mac80211]<br /> [18853.877733] rdev_auth+0x7c/0x438 [cfg80211]<br /> [18853.877826] cfg80211_mlme_auth+0x26c/0x390 [cfg80211]<br /> [18853.877919] nl80211_authenticate+0x6d4/0x904 [cfg80211]<br /> [18853.877938] genl_rcv_msg+0x748/0x93c<br /> [18853.877954] netlink_rcv_skb+0x160/0x2a8<br /> [18853.877969] genl_rcv+0x3c/0x54<br /> [18853.877985] netlink_unicast_kernel+0x104/0x1ec<br /> [18853.877999] netlink_unicast+0x178/0x268<br /> [18853.878015] netlink_sendmsg+0x3cc/0x5f0<br /> [18853.878030] sock_sendmsg+0xb4/0xd8<br /> [18853.878043] ____sys_sendmsg+0x2f8/0x53c<br /> [18853.878058] ___sys_sendmsg+0xe8/0x150<br /> [18853.878071] __sys_sendmsg+0xc4/0x1f4<br /> [18853.878087] __arm64_compat_sys_sendmsg+0x88/0x9c<br /> [18853.878101] el0_svc_common+0x1b4/0x390<br /> [18853.878115] do_el0_svc_compat+0x8c/0xdc<br /> [18853.878131] el0_svc_compat+0x10/0x1c<br /> [18853.878146] el0_sync_compat_handler+0xa8/0xcc<br /> [18853.878161] el0_sync_compat+0x188/0x1c0<br /> [18853.878171]<br /> [18853.878183] Freed by task 10927:<br /> [18853.878200] kasan_save_stack+0x38/0x68<br /> [18853.878215] kasan_set_track+0x28/0x3c<br /> [18853.878228] kasan_set_free_info+0x24/0x48<br /> [18853.878244] __kasan_slab_free+0x11c/0x154<br /> [18853.878259] kasan_slab_free+0x14/0x24<br /> [18853.878273] slab_free_freelist_hook+0xac/0x1b0<br /> [18853.878287] kfree+0x104/0x390<br /> [18853.878402] sta_info_free+0x198/0x210 [mac80211]<br /> [18853.878515] __sta_info_destroy_part2+0x230/0x2d4 [mac80211]<br /> [18853.878628] __sta_info_flush+0x300/0x37c [mac80211]<br /> [18853.878740] ieee80211_set_disassoc+0x2cc/0xa7c [mac80211]<br /> [18853.878851] ieee80211_mgd_deauth+0x4a4/0x10a0 [mac80211]<br /> [18853.878962] ieee80211_deauth+0x20/0x2c [mac80211]<br /> [18853.879057] rdev_deauth+0x7c/0x438 [cfg80211]<br /> [18853.879150] cfg80211_mlme_deauth+0x274/0x414 [cfg80211]<br /> [18853.879243] cfg80211_mlme_down+0xe4/0x118 [cfg80211]<br /> [18853.879335] cfg80211_disconnect+0x218/0x2d8 [cfg80211]<br /> [18853.879427] __cfg80211_leave+0x17c/0x240 [cfg80211]<br /> [18853.879519] cfg80211_leave+0x3c/0x58 [cfg80211]<br /> [18853.879611] wiphy_suspend+0xdc/0x200 [cfg80211]<br /> [18853.879628] dpm_run_callback+0x58/0x408<br /> [18853.879642] __device_suspend+0x4cc/0x864<br /> [18853.879658] async_suspend+0x34/0xf4<br /> [18<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vduse: Fix NULL pointer dereference on sysfs access<br /> <br /> The control device has no drvdata. So we will get a<br /> NULL pointer dereference when accessing control<br /> device&amp;#39;s msg_timeout attribute via sysfs:<br /> <br /> [ 132.841881][ T3644] BUG: kernel NULL pointer dereference, address: 00000000000000f8<br /> [ 132.850619][ T3644] RIP: 0010:msg_timeout_show (drivers/vdpa/vdpa_user/vduse_dev.c:1271)<br /> [ 132.869447][ T3644] dev_attr_show (drivers/base/core.c:2094)<br /> [ 132.870215][ T3644] sysfs_kf_seq_show (fs/sysfs/file.c:59)<br /> [ 132.871164][ T3644] ? device_remove_bin_file (drivers/base/core.c:2088)<br /> [ 132.872082][ T3644] kernfs_seq_show (fs/kernfs/file.c:164)<br /> [ 132.872838][ T3644] seq_read_iter (fs/seq_file.c:230)<br /> [ 132.873578][ T3644] ? __vmalloc_area_node (mm/vmalloc.c:3041)<br /> [ 132.874532][ T3644] kernfs_fop_read_iter (fs/kernfs/file.c:238)<br /> [ 132.875513][ T3644] __kernel_read (fs/read_write.c:440 (discriminator 1))<br /> [ 132.876319][ T3644] kernel_read (fs/read_write.c:459)<br /> [ 132.877129][ T3644] kernel_read_file (fs/kernel_read_file.c:94)<br /> [ 132.877978][ T3644] kernel_read_file_from_fd (include/linux/file.h:45 fs/kernel_read_file.c:186)<br /> [ 132.879019][ T3644] __do_sys_finit_module (kernel/module.c:4207)<br /> [ 132.879930][ T3644] __ia32_sys_finit_module (kernel/module.c:4189)<br /> [ 132.880930][ T3644] do_int80_syscall_32 (arch/x86/entry/common.c:112 arch/x86/entry/common.c:132)<br /> [ 132.881847][ T3644] entry_INT80_compat (arch/x86/entry/entry_64_compat.S:419)<br /> <br /> To fix it, don&amp;#39;t create the unneeded attribute for<br /> control device anymore.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: fix tcp_mtup_probe_success vs wrong snd_cwnd<br /> <br /> syzbot got a new report [1] finally pointing to a very old bug,<br /> added in initial support for MTU probing.<br /> <br /> tcp_mtu_probe() has checks about starting an MTU probe if<br /> tcp_snd_cwnd(tp) &gt;= 11.<br /> <br /> But nothing prevents tcp_snd_cwnd(tp) to be reduced later<br /> and before the MTU probe succeeds.<br /> <br /> This bug would lead to potential zero-divides.<br /> <br /> Debugging added in commit 40570375356c ("tcp: add accessors<br /> to read/set tp-&gt;snd_cwnd") has paid off :)<br /> <br /> While we are at it, address potential overflows in this code.<br /> <br /> [1]<br /> WARNING: CPU: 1 PID: 14132 at include/net/tcp.h:1219 tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712<br /> Modules linked in:<br /> CPU: 1 PID: 14132 Comm: syz-executor.2 Not tainted 5.18.0-syzkaller-07857-gbabf0bb978e3 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> RIP: 0010:tcp_snd_cwnd_set include/net/tcp.h:1219 [inline]<br /> RIP: 0010:tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712<br /> Code: 74 08 48 89 ef e8 da 80 17 f9 48 8b 45 00 65 48 ff 80 80 03 00 00 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 aa b0 c5 f8 0b e9 16 fe ff ff 48 8b 4c 24 08 80 e1 07 38 c1 0f 8c c7 fc ff<br /> RSP: 0018:ffffc900079e70f8 EFLAGS: 00010287<br /> RAX: ffffffff88c0f7f6 RBX: ffff8880756e7a80 RCX: 0000000000040000<br /> RDX: ffffc9000c6c4000 RSI: 0000000000031f9e RDI: 0000000000031f9f<br /> RBP: 0000000000000000 R08: ffffffff88c0f606 R09: ffffc900079e7520<br /> R10: ffffed101011226d R11: 1ffff1101011226c R12: 1ffff1100eadcf50<br /> R13: ffff8880756e72c0 R14: 1ffff1100eadcf89 R15: dffffc0000000000<br /> FS: 00007f643236e700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f1ab3f1e2a0 CR3: 0000000064fe7000 CR4: 00000000003506e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> tcp_clean_rtx_queue+0x223a/0x2da0 net/ipv4/tcp_input.c:3356<br /> tcp_ack+0x1962/0x3c90 net/ipv4/tcp_input.c:3861<br /> tcp_rcv_established+0x7c8/0x1ac0 net/ipv4/tcp_input.c:5973<br /> tcp_v6_do_rcv+0x57b/0x1210 net/ipv6/tcp_ipv6.c:1476<br /> sk_backlog_rcv include/net/sock.h:1061 [inline]<br /> __release_sock+0x1d8/0x4c0 net/core/sock.c:2849<br /> release_sock+0x5d/0x1c0 net/core/sock.c:3404<br /> sk_stream_wait_memory+0x700/0xdc0 net/core/stream.c:145<br /> tcp_sendmsg_locked+0x111d/0x3fc0 net/ipv4/tcp.c:1410<br /> tcp_sendmsg+0x2c/0x40 net/ipv4/tcp.c:1448<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg net/socket.c:734 [inline]<br /> __sys_sendto+0x439/0x5c0 net/socket.c:2119<br /> __do_sys_sendto net/socket.c:2131 [inline]<br /> __se_sys_sendto net/socket.c:2127 [inline]<br /> __x64_sys_sendto+0xda/0xf0 net/socket.c:2127<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> RIP: 0033:0x7f6431289109<br /> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f643236e168 EFLAGS: 00000246 ORIG_RAX: 000000000000002c<br /> RAX: ffffffffffffffda RBX: 00007f643139c100 RCX: 00007f6431289109<br /> RDX: 00000000d0d0c2ac RSI: 0000000020000080 RDI: 000000000000000a<br /> RBP: 00007f64312e308d R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007fff372533af R14: 00007f643236e300 R15: 0000000000022000

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling<br /> <br /> Error paths do not free previously allocated memory. Add devm_kfree() to<br /> those failure paths.