--- /dev/null
+From fd1894224407c484f652ad456e1ce423e89bb3eb Mon Sep 17 00:00:00 2001
+From: Zhengchao Shao <shaozhengchao@huawei.com>
+Date: Fri, 15 Jul 2022 19:55:59 +0800
+Subject: bpf: Don't redirect packets with invalid pkt_len
+
+From: Zhengchao Shao <shaozhengchao@huawei.com>
+
+commit fd1894224407c484f652ad456e1ce423e89bb3eb upstream.
+
+Syzbot found an issue [1]: fq_codel_drop() try to drop a flow whitout any
+skbs, that is, the flow->head is null.
+The root cause, as the [2] says, is because that bpf_prog_test_run_skb()
+run a bpf prog which redirects empty skbs.
+So we should determine whether the length of the packet modified by bpf
+prog or others like bpf_prog_test is valid before forwarding it directly.
+
+LINK: [1] https://syzkaller.appspot.com/bug?id=0b84da80c2917757915afa89f7738a9d16ec96c5
+LINK: [2] https://www.spinics.net/lists/netdev/msg777503.html
+
+Reported-by: syzbot+7a12909485b94426aceb@syzkaller.appspotmail.com
+Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
+Reviewed-by: Stanislav Fomichev <sdf@google.com>
+Link: https://lore.kernel.org/r/20220715115559.139691-1-shaozhengchao@huawei.com
+Signed-off-by: Alexei Starovoitov <ast@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/skbuff.h | 8 ++++++++
+ net/bpf/test_run.c | 3 +++
+ net/core/dev.c | 1 +
+ 3 files changed, 12 insertions(+)
+
+--- a/include/linux/skbuff.h
++++ b/include/linux/skbuff.h
+@@ -2624,6 +2624,14 @@ static inline void skb_set_tail_pointer(
+
+ #endif /* NET_SKBUFF_DATA_USES_OFFSET */
+
++static inline void skb_assert_len(struct sk_buff *skb)
++{
++#ifdef CONFIG_DEBUG_NET
++ if (WARN_ONCE(!skb->len, "%s\n", __func__))
++ DO_ONCE_LITE(skb_dump, KERN_ERR, skb, false);
++#endif /* CONFIG_DEBUG_NET */
++}
++
+ /*
+ * Add data to an sk_buff
+ */
+--- a/net/bpf/test_run.c
++++ b/net/bpf/test_run.c
+@@ -955,6 +955,9 @@ static int convert___skb_to_skb(struct s
+ {
+ struct qdisc_skb_cb *cb = (struct qdisc_skb_cb *)skb->cb;
+
++ if (!skb->len)
++ return -EINVAL;
++
+ if (!__skb)
+ return 0;
+
+--- a/net/core/dev.c
++++ b/net/core/dev.c
+@@ -4168,6 +4168,7 @@ int __dev_queue_xmit(struct sk_buff *skb
+ bool again = false;
+
+ skb_reset_mac_header(skb);
++ skb_assert_len(skb);
+
+ if (unlikely(skb_shinfo(skb)->tx_flags & SKBTX_SCHED_TSTAMP))
+ __skb_tstamp_tx(skb, NULL, NULL, skb->sk, SCM_TSTAMP_SCHED);
--- /dev/null
+From 19f953e7435644b81332dd632ba1b2d80b1e37af Mon Sep 17 00:00:00 2001
+From: Letu Ren <fantasquex@gmail.com>
+Date: Thu, 18 Aug 2022 18:44:24 +0800
+Subject: fbdev: fb_pm2fb: Avoid potential divide by zero error
+
+From: Letu Ren <fantasquex@gmail.com>
+
+commit 19f953e7435644b81332dd632ba1b2d80b1e37af upstream.
+
+In `do_fb_ioctl()` of fbmem.c, if cmd is FBIOPUT_VSCREENINFO, var will be
+copied from user, then go through `fb_set_var()` and
+`info->fbops->fb_check_var()` which could may be `pm2fb_check_var()`.
+Along the path, `var->pixclock` won't be modified. This function checks
+whether reciprocal of `var->pixclock` is too high. If `var->pixclock` is
+zero, there will be a divide by zero error. So, it is necessary to check
+whether denominator is zero to avoid crash. As this bug is found by
+Syzkaller, logs are listed below.
+
+divide error in pm2fb_check_var
+Call Trace:
+ <TASK>
+ fb_set_var+0x367/0xeb0 drivers/video/fbdev/core/fbmem.c:1015
+ do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110
+ fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189
+
+Reported-by: Zheyu Ma <zheyuma97@gmail.com>
+Signed-off-by: Letu Ren <fantasquex@gmail.com>
+Signed-off-by: Helge Deller <deller@gmx.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/video/fbdev/pm2fb.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/video/fbdev/pm2fb.c
++++ b/drivers/video/fbdev/pm2fb.c
+@@ -617,6 +617,11 @@ static int pm2fb_check_var(struct fb_var
+ return -EINVAL;
+ }
+
++ if (!var->pixclock) {
++ DPRINTK("pixclock is zero\n");
++ return -EINVAL;
++ }
++
+ if (PICOS2KHZ(var->pixclock) > PM2_MAX_PIXCLOCK) {
+ DPRINTK("pixclock too high (%ldKHz)\n",
+ PICOS2KHZ(var->pixclock));
--- /dev/null
+From c3b0f72e805f0801f05fa2aa52011c4bfc694c44 Mon Sep 17 00:00:00 2001
+From: Yang Jihong <yangjihong1@huawei.com>
+Date: Thu, 18 Aug 2022 11:26:59 +0800
+Subject: ftrace: Fix NULL pointer dereference in is_ftrace_trampoline when ftrace is dead
+
+From: Yang Jihong <yangjihong1@huawei.com>
+
+commit c3b0f72e805f0801f05fa2aa52011c4bfc694c44 upstream.
+
+ftrace_startup does not remove ops from ftrace_ops_list when
+ftrace_startup_enable fails:
+
+register_ftrace_function
+ ftrace_startup
+ __register_ftrace_function
+ ...
+ add_ftrace_ops(&ftrace_ops_list, ops)
+ ...
+ ...
+ ftrace_startup_enable // if ftrace failed to modify, ftrace_disabled is set to 1
+ ...
+ return 0 // ops is in the ftrace_ops_list.
+
+When ftrace_disabled = 1, unregister_ftrace_function simply returns without doing anything:
+unregister_ftrace_function
+ ftrace_shutdown
+ if (unlikely(ftrace_disabled))
+ return -ENODEV; // return here, __unregister_ftrace_function is not executed,
+ // as a result, ops is still in the ftrace_ops_list
+ __unregister_ftrace_function
+ ...
+
+If ops is dynamically allocated, it will be free later, in this case,
+is_ftrace_trampoline accesses NULL pointer:
+
+is_ftrace_trampoline
+ ftrace_ops_trampoline
+ do_for_each_ftrace_op(op, ftrace_ops_list) // OOPS! op may be NULL!
+
+Syzkaller reports as follows:
+[ 1203.506103] BUG: kernel NULL pointer dereference, address: 000000000000010b
+[ 1203.508039] #PF: supervisor read access in kernel mode
+[ 1203.508798] #PF: error_code(0x0000) - not-present page
+[ 1203.509558] PGD 800000011660b067 P4D 800000011660b067 PUD 130fb8067 PMD 0
+[ 1203.510560] Oops: 0000 [#1] SMP KASAN PTI
+[ 1203.511189] CPU: 6 PID: 29532 Comm: syz-executor.2 Tainted: G B W 5.10.0 #8
+[ 1203.512324] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
+[ 1203.513895] RIP: 0010:is_ftrace_trampoline+0x26/0xb0
+[ 1203.514644] Code: ff eb d3 90 41 55 41 54 49 89 fc 55 53 e8 f2 00 fd ff 48 8b 1d 3b 35 5d 03 e8 e6 00 fd ff 48 8d bb 90 00 00 00 e8 2a 81 26 00 <48> 8b ab 90 00 00 00 48 85 ed 74 1d e8 c9 00 fd ff 48 8d bb 98 00
+[ 1203.518838] RSP: 0018:ffffc900012cf960 EFLAGS: 00010246
+[ 1203.520092] RAX: 0000000000000000 RBX: 000000000000007b RCX: ffffffff8a331866
+[ 1203.521469] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 000000000000010b
+[ 1203.522583] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff8df18b07
+[ 1203.523550] R10: fffffbfff1be3160 R11: 0000000000000001 R12: 0000000000478399
+[ 1203.524596] R13: 0000000000000000 R14: ffff888145088000 R15: 0000000000000008
+[ 1203.525634] FS: 00007f429f5f4700(0000) GS:ffff8881daf00000(0000) knlGS:0000000000000000
+[ 1203.526801] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[ 1203.527626] CR2: 000000000000010b CR3: 0000000170e1e001 CR4: 00000000003706e0
+[ 1203.528611] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+[ 1203.529605] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+
+Therefore, when ftrace_startup_enable fails, we need to rollback registration
+process and remove ops from ftrace_ops_list.
+
+Link: https://lkml.kernel.org/r/20220818032659.56209-1-yangjihong1@huawei.com
+
+Suggested-by: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Yang Jihong <yangjihong1@huawei.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/ftrace.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/kernel/trace/ftrace.c
++++ b/kernel/trace/ftrace.c
+@@ -2937,6 +2937,16 @@ int ftrace_startup(struct ftrace_ops *op
+
+ ftrace_startup_enable(command);
+
++ /*
++ * If ftrace is in an undefined state, we just remove ops from list
++ * to prevent the NULL pointer, instead of totally rolling it back and
++ * free trampoline, because those actions could cause further damage.
++ */
++ if (unlikely(ftrace_disabled)) {
++ __unregister_ftrace_function(ops);
++ return -ENODEV;
++ }
++
+ ops->flags &= ~FTRACE_OPS_FL_ADDING;
+
+ return 0;
--- /dev/null
+From a5623a203cffe2d2b84d2f6c989d9017db1856af Mon Sep 17 00:00:00 2001
+From: Karthik Alapati <mail@karthek.com>
+Date: Thu, 28 Jul 2022 21:13:17 +0530
+Subject: HID: hidraw: fix memory leak in hidraw_release()
+
+From: Karthik Alapati <mail@karthek.com>
+
+commit a5623a203cffe2d2b84d2f6c989d9017db1856af upstream.
+
+Free the buffered reports before deleting the list entry.
+
+BUG: memory leak
+unreferenced object 0xffff88810e72f180 (size 32):
+ comm "softirq", pid 0, jiffies 4294945143 (age 16.080s)
+ hex dump (first 32 bytes):
+ 64 f3 c6 6a d1 88 07 04 00 00 00 00 00 00 00 00 d..j............
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+ backtrace:
+ [<ffffffff814ac6c3>] kmemdup+0x23/0x50 mm/util.c:128
+ [<ffffffff8357c1d2>] kmemdup include/linux/fortify-string.h:440 [inline]
+ [<ffffffff8357c1d2>] hidraw_report_event+0xa2/0x150 drivers/hid/hidraw.c:521
+ [<ffffffff8356ddad>] hid_report_raw_event+0x27d/0x740 drivers/hid/hid-core.c:1992
+ [<ffffffff8356e41e>] hid_input_report+0x1ae/0x270 drivers/hid/hid-core.c:2065
+ [<ffffffff835f0d3f>] hid_irq_in+0x1ff/0x250 drivers/hid/usbhid/hid-core.c:284
+ [<ffffffff82d3c7f9>] __usb_hcd_giveback_urb+0xf9/0x230 drivers/usb/core/hcd.c:1670
+ [<ffffffff82d3cc26>] usb_hcd_giveback_urb+0x1b6/0x1d0 drivers/usb/core/hcd.c:1747
+ [<ffffffff82ef1e14>] dummy_timer+0x8e4/0x14c0 drivers/usb/gadget/udc/dummy_hcd.c:1988
+ [<ffffffff812f50a8>] call_timer_fn+0x38/0x200 kernel/time/timer.c:1474
+ [<ffffffff812f5586>] expire_timers kernel/time/timer.c:1519 [inline]
+ [<ffffffff812f5586>] __run_timers.part.0+0x316/0x430 kernel/time/timer.c:1790
+ [<ffffffff812f56e4>] __run_timers kernel/time/timer.c:1768 [inline]
+ [<ffffffff812f56e4>] run_timer_softirq+0x44/0x90 kernel/time/timer.c:1803
+ [<ffffffff848000e6>] __do_softirq+0xe6/0x2ea kernel/softirq.c:571
+ [<ffffffff81246db0>] invoke_softirq kernel/softirq.c:445 [inline]
+ [<ffffffff81246db0>] __irq_exit_rcu kernel/softirq.c:650 [inline]
+ [<ffffffff81246db0>] irq_exit_rcu+0xc0/0x110 kernel/softirq.c:662
+ [<ffffffff84574f02>] sysvec_apic_timer_interrupt+0xa2/0xd0 arch/x86/kernel/apic/apic.c:1106
+ [<ffffffff84600c8b>] asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:649
+ [<ffffffff8458a070>] native_safe_halt arch/x86/include/asm/irqflags.h:51 [inline]
+ [<ffffffff8458a070>] arch_safe_halt arch/x86/include/asm/irqflags.h:89 [inline]
+ [<ffffffff8458a070>] acpi_safe_halt drivers/acpi/processor_idle.c:111 [inline]
+ [<ffffffff8458a070>] acpi_idle_do_entry+0xc0/0xd0 drivers/acpi/processor_idle.c:554
+
+Link: https://syzkaller.appspot.com/bug?id=19a04b43c75ed1092021010419b5e560a8172c4f
+Reported-by: syzbot+f59100a0428e6ded9443@syzkaller.appspotmail.com
+Signed-off-by: Karthik Alapati <mail@karthek.com>
+Signed-off-by: Jiri Kosina <jkosina@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/hid/hidraw.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/hid/hidraw.c
++++ b/drivers/hid/hidraw.c
+@@ -350,6 +350,8 @@ static int hidraw_release(struct inode *
+ down_write(&minors_rwsem);
+
+ spin_lock_irqsave(&hidraw_table[minor]->list_lock, flags);
++ for (int i = list->tail; i < list->head; i++)
++ kfree(list->buffer[i].value);
+ list_del(&list->node);
+ spin_unlock_irqrestore(&hidraw_table[minor]->list_lock, flags);
+ kfree(list);
--- /dev/null
+From 945a9a8e448b65bec055d37eba58f711b39f66f0 Mon Sep 17 00:00:00 2001
+From: Dongliang Mu <mudongliangabcd@gmail.com>
+Date: Thu, 9 Jun 2022 08:35:28 +0100
+Subject: media: pvrusb2: fix memory leak in pvr_probe
+
+From: Dongliang Mu <mudongliangabcd@gmail.com>
+
+commit 945a9a8e448b65bec055d37eba58f711b39f66f0 upstream.
+
+The error handling code in pvr2_hdw_create forgets to unregister the
+v4l2 device. When pvr2_hdw_create returns back to pvr2_context_create,
+it calls pvr2_context_destroy to destroy context, but mp->hdw is NULL,
+which leads to that pvr2_hdw_destroy directly returns.
+
+Fix this by adding v4l2_device_unregister to decrease the refcount of
+usb interface.
+
+Reported-by: syzbot+77b432d57c4791183ed4@syzkaller.appspotmail.com
+Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
++++ b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
+@@ -2610,6 +2610,7 @@ struct pvr2_hdw *pvr2_hdw_create(struct
+ del_timer_sync(&hdw->encoder_run_timer);
+ del_timer_sync(&hdw->encoder_wait_timer);
+ flush_work(&hdw->workpoll);
++ v4l2_device_unregister(&hdw->v4l2_dev);
+ usb_free_urb(hdw->ctl_read_urb);
+ usb_free_urb(hdw->ctl_write_urb);
+ kfree(hdw->ctl_read_buffer);
--- /dev/null
+From 2a0133723f9ebeb751cfce19f74ec07e108bef1f Mon Sep 17 00:00:00 2001
+From: Hawkins Jiawei <yin31149@gmail.com>
+Date: Fri, 5 Aug 2022 15:48:34 +0800
+Subject: net: fix refcount bug in sk_psock_get (2)
+
+From: Hawkins Jiawei <yin31149@gmail.com>
+
+commit 2a0133723f9ebeb751cfce19f74ec07e108bef1f upstream.
+
+Syzkaller reports refcount bug as follows:
+------------[ cut here ]------------
+refcount_t: saturated; leaking memory.
+WARNING: CPU: 1 PID: 3605 at lib/refcount.c:19 refcount_warn_saturate+0xf4/0x1e0 lib/refcount.c:19
+Modules linked in:
+CPU: 1 PID: 3605 Comm: syz-executor208 Not tainted 5.18.0-syzkaller-03023-g7e062cda7d90 #0
+ <TASK>
+ __refcount_add_not_zero include/linux/refcount.h:163 [inline]
+ __refcount_inc_not_zero include/linux/refcount.h:227 [inline]
+ refcount_inc_not_zero include/linux/refcount.h:245 [inline]
+ sk_psock_get+0x3bc/0x410 include/linux/skmsg.h:439
+ tls_data_ready+0x6d/0x1b0 net/tls/tls_sw.c:2091
+ tcp_data_ready+0x106/0x520 net/ipv4/tcp_input.c:4983
+ tcp_data_queue+0x25f2/0x4c90 net/ipv4/tcp_input.c:5057
+ tcp_rcv_state_process+0x1774/0x4e80 net/ipv4/tcp_input.c:6659
+ tcp_v4_do_rcv+0x339/0x980 net/ipv4/tcp_ipv4.c:1682
+ sk_backlog_rcv include/net/sock.h:1061 [inline]
+ __release_sock+0x134/0x3b0 net/core/sock.c:2849
+ release_sock+0x54/0x1b0 net/core/sock.c:3404
+ inet_shutdown+0x1e0/0x430 net/ipv4/af_inet.c:909
+ __sys_shutdown_sock net/socket.c:2331 [inline]
+ __sys_shutdown_sock net/socket.c:2325 [inline]
+ __sys_shutdown+0xf1/0x1b0 net/socket.c:2343
+ __do_sys_shutdown net/socket.c:2351 [inline]
+ __se_sys_shutdown net/socket.c:2349 [inline]
+ __x64_sys_shutdown+0x50/0x70 net/socket.c:2349
+ 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+0x46/0xb0
+ </TASK>
+
+During SMC fallback process in connect syscall, kernel will
+replaces TCP with SMC. In order to forward wakeup
+smc socket waitqueue after fallback, kernel will sets
+clcsk->sk_user_data to origin smc socket in
+smc_fback_replace_callbacks().
+
+Later, in shutdown syscall, kernel will calls
+sk_psock_get(), which treats the clcsk->sk_user_data
+as psock type, triggering the refcnt warning.
+
+So, the root cause is that smc and psock, both will use
+sk_user_data field. So they will mismatch this field
+easily.
+
+This patch solves it by using another bit(defined as
+SK_USER_DATA_PSOCK) in PTRMASK, to mark whether
+sk_user_data points to a psock object or not.
+This patch depends on a PTRMASK introduced in commit f1ff5ce2cd5e
+("net, sk_msg: Clear sk_user_data pointer on clone if tagged").
+
+For there will possibly be more flags in the sk_user_data field,
+this patch also refactor sk_user_data flags code to be more generic
+to improve its maintainability.
+
+Reported-and-tested-by: syzbot+5f26f85569bd179c18ce@syzkaller.appspotmail.com
+Suggested-by: Jakub Kicinski <kuba@kernel.org>
+Acked-by: Wen Gu <guwen@linux.alibaba.com>
+Signed-off-by: Hawkins Jiawei <yin31149@gmail.com>
+Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/skmsg.h | 3 +-
+ include/net/sock.h | 68 +++++++++++++++++++++++++++++++++++---------------
+ net/core/skmsg.c | 4 ++
+ 3 files changed, 53 insertions(+), 22 deletions(-)
+
+--- a/include/linux/skmsg.h
++++ b/include/linux/skmsg.h
+@@ -277,7 +277,8 @@ static inline void sk_msg_sg_copy_clear(
+
+ static inline struct sk_psock *sk_psock(const struct sock *sk)
+ {
+- return rcu_dereference_sk_user_data(sk);
++ return __rcu_dereference_sk_user_data_with_flags(sk,
++ SK_USER_DATA_PSOCK);
+ }
+
+ static inline void sk_psock_set_state(struct sk_psock *psock,
+--- a/include/net/sock.h
++++ b/include/net/sock.h
+@@ -545,14 +545,26 @@ enum sk_pacing {
+ SK_PACING_FQ = 2,
+ };
+
+-/* Pointer stored in sk_user_data might not be suitable for copying
+- * when cloning the socket. For instance, it can point to a reference
+- * counted object. sk_user_data bottom bit is set if pointer must not
+- * be copied.
++/* flag bits in sk_user_data
++ *
++ * - SK_USER_DATA_NOCOPY: Pointer stored in sk_user_data might
++ * not be suitable for copying when cloning the socket. For instance,
++ * it can point to a reference counted object. sk_user_data bottom
++ * bit is set if pointer must not be copied.
++ *
++ * - SK_USER_DATA_BPF: Mark whether sk_user_data field is
++ * managed/owned by a BPF reuseport array. This bit should be set
++ * when sk_user_data's sk is added to the bpf's reuseport_array.
++ *
++ * - SK_USER_DATA_PSOCK: Mark whether pointer stored in
++ * sk_user_data points to psock type. This bit should be set
++ * when sk_user_data is assigned to a psock object.
+ */
+ #define SK_USER_DATA_NOCOPY 1UL
+-#define SK_USER_DATA_BPF 2UL /* Managed by BPF */
+-#define SK_USER_DATA_PTRMASK ~(SK_USER_DATA_NOCOPY | SK_USER_DATA_BPF)
++#define SK_USER_DATA_BPF 2UL
++#define SK_USER_DATA_PSOCK 4UL
++#define SK_USER_DATA_PTRMASK ~(SK_USER_DATA_NOCOPY | SK_USER_DATA_BPF |\
++ SK_USER_DATA_PSOCK)
+
+ /**
+ * sk_user_data_is_nocopy - Test if sk_user_data pointer must not be copied
+@@ -565,24 +577,40 @@ static inline bool sk_user_data_is_nocop
+
+ #define __sk_user_data(sk) ((*((void __rcu **)&(sk)->sk_user_data)))
+
++/**
++ * __rcu_dereference_sk_user_data_with_flags - return the pointer
++ * only if argument flags all has been set in sk_user_data. Otherwise
++ * return NULL
++ *
++ * @sk: socket
++ * @flags: flag bits
++ */
++static inline void *
++__rcu_dereference_sk_user_data_with_flags(const struct sock *sk,
++ uintptr_t flags)
++{
++ uintptr_t sk_user_data = (uintptr_t)rcu_dereference(__sk_user_data(sk));
++
++ WARN_ON_ONCE(flags & SK_USER_DATA_PTRMASK);
++
++ if ((sk_user_data & flags) == flags)
++ return (void *)(sk_user_data & SK_USER_DATA_PTRMASK);
++ return NULL;
++}
++
+ #define rcu_dereference_sk_user_data(sk) \
++ __rcu_dereference_sk_user_data_with_flags(sk, 0)
++#define __rcu_assign_sk_user_data_with_flags(sk, ptr, flags) \
+ ({ \
+- void *__tmp = rcu_dereference(__sk_user_data((sk))); \
+- (void *)((uintptr_t)__tmp & SK_USER_DATA_PTRMASK); \
+-})
+-#define rcu_assign_sk_user_data(sk, ptr) \
+-({ \
+- uintptr_t __tmp = (uintptr_t)(ptr); \
+- WARN_ON_ONCE(__tmp & ~SK_USER_DATA_PTRMASK); \
+- rcu_assign_pointer(__sk_user_data((sk)), __tmp); \
+-})
+-#define rcu_assign_sk_user_data_nocopy(sk, ptr) \
+-({ \
+- uintptr_t __tmp = (uintptr_t)(ptr); \
+- WARN_ON_ONCE(__tmp & ~SK_USER_DATA_PTRMASK); \
++ uintptr_t __tmp1 = (uintptr_t)(ptr), \
++ __tmp2 = (uintptr_t)(flags); \
++ WARN_ON_ONCE(__tmp1 & ~SK_USER_DATA_PTRMASK); \
++ WARN_ON_ONCE(__tmp2 & SK_USER_DATA_PTRMASK); \
+ rcu_assign_pointer(__sk_user_data((sk)), \
+- __tmp | SK_USER_DATA_NOCOPY); \
++ __tmp1 | __tmp2); \
+ })
++#define rcu_assign_sk_user_data(sk, ptr) \
++ __rcu_assign_sk_user_data_with_flags(sk, ptr, 0)
+
+ static inline
+ struct net *sock_net(const struct sock *sk)
+--- a/net/core/skmsg.c
++++ b/net/core/skmsg.c
+@@ -735,7 +735,9 @@ struct sk_psock *sk_psock_init(struct so
+ sk_psock_set_state(psock, SK_PSOCK_TX_ENABLED);
+ refcount_set(&psock->refcnt, 1);
+
+- rcu_assign_sk_user_data_nocopy(sk, psock);
++ __rcu_assign_sk_user_data_with_flags(sk, psock,
++ SK_USER_DATA_NOCOPY |
++ SK_USER_DATA_PSOCK);
+ sock_hold(sk);
+
+ out:
bluetooth-l2cap-fix-build-errors-in-some-archs.patch
revert-pci-portdrv-don-t-disable-aer-reporting-in-get_port_device_capability.patch
hid-steam-prevent-null-pointer-dereference-in-steam_-recv-send-_report.patch
+udmabuf-set-the-dma-mask-for-the-udmabuf-device-v2.patch
+media-pvrusb2-fix-memory-leak-in-pvr_probe.patch
+usb-gadget-fix-use-after-free-read-in-usb_udc_uevent.patch
+hid-hidraw-fix-memory-leak-in-hidraw_release.patch
+net-fix-refcount-bug-in-sk_psock_get-2.patch
+fbdev-fb_pm2fb-avoid-potential-divide-by-zero-error.patch
+ftrace-fix-null-pointer-dereference-in-is_ftrace_trampoline-when-ftrace-is-dead.patch
+bpf-don-t-redirect-packets-with-invalid-pkt_len.patch
--- /dev/null
+From 9e9fa6a9198b767b00f48160800128e83a038f9f Mon Sep 17 00:00:00 2001
+From: Vivek Kasireddy <vivek.kasireddy@intel.com>
+Date: Fri, 20 May 2022 13:52:35 -0700
+Subject: udmabuf: Set the DMA mask for the udmabuf device (v2)
+
+From: Vivek Kasireddy <vivek.kasireddy@intel.com>
+
+commit 9e9fa6a9198b767b00f48160800128e83a038f9f upstream.
+
+If the DMA mask is not set explicitly, the following warning occurs
+when the userspace tries to access the dma-buf via the CPU as
+reported by syzbot here:
+
+WARNING: CPU: 1 PID: 3595 at kernel/dma/mapping.c:188
+__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188
+Modules linked in:
+CPU: 0 PID: 3595 Comm: syz-executor249 Not tainted
+5.17.0-rc2-syzkaller-00316-g0457e5153e0e #0
+Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
+Google 01/01/2011
+RIP: 0010:__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188
+Code: 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 75 71 4c 8b 3d c0
+83 b5 0d e9 db fe ff ff e8 b6 0f 13 00 0f 0b e8 af 0f 13 00 <0f> 0b 45
+ 31 e4 e9 54 ff ff ff e8 a0 0f 13 00 49 8d 7f 50 48 b8 00
+RSP: 0018:ffffc90002a07d68 EFLAGS: 00010293
+RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
+RDX: ffff88807e25e2c0 RSI: ffffffff81649e91 RDI: ffff88801b848408
+RBP: ffff88801b848000 R08: 0000000000000002 R09: ffff88801d86c74f
+R10: ffffffff81649d72 R11: 0000000000000001 R12: 0000000000000002
+R13: ffff88801d86c680 R14: 0000000000000001 R15: 0000000000000000
+FS: 0000555556e30300(0000) GS:ffff8880b9d00000(0000)
+knlGS:0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: 00000000200000cc CR3: 000000001d74a000 CR4: 00000000003506e0
+DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+Call Trace:
+ <TASK>
+ dma_map_sgtable+0x70/0xf0 kernel/dma/mapping.c:264
+ get_sg_table.isra.0+0xe0/0x160 drivers/dma-buf/udmabuf.c:72
+ begin_cpu_udmabuf+0x130/0x1d0 drivers/dma-buf/udmabuf.c:126
+ dma_buf_begin_cpu_access+0xfd/0x1d0 drivers/dma-buf/dma-buf.c:1164
+ dma_buf_ioctl+0x259/0x2b0 drivers/dma-buf/dma-buf.c:363
+ vfs_ioctl fs/ioctl.c:51 [inline]
+ __do_sys_ioctl fs/ioctl.c:874 [inline]
+ __se_sys_ioctl fs/ioctl.c:860 [inline]
+ __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860
+ 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+0x44/0xae
+RIP: 0033:0x7f62fcf530f9
+Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 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 <48> 3d 01
+f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
+RSP: 002b:00007ffe3edab9b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
+RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f62fcf530f9
+RDX: 0000000020000200 RSI: 0000000040086200 RDI: 0000000000000006
+RBP: 00007f62fcf170e0 R08: 0000000000000000 R09: 0000000000000000
+R10: 0000000000000000 R11: 0000000000000246 R12: 00007f62fcf17170
+R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
+ </TASK>
+
+v2: Dont't forget to deregister if DMA mask setup fails.
+
+Reported-by: syzbot+10e27961f4da37c443b2@syzkaller.appspotmail.com
+Cc: Gerd Hoffmann <kraxel@redhat.com>
+Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
+Link: http://patchwork.freedesktop.org/patch/msgid/20220520205235.3687336-1-vivek.kasireddy@intel.com
+Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/dma-buf/udmabuf.c | 18 +++++++++++++++++-
+ 1 file changed, 17 insertions(+), 1 deletion(-)
+
+--- a/drivers/dma-buf/udmabuf.c
++++ b/drivers/dma-buf/udmabuf.c
+@@ -368,7 +368,23 @@ static struct miscdevice udmabuf_misc =
+
+ static int __init udmabuf_dev_init(void)
+ {
+- return misc_register(&udmabuf_misc);
++ int ret;
++
++ ret = misc_register(&udmabuf_misc);
++ if (ret < 0) {
++ pr_err("Could not initialize udmabuf device\n");
++ return ret;
++ }
++
++ ret = dma_coerce_mask_and_coherent(udmabuf_misc.this_device,
++ DMA_BIT_MASK(64));
++ if (ret < 0) {
++ pr_err("Could not setup DMA mask for udmabuf device\n");
++ misc_deregister(&udmabuf_misc);
++ return ret;
++ }
++
++ return 0;
+ }
+
+ static void __exit udmabuf_dev_exit(void)
--- /dev/null
+From 2191c00855b03aa59c20e698be713d952d51fc18 Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Thu, 21 Jul 2022 11:07:10 -0400
+Subject: USB: gadget: Fix use-after-free Read in usb_udc_uevent()
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit 2191c00855b03aa59c20e698be713d952d51fc18 upstream.
+
+The syzbot fuzzer found a race between uevent callbacks and gadget
+driver unregistration that can cause a use-after-free bug:
+
+---------------------------------------------------------------
+BUG: KASAN: use-after-free in usb_udc_uevent+0x11f/0x130
+drivers/usb/gadget/udc/core.c:1732
+Read of size 8 at addr ffff888078ce2050 by task udevd/2968
+
+CPU: 1 PID: 2968 Comm: udevd Not tainted 5.19.0-rc4-next-20220628-syzkaller #0
+Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
+06/29/2022
+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+0xbe/0x1f0 mm/kasan/report.c:495
+ usb_udc_uevent+0x11f/0x130 drivers/usb/gadget/udc/core.c:1732
+ dev_uevent+0x290/0x770 drivers/base/core.c:2424
+---------------------------------------------------------------
+
+The bug occurs because usb_udc_uevent() dereferences udc->driver but
+does so without acquiring the udc_lock mutex, which protects this
+field. If the gadget driver is unbound from the udc concurrently with
+uevent processing, the driver structure may be accessed after it has
+been deallocated.
+
+To prevent the race, we make sure that the routine holds the mutex
+around the racing accesses.
+
+Link: <https://lore.kernel.org/all/0000000000004de90405a719c951@google.com>
+CC: stable@vger.kernel.org # fc274c1e9973
+Reported-and-tested-by: syzbot+b0de012ceb1e2a97891b@syzkaller.appspotmail.com
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Link: https://lore.kernel.org/r/YtlrnhHyrHsSky9m@rowland.harvard.edu
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/gadget/udc/core.c | 11 ++++++-----
+ 1 file changed, 6 insertions(+), 5 deletions(-)
+
+diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
+index 7886497253cc..cafcf260394c 100644
+--- a/drivers/usb/gadget/udc/core.c
++++ b/drivers/usb/gadget/udc/core.c
+@@ -1728,13 +1728,14 @@ static int usb_udc_uevent(struct device *dev, struct kobj_uevent_env *env)
+ return ret;
+ }
+
+- if (udc->driver) {
++ mutex_lock(&udc_lock);
++ if (udc->driver)
+ ret = add_uevent_var(env, "USB_UDC_DRIVER=%s",
+ udc->driver->function);
+- if (ret) {
+- dev_err(dev, "failed to add uevent USB_UDC_DRIVER\n");
+- return ret;
+- }
++ mutex_unlock(&udc_lock);
++ if (ret) {
++ dev_err(dev, "failed to add uevent USB_UDC_DRIVER\n");
++ return ret;
+ }
+
+ return 0;
+--
+2.37.2
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
