--- /dev/null
+From 3a0cf7ab8df3878a7e2f3d29275b785cf4e7afb6 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Fri, 24 Jun 2022 13:23:34 +0200
+Subject: ACPI: video: Change how we determine if brightness key-presses are handled
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit 3a0cf7ab8df3878a7e2f3d29275b785cf4e7afb6 upstream.
+
+Some systems have an ACPI video bus but not ACPI video devices with
+backlight capability. On these devices brightness key-presses are
+(logically) not reported through the ACPI video bus.
+
+Change how acpi_video_handles_brightness_key_presses() determines if
+brightness key-presses are handled by the ACPI video driver to avoid
+vendor specific drivers/platform/x86 drivers filtering out their
+brightness key-presses even though they are the only ones reporting
+these presses.
+
+Fixes: ed83c9171829 ("platform/x86: panasonic-laptop: Resolve hotkey double trigger bug")
+Reported-and-tested-by: Stefan Seyfried <seife+kernel@b1-systems.com>
+Reported-and-tested-by: Kenneth Chan <kenneth.t.chan@gmail.com>
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Link: https://lore.kernel.org/r/20220624112340.10130-2-hdegoede@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/acpi_video.c | 13 ++++++-------
+ 1 file changed, 6 insertions(+), 7 deletions(-)
+
+--- a/drivers/acpi/acpi_video.c
++++ b/drivers/acpi/acpi_video.c
+@@ -73,6 +73,7 @@ module_param(device_id_scheme, bool, 044
+ static int only_lcd = -1;
+ module_param(only_lcd, int, 0444);
+
++static bool has_backlight;
+ static int register_count;
+ static DEFINE_MUTEX(register_count_mutex);
+ static DEFINE_MUTEX(video_list_lock);
+@@ -1222,6 +1223,9 @@ acpi_video_bus_get_one_device(struct acp
+ acpi_video_device_bind(video, data);
+ acpi_video_device_find_cap(data);
+
++ if (data->cap._BCM && data->cap._BCL)
++ has_backlight = true;
++
+ mutex_lock(&video->device_list_lock);
+ list_add_tail(&data->entry, &video->video_device_list);
+ mutex_unlock(&video->device_list_lock);
+@@ -2251,6 +2255,7 @@ void acpi_video_unregister(void)
+ if (register_count) {
+ acpi_bus_unregister_driver(&acpi_video_bus);
+ register_count = 0;
++ has_backlight = false;
+ }
+ mutex_unlock(®ister_count_mutex);
+ }
+@@ -2272,13 +2277,7 @@ void acpi_video_unregister_backlight(voi
+
+ bool acpi_video_handles_brightness_key_presses(void)
+ {
+- bool have_video_busses;
+-
+- mutex_lock(&video_list_lock);
+- have_video_busses = !list_empty(&video_bus_head);
+- mutex_unlock(&video_list_lock);
+-
+- return have_video_busses &&
++ return has_backlight &&
+ (report_key_events & REPORT_BRIGHTNESS_KEY_EVENTS);
+ }
+ EXPORT_SYMBOL(acpi_video_handles_brightness_key_presses);
--- /dev/null
+From 4e43e64d0f1332fcc503babad4dc31aead7131ca Mon Sep 17 00:00:00 2001
+From: Eric Dumazet <edumazet@google.com>
+Date: Tue, 28 Jun 2022 12:12:48 +0000
+Subject: ipv6: fix lockdep splat in in6_dump_addrs()
+
+From: Eric Dumazet <edumazet@google.com>
+
+commit 4e43e64d0f1332fcc503babad4dc31aead7131ca upstream.
+
+As reported by syzbot, we should not use rcu_dereference()
+when rcu_read_lock() is not held.
+
+WARNING: suspicious RCU usage
+5.19.0-rc2-syzkaller #0 Not tainted
+
+net/ipv6/addrconf.c:5175 suspicious rcu_dereference_check() usage!
+
+other info that might help us debug this:
+
+rcu_scheduler_active = 2, debug_locks = 1
+1 lock held by syz-executor326/3617:
+ #0: ffffffff8d5848e8 (rtnl_mutex){+.+.}-{3:3}, at: netlink_dump+0xae/0xc20 net/netlink/af_netlink.c:2223
+
+stack backtrace:
+CPU: 0 PID: 3617 Comm: syz-executor326 Not tainted 5.19.0-rc2-syzkaller #0
+Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
+Call Trace:
+ <TASK>
+ __dump_stack lib/dump_stack.c:88 [inline]
+ dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
+ in6_dump_addrs+0x12d1/0x1790 net/ipv6/addrconf.c:5175
+ inet6_dump_addr+0x9c1/0xb50 net/ipv6/addrconf.c:5300
+ netlink_dump+0x541/0xc20 net/netlink/af_netlink.c:2275
+ __netlink_dump_start+0x647/0x900 net/netlink/af_netlink.c:2380
+ netlink_dump_start include/linux/netlink.h:245 [inline]
+ rtnetlink_rcv_msg+0x73e/0xc90 net/core/rtnetlink.c:6046
+ netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2501
+ netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
+ netlink_unicast+0x543/0x7f0 net/netlink/af_netlink.c:1345
+ netlink_sendmsg+0x917/0xe10 net/netlink/af_netlink.c:1921
+ sock_sendmsg_nosec net/socket.c:714 [inline]
+ sock_sendmsg+0xcf/0x120 net/socket.c:734
+ ____sys_sendmsg+0x6eb/0x810 net/socket.c:2492
+ ___sys_sendmsg+0xf3/0x170 net/socket.c:2546
+ __sys_sendmsg net/socket.c:2575 [inline]
+ __do_sys_sendmsg net/socket.c:2584 [inline]
+ __se_sys_sendmsg net/socket.c:2582 [inline]
+ __x64_sys_sendmsg+0x132/0x220 net/socket.c:2582
+ 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
+
+Fixes: 88e2ca308094 ("mld: convert ifmcaddr6 to RCU")
+Reported-by: syzbot <syzkaller@googlegroups.com>
+Signed-off-by: Eric Dumazet <edumazet@google.com>
+Cc: Taehee Yoo <ap420073@gmail.com>
+Link: https://lore.kernel.org/r/20220628121248.858695-1-edumazet@google.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ipv6/addrconf.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/net/ipv6/addrconf.c
++++ b/net/ipv6/addrconf.c
+@@ -5166,9 +5166,9 @@ next:
+ fillargs->event = RTM_GETMULTICAST;
+
+ /* multicast address */
+- for (ifmca = rcu_dereference(idev->mc_list);
++ for (ifmca = rtnl_dereference(idev->mc_list);
+ ifmca;
+- ifmca = rcu_dereference(ifmca->next), ip_idx++) {
++ ifmca = rtnl_dereference(ifmca->next), ip_idx++) {
+ if (ip_idx < s_ip_idx)
+ continue;
+ err = inet6_fill_ifmcaddr(skb, ifmca, fillargs);
--- /dev/null
+From adabdd8f6acabc0c3fdbba2e7f5a2edd9c5ef22d Mon Sep 17 00:00:00 2001
+From: katrinzhou <katrinzhou@tencent.com>
+Date: Tue, 28 Jun 2022 11:50:30 +0800
+Subject: ipv6/sit: fix ipip6_tunnel_get_prl return value
+
+From: katrinzhou <katrinzhou@tencent.com>
+
+commit adabdd8f6acabc0c3fdbba2e7f5a2edd9c5ef22d upstream.
+
+When kcalloc fails, ipip6_tunnel_get_prl() should return -ENOMEM.
+Move the position of label "out" to return correctly.
+
+Addresses-Coverity: ("Unused value")
+Fixes: 300aaeeaab5f ("[IPV6] SIT: Add SIOCGETPRL ioctl to get/dump PRL.")
+Signed-off-by: katrinzhou <katrinzhou@tencent.com>
+Reviewed-by: Eric Dumazet<edumazet@google.com>
+Reviewed-by: David Ahern <dsahern@kernel.org>
+Link: https://lore.kernel.org/r/20220628035030.1039171-1-zys.zljxml@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ipv6/sit.c | 8 +++-----
+ 1 file changed, 3 insertions(+), 5 deletions(-)
+
+--- a/net/ipv6/sit.c
++++ b/net/ipv6/sit.c
+@@ -323,8 +323,6 @@ static int ipip6_tunnel_get_prl(struct n
+ kcalloc(cmax, sizeof(*kp), GFP_KERNEL_ACCOUNT | __GFP_NOWARN) :
+ NULL;
+
+- rcu_read_lock();
+-
+ ca = min(t->prl_count, cmax);
+
+ if (!kp) {
+@@ -341,7 +339,7 @@ static int ipip6_tunnel_get_prl(struct n
+ }
+ }
+
+- c = 0;
++ rcu_read_lock();
+ for_each_prl_rcu(t->prl) {
+ if (c >= cmax)
+ break;
+@@ -353,7 +351,7 @@ static int ipip6_tunnel_get_prl(struct n
+ if (kprl.addr != htonl(INADDR_ANY))
+ break;
+ }
+-out:
++
+ rcu_read_unlock();
+
+ len = sizeof(*kp) * c;
+@@ -362,7 +360,7 @@ out:
+ ret = -EFAULT;
+
+ kfree(kp);
+-
++out:
+ return ret;
+ }
+
--- /dev/null
+From 665030fd0c1ed9f505932e6e73e7a2c788787a0a Mon Sep 17 00:00:00 2001
+From: Petr Machata <petrm@nvidia.com>
+Date: Wed, 29 Jun 2022 10:02:05 +0300
+Subject: mlxsw: spectrum_router: Fix rollback in tunnel next hop init
+
+From: Petr Machata <petrm@nvidia.com>
+
+commit 665030fd0c1ed9f505932e6e73e7a2c788787a0a upstream.
+
+In mlxsw_sp_nexthop6_init(), a next hop is always added to the router
+linked list, and mlxsw_sp_nexthop_type_init() is invoked afterwards. When
+that function results in an error, the next hop will not have been removed
+from the linked list. As the error is propagated upwards and the caller
+frees the next hop object, the linked list ends up holding an invalid
+object.
+
+A similar issue comes up with mlxsw_sp_nexthop4_init(), where rollback
+block does exist, however does not include the linked list removal.
+
+Both IPv6 and IPv4 next hops have a similar issue with next-hop counter
+rollbacks. As these were introduced in the same patchset as the next hop
+linked list, include the cleanup in this patch.
+
+Fixes: dbe4598c1e92 ("mlxsw: spectrum_router: Keep nexthops in a linked list")
+Fixes: a5390278a5eb ("mlxsw: spectrum: Add support for setting counters on nexthops")
+Signed-off-by: Petr Machata <petrm@nvidia.com>
+Reviewed-by: Amit Cohen <amcohen@nvidia.com>
+Signed-off-by: Ido Schimmel <idosch@nvidia.com>
+Link: https://lore.kernel.org/r/20220629070205.803952-1-idosch@nvidia.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 14 +++++++++++++-
+ 1 file changed, 13 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
++++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
+@@ -4293,6 +4293,8 @@ static int mlxsw_sp_nexthop4_init(struct
+ return 0;
+
+ err_nexthop_neigh_init:
++ list_del(&nh->router_list_node);
++ mlxsw_sp_nexthop_counter_free(mlxsw_sp, nh);
+ mlxsw_sp_nexthop_remove(mlxsw_sp, nh);
+ return err;
+ }
+@@ -6578,6 +6580,7 @@ static int mlxsw_sp_nexthop6_init(struct
+ const struct fib6_info *rt)
+ {
+ struct net_device *dev = rt->fib6_nh->fib_nh_dev;
++ int err;
+
+ nh->nhgi = nh_grp->nhgi;
+ nh->nh_weight = rt->fib6_nh->fib_nh_weight;
+@@ -6593,7 +6596,16 @@ static int mlxsw_sp_nexthop6_init(struct
+ return 0;
+ nh->ifindex = dev->ifindex;
+
+- return mlxsw_sp_nexthop_type_init(mlxsw_sp, nh, dev);
++ err = mlxsw_sp_nexthop_type_init(mlxsw_sp, nh, dev);
++ if (err)
++ goto err_nexthop_type_init;
++
++ return 0;
++
++err_nexthop_type_init:
++ list_del(&nh->router_list_node);
++ mlxsw_sp_nexthop_counter_free(mlxsw_sp, nh);
++ return err;
+ }
+
+ static void mlxsw_sp_nexthop6_fini(struct mlxsw_sp *mlxsw_sp,
tipc-move-bc-link-creation-back-to-tipc_node_create.patch
epic100-fix-use-after-free-on-rmmod.patch
io_uring-ensure-that-send-sendmsg-and-recv-recvmsg-check-sqe-ioprio.patch
+acpi-video-change-how-we-determine-if-brightness-key-presses-are-handled.patch
+tunnels-do-not-assume-mac-header-is-set-in-skb_tunnel_check_pmtu.patch
+ipv6-sit-fix-ipip6_tunnel_get_prl-return-value.patch
+ipv6-fix-lockdep-splat-in-in6_dump_addrs.patch
+mlxsw-spectrum_router-fix-rollback-in-tunnel-next-hop-init.patch
--- /dev/null
+From 853a7614880231747040cada91d2b8d2e995c51a Mon Sep 17 00:00:00 2001
+From: Eric Dumazet <edumazet@google.com>
+Date: Fri, 24 Jun 2022 15:30:20 +0000
+Subject: tunnels: do not assume mac header is set in skb_tunnel_check_pmtu()
+
+From: Eric Dumazet <edumazet@google.com>
+
+commit 853a7614880231747040cada91d2b8d2e995c51a upstream.
+
+Recently added debug in commit f9aefd6b2aa3 ("net: warn if mac header
+was not set") caught a bug in skb_tunnel_check_pmtu(), as shown
+in this syzbot report [1].
+
+In ndo_start_xmit() paths, there is really no need to use skb->mac_header,
+because skb->data is supposed to point at it.
+
+[1] WARNING: CPU: 1 PID: 8604 at include/linux/skbuff.h:2784 skb_mac_header_len include/linux/skbuff.h:2784 [inline]
+WARNING: CPU: 1 PID: 8604 at include/linux/skbuff.h:2784 skb_tunnel_check_pmtu+0x5de/0x2f90 net/ipv4/ip_tunnel_core.c:413
+Modules linked in:
+CPU: 1 PID: 8604 Comm: syz-executor.3 Not tainted 5.19.0-rc2-syzkaller-00443-g8720bd951b8e #0
+Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
+RIP: 0010:skb_mac_header_len include/linux/skbuff.h:2784 [inline]
+RIP: 0010:skb_tunnel_check_pmtu+0x5de/0x2f90 net/ipv4/ip_tunnel_core.c:413
+Code: 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 80 3c 02 00 0f 84 b9 fe ff ff 4c 89 ff e8 7c 0f d7 f9 e9 ac fe ff ff e8 c2 13 8a f9 <0f> 0b e9 28 fc ff ff e8 b6 13 8a f9 48 8b 54 24 70 48 b8 00 00 00
+RSP: 0018:ffffc90002e4f520 EFLAGS: 00010212
+RAX: 0000000000000324 RBX: ffff88804d5fd500 RCX: ffffc90005b52000
+RDX: 0000000000040000 RSI: ffffffff87f05e3e RDI: 0000000000000003
+RBP: ffffc90002e4f650 R08: 0000000000000003 R09: 000000000000ffff
+R10: 000000000000ffff R11: 0000000000000000 R12: 000000000000ffff
+R13: 0000000000000000 R14: 000000000000ffcd R15: 000000000000001f
+FS: 00007f3babba9700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: 0000000020000080 CR3: 0000000075319000 CR4: 00000000003506e0
+DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+Call Trace:
+<TASK>
+geneve_xmit_skb drivers/net/geneve.c:927 [inline]
+geneve_xmit+0xcf8/0x35d0 drivers/net/geneve.c:1107
+__netdev_start_xmit include/linux/netdevice.h:4805 [inline]
+netdev_start_xmit include/linux/netdevice.h:4819 [inline]
+__dev_direct_xmit+0x500/0x730 net/core/dev.c:4309
+dev_direct_xmit include/linux/netdevice.h:3007 [inline]
+packet_direct_xmit+0x1b8/0x2c0 net/packet/af_packet.c:282
+packet_snd net/packet/af_packet.c:3073 [inline]
+packet_sendmsg+0x21f4/0x55d0 net/packet/af_packet.c:3104
+sock_sendmsg_nosec net/socket.c:714 [inline]
+sock_sendmsg+0xcf/0x120 net/socket.c:734
+____sys_sendmsg+0x6eb/0x810 net/socket.c:2489
+___sys_sendmsg+0xf3/0x170 net/socket.c:2543
+__sys_sendmsg net/socket.c:2572 [inline]
+__do_sys_sendmsg net/socket.c:2581 [inline]
+__se_sys_sendmsg net/socket.c:2579 [inline]
+__x64_sys_sendmsg+0x132/0x220 net/socket.c:2579
+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
+RIP: 0033:0x7f3baaa89109
+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 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
+RSP: 002b:00007f3babba9168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
+RAX: ffffffffffffffda RBX: 00007f3baab9bf60 RCX: 00007f3baaa89109
+RDX: 0000000000000000 RSI: 0000000020000a00 RDI: 0000000000000003
+RBP: 00007f3baaae305d R08: 0000000000000000 R09: 0000000000000000
+R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
+R13: 00007ffe74f2543f R14: 00007f3babba9300 R15: 0000000000022000
+</TASK>
+
+Fixes: 4cb47a8644cc ("tunnels: PMTU discovery support for directly bridged IP packets")
+Reported-by: syzbot <syzkaller@googlegroups.com>
+Signed-off-by: Eric Dumazet <edumazet@google.com>
+Cc: Stefano Brivio <sbrivio@redhat.com>
+Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ipv4/ip_tunnel_core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/ipv4/ip_tunnel_core.c
++++ b/net/ipv4/ip_tunnel_core.c
+@@ -410,7 +410,7 @@ int skb_tunnel_check_pmtu(struct sk_buff
+ u32 mtu = dst_mtu(encap_dst) - headroom;
+
+ if ((skb_is_gso(skb) && skb_gso_validate_network_len(skb, mtu)) ||
+- (!skb_is_gso(skb) && (skb->len - skb_mac_header_len(skb)) <= mtu))
++ (!skb_is_gso(skb) && (skb->len - skb_network_offset(skb)) <= mtu))
+ return 0;
+
+ skb_dst_update_pmtu_no_confirm(skb, mtu);
projects / thirdparty / kernel / stable-queue.git / commitdiff
