CVE-2023-26545

commit 1ac8758e027247774464c808447a9c2f1f97b637 Author: Greg Kroah-Hartman Date: Wed Feb 22 12:59:56 2023 +0100 Linux 6.1.13 Link: https://lore.kernel.org/r/[email protected] Tested-by: Conor Dooley Tested-by: Ronald Warsow Tested-by: Ron Economos Tested-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya Tested-by: Jon Hunter Tested-by: Sudip Mukherjee Tested-by: Salvatore Bonaccorso Tested-by: Guenter Roeck Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Justin M. Forbes Signed-off-by: Greg Kroah-Hartman commit 4419cb8e5b0f19d8c6730616d9dd493b53c4442a Author: Dan Carpenter Date: Mon Feb 6 16:18:32 2023 +0300 net: sched: sch: Fix off by one in htb_activate_prios() commit 9cec2aaffe969f2a3e18b5ec105fc20bb908e475 upstream. The > needs be >= to prevent an out of bounds access. Fixes: de5ca4c3852f (“net: sched: sch: Bounds check priority”) Signed-off-by: Dan Carpenter Reviewed-by: Simon Horman Reviewed-by: Kees Cook Link: https://lore.kernel.org/r/Y+D+KN18FQI2DKLq@kili Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0c89a43beb877bdd923f998ad80955559f6a1bcc Author: Pierre-Louis Bossart Date: Thu Feb 16 18:23:40 2023 +0200 ASoC: SOF: Intel: hda-dai: fix possible stream_tag leak commit 1f810d2b6b2fbdc5279644d8b2c140b1f7c9d43d upstream. The HDaudio stream allocation is done first, and in a second step the LOSIDV parameter is programmed for the multi-link used by a codec. This leads to a possible stream_tag leak, e.g. if a DisplayAudio link is not used. This would happen when a non-Intel graphics card is used and userspace unconditionally uses the Intel Display Audio PCMs without checking if they are connected to a receiver with jack controls. We should first check that there is a valid multi-link entry to configure before allocating a stream_tag. This change aligns the dma_assign and dma_cleanup phases. Complements: b0cd60f3e9f5 (“ALSA/ASoC: hda: clarify bus_get_link() and bus_link_get() helpers”) Link: https://github.com/thesofproject/linux/issues/4151 Signed-off-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Reviewed-by: Rander Wang Reviewed-by: Bard Liao Signed-off-by: Peter Ujfalusi Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 02f81e0256d080adbe3fb9d9fb412b042d226963 Author: Keith Busch Date: Thu Feb 16 08:44:03 2023 -0800 nvme-pci: refresh visible attrs for cmb attributes commit e917a849c3fc317c4a5f82bb18726000173d39e6 upstream. The sysfs group containing the cmb attributes is registered before the driver knows if they need to be visible or not. Update the group when cmb attributes are known to exist so the visibility setting is correct. Link: https://bugzilla.kernel.org/show_bug.cgi?id=217037 Fixes: 86adbf0cdb9ec65 (“nvme: simplify transport specific device attribute handling”) Signed-off-by: Keith Busch Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit 70fdd9831a5fe2cc405588a3d9e3df6ee6127c8b Author: Thomas Gleixner Date: Thu Feb 9 23:25:49 2023 +0100 alarmtimer: Prevent starvation by small intervals and SIG_IGN commit d125d1349abeb46945dc5e98f7824bf688266f13 upstream. syzbot reported a RCU stall which is caused by setting up an alarmtimer with a very small interval and ignoring the signal. The reproducer arms the alarm timer with a relative expiry of 8ns and an interval of 9ns. Not a problem per se, but that’s an issue when the signal is ignored because then the timer is immediately rearmed because there is no way to delay that rearming to the signal delivery path. See posix_timer_fn() and commit 58229a189942 (“posix-timers: Prevent softirq starvation by small intervals and SIG_IGN”) for details. The reproducer does not set SIG_IGN explicitely, but it sets up the timers signal with SIGCONT. That has the same effect as explicitely setting SIG_IGN for a signal as SIGCONT is ignored if there is no handler set and the task is not ptraced. The log clearly shows that: [pid 5102] — SIGCONT {si_signo=SIGCONT, si_code=SI_TIMER, si_timerid=0, si_overrun=316014, si_int=0, si_ptr=NULL} — It works because the tasks are traced and therefore the signal is queued so the tracer can see it, which delays the restart of the timer to the signal delivery path. But then the tracer is killed: [pid 5087] kill(-5102, SIGKILL … ./strace-static-x86_64: Process 5107 detached and after it’s gone the stall can be observed: syzkaller login: [ 79.439102][ C0] hrtimer: interrupt took 68471 ns [ 184.460538][ C1] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: … [ 184.658237][ C1] rcu: Stack dump where RCU GP kthread last ran: [ 184.664574][ C1] Sending NMI from CPU 1 to CPUs 0: [ 184.669821][ C0] NMI backtrace for cpu 0 [ 184.669831][ C0] CPU: 0 PID: 5108 Comm: syz-executor192 Not tainted 6.2.0-rc6-next-20230203-syzkaller #0 … [ 184.670036][ C0] Call Trace: [ 184.670041][ C0] [ 184.670045][ C0] alarmtimer_fired+0x327/0x670 posix_timer_fn() prevents that by checking whether the interval for timers which have the signal ignored is smaller than a jiffie and artifically delay it by shifting the next expiry out by a jiffie. That’s accurate vs. the overrun accounting, but slightly inaccurate vs. timer_gettimer(2). The comment in that function says what needs to be done and there was a fix available for the regular userspace induced SIG_IGN mechanism, but that did not work due to the implicit ignore for SIGCONT and similar signals. This needs to be worked on, but for now the only available workaround is to do exactly what posix_timer_fn() does: Increase the interval of self-rearming timers, which have their signal ignored, to at least a jiffie. Interestingly this has been fixed before via commit ff86bf0c65f1 (“alarmtimer: Rate limit periodic intervals”) already, but that fix got lost in a later rework. Reported-by: [email protected] Fixes: f2c45807d399 (“alarmtimer: Switch over to generic set/get/rearm routine”) Signed-off-by: Thomas Gleixner Acked-by: John Stultz Cc: [email protected] Link: https://lore.kernel.org/r/87k00q1no2.ffs@tglx Signed-off-by: Greg Kroah-Hartman commit cfc2faf3a6fe26249c7feade89695dc559a754a8 Author: Sean Christopherson Date: Wed Feb 8 20:42:30 2023 +0000 perf/x86: Refuse to export capabilities for hybrid PMUs commit 4b4191b8ae1278bde3642acaaef8f92810ed111a upstream. Now that KVM disables vPMU support on hybrid CPUs, WARN and return zeros if perf_get_x86_pmu_capability() is invoked on a hybrid CPU. The helper doesn’t provide an accurate accounting of the PMU capabilities for hybrid CPUs and needs to be enhanced if KVM, or anything else outside of perf, wants to act on the PMU capabilities. Cc: [email protected] Cc: Andrew Cooper Cc: Peter Zijlstra Cc: Kan Liang Cc: Andi Kleen Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Sean Christopherson Message-Id: [email protected] Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 747ca7c8a0c7bce004709143d1cd6596b79b1deb Author: Greg Kroah-Hartman Date: Tue Feb 14 11:33:04 2023 +0100 kvm: initialize all of the kvm_debugregs structure before sending it to userspace commit 2c10b61421a28e95a46ab489fd56c0f442ff6952 upstream. When calling the KVM_GET_DEBUGREGS ioctl, on some configurations, there might be some unitialized portions of the kvm_debugregs structure that could be copied to userspace. Prevent this as is done in the other kvm ioctls, by setting the whole structure to 0 before copying anything into it. Bonus is that this reduces the lines of code as the explicit flag setting and reserved space zeroing out can be removed. Cc: Sean Christopherson Cc: Paolo Bonzini Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Dave Hansen Cc: Cc: “H. Peter Anvin” Cc: stable Reported-by: Xingyuan Mo Signed-off-by: Greg Kroah-Hartman Message-Id: [email protected] Tested-by: Xingyuan Mo Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 9ca0910b2def0984df080cf3d5331d0d4bd1f96f Author: Sean Christopherson Date: Wed Feb 8 20:42:29 2023 +0000 KVM: x86/pmu: Disable vPMU support on hybrid CPUs (host PMUs) commit 4d7404e5ee0066e9a9e8268675de8a273b568b08 upstream. Disable KVM support for virtualizing PMUs on hosts with hybrid PMUs until KVM gains a sane way to enumeration the hybrid vPMU to userspace and/or gains a mechanism to let userspace opt-in to the dangers of exposing a hybrid vPMU to KVM guests. Virtualizing a hybrid PMU, or at least part of a hybrid PMU, is possible, but it requires careful, deliberate configuration from userspace. E.g. to expose full functionality, vCPUs need to be pinned to pCPUs to prevent migrating a vCPU between a big core and a little core, userspace must enumerate a reasonable topology to the guest, and guest CPUID must be curated per vCPU to enumerate accurate vPMU capabilities. The last point is especially problematic, as KVM doesn’t control which pCPU it runs on when enumerating KVM’s vPMU capabilities to userspace, i.e. userspace can’t rely on KVM_GET_SUPPORTED_CPUID in it’s current form. Alternatively, userspace could enable vPMU support by enumerating the set of features that are common and coherent across all cores, e.g. by filtering PMU events and restricting guest capabilities. But again, that requires userspace to take action far beyond reflecting KVM’s supported feature set into the guest. For now, simply disable vPMU support on hybrid CPUs to avoid inducing seemingly random #GPs in guests, and punt support for hybrid CPUs to a future enabling effort. Reported-by: Jianfeng Gao Cc: [email protected] Cc: Andrew Cooper Cc: Peter Zijlstra Cc: Kan Liang Cc: Andi Kleen Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Sean Christopherson Message-Id: [email protected] Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 8017a161e84efe2e5f3adf30432981ddd060f34d Author: Sagi Grimberg Date: Sun Nov 13 13:24:24 2022 +0200 nvme-rdma: stop auth work after tearing down queues in error recovery [ Upstream commit 91c11d5f32547a08d462934246488fe72f3d44c3 ] when starting error recovery there might be a authentication work running, and it involves I/O commands. Given the controller is tearing down there is no chance for the I/O to complete other than timing out which may unnecessarily take a full io timeout. So first tear down the queues, fail/cancel all inflight I/O (including potentially authentication) and only then stop authentication. This ensures that failover is not stalled due to blocked authentication I/O. Signed-off-by: Sagi Grimberg Reviewed-by: Chaitanya Kulkarni Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit e94e1ea596f0e072e9f47acd1782ebfa722f1307 Author: Sagi Grimberg Date: Sun Nov 13 13:24:23 2022 +0200 nvme-tcp: stop auth work after tearing down queues in error recovery [ Upstream commit 1f1a4f89562d3b33b6ca4fc8a4f3bd4cd35ab4ea ] when starting error recovery there might be a authentication work running, and it involves I/O commands. Given the controller is tearing down there is no chance for the I/O to complete other than timing out which may unnecessarily take a full io timeout. So first tear down the queues, fail/cancel all inflight I/O (including potentially authentication) and only then stop authentication. This ensures that failover is not stalled due to blocked authentication I/O. Signed-off-by: Sagi Grimberg Reviewed-by: Chaitanya Kulkarni Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 513e4b876ec59c4d3b26764101c728a82afc7dfa Author: Pedro Tammela Date: Mon Feb 13 22:47:29 2023 -0300 net/sched: tcindex: search key must be 16 bits [ Upstream commit 42018a322bd453e38b3ffee294982243e50a484f ] Syzkaller found an issue where a handle greater than 16 bits would trigger a null-ptr-deref in the imperfect hash area update. general protection fault, probably for non-canonical address 0xdffffc0000000015: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x00000000000000a8-0x00000000000000af] CPU: 0 PID: 5070 Comm: syz-executor456 Not tainted 6.2.0-rc7-syzkaller-00112-gc68f345b7c42 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/21/2023 RIP: 0010:tcindex_set_parms+0x1a6a/0x2990 net/sched/cls_tcindex.c:509 Code: 01 e9 e9 fe ff ff 4c 8b bd 28 fe ff ff e8 0e 57 7d f9 48 8d bb a8 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 94 0c 00 00 48 8b 85 f8 fd ff ff 48 8b 9b a8 00 RSP: 0018:ffffc90003d3ef88 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000015 RSI: ffffffff8803a102 RDI: 00000000000000a8 RBP: ffffc90003d3f1d8 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: ffff88801e2b10a8 R13: dffffc0000000000 R14: 0000000000030000 R15: ffff888017b3be00 FS: 00005555569af300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000056041c6d2000 CR3: 000000002bfca000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: tcindex_change+0x1ea/0x320 net/sched/cls_tcindex.c:572 tc_new_tfilter+0x96e/0x2220 net/sched/cls_api.c:2155 rtnetlink_rcv_msg+0x959/0xca0 net/core/rtnetlink.c:6132 netlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2574 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline] netlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1365 netlink_sendmsg+0x91b/0xe10 net/netlink/af_netlink.c:1942 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xd3/0x120 net/socket.c:734 ____sys_sendmsg+0x334/0x8c0 net/socket.c:2476 ___sys_sendmsg+0x110/0x1b0 net/socket.c:2530 __sys_sendmmsg+0x18f/0x460 net/socket.c:2616 __do_sys_sendmmsg net/socket.c:2645 [inline] __se_sys_sendmmsg net/socket.c:2642 [inline] __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2642 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 Fixes: ee059170b1f7 (“net/sched: tcindex: update imperfect hash filters respecting rcu”) Signed-off-by: Jamal Hadi Salim Signed-off-by: Pedro Tammela Reported-by: syzbot Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 49f04300d49569a4bb3788573925618ed96afbe1 Author: Natalia Petrova Date: Thu Feb 9 09:28:33 2023 -0800 i40e: Add checking for null for nlmsg_find_attr() [ Upstream commit 7fa0b526f865cb42aa33917fd02a92cb03746f4d ] The result of nlmsg_find_attr() ‘br_spec’ is dereferenced in nla_for_each_nested(), but it can take NULL value in nla_find() function, which will result in an error. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 51616018dd1b (“i40e: Add support for getlink, setlink ndo ops”) Signed-off-by: Natalia Petrova Reviewed-by: Jesse Brandeburg Tested-by: Gurucharan G (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 974cfed82cc962eb9f656ac709f0902378f75e2a Author: Arnd Bergmann Date: Mon Jan 30 14:07:26 2023 +0100 mm: extend max struct page size for kmsan commit 3770e52fd4ec40ebee16ba19ad6c09dc0b52739b upstream. After x86 enabled support for KMSAN, it has become possible to have larger ‘struct page’ than was expected when commit 5470dea49f53 (“mm: use mm_zero_struct_page from SPARC on all 64b architectures”) was merged: include/linux/mm.h:156:10: warning: no case matching constant switch condition ‘96’ switch (sizeof(struct page)) { Extend the maximum accordingly. Link: https://lkml.kernel.org/r/[email protected] Fixes: 5470dea49f53 (“mm: use mm_zero_struct_page from SPARC on all 64b architectures”) Fixes: 4ca8cc8d1bbe (“x86: kmsan: enable KMSAN builds for x86”) Fixes: f80be4571b19 (“kmsan: add KMSAN runtime core”) Signed-off-by: Arnd Bergmann Acked-by: Michal Hocko Reviewed-by: Pasha Tatashin Cc: Alexander Duyck Cc: Alexander Potapenko Cc: Alex Sierra Cc: David Hildenbrand Cc: Hugh Dickins Cc: John Hubbard Cc: Liam R. Howlett Cc: Matthew Wilcox Cc: Naoya Horiguchi Cc: Suren Baghdasaryan Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit eaba8521fd2056b0d2ce24538ed5ddc0a0336c72 Author: Kuan-Ying Lee Date: Tue Jan 31 14:32:06 2023 +0800 mm/gup: add folio to list when folio_isolate_lru() succeed commit aa1e6a932ca652a50a5df458399724a80459f521 upstream. If we call folio_isolate_lru() successfully, we will get return value 0. We need to add this folio to the movable_pages_list. Link: https://lkml.kernel.org/r/[email protected] Fixes: 67e139b02d99 (“mm/gup.c: refactor check_and_migrate_movable_pages()") Signed-off-by: Kuan-Ying Lee Reviewed-by: Alistair Popple Acked-by: David Hildenbrand Reviewed-by: Baolin Wang Cc: Andrew Yang Cc: Chinwen Chang Cc: John Hubbard Cc: Matthias Brugger Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit f16e2f7c52d0b6f46c89090ac92a922c2ee45348 Author: Guillaume Nault Date: Wed Feb 8 18:14:03 2023 +0100 ipv6: Fix tcp socket connection with DSCP. commit 8230680f36fd1525303d1117768c8852314c488c upstream. Take into account the IPV6_TCLASS socket option (DSCP) in tcp_v6_connect(). Otherwise fib6_rule_match() can’t properly match the DSCP value, resulting in invalid route lookup. For example: ip route add unreachable table main 2001:db8::10/124 ip route add table 100 2001:db8::10/124 dev eth0 ip -6 rule add dsfield 0x04 table 100 echo test | socat - TCP6:[2001:db8::11]:54321,ipv6-tclass=0x04 Without this patch, socat fails at connect() time (“No route to host”) because the fib-rule doesn’t jump to table 100 and the lookup ends up being done in the main table. Fixes: 2cc67cc731d9 ("[IPV6] ROUTE: Routing by Traffic Class.”) Signed-off-by: Guillaume Nault Reviewed-by: Eric Dumazet Reviewed-by: David Ahern Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 22e6dc0653236357557042fe6f65c9c909c6f8e9 Author: Guillaume Nault Date: Wed Feb 8 18:13:59 2023 +0100 ipv6: Fix datagram socket connection with DSCP. commit e010ae08c71fda8be3d6bda256837795a0b3ea41 upstream. Take into account the IPV6_TCLASS socket option (DSCP) in ip6_datagram_flow_key_init(). Otherwise fib6_rule_match() can’t properly match the DSCP value, resulting in invalid route lookup. For example: ip route add unreachable table main 2001:db8::10/124 ip route add table 100 2001:db8::10/124 dev eth0 ip -6 rule add dsfield 0x04 table 100 echo test | socat - UDP6:[2001:db8::11]:54321,ipv6-tclass=0x04 Without this patch, socat fails at connect() time (“No route to host”) because the fib-rule doesn’t jump to table 100 and the lookup ends up being done in the main table. Fixes: 2cc67cc731d9 ("[IPV6] ROUTE: Routing by Traffic Class.") Signed-off-by: Guillaume Nault Reviewed-by: Eric Dumazet Reviewed-by: David Ahern Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b6eabfb05c3df126e01dd546bf485166cec4710a Author: Jason Xing Date: Thu Feb 9 10:41:28 2023 +0800 ixgbe: add double of VLAN header when computing the max MTU commit 0967bf837784a11c65d66060623a74e65211af0b upstream. Include the second VLAN HLEN into account when computing the maximum MTU size as other drivers do. Fixes: fabf1bce103a (“ixgbe: Prevent unsupported configurations with XDP”) Signed-off-by: Jason Xing Reviewed-by: Alexander Duyck Tested-by: Chandan Kumar Rout (A Contingent Worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit 55c96c5e8e08c0c89fa9930ac57c52b6457d2fe8 Author: Miroslav Lichvar Date: Mon Feb 13 10:58:22 2023 -0800 igb: Fix PPS input and output using 3rd and 4th SDP commit 207ce626add80ddd941f62fc2fe5d77586e0801b upstream. Fix handling of the tsync interrupt to compare the pin number with IGB_N_SDP instead of IGB_N_EXTTS/IGB_N_PEROUT and fix the indexing to the perout array. Fixes: cf99c1dd7b77 (“igb: move PEROUT and EXTTS isr logic to separate functions”) Reported-by: Matt Corallo Signed-off-by: Miroslav Lichvar Reviewed-by: Jacob Keller Tested-by: Gurucharan G (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 39f797719d5cb28a86f8ff0fc1a85ce9fd4e11ff Author: Corinna Vinschen Date: Tue Feb 14 10:55:48 2023 -0800 igb: conditionalize I2C bit banging on external thermal sensor support commit 5d54cb1767e06025819daa6769e0f18dcbc60936 upstream. Commit a97f8783a937 (“igb: unbreak I2C bit-banging on i350”) introduced code to change I2C settings to bit banging unconditionally. However, this patch introduced a regression: On an Intel S2600CWR Server Board with three NICs: - 1x dual-port copper Intel I350 Gigabit Network Connection [8086:1521] (rev 01) fw 1.63, 0x80000dda - 2x quad-port SFP+ with copper SFP Avago ABCU-5700RZ Intel I350 Gigabit Fiber Network Connection [8086:1522] (rev 01) fw 1.52.0 the SFP NICs no longer get link at all. Reverting commit a97f8783a937 or switching to the Intel out-of-tree driver both fix the problem. Per the igb out-of-tree driver, I2C bit banging on i350 depends on support for an external thermal sensor (ETS). However, commit a97f8783a937 added bit banging unconditionally. Additionally, the out-of-tree driver always calls init_thermal_sensor_thresh on probe, while our driver only calls init_thermal_sensor_thresh only in igb_reset(), and only if an ETS is present, ignoring the internal thermal sensor. The affected SFPs don’t provide an ETS. Per Intel, the behaviour is a result of i350 firmware requirements. This patch fixes the problem by aligning the behaviour to the out-of-tree driver: - split igb_init_i2c() into two functions: - igb_init_i2c() only performs the basic I2C initialization. - igb_set_i2c_bb() makes sure that E1000_CTRL_I2C_ENA is set and enables bit-banging. - igb_probe() only calls igb_set_i2c_bb() if an ETS is present. - igb_probe() calls init_thermal_sensor_thresh() unconditionally. - igb_reset() aligns its behaviour to igb_probe(), i. e., call igb_set_i2c_bb() if an ETS is present and call init_thermal_sensor_thresh() unconditionally. Fixes: a97f8783a937 (“igb: unbreak I2C bit-banging on i350”) Tested-by: Mateusz Palczewski Co-developed-by: Jamie Bainbridge Signed-off-by: Jamie Bainbridge Signed-off-by: Corinna Vinschen Signed-off-by: Tony Nguyen Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c376227845eef8f2e62e2c29c3cf2140d35dd8e8 Author: Jakub Kicinski Date: Mon Feb 13 22:53:55 2023 -0800 net: mpls: fix stale pointer if allocation fails during device rename commit fda6c89fe3d9aca073495a664e1d5aea28cd4377 upstream. lianhui reports that when MPLS fails to register the sysctl table under new location (during device rename) the old pointers won’t get overwritten and may be freed again (double free). Handle this gracefully. The best option would be unregistering the MPLS from the device completely on failure, but unfortunately mpls_ifdown() can fail. So failing fully is also unreliable. Another option is to register the new table first then only remove old one if the new one succeeds. That requires more code, changes order of notifications and two tables may be visible at the same time. sysctl point is not used in the rest of the code - set to NULL on failures and skip unregister if already NULL. Reported-by: lianhui tang Fixes: 0fae3bf018d9 (“mpls: handle device renames for per-device sysctls”) Signed-off-by: Jakub Kicinski Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 54b6082aec178f16ad6d193b4ecdc9c4823d9a32 Author: Tung Nguyen Date: Tue Feb 14 01:26:06 2023 +0000 tipc: fix kernel warning when sending SYN message commit 11a4d6f67cf55883dc78e31c247d1903ed7feccc upstream. When sending a SYN message, this kernel stack trace is observed: … [ 13.396352] RIP: 0010:_copy_from_iter+0xb4/0x550 … [ 13.398494] Call Trace: [ 13.398630] [ 13.398630] ? __alloc_skb+0xed/0x1a0 [ 13.398630] tipc_msg_build+0x12c/0x670 [tipc] [ 13.398630] ? shmem_add_to_page_cache.isra.71+0x151/0x290 [ 13.398630] __tipc_sendmsg+0x2d1/0x710 [tipc] [ 13.398630] ? tipc_connect+0x1d9/0x230 [tipc] [ 13.398630] ? __local_bh_enable_ip+0x37/0x80 [ 13.398630] tipc_connect+0x1d9/0x230 [tipc] [ 13.398630] ? __sys_connect+0x9f/0xd0 [ 13.398630] __sys_connect+0x9f/0xd0 [ 13.398630] ? preempt_count_add+0x4d/0xa0 [ 13.398630] ? fpregs_assert_state_consistent+0x22/0x50 [ 13.398630] __x64_sys_connect+0x16/0x20 [ 13.398630] do_syscall_64+0x42/0x90 [ 13.398630] entry_SYSCALL_64_after_hwframe+0x63/0xcd It is because commit a41dad905e5a (“iov_iter: saner checks for attempt to copy to/from iterator”) has introduced sanity check for copying from/to iov iterator. Lacking of copy direction from the iterator viewpoint would lead to kernel stack trace like above. This commit fixes this issue by initializing the iov iterator with the correct copy direction when sending SYN or ACK without data. Fixes: f25dcc7687d4 (“tipc: tipc ->sendmsg() conversion”) Reported-by: [email protected] Acked-by: Jon Maloy Signed-off-by: Tung Nguyen Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 863a7de987f02a901bf215509276a7de0370e0f9 Author: Eric Dumazet Date: Mon Feb 13 16:00:59 2023 +0000 net: use a bounce buffer for copying skb->mark commit 2558b8039d059342197610498c8749ad294adee5 upstream. syzbot found arm64 builds would crash in sock_recv_mark() when CONFIG_HARDENED_USERCOPY=y x86 and powerpc are not detecting the issue because they define user_access_begin. This will be handled in a different patch, because a check_object_size() is missing. Only data from skb->cb[] can be copied directly to/from user space, as explained in commit 79a8a642bf05 (“net: Whitelist the skbuff_head_cache “cb” field”) syzbot report was: usercopy: Kernel memory exposure attempt detected from SLUB object ‘skbuff_head_cache’ (offset 168, size 4)! ------------[ cut here ]------------ kernel BUG at mm/usercopy.c:102 ! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 4410 Comm: syz-executor533 Not tainted 6.2.0-rc7-syzkaller-17907-g2d3827b3f393 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/21/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=–) pc : usercopy_abort+0x90/0x94 mm/usercopy.c:90 lr : usercopy_abort+0x90/0x94 mm/usercopy.c:90 sp : ffff80000fb9b9a0 x29: ffff80000fb9b9b0 x28: ffff0000c6073400 x27: 0000000020001a00 x26: 0000000000000014 x25: ffff80000cf52000 x24: fffffc0000000000 x23: 05ffc00000000200 x22: fffffc000324bf80 x21: ffff0000c92fe1a8 x20: 0000000000000001 x19: 0000000000000004 x18: 0000000000000000 x17: 656a626f2042554c x16: ffff0000c6073dd0 x15: ffff80000dbd2118 x14: ffff0000c6073400 x13: 00000000ffffffff x12: ffff0000c6073400 x11: ff808000081bbb4c x10: 0000000000000000 x9 : 7b0572d7cc0ccf00 x8 : 7b0572d7cc0ccf00 x7 : ffff80000bf650d4 x6 : 0000000000000000 x5 : 0000000000000001 x4 : 0000000000000001 x3 : 0000000000000000 x2 : ffff0001fefbff08 x1 : 0000000100000000 x0 : 000000000000006c Call trace: usercopy_abort+0x90/0x94 mm/usercopy.c:90 __check_heap_object+0xa8/0x100 mm/slub.c:4761 check_heap_object mm/usercopy.c:196 [inline] __check_object_size+0x208/0x6b8 mm/usercopy.c:251 check_object_size include/linux/thread_info.h:199 [inline] __copy_to_user include/linux/uaccess.h:115 [inline] put_cmsg+0x408/0x464 net/core/scm.c:238 sock_recv_mark net/socket.c:975 [inline] __sock_recv_cmsgs+0x1fc/0x248 net/socket.c:984 sock_recv_cmsgs include/net/sock.h:2728 [inline] packet_recvmsg+0x2d8/0x678 net/packet/af_packet.c:3482 ____sys_recvmsg+0x110/0x3a0 ___sys_recvmsg net/socket.c:2737 [inline] __sys_recvmsg+0x194/0x210 net/socket.c:2767 __do_sys_recvmsg net/socket.c:2777 [inline] __se_sys_recvmsg net/socket.c:2774 [inline] __arm64_sys_recvmsg+0x2c/0x3c net/socket.c:2774 __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline] invoke_syscall+0x64/0x178 arch/arm64/kernel/syscall.c:52 el0_svc_common+0xbc/0x180 arch/arm64/kernel/syscall.c:142 do_el0_svc+0x48/0x110 arch/arm64/kernel/syscall.c:193 el0_svc+0x58/0x14c arch/arm64/kernel/entry-common.c:637 el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:655 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591 Code: 91388800 aa0903e1 f90003e8 94e6d752 (d4210000) Fixes: 6fd1d51cfa25 ("net: SO_RCVMARK socket option for SO_MARK with recvmsg()") Reported-by: syzbot Signed-off-by: Eric Dumazet Cc: Erin MacNeil Reviewed-by: Alexander Lobakin Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 92573c6d20c4dd53c9db6140efd6cd49e4195aee Author: Cristian Ciocaltea Date: Fri Feb 10 22:21:26 2023 +0200 net: stmmac: Restrict warning on disabling DMA store and fwd mode commit 05d7623a892a9da62da0e714428e38f09e4a64d8 upstream. When setting ‘snps,force_thresh_dma_mode’ DT property, the following warning is always emitted, regardless the status of force_sf_dma_mode: dwmac-starfive 10020000.ethernet: force_sf_dma_mode is ignored if force_thresh_dma_mode is set. Do not print the rather misleading message when DMA store and forward mode is already disabled. Fixes: e2a240c7d3bc (“driver:net:stmmac: Disable DMA store and forward mode if platform data force_thresh_dma_mode is set.”) Signed-off-by: Cristian Ciocaltea Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit ac6e733f81f8819bc4ae720be7af5f9caf26fe21 Author: Steven Rostedt (Google) Date: Sun Feb 12 20:11:42 2023 -0500 tracing: Make trace_define_field_ext() static commit 70b5339caf847b8b6097b6dfab0c5a99b40713c8 upstream. trace_define_field_ext() is not used outside of trace_events.c, it should be static. Link: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Fixes: b6c7abd1c28a (“tracing: Fix TASK_COMM_LEN in trace event format file”) Reported-by: Reported-by: kernel test robot Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit b444fcc306a768419a0123938de68913c6e580de Author: Michael Chan Date: Fri Feb 10 12:31:55 2023 -0500 bnxt_en: Fix mqprio and XDP ring checking logic commit 2038cc592811209de20c4e094ca08bfb1e6fbc6c upstream. In bnxt_reserve_rings(), there is logic to check that the number of TX rings reserved is enough to cover all the mqprio TCs, but it fails to account for the TX XDP rings. So the check will always fail if there are mqprio TCs and TX XDP rings. As a result, the driver always fails to initialize after the XDP program is attached and the device will be brought down. A subsequent ifconfig up will also fail because the number of TX rings is set to an inconsistent number. Fix the check to properly account for TX XDP rings. If the check fails, set the number of TX rings back to a consistent number after calling netdev_reset_tc(). Fixes: 674f50a5b026 (“bnxt_en: Implement new method to reserve rings.”) Reviewed-by: Hongguang Gao Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c9d483a82848ba9686bf311caf1b25e49060fa20 Author: Johannes Zink Date: Fri Feb 10 15:39:37 2023 +0100 net: stmmac: fix order of dwmac5 FlexPPS parametrization sequence commit 4562c65ec852067c6196abdcf2d925f08841dcbc upstream. So far changing the period by just setting new period values while running did not work. The order as indicated by the publicly available reference manual of the i.MX8MP [1] indicates a sequence: * initiate the programming sequence * set the values for PPS period and start time * start the pulse train generation. This is currently not used in dwmac5_flex_pps_config(), which instead does: * initiate the programming sequence and immediately start the pulse train generation * set the values for PPS period and start time This caused the period values written not to take effect until the FlexPPS output was disabled and re-enabled again. This patch fix the order and allows the period to be set immediately. [1] https://www.nxp.com/webapp/Download?colCode=IMX8MPRM Fixes: 9a8a02c9d46d (“net: stmmac: Add Flexible PPS support”) Signed-off-by: Johannes Zink Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e336a9e08618203a456fb5367f1387b14554f55e Author: Hangyu Hua Date: Fri Feb 10 10:05:51 2023 +0800 net: openvswitch: fix possible memory leak in ovs_meter_cmd_set() commit 2fa28f5c6fcbfc794340684f36d2581b4f2d20b5 upstream. old_meter needs to be free after it is detached regardless of whether the new meter is successfully attached. Fixes: c7c4c44c9a95 (“net: openvswitch: expand the meters supported number”) Signed-off-by: Hangyu Hua Acked-by: Eelco Chaudron Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b6d204731178037de0fbb30d41be8e9ce6132352 Author: Pedro Tammela Date: Fri Feb 10 17:08:25 2023 -0300 net/sched: act_ctinfo: use percpu stats commit 21c167aa0ba943a7cac2f6969814f83bb701666b upstream. The tc action act_ctinfo was using shared stats, fix it to use percpu stats since bstats_update() must be called with locks or with a percpu pointer argument. tdc results: 1…12 ok 1 c826 - Add ctinfo action with default setting ok 2 0286 - Add ctinfo action with dscp ok 3 4938 - Add ctinfo action with valid cpmark and zone ok 4 7593 - Add ctinfo action with drop control ok 5 2961 - Replace ctinfo action zone and action control ok 6 e567 - Delete ctinfo action with valid index ok 7 6a91 - Delete ctinfo action with invalid index ok 8 5232 - List ctinfo actions ok 9 7702 - Flush ctinfo actions ok 10 3201 - Add ctinfo action with duplicate index ok 11 8295 - Add ctinfo action with invalid index ok 12 3964 - Replace ctinfo action with invalid goto_chain control Fixes: 24ec483cec98 (“net: sched: Introduce act_ctinfo action”) Reviewed-by: Jamal Hadi Salim Signed-off-by: Pedro Tammela Reviewed-by: Larysa Zaremba Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 02df3170c04a8356cd571ab9155a42f030190abc Author: Miko Larsson Date: Fri Feb 10 09:13:44 2023 +0100 net/usb: kalmia: Don’t pass act_len in usb_bulk_msg error path commit c68f345b7c425b38656e1791a0486769a8797016 upstream. syzbot reported that act_len in kalmia_send_init_packet() is uninitialized when passing it to the first usb_bulk_msg error path. Jiri Pirko noted that it’s pointless to pass it in the error path, and that the value that would be printed in the second error path would be the value of act_len from the first call to usb_bulk_msg.[1] With this in mind, let’s just not pass act_len to the usb_bulk_msg error paths. 1: https://lore.kernel.org/lkml/Y9pY61y1nwTuzMOa@nanopsycho/ Fixes: d40261236e8e (“net/usb: Add Samsung Kalmia driver for Samsung GT-B3730”) Reported-and-tested-by: [email protected] Signed-off-by: Miko Larsson Reviewed-by: Alexander Duyck Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 229461ff0f43b273cde8df7c2a7712965aa5380c Author: Kuniyuki Iwashima Date: Thu Feb 9 16:22:01 2023 -0800 dccp/tcp: Avoid negative sk_forward_alloc by ipv6_pinfo.pktoptions. commit ca43ccf41224b023fc290073d5603a755fd12eed upstream. Eric Dumazet pointed out [0] that when we call skb_set_owner_r() for ipv6_pinfo.pktoptions, sk_rmem_schedule() has not been called, resulting in a negative sk_forward_alloc. We add a new helper which clones a skb and sets its owner only when sk_rmem_schedule() succeeds. Note that we move skb_set_owner_r() forward in (dccp|tcp)_v6_do_rcv() because tcp_send_synack() can make sk_forward_alloc negative before ipv6_opt_accepted() in the crossed SYN-ACK or self-connect() cases. [0]: https://lore.kernel.org/netdev/CANn89iK9oc20Jdi_41jb9URdF210r7d1Y-+uypbMSbOfY6jqrg@mail.gmail.com/ Fixes: 323fbd0edf3f (“net: dccp: Add handling of IPV6_PKTOPTIONS to dccp_v6_do_rcv()") Fixes: 3df80d9320bc ("[DCCP]: Introduce DCCPv6”) Fixes: 1da177e4c3f4 (“Linux-2.6.12-rc2”) Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 736281d45907baafab421f66f43e076c278e91b6 Author: Larysa Zaremba Date: Thu Feb 9 17:01:30 2023 +0100 ice: xsk: Fix cleaning of XDP_TX frames commit 1f090494170ea298530cf1285fb8d078e355b4c0 upstream. Incrementation of xsk_frames inside the for-loop produces infinite loop, if we have both normal AF_XDP-TX and XDP_TXed buffers to complete. Split xsk_frames into 2 variables (xsk_frames and completed_frames) to eliminate this bug. Fixes: 29322791bc8b (“ice: xsk: change batched Tx descriptor cleaning”) Acked-by: Maciej Fijalkowski Signed-off-by: Larysa Zaremba Reviewed-by: Alexander Duyck Acked-by: Tony Nguyen Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit bd662ba56187b5ef8a62a3511371cd38299a507f Author: Pedro Tammela Date: Thu Feb 9 11:37:39 2023 -0300 net/sched: tcindex: update imperfect hash filters respecting rcu commit ee059170b1f7e94e55fa6cadee544e176a6e59c2 upstream. The imperfect hash area can be updated while packets are traversing, which will cause a use-after-free when 'tcf_exts_exec()' is called with the destroyed tcf_ext. CPU 0: CPU 1: tcindex_set_parms tcindex_classify tcindex_lookup tcindex_lookup tcf_exts_change tcf_exts_exec [UAF] Stop operating on the shared area directly, by using a local copy, and update the filter with 'rcu_replace_pointer()'. Delete the old filter version only after a rcu grace period elapsed. Fixes: 9b0d4446b569 (“net: sched: avoid atomic swap in tcf_exts_change”) Reported-by: valis Suggested-by: valis Signed-off-by: Jamal Hadi Salim Signed-off-by: Pedro Tammela Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b70ec98729107544b089116e6e54c782120e46e8 Author: Pietro Borrello Date: Thu Feb 9 12:13:05 2023 +0000 sctp: sctp_sock_filter(): avoid list_entry() on possibly empty list commit a1221703a0f75a9d81748c516457e0fc76951496 upstream. Use list_is_first() to check whether tsp->asoc matches the first element of ep->asocs, as the list is not guaranteed to have an entry. Fixes: 8f840e47f190 (“sctp: add the sctp_diag.c file”) Signed-off-by: Pietro Borrello Acked-by: Xin Long Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b7ec3971f1832528e8612067a2a197bc15d884b3 Author: Siddharth Vadapalli Date: Thu Feb 9 14:14:32 2023 +0530 net: ethernet: ti: am65-cpsw: Add RX DMA Channel Teardown Quirk commit 0ed577e7e8e508c24e22ba07713ecc4903e147c3 upstream. In TI’s AM62x/AM64x SoCs, successful teardown of RX DMA Channel raises an interrupt. The process of servicing this interrupt involves flushing all pending RX DMA descriptors and clearing the teardown completion marker (TDCM). The am65_cpsw_nuss_rx_packets() function invoked from the RX NAPI callback services the interrupt. Thus, it is necessary to wait for this handler to run, drain all packets and clear TDCM, before calling napi_disable() in am65_cpsw_nuss_common_stop() function post channel teardown. If napi_disable() executes before ensuring that TDCM is cleared, the TDCM remains set when the interfaces are down, resulting in an interrupt storm when the interfaces are brought up again. Since the interrupt raised to indicate the RX DMA Channel teardown is specific to the AM62x and AM64x SoCs, add a quirk for it. Fixes: 4f7cce272403 (“net: ethernet: ti: am65-cpsw: add support for am64x cpsw3g”) Co-developed-by: Vignesh Raghavendra Signed-off-by: Vignesh Raghavendra Signed-off-by: Siddharth Vadapalli Reviewed-by: Roger Quadros Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ec9938d1b56e39a2e1d1381fe296c3ec647b4f5e Author: Rafał Miłecki Date: Wed Feb 8 10:16:37 2023 +0100 net: bgmac: fix BCM5358 support by setting correct flags commit d61615c366a489646a1bfe5b33455f916762d5f4 upstream. Code blocks handling BCMA_CHIP_ID_BCM5357 and BCMA_CHIP_ID_BCM53572 were incorrectly unified. Chip package values are not unique and cannot be checked independently. They are meaningful only in a context of a given chip. Packages BCM5358 and BCM47188 share the same value but then belong to different chips. Code unification resulted in treating BCM5358 as BCM47188 and broke its initialization. Link: https://github.com/openwrt/openwrt/issues/8278 Fixes: cb1b0f90acfe (“net: ethernet: bgmac: unify code of the same family”) Cc: Jon Mason Signed-off-by: Rafał Miłecki Reviewed-by: Florian Fainelli Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 5fbf79841b3f9d6b1dabf60f306f2bf494342008 Author: Jason Xing Date: Wed Feb 8 10:43:33 2023 +0800 i40e: add double of VLAN header when computing the max MTU commit ce45ffb815e8e238f05de1630be3969b6bb15e4e upstream. Include the second VLAN HLEN into account when computing the maximum MTU size as other drivers do. Fixes: 0c8493d90b6b (“i40e: add XDP support for pass and drop actions”) Signed-off-by: Jason Xing Reviewed-by: Alexander Duyck Tested-by: Chandan Kumar Rout (A Contingent Worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit 6d9f1ff81a893070f0d0e1a8b3b51d89458c8b3e Author: Jason Xing Date: Wed Feb 8 10:43:32 2023 +0800 ixgbe: allow to increase MTU to 3K with XDP enabled commit f9cd6a4418bac6a046ee78382423b1ae7565fb24 upstream. Recently I encountered one case where I cannot increase the MTU size directly from 1500 to a much bigger value with XDP enabled if the server is equipped with IXGBE card, which happened on thousands of servers in production environment. After applying the current patch, we can set the maximum MTU size to 3K. This patch follows the behavior of changing MTU as i40e/ice does. References: [1] commit 23b44513c3e6 (“ice: allow 3k MTU for XDP”) [2] commit 0c8493d90b6b (“i40e: add XDP support for pass and drop actions”) Fixes: fabf1bce103a (“ixgbe: Prevent unsupported configurations with XDP”) Signed-off-by: Jason Xing Reviewed-by: Alexander Duyck Tested-by: Chandan Kumar Rout (A Contingent Worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit a813e55c108691f8a513212666457d6b0d59927f Author: Jesse Brandeburg Date: Mon Feb 6 15:54:36 2023 -0800 ice: fix lost multicast packets in promisc mode commit 43fbca02c2ddc39ff5879b6f3a4a097b1ba02098 upstream. There was a problem reported to us where the addition of a VF with an IPv6 address ending with a particular sequence would cause the parent device on the PF to no longer be able to respond to neighbor discovery packets. In this case, we had an ovs-bridge device living on top of a VLAN, which was on top of a PF, and it would not be able to talk anymore (the neighbor entry would expire and couldn’t be restored). The root cause of the issue is that if the PF is asked to be in IFF_PROMISC mode (promiscuous mode) and it had an ipv6 address that needed the 33:33:ff:00:00:04 multicast address to work, then when the VF was added with the need for the same multicast address, the VF would steal all the traffic destined for that address. The ice driver didn’t auto-subscribe a request of IFF_PROMISC to the “multicast replication from other port’s traffic” meaning that it won’t get for instance, packets with an exact destination in the VF, as above. The VF’s IPv6 address, which adds a “perfect filter” for 33:33:ff:00:00:04, results in no packets for that multicast address making it to the PF (which is in promisc but NOT “multicast replication”). The fix is to enable “multicast promiscuous” whenever the driver is asked to enable IFF_PROMISC, and make sure to disable it when appropriate. Fixes: e94d44786693 (“ice: Implement filter sync, NDO operations and bump version”) Signed-off-by: Jesse Brandeburg Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit 2fc3ff76e96f48e5e4dd705f6794b8483f7c1624 Author: Matt Roper Date: Wed Feb 1 14:28:29 2023 -0800 drm/i915/gen11: Wa_1408615072/Wa_1407596294 should be on GT list commit d5a1224aa68c8b124a4c5c390186e571815ed390 upstream. The UNSLICE_UNIT_LEVEL_CLKGATE register programmed by this workaround has ‘BUS’ style reset, indicating that it does not lose its value on engine resets. Furthermore, this register is part of the GT forcewake domain rather than the RENDER domain, so it should not be impacted by RCS engine resets. As such, we should implement this on the GT workaround list rather than an engine list. Bspec: 19219 Fixes: 3551ff928744 ("drm/i915/gen11: Moving WAs to rcs_engine_wa_init()") Signed-off-by: Matt Roper Reviewed-by: Gustavo Sousa Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 5f21dc07b52eb54a908e66f5d6e05a87bcb5b049) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit e105b5e0d703ec66b2427e73c66727d198606f4b Author: Dave Stevenson Date: Fri Jan 27 16:57:08 2023 +0100 drm/vc4: Fix YUV plane handling when planes are in different buffers commit 6b77b16de75a6efc0870b1fa467209387cbee8f3 upstream. YUV images can either be presented as one allocation with offsets for the different planes, or multiple allocations with 0 offsets. The driver only ever calls drm_fb_[dma|cma]_get_gem_obj with plane index 0, therefore any application using the second approach was incorrectly rendered. Correctly determine the address for each plane, removing the assumption that the base address is the same for each. Fixes: fc04023fafec (“drm/vc4: Add support for YUV planes.”) Signed-off-by: Dave Stevenson Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman commit fcc6266d0da40a6931d846f7df03add0a04e30a7 Author: Dom Cobley Date: Fri Jan 27 15:55:58 2023 +0100 drm/vc4: crtc: Increase setup cost in core clock calculation to handle extreme reduced blanking commit 247a631f9c0ffb37ed0786a94cb4c5f2b6fc7ab1 upstream. The formula that determines the core clock requirement based on pixel clock and blanking has been determined experimentally to minimise the clock while supporting all modes we’ve seen. A new reduced blanking mode (4kp60 at 533MHz rather than the standard 594MHz) has been seen that doesn’t produce a high enough clock and results in “flip_done timed out” error. Increase the setup cost in the formula to make this work. The result is a reduced blanking mode increases by up to 7MHz while leaving the standard timing mode untouched Link: https://github.com/raspberrypi/linux/issues/4446 Fixes: 16e101051f32 (“drm/vc4: Increase the core clock based on HVS load”) Signed-off-by: Dom Cobley Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman commit b5aa09a0d4b70ffad526cace6f578cbafda131a8 Author: Andrew Morton Date: Thu Feb 2 18:07:35 2023 -0800 revert “squashfs: harden sanity check in squashfs_read_xattr_id_table” commit a5b21d8d791cd4db609d0bbcaa9e0c7e019888d1 upstream. This fix was nacked by Philip, for reasons identified in the email linked below. Link: https://lkml.kernel.org/r/[email protected] Fixes: 72e544b1b28325 (“squashfs: harden sanity check in squashfs_read_xattr_id_table”) Cc: Alexey Khoroshilov Cc: Fedor Pchelkin Cc: Phillip Lougher Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 3d16f4d7a1bcad5c04180ae90de7836bba478ce4 Author: Felix Riemann Date: Fri Feb 10 13:36:44 2023 +0100 net: Fix unwanted sign extension in netdev_stats_to_stats64() commit 9b55d3f0a69af649c62cbc2633e6d695bb3cc583 upstream. When converting net_device_stats to rtnl_link_stats64 sign extension is triggered on ILP32 machines as 6c1c509778 changed the previous “ulong -> u64” conversion to “long -> u64” by accessing the net_device_stats fields through a (signed) atomic_long_t. This causes for example the received bytes counter to jump to 16EiB after having received 2^31 bytes. Casting the atomic value to “unsigned long” beforehand converting it into u64 avoids this. Fixes: 6c1c5097781f (“net: add atomic_long_t to net_device_stats fields”) Signed-off-by: Felix Riemann Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2578123d5bdb7ecbb87679d82f13613173cba428 Author: Aaron Thompson Date: Tue Feb 7 08:21:51 2023 +0000 Revert “mm: Always release pages to the buddy allocator in memblock_free_late().” commit 647037adcad00f2bab8828d3d41cd0553d41f3bd upstream. This reverts commit 115d9d77bb0f9152c60b6e8646369fa7f6167593. The pages being freed by memblock_free_late() have already been initialized, but if they are in the deferred init range, __free_one_page() might access nearby uninitialized pages when trying to coalesce buddies. This can, for example, trigger this BUG: BUG: unable to handle page fault for address: ffffe964c02580c8 RIP: 0010:__list_del_entry_valid+0x3f/0x70 __free_one_page+0x139/0x410 __free_pages_ok+0x21d/0x450 memblock_free_late+0x8c/0xb9 efi_free_boot_services+0x16b/0x25c efi_enter_virtual_mode+0x403/0x446 start_kernel+0x678/0x714 secondary_startup_64_no_verify+0xd2/0xdb A proper fix will be more involved so revert this change for the time being. Fixes: 115d9d77bb0f (“mm: Always release pages to the buddy allocator in memblock_free_late().”) Signed-off-by: Aaron Thompson Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mike Rapoport (IBM) Signed-off-by: Greg Kroah-Hartman commit 0ed7b542c21c507fa170d02e3dd69837a55bffda Author: Geert Uytterhoeven Date: Mon Oct 3 11:06:57 2022 +0200 coredump: Move dump_emit_page() to kill unused warning commit 9c7417b5ec440242bb5b64521acd53d4e19130c1 upstream. If CONFIG_ELF_CORE is not set: fs/coredump.c:835:12: error: ‘dump_emit_page’ defined but not used [-Werror=unused-function] 835 | static int dump_emit_page(struct coredump_params *cprm, struct page *page) | ^~~~~~~~~~~~~~ Fix this by moving dump_emit_page() inside the existing section protected by #ifdef CONFIG_ELF_CORE. Fixes: 06bbaa6dc53cb720 ("[coredump] don’t use __kernel_write() on kmap_local_page()") Signed-off-by: Geert Uytterhoeven Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 7f9f6c54da876b3f0bece2b569456ceb96965ed7 Author: Peter Zijlstra Date: Fri Feb 3 15:31:11 2023 +0100 freezer,umh: Fix call_usermode_helper_exec() vs SIGKILL commit eedeb787ebb53de5c5dcf7b7b39d01bf1b0f037d upstream. Tetsuo-San noted that commit f5d39b020809 (“freezer,sched: Rewrite core freezer logic”) broke call_usermodehelper_exec() for the KILLABLE case. Specifically it was missed that the second, unconditional, wait_for_completion() was not optional and ensures the on-stack completion is unused before going out-of-scope. Fixes: f5d39b020809 (“freezer,sched: Rewrite core freezer logic”) Reported-by: [email protected] Reported-by: Tetsuo Handa Debugged-by: Tetsuo Handa Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman commit 854e1ecff266033d3149666d3c5b8b0e174b4210 Author: Bartosz Golaszewski Date: Fri Feb 17 12:02:26 2023 +0100 gpio: sim: fix a memory leak commit 79eeab1d85e0fee4c0bc36f3b6ddf3920f39f74b upstream. Fix an inverted logic bug in gpio_sim_remove_hogs() that leads to GPIO hog structures never being freed. Fixes: cb8c474e79be (“gpio: sim: new testing module”) Reported-by: Mirsad Goran Todorovac Signed-off-by: Bartosz Golaszewski Reviewed-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman commit 54806cb7516c2ad0cb9887a8ef1a0c4df914837f Author: Peter Xu Date: Thu Feb 16 10:30:59 2023 -0500 mm/migrate: fix wrongly apply write bit after mkdirty on sparc64 commit 96a9c287e25d690fd9623b5133703b8e310fbed1 upstream. Nick Bowler reported another sparc64 breakage after the young/dirty persistent work for page migration (per “Link:” below). That’s after a similar report [2]. It turns out page migration was overlooked, and it wasn’t failing before because page migration was not enabled in the initial report test environment. David proposed another way [2] to fix this from sparc64 side, but that patch didn’t land somehow. Neither did I check whether there’s any other arch that has similar issues. Let’s fix it for now as simple as moving the write bit handling to be after dirty, like what we did before. Note: this is based on mm-unstable, because the breakage was since 6.1 and we’re at a very late stage of 6.2 (-rc8), so I assume for this specific case we should target this at 6.3. [1] https://lore.kernel.org/all/[email protected]/ [2] https://lore.kernel.org/all/[email protected]/ Link: https://lkml.kernel.org/r/[email protected] Fixes: 2e3468778dbe (“mm: remember young/dirty bit for page migrations”) Link: https://lore.kernel.org/all/CADyTPExpEqaJiMGoV+Z6xVgL50ZoMJg49B10LcZ=8eg19u34BA@mail.gmail.com/ Signed-off-by: Peter Xu Reported-by: Nick Bowler Acked-by: David Hildenbrand Tested-by: Nick Bowler Cc: Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit d4d9bdc6946d9523a021d44de94eb58e06927cd1 Author: Qian Yingjin Date: Wed Feb 8 10:24:00 2023 +0800 mm/filemap: fix page end in filemap_get_read_batch commit 5956592ce337330cdff0399a6f8b6a5aea397a8e upstream. I was running traces of the read code against an RAID storage system to understand why read requests were being misaligned against the underlying RAID strips. I found that the page end offset calculation in filemap_get_read_batch() was off by one. When a read is submitted with end offset 1048575, then it calculates the end page for read of 256 when it should be 255. “last_index” is the index of the page beyond the end of the read and it should be skipped when get a batch of pages for read in @filemap_get_read_batch(). The below simple patch fixes the problem. This code was introduced in kernel 5.12. Link: https://lkml.kernel.org/r/[email protected] Fixes: cbd59c48ae2b (“mm/filemap: use head pages in generic_file_buffered_read”) Signed-off-by: Qian Yingjin Reviewed-by: Matthew Wilcox (Oracle) Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit fd71c8d3b005f0f5047f0c7480ee3bba12b76aa9 Author: Zach O’Keefe Date: Tue Jan 24 17:57:37 2023 -0800 mm/MADV_COLLAPSE: set EAGAIN on unexpected page refcount commit ae63c898f4004bbc7d212f4adcb3bb14852c30d6 upstream. During collapse, in a few places we check to see if a given small page has any unaccounted references. If the refcount on the page doesn’t match our expectations, it must be there is an unknown user concurrently interested in the page, and so it’s not safe to move the contents elsewhere. However, the unaccounted pins are likely an ephemeral state. In this situation, MADV_COLLAPSE returns -EINVAL when it should return -EAGAIN. This could cause userspace to conclude that the syscall failed, when it in fact could succeed by retrying. Link: https://lkml.kernel.org/r/[email protected] Fixes: 7d8faaf15545 (“mm/madvise: introduce MADV_COLLAPSE sync hugepage collapse”) Signed-off-by: Zach O’Keefe Reported-by: Hugh Dickins Acked-by: Hugh Dickins Reviewed-by: Yang Shi Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit a8ef5109f93cea9933bbac0455d8c18757b3fcb4 Author: Ryusuke Konishi Date: Wed Feb 15 07:40:43 2023 +0900 nilfs2: fix underflow in second superblock position calculations commit 99b9402a36f0799f25feee4465bfa4b8dfa74b4d upstream. Macro NILFS_SB2_OFFSET_BYTES, which computes the position of the second superblock, underflows when the argument device size is less than 4096 bytes. Therefore, when using this macro, it is necessary to check in advance that the device size is not less than a lower limit, or at least that underflow does not occur. The current nilfs2 implementation lacks this check, causing out-of-bound block access when mounting devices smaller than 4096 bytes: I/O error, dev loop0, sector 36028797018963960 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 NILFS (loop0): unable to read secondary superblock (blocksize = 1024) In addition, when trying to resize the filesystem to a size below 4096 bytes, this underflow occurs in nilfs_resize_fs(), passing a huge number of segments to nilfs_sufile_resize(), corrupting parameters such as the number of segments in superblocks. This causes excessive loop iterations in nilfs_sufile_resize() during a subsequent resize ioctl, causing semaphore ns_segctor_sem to block for a long time and hang the writer thread: INFO: task segctord:5067 blocked for more than 143 seconds. Not tainted 6.2.0-rc8-syzkaller-00015-gf6feea56f66d #0 “echo 0 > /proc/sys/kernel/hung_task_timeout_secs” disables this message. task:segctord state:D stack:23456 pid:5067 ppid:2 flags:0x00004000 Call Trace: context_switch kernel/sched/core.c:5293 [inline] __schedule+0x1409/0x43f0 kernel/sched/core.c:6606 schedule+0xc3/0x190 kernel/sched/core.c:6682 rwsem_down_write_slowpath+0xfcf/0x14a0 kernel/locking/rwsem.c:1190 nilfs_transaction_lock+0x25c/0x4f0 fs/nilfs2/segment.c:357 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2486 [inline] nilfs_segctor_thread+0x52f/0x1140 fs/nilfs2/segment.c:2570 kthread+0x270/0x300 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 … Call Trace: folio_mark_accessed+0x51c/0xf00 mm/swap.c:515 __nilfs_get_page_block fs/nilfs2/page.c:42 [inline] nilfs_grab_buffer+0x3d3/0x540 fs/nilfs2/page.c:61 nilfs_mdt_submit_block+0xd7/0x8f0 fs/nilfs2/mdt.c:121 nilfs_mdt_read_block+0xeb/0x430 fs/nilfs2/mdt.c:176 nilfs_mdt_get_block+0x12d/0xbb0 fs/nilfs2/mdt.c:251 nilfs_sufile_get_segment_usage_block fs/nilfs2/sufile.c:92 [inline] nilfs_sufile_truncate_range fs/nilfs2/sufile.c:679 [inline] nilfs_sufile_resize+0x7a3/0x12b0 fs/nilfs2/sufile.c:777 nilfs_resize_fs+0x20c/0xed0 fs/nilfs2/super.c:422 nilfs_ioctl_resize fs/nilfs2/ioctl.c:1033 [inline] nilfs_ioctl+0x137c/0x2440 fs/nilfs2/ioctl.c:1301 … This fixes these issues by inserting appropriate minimum device size checks or anti-underflow checks, depending on where the macro is used. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ryusuke Konishi Reported-by: Tested-by: Ryusuke Konishi Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 0047bcac7af7aea48a5ae06b5fdc997c36b07a54 Author: Mike Kravetz Date: Wed Feb 15 17:35:42 2023 -0800 hugetlb: check for undefined shift on 32 bit architectures commit ec4288fe63966b26d53907212ecd05dfa81dd2cc upstream. Users can specify the hugetlb page size in the mmap, shmget and memfd_create system calls. This is done by using 6 bits within the flags argument to encode the base-2 logarithm of the desired page size. The routine hstate_sizelog() uses the log2 value to find the corresponding hugetlb hstate structure. Converting the log2 value (page_size_log) to potential hugetlb page size is the simple statement: 1UL << page_size_log Because only 6 bits are used for page_size_log, the left shift can not be greater than 63. This is fine on 64 bit architectures where a long is 64 bits. However, if a value greater than 31 is passed on a 32 bit architecture (where long is 32 bits) the shift will result in undefined behavior. This was generally not an issue as the result of the undefined shift had to exactly match hugetlb page size to proceed. Recent improvements in runtime checking have resulted in this undefined behavior throwing errors such as reported below. Fix by comparing page_size_log to BITS_PER_LONG before doing shift. Link: https://lkml.kernel.org/r/[email protected] Link: https://lore.kernel.org/lkml/CA+G9fYuei_Tr-vN9GS7SfFyU1y9hNysnf=PB7kT0=yv4MiPgVg@mail.gmail.com/ Fixes: 42d7395feb56 (“mm: support more pagesizes for MAP_HUGETLB/SHM_HUGETLB”) Signed-off-by: Mike Kravetz Reported-by: Naresh Kamboju Reviewed-by: Jesper Juhl Acked-by: Muchun Song Tested-by: Linux Kernel Functional Testing Tested-by: Naresh Kamboju Cc: Anders Roxell Cc: Andi Kleen Cc: Sasha Levin Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit c6879a4dcefe92d870ab68cabaa9caeda4f2af5a Author: Munehisa Kamata Date: Tue Feb 14 13:27:05 2023 -0800 sched/psi: Fix use-after-free in ep_remove_wait_queue() commit c2dbe32d5db5c4ead121cf86dabd5ab691fb47fe upstream. If a non-root cgroup gets removed when there is a thread that registered trigger and is polling on a pressure file within the cgroup, the polling waitqueue gets freed in the following path: do_rmdir cgroup_rmdir kernfs_drain_open_files cgroup_file_release cgroup_pressure_release psi_trigger_destroy However, the polling thread still has a reference to the pressure file and will access the freed waitqueue when the file is closed or upon exit: fput ep_eventpoll_release ep_free ep_remove_wait_queue remove_wait_queue This results in use-after-free as pasted below. The fundamental problem here is that cgroup_file_release() (and consequently waitqueue’s lifetime) is not tied to the file’s real lifetime. Using wake_up_pollfree() here might be less than ideal, but it is in line with the comment at commit 42288cb44c4b ("wait: add wake_up_pollfree()") since the waitqueue’s lifetime is not tied to file’s one and can be considered as another special case. While this would be fixable by somehow making cgroup_file_release() be tied to the fput(), it would require sizable refactoring at cgroups or higher layer which might be more justifiable if we identify more cases like this. BUG: KASAN: use-after-free in _raw_spin_lock_irqsave+0x60/0xc0 Write of size 4 at addr ffff88810e625328 by task a.out/4404 CPU: 19 PID: 4404 Comm: a.out Not tainted 6.2.0-rc6 #38 Hardware name: Amazon EC2 c5a.8xlarge/, BIOS 1.0 10/16/2017 Call Trace: dump_stack_lvl+0x73/0xa0 print_report+0x16c/0x4e0 kasan_report+0xc3/0xf0 kasan_check_range+0x2d2/0x310 _raw_spin_lock_irqsave+0x60/0xc0 remove_wait_queue+0x1a/0xa0 ep_free+0x12c/0x170 ep_eventpoll_release+0x26/0x30 __fput+0x202/0x400 task_work_run+0x11d/0x170 do_exit+0x495/0x1130 do_group_exit+0x100/0x100 get_signal+0xd67/0xde0 arch_do_signal_or_restart+0x2a/0x2b0 exit_to_user_mode_prepare+0x94/0x100 syscall_exit_to_user_mode+0x20/0x40 do_syscall_64+0x52/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Allocated by task 4404: kasan_set_track+0x3d/0x60 __kasan_kmalloc+0x85/0x90 psi_trigger_create+0x113/0x3e0 pressure_write+0x146/0x2e0 cgroup_file_write+0x11c/0x250 kernfs_fop_write_iter+0x186/0x220 vfs_write+0x3d8/0x5c0 ksys_write+0x90/0x110 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Freed by task 4407: kasan_set_track+0x3d/0x60 kasan_save_free_info+0x27/0x40 ____kasan_slab_free+0x11d/0x170 slab_free_freelist_hook+0x87/0x150 __kmem_cache_free+0xcb/0x180 psi_trigger_destroy+0x2e8/0x310 cgroup_file_release+0x4f/0xb0 kernfs_drain_open_files+0x165/0x1f0 kernfs_drain+0x162/0x1a0 __kernfs_remove+0x1fb/0x310 kernfs_remove_by_name_ns+0x95/0xe0 cgroup_addrm_files+0x67f/0x700 cgroup_destroy_locked+0x283/0x3c0 cgroup_rmdir+0x29/0x100 kernfs_iop_rmdir+0xd1/0x140 vfs_rmdir+0xfe/0x240 do_rmdir+0x13d/0x280 __x64_sys_rmdir+0x2c/0x30 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Fixes: 0e94682b73bf (“psi: introduce psi monitor”) Signed-off-by: Munehisa Kamata Signed-off-by: Mengchi Cheng Signed-off-by: Ingo Molnar Acked-by: Suren Baghdasaryan Acked-by: Peter Zijlstra Cc: [email protected] Link: https://lore.kernel.org/lkml/[email protected]/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman commit bd302d7db300a89e0b419ce6fc83c739e04aff16 Author: Patrick McLean Date: Fri Feb 10 13:51:51 2023 -0800 ata: libata-core: Disable READ LOG DMA EXT for Samsung MZ7LH commit ead089577e0f55b238f980d9f62eaa90b7b64672 upstream. Samsung MZ7LH drives are spewing messages like this in to dmesg with AMD SATA controllers: ata1.00: exception Emask 0x0 SAct 0x7e0000 SErr 0x0 action 0x6 frozen ata1.00: failed command: SEND FPDMA QUEUED ata1.00: cmd 64/01:88:00:00:00/00:00:00:00:00/a0 tag 17 ncq dma 512 out res 40/00:01:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) Since this was seen previously with SSD 840 EVO drives in https://bugzilla.kernel.org/show_bug.cgi?id=203475 let’s add the same fix for these drives as the EVOs have, since they likely have very similar firmwares. Signed-off-by: Patrick McLean Signed-off-by: Damien Le Moal Signed-off-by: Greg Kroah-Hartman commit 939640b997438ea2214d71f644f8d34759f6dc3e Author: Simon Gaiser Date: Mon Feb 13 11:24:49 2023 +0100 ata: ahci: Add Tiger Lake UP{3,4} AHCI controller commit 104ff59af73aba524e57ae0fef70121643ff270e upstream. Mark the Tiger Lake UP{3,4} AHCI controller as "low_power". This enables S0ix to work out of the box. Otherwise this isn’t working unless the user manually sets /sys/class/scsi_host/*/link_power_management_policy. Intel lists a total of 4 SATA controller IDs in [1] for those mobile PCHs. This commit just adds the “AHCI” variant since I only tested those. [1]: https://cdrdv2.intel.com/v1/dl/getContent/631119 Signed-off-by: Simon Gaiser CC: [email protected] Signed-off-by: Damien Le Moal Signed-off-by: Greg Kroah-Hartman commit 6f07db9550a6c3b32712def0701f1708b9db054d Author: Andy Chi Date: Tue Feb 14 22:04:31 2023 +0800 ALSA: hda/realtek: Enable mute/micmute LEDs and speaker support for HP Laptops commit 9251584af09285133bec0595e5c7218fe2e595c9 upstream. On HP Laptops, requires the ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED quirk to make its audio LEDs and speaker work. Signed-off-by: Andy Chi Cc: Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 789597ef058d4f860f05944166df47b2792cdcb8 Author: Andy Chi Date: Tue Feb 14 11:58:51 2023 +0800 ALSA: hda/realtek: fix mute/micmute LEDs don’t work for a HP platform. commit 5007b848ff2234ff7ea55755cb315766888988da upstream. There is a HP platform needs ALC236_FIXUP_HP_GPIO_LED quirk to make mic-mute/audio-mute working. Signed-off-by: Andy Chi Cc: Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9755eefe8ae01b58b4706b9fd7823336a1ffab81 Author: Kailang Yang Date: Mon Feb 13 14:54:22 2023 +0800 ALSA: hda/realtek - fixed wrong gpio assigned commit 2bdccfd290d421b50df4ec6a68d832dad1310748 upstream. GPIO2 PIN use for output. Mask Dir and Data need to assign for 0x4. Not 0x3. This fixed was for Lenovo Desktop(0x17aa1056). GPIO2 use for AMP enable. Signed-off-by: Kailang Yang Cc: Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c1de4def2e8875acaf433a443383d12d1d7725e1 Author: Bo Liu Date: Thu Feb 9 10:13:48 2023 +0800 ALSA: hda/conexant: add a new hda codec SN6180 commit 18d7e16c917a08f08778ecf2b780d63648d5d923 upstream. The current kernel does not support the SN6180 codec chip. Add the SN6180 codec configuration item to kernel. Signed-off-by: Bo Liu Cc: Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e0089167543ea67896ed710dfd732a0949a33d5a Author: Cezary Rojewski Date: Fri Feb 10 17:55:41 2023 +0100 ALSA: hda: Fix codec device field initializan commit 3af4a4f7a20c94009adba65764fa5a0269d70a82 upstream. Commit f2bd1c5ae2cb ("ALSA: hda: Fix page fault in snd_hda_codec_shutdown()") relocated initialization of several codec device fields. Due to differences between codec_exec_verb() and snd_hdac_bus_exec_bus() in how they handle VERB execution - the latter does not touch PM - assigning ->exec_verb to codec_exec_verb() causes PM to be engaged before it is configured for the device. Configuration of PM for the ASoC HDAudio sound card is done with snd_hda_set_power_save() during skl_hda_audio_probe() whereas the assignment happens early, in snd_hda_codec_device_init(). Revert to previous behavior to avoid problems caused by too early PM manipulation. Suggested-by: Jason Montleon Link: https://lore.kernel.org/regressions/CALFERdzKUodLsm6=Ub3g2+PxpNpPtPq3bGBLbff=eZr9_S=YVA@mail.gmail.com Fixes: f2bd1c5ae2cb ("ALSA: hda: Fix page fault in snd_hda_codec_shutdown()") Signed-off-by: Cezary Rojewski Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 82645bf4ed02abe930a659c5fe16d593a6dbd93f Author: Yang Yingliang Date: Tue Jan 31 09:38:35 2023 +0800 mmc: mmc_spi: fix error handling in mmc_spi_probe() commit cf4c9d2ac1e42c7d18b921bec39486896645b714 upstream. If mmc_add_host() fails, it doesn’t need to call mmc_remove_host(), or it will cause null-ptr-deref, because of deleting a not added device in mmc_remove_host(). To fix this, goto label 'fail_glue_init’, if mmc_add_host() fails, and change the label ‘fail_add_host’ to 'fail_gpiod_request’. Fixes: 15a0580ced08 (“mmc_spi host driver”) Signed-off-by: Yang Yingliang Cc:[email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit f855d31bb38d663c3ba672345d7cce9324ba3b72 Author: Yang Yingliang Date: Mon Jan 30 20:58:08 2023 +0800 mmc: sdio: fix possible resource leaks in some error paths commit 605d9fb9556f8f5fb4566f4df1480f280f308ded upstream. If sdio_add_func() or sdio_init_func() fails, sdio_remove_func() can not release the resources, because the sdio function is not presented in these two cases, it won’t call of_node_put() or put_device(). To fix these leaks, make sdio_func_present() only control whether device_del() needs to be called or not, then always call of_node_put() and put_device(). In error case in sdio_init_func(), the reference of ‘card->dev’ is not get, to avoid redundant put in sdio_free_func_cis(), move the get_device() to sdio_alloc_func() and put_device() to sdio_release_func(), it can keep the get/put function be balanced. Without this patch, while doing fault inject test, it can get the following leak reports, after this fix, the leak is gone. unreferenced object 0xffff888112514000 (size 2048): comm "kworker/3:2", pid 65, jiffies 4294741614 (age 124.774s) hex dump (first 32 bytes): 00 e0 6f 12 81 88 ff ff 60 58 8d 06 81 88 ff ff …o…`X… 10 40 51 12 81 88 ff ff 10 40 51 12 81 88 ff ff .@Q…@Q… backtrace: [<000000009e5931da>] kmalloc_trace+0x21/0x110 [<000000002f839ccb>] mmc_alloc_card+0x38/0xb0 [mmc_core] [<0000000004adcbf6>] mmc_sdio_init_card+0xde/0x170 [mmc_core] [<000000007538fea0>] mmc_attach_sdio+0xcb/0x1b0 [mmc_core] [<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core] unreferenced object 0xffff888112511000 (size 2048): comm "kworker/3:2", pid 65, jiffies 4294741623 (age 124.766s) hex dump (first 32 bytes): 00 40 51 12 81 88 ff ff e0 58 8d 06 81 88 ff ff .@Q…X… 10 10 51 12 81 88 ff ff 10 10 51 12 81 88 ff ff …Q…Q… backtrace: [<000000009e5931da>] kmalloc_trace+0x21/0x110 [<00000000fcbe706c>] sdio_alloc_func+0x35/0x100 [mmc_core] [<00000000c68f4b50>] mmc_attach_sdio.cold.18+0xb1/0x395 [mmc_core] [<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core] Fixes: 3d10a1ba0d37 ("sdio: fix reference counting in sdio_remove_func()") Signed-off-by: Yang Yingliang Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 0de3e53eab9529a0338b1d552fbc1f8e95082fac Author: Heiner Kallweit Date: Mon Feb 13 21:55:56 2023 +0100 mmc: meson-gx: fix SDIO mode if cap_sdio_irq isn’t set commit 6ea6b95a7e3ec2015954cb514ee9dbc6dc80ec8f upstream. Some SDIO WiFi modules stopped working after SDIO interrupt mode was added if cap_sdio_irq isn’t set in device tree. This patch was confirmed to fix the issue. Fixes: 066ecde6d826 (“mmc: meson-gx: add SDIO interrupt support”) Reported-by: Geraldo Nascimento Tested-by: Geraldo Nascimento Cc: [email protected] Signed-off-by: Heiner Kallweit Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 459980cc1448f9ed36846cc93a0604b37208ae79 Author: Paul Cercueil Date: Tue Jan 31 21:02:28 2023 +0000 mmc: jz4740: Work around bug on JZ4760(B) commit 3f18c5046e633cc4bbad396b74c05d46d353033d upstream. On JZ4760 and JZ4760B, SD cards fail to run if the maximum clock rate is set to 50 MHz, even though the controller officially does support it. Until the actual bug is found and fixed, limit the maximum clock rate to 24 MHz. Signed-off-by: Paul Cercueil Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 0a127ac972404600c99eb141c8d5b5348e53ee4f Author: Zack Rusin Date: Sat Feb 11 00:05:14 2023 -0500 drm/vmwgfx: Do not drop the reference to the handle too soon commit a950b989ea29ab3b38ea7f6e3d2540700a3c54e8 upstream. v3: Fix vmw_user_bo_lookup which was also dropping the gem reference before the kernel was done with buffer depending on userspace doing the right thing. Same bug, different spot. It is possible for userspace to predict the next buffer handle and to destroy the buffer while it’s still used by the kernel. Delay dropping the internal reference on the buffers until kernel is done with them. Instead of immediately dropping the gem reference in vmw_user_bo_lookup and vmw_gem_object_create_with_handle let the callers decide when they’re ready give the control back to userspace. Also fixes the second usage of vmw_gem_object_create_with_handle in vmwgfx_surface.c which wasn’t grabbing an explicit reference to the gem object which could have been destroyed by the userspace on the owning surface at any point. Signed-off-by: Zack Rusin Fixes: 8afa13a0583f (“drm/vmwgfx: Implement DRIVER_GEM”) Reviewed-by: Martin Krastev Reviewed-by: Maaz Mombasawala Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 9ef8d83e8e25d5f1811b3a38eb1484f85f64296c) Cc: # v5.17+ Signed-off-by: Greg Kroah-Hartman commit 14a14da042ddbbb07e879abc834a60e839f7642c Author: Zack Rusin Date: Wed Feb 8 13:00:50 2023 -0500 drm/vmwgfx: Stop accessing buffer objects which failed init commit 1a6897921f52ceb2c8665ef826e405bd96385159 upstream. ttm_bo_init_reserved on failure puts the buffer object back which causes it to be deleted, but kfree was still being called on the same buffer in vmw_bo_create leading to a double free. After the double free the vmw_gem_object_create_with_handle was setting the gem function objects before checking the return status of vmw_bo_create leading to null pointer access. Fix the entire path by relaying on ttm_bo_init_reserved to delete the buffer objects on failure and making sure the return status is checked before setting the gem function objects on the buffer object. Signed-off-by: Zack Rusin Fixes: 8afa13a0583f (“drm/vmwgfx: Implement DRIVER_GEM”) Reviewed-by: Maaz Mombasawala Reviewed-by: Martin Krastev Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 36d421e632e9a0e8375eaed0143551a34d81a7e3) Cc: # v5.17+ Signed-off-by: Greg Kroah-Hartman commit 020eccac747e30a35f1fdd4dc6f18425ff1a5870 Author: Leo Li Date: Thu Feb 9 12:15:21 2023 -0500 drm/amd/display: Fail atomic_check early on normalize_zpos error commit 2a00299e7447395d0898e7c6214817c06a61a8e8 upstream. [Why] drm_atomic_normalize_zpos() can return an error code when there’s modeset lock contention. This was being ignored. [How] Bail out of atomic check if normalize_zpos() returns an error. Fixes: b261509952bc (“drm/amd/display: Fix double cursor on non-video RGB MPO”) Signed-off-by: Leo Li Tested-by: Mikhail Gavrilov Reviewed-by: Hamza Mahfooz Signed-off-by: Alex Deucher Cc: [email protected] Signed-off-by: Greg Kroah-Hartman commit dbe3529e816ee77a19fb6636e762b1dadbd02d10 Author: Jack Xiao Date: Fri Feb 10 10:31:32 2023 +0800 drm/amd/amdgpu: fix warning during suspend commit 8f32378986218812083b127da5ba42d48297d7c4 upstream. Freeing memory was warned during suspend. Move the self test out of suspend. Link: https://bugzilla.redhat.com/show_bug.cgi?id=2151825 Cc: [email protected] Signed-off-by: Jack Xiao Reviewed-by: Christian König Reviewed-by: Feifei Xu Reviewed-and-tested-by: Evan Quan Tested-by: Jocelyn Falempe Signed-off-by: Alex Deucher Cc: [email protected] # 6.1.x Signed-off-by: Greg Kroah-Hartman commit 8da6df028d53c3d3ebde37c99c33d028f8ba3a8f Author: Ville Syrjälä Date: Tue Feb 7 16:33:37 2023 +0200 drm: Disable dynamic debug as broken commit bb2ff6c27bc9e1da4d3ec5e7b1d6b9df1092cb5a upstream. CONFIG_DRM_USE_DYNAMIC_DEBUG breaks debug prints for (at least modular) drm drivers. The debug prints can be reinstated by manually frobbing /sys/module/drm/parameters/debug after the fact, but at that point the damage is done and all debugs from driver probe are lost. This makes drivers totally undebuggable. There’s a more complete fix in progress [1], with further details, but we need this fixed in stable kernels. Mark the feature as broken and disable it by default, with hopes distros follow suit and disable it as well. [1] https://lore.kernel.org/r/[email protected] Fixes: 84ec67288c10 (“drm_print: wrap drm_*_dbg in dyndbg descriptor factory macro”) Cc: Jim Cromie Cc: Greg Kroah-Hartman Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Cc: [email protected] Cc: # v6.1+ Signed-off-by: Ville Syrjälä Acked-by: Greg Kroah-Hartman Acked-by: Jim Cromie Acked-by: Maxime Ripard Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman commit f1d91f0e9d5a240a809698d7d9c5a538e7dcc149 Author: Takashi Iwai Date: Sun Jan 29 09:28:56 2023 +0100 fbdev: Fix invalid page access after closing deferred I/O devices commit 3efc61d95259956db25347e2a9562c3e54546e20 upstream. When a fbdev with deferred I/O is once opened and closed, the dirty pages still remain queued in the pageref list, and eventually later those may be processed in the delayed work. This may lead to a corruption of pages, hitting an Oops. This patch makes sure to cancel the delayed work and clean up the pageref list at closing the device for addressing the bug. A part of the cleanup code is factored out as a new helper function that is called from the common fb_release(). Reviewed-by: Patrik Jakobsson Cc: Signed-off-by: Takashi Iwai Tested-by: Miko Larsson Fixes: 56c134f7f1b5 (“fbdev: Track deferred-I/O pages in pageref struct”) Reviewed-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman commit eb80a7f34f3a48158f0536137551ab346f186324 Author: Ronak Doshi Date: Wed Feb 8 14:38:59 2023 -0800 vmxnet3: move rss code block under eop descriptor commit ec76d0c2da5c6dfb6a33f1545cc15997013923da upstream. Commit b3973bb40041 (“vmxnet3: set correct hash type based on rss information”) added hashType information into skb. However, rssType field is populated for eop descriptor. This can lead to incorrectly reporting of hashType for packets which use multiple rx descriptors. Multiple rx descriptors are used for Jumbo frame or LRO packets, which can hit this issue. This patch moves the RSS codeblock under eop descritor. Cc: [email protected] Fixes: b3973bb40041 (“vmxnet3: set correct hash type based on rss information”) Signed-off-by: Ronak Doshi Acked-by: Peng Li Acked-by: Guolin Yang Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit af126acf01a12bdb04986fd26fc2eb3b40249e0d Author: Seth Jenkins Date: Tue Jan 31 12:25:55 2023 -0500 aio: fix mremap after fork null-deref commit 81e9d6f8647650a7bead74c5f926e29970e834d1 upstream. Commit e4a0d3e720e7 (“aio: Make it possible to remap aio ring”) introduced a null-deref if mremap is called on an old aio mapping after fork as mm->ioctx_table will be set to NULL. [[email protected]: fix 80 column issue] Link: https://lkml.kernel.org/r/[email protected] Fixes: e4a0d3e720e7 (“aio: Make it possible to remap aio ring”) Signed-off-by: Seth Jenkins Signed-off-by: Jeff Moyer Cc: Alexander Viro Cc: Benjamin LaHaise Cc: Jann Horn Cc: Pavel Emelyanov Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 86e3baf6a6a2b8c145f17dad7df7c6af2d6cc293 Author: Qi Zheng Date: Thu Feb 2 18:56:12 2023 +0800 mm: shrinkers: fix deadlock in shrinker debugfs commit badc28d4924bfed73efc93f716a0c3aa3afbdf6f upstream. The debugfs_remove_recursive() is invoked by unregister_shrinker(), which is holding the write lock of shrinker_rwsem. It will waits for the handler of debugfs file complete. The handler also needs to hold the read lock of shrinker_rwsem to do something. So it may cause the following deadlock: CPU0 CPU1 debugfs_file_get() shrinker_debugfs_count_show()/shrinker_debugfs_scan_write() unregister_shrinker() --> down_write(&shrinker_rwsem); debugfs_remove_recursive() // wait for (A) --> wait_for_completion(); // wait for (B) --> down_read_killable(&shrinker_rwsem) debugfs_file_put() – (A) up_write() – (B) The down_read_killable() can be killed, so that the above deadlock can be recovered. But it still requires an extra kill action, otherwise it will block all subsequent shrinker-related operations, so it’s better to fix it. [[email protected]: fix CONFIG_SHRINKER_DEBUG=n stub] Link: https://lkml.kernel.org/r/[email protected] Fixes: 5035ebc644ae (“mm: shrinkers: introduce debugfs interface for memory shrinkers”) Signed-off-by: Qi Zheng Reviewed-by: Roman Gushchin Cc: Kent Overstreet Cc: Muchun Song Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit b184caaf62aa4ee6a5932eee555e630f34880616 Author: Christophe Leroy Date: Thu Jan 26 08:04:47 2023 +0100 kasan: fix Oops due to missing calls to kasan_arch_is_ready() commit 55d77bae73426237b3c74c1757a894b056550dff upstream. On powerpc64, you can build a kernel with KASAN as soon as you build it with RADIX MMU support. However if the CPU doesn’t have RADIX MMU, KASAN isn’t enabled at init and the following Oops is encountered. [ 0.000000][ T0] KASAN not enabled as it requires radix! [ 4.484295][ T26] BUG: Unable to handle kernel data access at 0xc00e000000804a04 [ 4.485270][ T26] Faulting instruction address: 0xc00000000062ec6c [ 4.485748][ T26] Oops: Kernel access of bad area, sig: 11 [#1] [ 4.485920][ T26] BE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries [ 4.486259][ T26] Modules linked in: [ 4.486637][ T26] CPU: 0 PID: 26 Comm: kworker/u2:2 Not tainted 6.2.0-rc3-02590-gf8a023b0a805 #249 [ 4.486907][ T26] Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1200 0xf000005 of:SLOF,HEAD pSeries [ 4.487445][ T26] Workqueue: eval_map_wq .tracer_init_tracefs_work_func [ 4.488744][ T26] NIP: c00000000062ec6c LR: c00000000062bb84 CTR: c0000000002ebcd0 [ 4.488867][ T26] REGS: c0000000049175c0 TRAP: 0380 Not tainted (6.2.0-rc3-02590-gf8a023b0a805) [ 4.489028][ T26] MSR: 8000000002009032 CR: 44002808 XER: 00000000 [ 4.489584][ T26] CFAR: c00000000062bb80 IRQMASK: 0 [ 4.489584][ T26] GPR00: c0000000005624d4 c000000004917860 c000000001cfc000 1800000000804a04 [ 4.489584][ T26] GPR04: c0000000003a2650 0000000000000cc0 c00000000000d3d8 c00000000000d3d8 [ 4.489584][ T26] GPR08: c0000000049175b0 a80e000000000000 0000000000000000 0000000017d78400 [ 4.489584][ T26] GPR12: 0000000044002204 c000000003790000 c00000000435003c c0000000043f1c40 [ 4.489584][ T26] GPR16: c0000000043f1c68 c0000000043501a0 c000000002106138 c0000000043f1c08 [ 4.489584][ T26] GPR20: c0000000043f1c10 c0000000043f1c20 c000000004146c40 c000000002fdb7f8 [ 4.489584][ T26] GPR24: c000000002fdb834 c000000003685e00 c000000004025030 c000000003522e90 [ 4.489584][ T26] GPR28: 0000000000000cc0 c0000000003a2650 c000000004025020 c000000004025020 [ 4.491201][ T26] NIP [c00000000062ec6c] .kasan_byte_accessible+0xc/0x20 [ 4.491430][ T26] LR [c00000000062bb84] .__kasan_check_byte+0x24/0x90 [ 4.491767][ T26] Call Trace: [ 4.491941][ T26] [c000000004917860] [c00000000062ae70] .__kasan_kmalloc+0xc0/0x110 (unreliable) [ 4.492270][ T26] [c0000000049178f0] [c0000000005624d4] .krealloc+0x54/0x1c0 [ 4.492453][ T26] [c000000004917990] [c0000000003a2650] .create_trace_option_files+0x280/0x530 [ 4.492613][ T26] [c000000004917a90] [c000000002050d90] .tracer_init_tracefs_work_func+0x274/0x2c0 [ 4.492771][ T26] [c000000004917b40] [c0000000001f9948] .process_one_work+0x578/0x9f0 [ 4.492927][ T26] [c000000004917c30] [c0000000001f9ebc] .worker_thread+0xfc/0x950 [ 4.493084][ T26] [c000000004917d60] [c00000000020be84] .kthread+0x1a4/0x1b0 [ 4.493232][ T26] [c000000004917e10] [c00000000000d3d8] .ret_from_kernel_thread+0x58/0x60 [ 4.495642][ T26] Code: 60000000 7cc802a6 38a00000 4bfffc78 60000000 7cc802a6 38a00001 4bfffc68 60000000 3d20a80e 7863e8c2 792907c6 <7c6348ae> 20630007 78630fe0 68630001 [ 4.496704][ T26] —[ end trace 0000000000000000 ]— The Oops is due to kasan_byte_accessible() not checking the readiness of KASAN. Add missing call to kasan_arch_is_ready() and bail out when not ready. The same problem is observed with ____kasan_kfree_large() so fix it the same. Also, as KASAN is not available and no shadow area is allocated for linear memory mapping, there is no point in allocating shadow mem for vmalloc memory as shown below in /sys/kernel/debug/kernel_page_tables —[ kasan shadow mem start ]— 0xc00f000000000000-0xc00f00000006ffff 0x00000000040f0000 448K r w pte valid present dirty accessed 0xc00f000000860000-0xc00f00000086ffff 0x000000000ac10000 64K r w pte valid present dirty accessed 0xc00f3ffffffe0000-0xc00f3fffffffffff 0x0000000004d10000 128K r w pte valid present dirty accessed —[ kasan shadow mem end ]— So, also verify KASAN readiness before allocating and poisoning shadow mem for VMAs. Link: https://lkml.kernel.org/r/150768c55722311699fdcf8f5379e8256749f47d.1674716617.git.christophe.leroy@csgroup.eu Fixes: 41b7a347bf14 (“powerpc: Book3S 64-bit outline-only KASAN support”) Signed-off-by: Christophe Leroy Reported-by: Nathan Lynch Suggested-by: Michael Ellerman Cc: Alexander Potapenko Cc: Andrey Konovalov Cc: Andrey Ryabinin Cc: Dmitry Vyukov Cc: Vincenzo Frascino Cc: [5.19+] Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 50b21bba362647b7a8ae71e3e06cf26eeeae2053 Author: Isaac J. Manjarres Date: Wed Feb 8 15:20:00 2023 -0800 of: reserved_mem: Have kmemleak ignore dynamically allocated reserved mem commit ce4d9a1ea35ac5429e822c4106cb2859d5c71f3e upstream. Patch series "Fix kmemleak crashes when scanning CMA regions", v2. When trying to boot a device with an ARM64 kernel with the following config options enabled: CONFIG_DEBUG_PAGEALLOC=y CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT=y CONFIG_DEBUG_KMEMLEAK=y a crash is encountered when kmemleak starts to scan the list of gray or allocated objects that it maintains. Upon closer inspection, it was observed that these page-faults always occurred when kmemleak attempted to scan a CMA region. At the moment, kmemleak is made aware of CMA regions that are specified through the devicetree to be dynamically allocated within a range of addresses. However, kmemleak should not need to scan CMA regions or any reserved memory region, as those regions can be used for DMA transfers between drivers and peripherals, and thus wouldn’t contain anything useful for kmemleak. Additionally, since CMA regions are unmapped from the kernel’s address space when they are freed to the buddy allocator at boot when CONFIG_DEBUG_PAGEALLOC is enabled, kmemleak shouldn’t attempt to access those memory regions, as that will trigger a crash. Thus, kmemleak should ignore all dynamically allocated reserved memory regions. This patch (of 1): Currently, kmemleak ignores dynamically allocated reserved memory regions that don’t have a kernel mapping. However, regions that do retain a kernel mapping (e.g. CMA regions) do get scanned by kmemleak. This is not ideal for two reasons: 1 kmemleak works by scanning memory regions for pointers to allocated objects to determine if those objects have been leaked or not. However, reserved memory regions can be used between drivers and peripherals for DMA transfers, and thus, would not contain pointers to allocated objects, making it unnecessary for kmemleak to scan these reserved memory regions. 2 When CONFIG_DEBUG_PAGEALLOC is enabled, along with kmemleak, the CMA reserved memory regions are unmapped from the kernel’s address space when they are freed to buddy at boot. These CMA reserved regions are still tracked by kmemleak, however, and when kmemleak attempts to scan them, a crash will happen, as accessing the CMA region will result in a page-fault, since the regions are unmapped. Thus, use kmemleak_ignore_phys() for all dynamically allocated reserved memory regions, instead of those that do not have a kernel mapping associated with them. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Fixes: a7259df76702 (“memblock: make memblock_find_in_range method private”) Signed-off-by: Isaac J. Manjarres Acked-by: Mike Rapoport (IBM) Acked-by: Catalin Marinas Cc: Frank Rowand Cc: Kirill A. Shutemov Cc: Nick Kossifidis Cc: Rafael J. Wysocki Cc: Rob Herring Cc: Russell King (Oracle) Cc: Saravana Kannan Cc: [5.15+] Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 421eea6b41adbeddc236515917f131d39632d7ab Author: Matthieu Baerts Date: Tue Feb 14 17:05:10 2023 +0100 selftests: mptcp: userspace: fix v4-v6 test in v6.1 The commit 4656d72c1efa (“selftests: mptcp: userspace: validate v4-v6 subflows mix”) has been backported to v6.1.8 without any conflicts. But it looks like it was depending on a previous one: commit 1cc94ac1af4b (“selftests: mptcp: make evts global in userspace_pm”) Without it, the test fails with: ./userspace_pm.sh: line 788: : No such file or directory # ADD_ADDR4 id:14 10.0.2.1 (ns1) => ns2, reuse port [FAIL] sed: can’t read : No such file or directory This dependence refactors the way the monitoring files are being created: only once for all the different sub-tests instead of per sub-test. It is probably better to avoid backporting the refactoring. That is why the new sub-test has been adapted to work using the previous way that is still in place here in v6.1: the monitoring is started at the beginning of each sub-test and the created file is removed at the end. Fixes: f59549814a64 (“selftests: mptcp: userspace: validate v4-v6 subflows mix”) Signed-off-by: Matthieu Baerts Signed-off-by: Sasha Levin commit 66ec619e4591f8350f99c5269a7ce160cccc7a7c Author: Xiubo Li Date: Wed Feb 1 09:36:45 2023 +0800 ceph: blocklist the kclient when receiving corrupted snap trace [ Upstream commit a68e564adcaa69b0930809fb64d9d5f7d9c32ba9 ] When received corrupted snap trace we don’t know what exactly has happened in MDS side. And we shouldn’t continue IOs and metadatas access to MDS, which may corrupt or get incorrect contents. This patch will just block all the further IO/MDS requests immediately and then evict the kclient itself. The reason why we still need to evict the kclient just after blocking all the further IOs is that the MDS could revoke the caps faster. Link: https://tracker.ceph.com/issues/57686 Signed-off-by: Xiubo Li Reviewed-by: Venky Shankar Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit eb253f83d403a4d5f9a6160fe95a56257d358601 Author: Xiubo Li Date: Wed Feb 1 09:36:44 2023 +0800 ceph: move mount state enum to super.h [ Upstream commit b38b17b6a01ca4e738af097a1529910646ef4270 ] These flags are only used in ceph filesystem in fs/ceph, so just move it to the place it should be. Signed-off-by: Xiubo Li Reviewed-by: Venky Shankar Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit b9f21e40135ab8d18bec9e8e0c8396a9fdb715f2 Author: Hans de Goede Date: Thu Feb 2 11:34:13 2023 +0100 platform/x86: touchscreen_dmi: Add Chuwi Vi8 (CWI501) DMI match [ Upstream commit eecf2acd4a580e9364e5087daf0effca60a240b7 ] Add a DMI match for the CWI501 version of the Chuwi Vi8 tablet, pointing to the same chuwi_vi8_data as the existing CWI506 version DMI match. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin commit b4e79d0c7f9bb938525716b3e05cfca6418e2bae Author: Alex Deucher Date: Wed Jan 25 14:35:16 2023 -0500 drm/amd/display: Properly handle additional cases where DCN is not supported [ Upstream commit 6fc547a5a2ef5ce05b16924106663ab92f8f87a7 ] There could be boards with DCN listed in IP discovery, but no display hardware actually wired up. In this case the vbios display table will not be populated. Detect this case and skip loading DM when we detect it. v2: Mark DCN as harvested as well so other display checks elsewhere in the driver are handled properly. Cc: Aurabindo Pillai Reviewed-by: Aurabindo Pillai Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit fc64b04297a0674f4e5aff50622efdce46715fe1 Author: Yiqing Yao Date: Tue Jan 31 16:02:47 2023 +0800 drm/amdgpu: Enable vclk dclk node for gc11.0.3 [ Upstream commit ac7170082c0e140663f0853d3de733a5341ce7b0 ] These sysfs nodes are tested supported, so enable them. Signed-off-by: Yiqing Yao Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit e9cbb2b0d9f679d7e25b9415cf9d7345441a95c5 Author: Evan Quan Date: Sat Jan 28 14:24:34 2023 +0800 drm/amdgpu: enable HDP SD for gfx 11.0.3 [ Upstream commit bb25849c0fa550b26cecc9c476c519a927c66898 ] Enable HDP clock gating control for gfx 11.0.3. Signed-off-by: Evan Quan Reviewed-by: Feifei Xu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 488770cbddd8a873fb3bb8866e8a46211570c367 Author: Nicholas Kazlauskas Date: Fri Jan 20 11:14:30 2023 -0500 drm/amd/display: Reset DMUB mailbox SW state after HW reset [ Upstream commit 154711aa5759ef9b45903124fa813c4c29ee681c ] [Why] Otherwise we can be out of sync with what’s in the hardware, leading to us rerunning every command that’s presently in the ringbuffer. [How] Reset software state for the mailboxes in hw_reset callback. This is already done as part of the mailbox init in hw_init, but we do need to remember to reset the last cached wptr value as well here. Reviewed-by: Hansen Dsouza Acked-by: Alex Hung Signed-off-by: Nicholas Kazlauskas Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 383e32fa274a330dbf2d2db538b6bf2f9ef390aa Author: George Shen Date: Thu Jan 19 17:09:54 2023 -0500 drm/amd/display: Unassign does_plane_fit_in_mall function from dcn3.2 [ Upstream commit 275d8a1db261a1272a818d40ebc61b3b865b60e5 ] [Why] The hwss function does_plane_fit_in_mall not applicable to dcn3.2 asics. Using it with dcn3.2 can result in undefined behaviour. [How] Assign the function pointer to NULL. Reviewed-by: Alvin Lee Acked-by: Alex Hung Signed-off-by: George Shen Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 7dbd205349f1fb098057c28a9a2af244aa868f72 Author: Daniel Miess Date: Tue Jan 17 15:45:30 2023 -0500 drm/amd/display: Adjust downscaling limits for dcn314 [ Upstream commit dd2db2dc4bd298f33dea50c80c3c11bee4e3b0a4 ] [Why] Lower max_downscale_ratio and ARGB888 downscale factor to prevent cases where underflow may occur on dcn314 [How] Set max_downscale_ratio to 400 and ARGB downscale factor to 250 for dcn314 Reviewed-by: Nicholas Kazlauskas Acked-by: Alex Hung Signed-off-by: Daniel Miess Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0c42622a573b716d79c57ff61c52fea46c0a5c94 Author: Daniel Miess Date: Tue Jan 17 15:34:35 2023 -0500 drm/amd/display: Add missing brackets in calculation [ Upstream commit ea062fd28f922cb118bfb33229f405b81aff7781 ] [Why] Brackets missing in the calculation for MIN_DST_Y_NEXT_START [How] Add missing brackets for this calculation Reviewed-by: Nicholas Kazlauskas Acked-by: Alex Hung Signed-off-by: Daniel Miess Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 53fb698a8a280f33e43b5847d653b595b97e3947 Author: Maurizio Lombardi Date: Tue Jan 31 17:38:42 2023 +0100 nvme: clear the request_queue pointers on failure in nvme_alloc_io_tag_set [ Upstream commit 6fbf13c0e24fd86ab2e4477cd8484a485b687421 ] In nvme_alloc_io_tag_set(), the connect_q pointer should be set to NULL in case of error to avoid potential invalid pointer dereferences. Signed-off-by: Maurizio Lombardi Reviewed-by: Chaitanya Kulkarni Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 84ea5242b723573d1bc78049128a8b61d2c60465 Author: Maurizio Lombardi Date: Fri Jan 27 16:42:37 2023 +0100 nvme: clear the request_queue pointers on failure in nvme_alloc_admin_tag_set [ Upstream commit fd62678ab55cb01e11a404d302cdade222bf4022 ] If nvme_alloc_admin_tag_set() fails, the admin_q and fabrics_q pointers are left with an invalid, non-NULL value. Other functions may then check the pointers and dereference them, e.g. in nvme_probe() -> out_disable: -> nvme_dev_remove_admin(). Fix the bug by setting admin_q and fabrics_q to NULL in case of error. Also use the set variable to free the tag_set as ctrl->admin_tagset isn’t initialized yet. Signed-off-by: Maurizio Lombardi Reviewed-by: Keith Busch Reviewed-by: Chaitanya Kulkarni Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit fd646ac5403f9a6d693065edeb21fec2a8b19727 Author: Amit Engel Date: Mon Jan 23 14:37:28 2023 +0200 nvme-fc: fix a missing queue put in nvmet_fc_ls_create_association [ Upstream commit 0cab4404874f2de52617de8400c844891c6ea1ce ] As part of nvmet_fc_ls_create_association there is a case where nvmet_fc_alloc_target_queue fails right after a new association with an admin queue is created. In this case, no one releases the get taken in nvmet_fc_alloc_target_assoc. This fix is adding the missing put. Signed-off-by: Amit Engel Reviewed-by: James Smart Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit f1eb22d0ff064ad458b3b1a1eaa84ac3996206c2 Author: Vasily Gorbik Date: Sun Jan 29 23:47:23 2023 +0100 s390/decompressor: specify __decompress() buf len to avoid overflow [ Upstream commit 7ab41c2c08a32132ba8c14624910e2fe8ce4ba4b ] Historically calls to __decompress() didn’t specify “out_len” parameter on many architectures including s390, expecting that no writes beyond uncompressed kernel image are performed. This has changed since commit 2aa14b1ab2c4 (“zstd: import usptream v1.5.2”) which includes zstd library commit 6a7ede3dfccb ("Reduce size of dctx by reutilizing dst buffer (#2751)"). Now zstd decompression code might store literal buffer in the unwritten portion of the destination buffer. Since “out_len” is not set, it is considered to be unlimited and hence free to use for optimization needs. On s390 this might corrupt initrd or ipl report which are often placed right after the decompressor buffer. Luckily the size of uncompressed kernel image is already known to the decompressor, so to avoid the problem simply specify it in the “out_len” parameter. Link: https://github.com/facebook/zstd/commit/6a7ede3dfccb Signed-off-by: Vasily Gorbik Tested-by: Alexander Egorenkov Link: https://lore.kernel.org/r/patch-1.thread-41c676.git-41c676c2d153.your-ad-here.call-01675030179-ext-9637@work.hours Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit f6415c9c9a0b3881543d38528a58b54af4351522 Author: Kees Cook Date: Fri Jan 27 14:40:37 2023 -0800 net: sched: sch: Bounds check priority [ Upstream commit de5ca4c3852f896cacac2bf259597aab5e17d9e3 ] Nothing was explicitly bounds checking the priority index used to access clpriop[]. WARN and bail out early if it’s pathological. Seen with GCC 13: …/net/sched/sch_htb.c: In function 'htb_activate_prios’: …/net/sched/sch_htb.c:437:44: warning: array subscript [0, 31] is outside array bounds of 'struct htb_prio[8]' [-Warray-bounds=] 437 | if (p->inner.clprio[prio].feed.rb_node) | ~~~~~~~~~~~~~~~^~~~~~ …/net/sched/sch_htb.c:131:41: note: while referencing ‘clprio’ 131 | struct htb_prio clprio[TC_HTB_NUMPRIO]; | ^~~~~~ Cc: Jamal Hadi Salim Cc: Cong Wang Cc: Jiri Pirko Cc: “David S. Miller” Cc: Eric Dumazet Cc: Jakub Kicinski Cc: Paolo Abeni Cc: [email protected] Signed-off-by: Kees Cook Reviewed-by: Simon Horman Reviewed-by: Cong Wang Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 5252655127c79e933d2fa8b49a3028dedb417491 Author: Kees Cook Date: Fri Jan 27 14:38:54 2023 -0800 net: ethernet: mtk_eth_soc: Avoid truncating allocation [ Upstream commit f3eceaed9edd7c0e0d9fb057613131f92973626f ] There doesn’t appear to be a reason to truncate the allocation used for flow_info, so do a full allocation and remove the unused empty struct. GCC does not like having a reference to an object that has been partially allocated, as bounds checking may become impossible when such an object is passed to other code. Seen with GCC 13: …/drivers/net/ethernet/mediatek/mtk_ppe.c: In function 'mtk_foe_entry_commit_subflow’: …/drivers/net/ethernet/mediatek/mtk_ppe.c:623:18: warning: array subscript 'struct mtk_flow_entry[0]' is partly outside array bounds of ‘unsigned char[48]' [-Warray-bounds=] 623 | flow_info->l2_data.base_flow = entry; | ^~ Cc: Felix Fietkau Cc: John Crispin Cc: Sean Wang Cc: Mark Lee Cc: Lorenzo Bianconi Cc: “David S. Miller” Cc: Eric Dumazet Cc: Jakub Kicinski Cc: Paolo Abeni Cc: Matthias Brugger Cc: [email protected] Cc: [email protected] Cc: [email protected] Signed-off-by: Kees Cook Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 07a0e6d2010664f0e8eb122bb4e1a2a6e008b0e4 Author: Ben Skeggs Date: Tue Jan 31 08:37:13 2023 +1000 drm/nouveau/devinit/tu102-: wait for GFW_BOOT_PROGRESS == COMPLETED [ Upstream commit d22915d22ded21fd5b24b60d174775789f173997 ] Starting from Turing, the driver is no longer responsible for initiating DEVINIT when required as the GPU started loading a FW image from ROM and executing DEVINIT itself after power-on. However - we apparently still need to wait for it to complete. This should correct some issues with runpm on some systems, where we get control of the HW before it’s been fully reinitialised after resume from suspend. Signed-off-by: Ben Skeggs Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin commit b266c2e72ef319ebc6ae298766c81bfd3ec33f57 Author: Hou Tao Date: Fri Jan 13 19:52:11 2023 +0800 fscache: Use clear_and_wake_up_bit() in fscache_create_volume_work() [ Upstream commit 3288666c72568fe1cc7f5c5ae33dfd3ab18004c8 ] fscache_create_volume_work() uses wake_up_bit() to wake up the processes which are waiting for the completion of volume creation. According to comments in wake_up_bit() and waitqueue_active(), an extra smp_mb() is needed to guarantee the memory order between FSCACHE_VOLUME_CREATING flag and waitqueue_active() before invoking wake_up_bit(). Fixing it by using clear_and_wake_up_bit() to add the missing memory barrier. Reviewed-by: Jingbo Xu Signed-off-by: Hou Tao Signed-off-by: David Howells Reviewed-by: Jeff Layton Link: https://lore.kernel.org/r/[email protected]/ # v3 Signed-off-by: Sasha Levin commit 63c12d00d8565bc0d36ec32491e3f52f91498a49 Author: Nicholas Piggin Date: Sat Jan 21 20:01:56 2023 +1000 powerpc/64: Fix perf profiling asynchronous interrupt handlers [ Upstream commit c28548012ee2bac55772ef7685138bd1124b80c3 ] Interrupt entry sets the soft mask to IRQS_ALL_DISABLED to match the hard irq disabled state. So when should_hard_irq_enable() returns true because we want PMI interrupts in irq handlers, MSR[EE] is enabled but PMIs just get soft-masked. Fix this by clearing IRQS_PMI_DISABLED before enabling MSR[EE]. This also tidies some of the warnings, no need to duplicate them in both should_hard_irq_enable() and do_hard_irq_enable(). Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin commit 07c53834ec278d49ff67fe623ded572578e6968e Author: Andrey Konovalov Date: Fri Jan 27 00:35:39 2023 +0300 net: stmmac: do not stop RX_CLK in Rx LPI state for qcs404 SoC [ Upstream commit 54aa39a513dbf2164ca462a19f04519b2407a224 ] Currently in phy_init_eee() the driver unconditionally configures the PHY to stop RX_CLK after entering Rx LPI state. This causes an LPI interrupt storm on my qcs404-base board. Change the PHY initialization so that for “qcom,qcs404-ethqos” compatible device RX_CLK continues to run even in Rx LPI state. Signed-off-by: Andrey Konovalov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 15aa6a4274fbbd595435dea72c193f95543c756d Author: Andrei Gherzan Date: Thu Jan 26 16:55:48 2023 +0000 selftest: net: Improve IPV6_TCLASS/IPV6_HOPLIMIT tests apparmor compatibility [ Upstream commit a6efc42a86c0c87cfe2f1c3d1f09a4c9b13ba890 ] “tcpdump” is used to capture traffic in these tests while using a random, temporary and not suffixed file for it. This can interfere with apparmor configuration where the tool is only allowed to read from files with ‘known’ extensions. The MINE type application/vnd.tcpdump.pcap was registered with IANA for pcap files and .pcap is the extension that is both most common but also aligned with standard apparmor configurations. See TCPDUMP(8) for more details. This improves compatibility with standard apparmor configurations by using “.pcap” as the file extension for the tests’ temporary files. Signed-off-by: Andrei Gherzan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ad549f06e3de3f1e7dac857fb629845fee3423a5 Author: Hyunwoo Kim Date: Wed Jan 25 02:59:44 2023 -0800 net/rose: Fix to not accept on connected socket [ Upstream commit 14caefcf9837a2be765a566005ad82cd0d2a429f ] If you call listen() and accept() on an already connect()ed rose socket, accept() can successfully connect. This is because when the peer socket sends data to sendmsg, the skb with its own sk stored in the connected socket’s sk->sk_receive_queue is connected, and rose_accept() dequeues the skb waiting in the sk->sk_receive_queue. This creates a child socket with the sk of the parent rose socket, which can cause confusion. Fix rose_listen() to return -EINVAL if the socket has already been successfully connected, and add lock_sock to prevent this issue. Signed-off-by: Hyunwoo Kim Reviewed-by: Kuniyuki Iwashima Link: https://lore.kernel.org/r/20230125105944.GA133314@ubuntu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5d2cc32c1c10bd889125d2adc16a6bc3338dcd3e Author: Tanmay Bhushan [email protected] Date: Tue Dec 27 22:02:16 2022 +0100 vdpa: ifcvf: Do proper cleanup if IFCVF init fails [ Upstream commit 6b04456e248761cf68f562f2fd7c04e591fcac94 ] ifcvf_mgmt_dev leaks memory if it is not freed before returning. Call is made to correct return statement so memory does not leak. ifcvf_init_hw does not take care of this so it is needed to do it here. Signed-off-by: Tanmay Bhushan [email protected] Message-Id: [email protected] Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Acked-by: Zhu Lingshan Signed-off-by: Sasha Levin commit 2ad95cb1af7ada2a7a3a558352cbb7a7ab160e43 Author: Shunsuke Mie Date: Tue Jan 10 12:43:10 2023 +0900 tools/virtio: fix the vringh test for virtio ring changes [ Upstream commit 3f7b75abf41cc4143aa295f62acbb060a012868d ] Fix the build caused by missing kmsan_handle_dma() and is_power_of_2() that are used in drivers/virtio/virtio_ring.c. Signed-off-by: Shunsuke Mie Message-Id: [email protected] Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 925b1c909d112dfa4dee168004834f75ccdf8a88 Author: Arnd Bergmann Date: Thu Jan 26 17:21:24 2023 +0100 ASoC: cs42l56: fix DT probe [ Upstream commit e18c6da62edc780e4f4f3c9ce07bdacd69505182 ] While looking through legacy platform data users, I noticed that the DT probing never uses data from the DT properties, as the platform_data structure gets overwritten directly after it is initialized. There have never been any boards defining the platform_data in the mainline kernel either, so this driver so far only worked with patched kernels or with the default values. For the benefit of possible downstream users, fix the DT probe by no longer overwriting the data. Signed-off-by: Arnd Bergmann Acked-by: Charles Keepax Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7499859881488da97589f3c79cc66fa75748ad49 Author: Jakub Sitnicki Date: Sat Jan 21 13:41:43 2023 +0100 bpf, sockmap: Don’t let sock_map_{close,destroy,unhash} call itself [ Upstream commit 5b4a79ba65a1ab479903fff2e604865d229b70a9 ] sock_map proto callbacks should never call themselves by design. Protect against bugs like [1] and break out of the recursive loop to avoid a stack overflow in favor of a resource leak. [1] https://lore.kernel.org/all/[email protected]/ Suggested-by: Eric Dumazet Signed-off-by: Jakub Sitnicki Acked-by: John Fastabend Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 22fcbb7802b98a121e9d7d3d8e42b498f070d6aa Author: fengwk Date: Sun Jan 22 01:51:06 2023 +0800 ASoC: amd: yc: Add Xiaomi Redmi Book Pro 15 2022 into DMI table [ Upstream commit dcff8b7ca92d724bdaf474a3fa37a7748377813a ] This model requires an additional detection quirk to enable the internal microphone - BIOS doesn’t seem to support AcpDmicConnected (nothing in acpidump output). Signed-off-by: fengwk Link: https://lore.kernel.org/r/Y8wmCutc74j/tyHP@arch Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 427ca2530da8dc61a42620d7113b05e187b6c2c0 Author: Cezary Rojewski Date: Thu Jan 19 15:32:35 2023 +0100 ALSA: hda: Do not unset preset when cleaning up codec [ Upstream commit 87978e6ad45a16835cc58234451111091be3c59a ] Several functions that take part in codec’s initialization and removal are re-used by ASoC codec drivers implementations. Drivers mimic the behavior of hda_codec_driver_probe/remove() found in sound/pci/hda/hda_bind.c with their component->probe/remove() instead. One of the reasons for that is the expectation of snd_hda_codec_device_new() to receive a valid pointer to an instance of struct snd_card. This expectation can be met only once sound card components probing commences. As ASoC sound card may be unbound without codec device being actually removed from the system, unsetting ->preset in snd_hda_codec_cleanup_for_unbind() interferes with module unload -> load scenario causing null-ptr-deref. Preset is assigned only once, during device/driver matching whereas ASoC codec driver’s module reloading may occur several times throughout the lifetime of an audio stack. Suggested-by: Takashi Iwai Signed-off-by: Cezary Rojewski Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 544062e65f44195761efc8b534aff0c786aebf4b Author: Eduard Zingerman Date: Fri Jan 6 16:22:14 2023 +0200 selftests/bpf: Verify copy_register_state() preserves parent/live fields [ Upstream commit b9fa9bc839291020b362ab5392e5f18ba79657ac ] A testcase to check that verifier.c:copy_register_state() preserves register parentage chain and livness information. Signed-off-by: Eduard Zingerman Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 2cd6e872d88da58385824ff72bcf646dc58cdb05 Author: Pierre-Louis Bossart Date: Thu Jan 19 18:34:59 2023 +0200 ASoC: Intel: sof_ssp_amp: always set dpcm_capture for amplifiers [ Upstream commit b3c00316a2f847791bae395ea6dd91aa7a221471 ] The amplifier may provide hardware support for I/V feedback, or alternatively the firmware may generate an echo reference attached to the SSP and dailink used for the amplifier. To avoid any issues with invalid/NULL substreams in the latter case, always unconditionally set dpcm_capture. Link: https://github.com/thesofproject/linux/issues/4083 Signed-off-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Reviewed-by: Péter Ujfalusi Reviewed-by: Bard Liao Signed-off-by: Kai Vehmanen Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c2241c6c8e2172933de2aba00ebe103453775c6b Author: Pierre-Louis Bossart Date: Thu Jan 19 18:34:58 2023 +0200 ASoC: Intel: sof_nau8825: always set dpcm_capture for amplifiers [ Upstream commit 36a71a0eb7cdb5ccf4b0214dbd41ab00dff18c7f ] The amplifier may provide hardware support for I/V feedback, or alternatively the firmware may generate an echo reference attached to the SSP and dailink used for the amplifier. To avoid any issues with invalid/NULL substreams in the latter case, always unconditionally set dpcm_capture. Link: https://github.com/thesofproject/linux/issues/4083 Signed-off-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Reviewed-by: Péter Ujfalusi Reviewed-by: Bard Liao Signed-off-by: Kai Vehmanen Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0a0754ca3c7c630a9a8f24f6bb0968e2e73ce59b Author: Pierre-Louis Bossart Date: Thu Jan 19 18:34:57 2023 +0200 ASoC: Intel: sof_cs42l42: always set dpcm_capture for amplifiers [ Upstream commit e0a52220344ab7defe25b9cdd58fe1dc1122e67c ] The amplifier may provide hardware support for I/V feedback, or alternatively the firmware may generate an echo reference attached to the SSP and dailink used for the amplifier. To avoid any issues with invalid/NULL substreams in the latter case, always unconditionally set dpcm_capture. Link: https://github.com/thesofproject/linux/issues/4083 Signed-off-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Reviewed-by: Péter Ujfalusi Reviewed-by: Bard Liao Signed-off-by: Kai Vehmanen Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f40f3dd005760f6fc2e200e1a9c77330a17d57b9 Author: Pierre-Louis Bossart Date: Thu Jan 19 18:34:56 2023 +0200 ASoC: Intel: sof_rt5682: always set dpcm_capture for amplifiers [ Upstream commit 324f065cdbaba1b879a63bf07e61ca156b789537 ] The amplifier may provide hardware support for I/V feedback, or alternatively the firmware may generate an echo reference attached to the SSP and dailink used for the amplifier. To avoid any issues with invalid/NULL substreams in the latter case, always unconditionally set dpcm_capture. Link: https://github.com/thesofproject/linux/issues/4083 Signed-off-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Reviewed-by: Péter Ujfalusi Reviewed-by: Bard Liao Signed-off-by: Kai Vehmanen Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 44bec0e7bf0a71abbe2f876eb113424ea7c87095 Author: Takashi Iwai Date: Wed Jan 18 17:59:47 2023 +0100 ALSA: usb-audio: Add FIXED_RATE quirk for JBL Quantum610 Wireless [ Upstream commit dfd5fe19db7dc7006642f8109ee8965e5d031897 ] JBL Quantum610 Wireless (0ecb:205c) requires the same workaround that was used for JBL Quantum810 for limiting the sample rate. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216798 Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ad5716dea7d81ca6a1ba1ca0b4c41d16b32122a4 Author: Bard Liao Date: Tue Jan 17 14:35:34 2023 +0200 ASoC: SOF: sof-audio: start with the right widget type [ Upstream commit fcc4348adafe53928fda46d104c1798e5a4de4ff ] If there is a connection between a playback stream and a capture stream, all widgets that are connected to the playback stream and the capture stream will be in the list. So, we have to start with the exactly right widget type. snd_soc_dapm_aif_out is for capture stream and a playback stream should start with a snd_soc_dapm_aif_in widget. Contrarily, snd_soc_dapm_dai_in is for playback stream, and a capture stream should start with a snd_soc_dapm_dai_out widget. Signed-off-by: Bard Liao Reviewed-by: Ranjani Sridharan Reviewed-by: Kai Vehmanen Reviewed-by: Péter Ujfalusi Reviewed-by: Pierre-Louis Bossart Signed-off-by: Peter Ujfalusi Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 591d69e47a58c1a20756c7c808fc1d880e3bf645 Author: Syed Saba Kareem Date: Wed Jan 11 15:51:23 2023 +0530 ASoC: amd: yc: Add DMI support for new acer/emdoor platforms [ Upstream commit 7fd26a27680aa9032920f798a5a8b38a2c61075f ] Adding DMI entries to support new acer/emdoor platforms. Suggested-by: shanshengwang Signed-off-by: Syed Saba Kareem Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d8c594da79bc0244e610a70594e824a401802be1 Author: Filipe Manana Date: Mon Jan 23 16:54:46 2023 +0000 btrfs: lock the inode in shared mode before starting fiemap [ Upstream commit 519b7e13b5ae8dd38da1e52275705343be6bb508 ] Currently fiemap does not take the inode’s lock (VFS lock), it only locks a file range in the inode’s io tree. This however can lead to a deadlock if we have a concurrent fsync on the file and fiemap code triggers a fault when accessing the user space buffer with fiemap_fill_next_extent(). The deadlock happens on the inode’s i_mmap_lock semaphore, which is taken both by fsync and btrfs_page_mkwrite(). This deadlock was recently reported by syzbot and triggers a trace like the following: task:syz-executor361 state:D stack:20264 pid:5668 ppid:5119 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c:5293 [inline] __schedule+0x995/0xe20 kernel/sched/core.c:6606 schedule+0xcb/0x190 kernel/sched/core.c:6682 wait_on_state fs/btrfs/extent-io-tree.c:707 [inline] wait_extent_bit+0x577/0x6f0 fs/btrfs/extent-io-tree.c:751 lock_extent+0x1c2/0x280 fs/btrfs/extent-io-tree.c:1742 find_lock_delalloc_range+0x4e6/0x9c0 fs/btrfs/extent_io.c:488 writepage_delalloc+0x1ef/0x540 fs/btrfs/extent_io.c:1863 __extent_writepage+0x736/0x14e0 fs/btrfs/extent_io.c:2174 extent_write_cache_pages+0x983/0x1220 fs/btrfs/extent_io.c:3091 extent_writepages+0x219/0x540 fs/btrfs/extent_io.c:3211 do_writepages+0x3c3/0x680 mm/page-writeback.c:2581 filemap_fdatawrite_wbc+0x11e/0x170 mm/filemap.c:388 __filemap_fdatawrite_range mm/filemap.c:421 [inline] filemap_fdatawrite_range+0x175/0x200 mm/filemap.c:439 btrfs_fdatawrite_range fs/btrfs/file.c:3850 [inline] start_ordered_ops fs/btrfs/file.c:1737 [inline] btrfs_sync_file+0x4ff/0x1190 fs/btrfs/file.c:1839 generic_write_sync include/linux/fs.h:2885 [inline] btrfs_do_write_iter+0xcd3/0x1280 fs/btrfs/file.c:1684 call_write_iter include/linux/fs.h:2189 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x7dc/0xc50 fs/read_write.c:584 ksys_write+0x177/0x2a0 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f7d4054e9b9 RSP: 002b:00007f7d404fa2f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f7d405d87a0 RCX: 00007f7d4054e9b9 RDX: 0000000000000090 RSI: 0000000020000000 RDI: 0000000000000006 RBP: 00007f7d405a51d0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 61635f65646f6e69 R13: 65646f7475616f6e R14: 7261637369646f6e R15: 00007f7d405d87a8 INFO: task syz-executor361:5697 blocked for more than 145 seconds. Not tainted 6.2.0-rc3-syzkaller-00376-g7c6984405241 #0 “echo 0 > /proc/sys/kernel/hung_task_timeout_secs” disables this message. task:syz-executor361 state:D stack:21216 pid:5697 ppid:5119 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c:5293 [inline] __schedule+0x995/0xe20 kernel/sched/core.c:6606 schedule+0xcb/0x190 kernel/sched/core.c:6682 rwsem_down_read_slowpath+0x5f9/0x930 kernel/locking/rwsem.c:1095 __down_read_common+0x54/0x2a0 kernel/locking/rwsem.c:1260 btrfs_page_mkwrite+0x417/0xc80 fs/btrfs/inode.c:8526 do_page_mkwrite+0x19e/0x5e0 mm/memory.c:2947 wp_page_shared+0x15e/0x380 mm/memory.c:3295 handle_pte_fault mm/memory.c:4949 [inline] __handle_mm_fault mm/memory.c:5073 [inline] handle_mm_fault+0x1b79/0x26b0 mm/memory.c:5219 do_user_addr_fault+0x69b/0xcb0 arch/x86/mm/fault.c:1428 handle_page_fault arch/x86/mm/fault.c:1519 [inline] exc_page_fault+0x7a/0x110 arch/x86/mm/fault.c:1575 asm_exc_page_fault+0x22/0x30 arch/x86/include/asm/idtentry.h:570 RIP: 0010:copy_user_short_string+0xd/0x40 arch/x86/lib/copy_user_64.S:233 Code: 74 0a 89 (…) RSP: 0018:ffffc9000570f330 EFLAGS: 00050202 RAX: ffffffff843e6601 RBX: 00007fffffffefc8 RCX: 0000000000000007 RDX: 0000000000000000 RSI: ffffc9000570f3e0 RDI: 0000000020000120 RBP: ffffc9000570f490 R08: 0000000000000000 R09: fffff52000ae1e83 R10: fffff52000ae1e83 R11: 1ffff92000ae1e7c R12: 0000000000000038 R13: ffffc9000570f3e0 R14: 0000000020000120 R15: ffffc9000570f3e0 copy_user_generic arch/x86/include/asm/uaccess_64.h:37 [inline] raw_copy_to_user arch/x86/include/asm/uaccess_64.h:58 [inline] _copy_to_user+0xe9/0x130 lib/usercopy.c:34 copy_to_user include/linux/uaccess.h:169 [inline] fiemap_fill_next_extent+0x22e/0x410 fs/ioctl.c:144 emit_fiemap_extent+0x22d/0x3c0 fs/btrfs/extent_io.c:3458 fiemap_process_hole+0xa00/0xad0 fs/btrfs/extent_io.c:3716 extent_fiemap+0xe27/0x2100 fs/btrfs/extent_io.c:3922 btrfs_fiemap+0x172/0x1e0 fs/btrfs/inode.c:8209 ioctl_fiemap fs/ioctl.c:219 [inline] do_vfs_ioctl+0x185b/0x2980 fs/ioctl.c:810 __do_sys_ioctl fs/ioctl.c:868 [inline] __se_sys_ioctl+0x83/0x170 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f7d4054e9b9 RSP: 002b:00007f7d390d92f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f7d405d87b0 RCX: 00007f7d4054e9b9 RDX: 0000000020000100 RSI: 00000000c020660b RDI: 0000000000000005 RBP: 00007f7d405a51d0 R08: 00007f7d390d9700 R09: 0000000000000000 R10: 00007f7d390d9700 R11: 0000000000000246 R12: 61635f65646f6e69 R13: 65646f7475616f6e R14: 7261637369646f6e R15: 00007f7d405d87b8 What happens is the following: 1) Task A is doing an fsync, enters btrfs_sync_file() and flushes delalloc before locking the inode and the i_mmap_lock semaphore, that is, before calling btrfs_inode_lock(); 2) After task A flushes delalloc and before it calls btrfs_inode_lock(), another task dirties a page; 3) Task B starts a fiemap without FIEMAP_FLAG_SYNC, so the page dirtied at step 2 remains dirty and unflushed. Then when it enters extent_fiemap() and it locks a file range that includes the range of the page dirtied in step 2; 4) Task A calls btrfs_inode_lock() and locks the inode (VFS lock) and the inode’s i_mmap_lock semaphore in write mode. Then it tries to flush delalloc by calling start_ordered_ops(), which will block, at find_lock_delalloc_range(), when trying to lock the range of the page dirtied at step 2, since this range was locked by the fiemap task (at step 3); 5) Task B generates a page fault when accessing the user space fiemap buffer with a call to fiemap_fill_next_extent(). The fault handler needs to call btrfs_page_mkwrite() for some other page of our inode, and there we deadlock when trying to lock the inode’s i_mmap_lock semaphore in read mode, since the fsync task locked it in write mode (step 4) and the fsync task can not progress because it’s waiting to lock a file range that is currently locked by us (the fiemap task, step 3). Fix this by taking the inode’s lock (VFS lock) in shared mode when entering fiemap. This effectively serializes fiemap with fsync (except the most expensive part of fsync, the log sync), preventing this deadlock. Reported-by: [email protected] Link: https://lore.kernel.org/linux-btrfs/[email protected]/ CC: [email protected] # 6.1+ Reviewed-by: Josef Bacik Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit f2e0134b43be591c4e60091a8c9c61762ea4b337 Author: Josef Bacik Date: Wed Oct 26 15:08:23 2022 -0400 btrfs: move the auto defrag code to defrag.c [ Upstream commit 6e3df18ba7e8e68015dd66bcab326a4b7aaed085 ] This currently exists in file.c, move it to the more natural location in defrag.c. Signed-off-by: Josef Bacik [ reformat comments ] Reviewed-by: David Sterba Signed-off-by: David Sterba Stable-dep-of: 519b7e13b5ae (“btrfs: lock the inode in shared mode before starting fiemap”) Signed-off-by: Sasha Levin commit 3fbcd42b3e66c0a14528f9cb707f31e8986c6dc8 Author: Paolo Abeni Date: Tue Feb 7 14:04:15 2023 +0100 mptcp: fix locking for in-kernel listener creation [ Upstream commit ad2171009d968104ccda9dc517f5a3ba891515db ] For consistency, in mptcp_pm_nl_create_listen_socket(), we need to call the __mptcp_nmpc_socket() under the msk socket lock. Note that as a side effect, mptcp_subflow_create_socket() needs a ‘nested’ lockdep annotation, as it will acquire the subflow (kernel) socket lock under the in-kernel listener msk socket lock. The current lack of locking is almost harmless, because the relevant socket is not exposed to the user space, but in future we will add more complexity to the mentioned helper, let’s play safe. Fixes: 1729cf186d8a (“mptcp: create the listening socket for new port”) Cc: [email protected] Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts Signed-off-by: Matthieu Baerts Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c4fcda0def0426057e2c642d25c1b06e3ad6858d Author: Paolo Abeni Date: Fri Nov 18 10:46:07 2022 -0800 mptcp: deduplicate error paths on endpoint creation [ Upstream commit 976d302fb6165ad620778d7ba834cde6e3fe9f9f ] When endpoint creation fails, we need to free the newly allocated entry and eventually destroy the paired mptcp listener socket. Consolidate such action in a single point let all the errors path reach it. Reviewed-by: Mat Martineau Signed-off-by: Paolo Abeni Signed-off-by: Mat Martineau Signed-off-by: David S. Miller Stable-dep-of: ad2171009d96 (“mptcp: fix locking for in-kernel listener creation”) Signed-off-by: Sasha Levin commit 03edc4a27dad21f787ce294c23786858b83b34a3 Author: Paolo Abeni Date: Tue Feb 7 14:04:14 2023 +0100 mptcp: fix locking for setsockopt corner-case [ Upstream commit 21e43569685de4ad773fb060c11a15f3fd5e7ac4 ] We need to call the __mptcp_nmpc_socket(), and later subflow socket access under the msk socket lock, or e.g. a racing connect() could change the socket status under the hood, with unexpected results. Fixes: 54635bd04701 (“mptcp: add TCP_FASTOPEN_CONNECT socket option”) Cc: [email protected] Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts Signed-off-by: Matthieu Baerts Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 94ed108bf18cb045a40a42661c093a579770c831 Author: Matthieu Baerts Date: Fri Oct 21 17:45:03 2022 -0700 mptcp: sockopt: make ‘tcp_fastopen_connect’ generic [ Upstream commit d3d429047cc66ff49780c93e4fccd9527723d385 ] There are other socket options that need to act only on the first subflow, e.g. all TCP_FASTOPEN* socket options. This is similar to the getsockopt version. In the next commit, this new mptcp_setsockopt_first_sf_only() helper is used by other another option. Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts Signed-off-by: Mat Martineau Signed-off-by: Paolo Abeni Stable-dep-of: 21e43569685d (“mptcp: fix locking for setsockopt corner-case”) Signed-off-by: Sasha Levin