From d4833ef7e1c770b6b0cd791a4befcee810fa9c7d Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 4 Jul 2022 15:30:42 +0200 Subject: [PATCH] 5.15-stable patches added patches: acpi-video-change-how-we-determine-if-brightness-key-presses-are-handled.patch ipv6-fix-lockdep-splat-in-in6_dump_addrs.patch ipv6-sit-fix-ipip6_tunnel_get_prl-return-value.patch mlxsw-spectrum_router-fix-rollback-in-tunnel-next-hop-init.patch tunnels-do-not-assume-mac-header-is-set-in-skb_tunnel_check_pmtu.patch --- ...f-brightness-key-presses-are-handled.patch | 74 +++++++++++++++ ...-fix-lockdep-splat-in-in6_dump_addrs.patch | 77 ++++++++++++++++ ...ix-ipip6_tunnel_get_prl-return-value.patch | 62 +++++++++++++ ...fix-rollback-in-tunnel-next-hop-init.patch | 72 +++++++++++++++ queue-5.15/series | 5 ++ ...ader-is-set-in-skb_tunnel_check_pmtu.patch | 89 +++++++++++++++++++ 6 files changed, 379 insertions(+) create mode 100644 queue-5.15/acpi-video-change-how-we-determine-if-brightness-key-presses-are-handled.patch create mode 100644 queue-5.15/ipv6-fix-lockdep-splat-in-in6_dump_addrs.patch create mode 100644 queue-5.15/ipv6-sit-fix-ipip6_tunnel_get_prl-return-value.patch create mode 100644 queue-5.15/mlxsw-spectrum_router-fix-rollback-in-tunnel-next-hop-init.patch create mode 100644 queue-5.15/tunnels-do-not-assume-mac-header-is-set-in-skb_tunnel_check_pmtu.patch diff --git a/queue-5.15/acpi-video-change-how-we-determine-if-brightness-key-presses-are-handled.patch b/queue-5.15/acpi-video-change-how-we-determine-if-brightness-key-presses-are-handled.patch new file mode 100644 index 00000000000..740f8bc7e69 --- /dev/null +++ b/queue-5.15/acpi-video-change-how-we-determine-if-brightness-key-presses-are-handled.patch @@ -0,0 +1,74 @@ +From 3a0cf7ab8df3878a7e2f3d29275b785cf4e7afb6 Mon Sep 17 00:00:00 2001 +From: Hans de Goede +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 + +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 +Reported-and-tested-by: Kenneth Chan +Signed-off-by: Hans de Goede +Acked-by: Rafael J. Wysocki +Reviewed-by: Andy Shevchenko +Link: https://lore.kernel.org/r/20220624112340.10130-2-hdegoede@redhat.com +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-5.15/ipv6-fix-lockdep-splat-in-in6_dump_addrs.patch b/queue-5.15/ipv6-fix-lockdep-splat-in-in6_dump_addrs.patch new file mode 100644 index 00000000000..89a8c9eb0c7 --- /dev/null +++ b/queue-5.15/ipv6-fix-lockdep-splat-in-in6_dump_addrs.patch @@ -0,0 +1,77 @@ +From 4e43e64d0f1332fcc503babad4dc31aead7131ca Mon Sep 17 00:00:00 2001 +From: Eric Dumazet +Date: Tue, 28 Jun 2022 12:12:48 +0000 +Subject: ipv6: fix lockdep splat in in6_dump_addrs() + +From: Eric Dumazet + +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: + + __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 +Signed-off-by: Eric Dumazet +Cc: Taehee Yoo +Link: https://lore.kernel.org/r/20220628121248.858695-1-edumazet@google.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-5.15/ipv6-sit-fix-ipip6_tunnel_get_prl-return-value.patch b/queue-5.15/ipv6-sit-fix-ipip6_tunnel_get_prl-return-value.patch new file mode 100644 index 00000000000..631369e8a1f --- /dev/null +++ b/queue-5.15/ipv6-sit-fix-ipip6_tunnel_get_prl-return-value.patch @@ -0,0 +1,62 @@ +From adabdd8f6acabc0c3fdbba2e7f5a2edd9c5ef22d Mon Sep 17 00:00:00 2001 +From: katrinzhou +Date: Tue, 28 Jun 2022 11:50:30 +0800 +Subject: ipv6/sit: fix ipip6_tunnel_get_prl return value + +From: katrinzhou + +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 +Reviewed-by: Eric Dumazet +Reviewed-by: David Ahern +Link: https://lore.kernel.org/r/20220628035030.1039171-1-zys.zljxml@gmail.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } + diff --git a/queue-5.15/mlxsw-spectrum_router-fix-rollback-in-tunnel-next-hop-init.patch b/queue-5.15/mlxsw-spectrum_router-fix-rollback-in-tunnel-next-hop-init.patch new file mode 100644 index 00000000000..451d13afa8d --- /dev/null +++ b/queue-5.15/mlxsw-spectrum_router-fix-rollback-in-tunnel-next-hop-init.patch @@ -0,0 +1,72 @@ +From 665030fd0c1ed9f505932e6e73e7a2c788787a0a Mon Sep 17 00:00:00 2001 +From: Petr Machata +Date: Wed, 29 Jun 2022 10:02:05 +0300 +Subject: mlxsw: spectrum_router: Fix rollback in tunnel next hop init + +From: Petr Machata + +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 +Reviewed-by: Amit Cohen +Signed-off-by: Ido Schimmel +Link: https://lore.kernel.org/r/20220629070205.803952-1-idosch@nvidia.com +Signed-off-by: Paolo Abeni +Signed-off-by: Greg Kroah-Hartman +--- + 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, diff --git a/queue-5.15/series b/queue-5.15/series index 57c5aa199f9..db62e9122aa 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -50,3 +50,8 @@ nfc-nxp-nci-don-t-issue-a-zero-length-i2c_master_read.patch 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 diff --git a/queue-5.15/tunnels-do-not-assume-mac-header-is-set-in-skb_tunnel_check_pmtu.patch b/queue-5.15/tunnels-do-not-assume-mac-header-is-set-in-skb_tunnel_check_pmtu.patch new file mode 100644 index 00000000000..5f9b924ad59 --- /dev/null +++ b/queue-5.15/tunnels-do-not-assume-mac-header-is-set-in-skb_tunnel_check_pmtu.patch @@ -0,0 +1,89 @@ +From 853a7614880231747040cada91d2b8d2e995c51a Mon Sep 17 00:00:00 2001 +From: Eric Dumazet +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 + +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: + +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 + + +Fixes: 4cb47a8644cc ("tunnels: PMTU discovery support for directly bridged IP packets") +Reported-by: syzbot +Signed-off-by: Eric Dumazet +Cc: Stefano Brivio +Reviewed-by: Stefano Brivio +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + 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); -- 2.47.3