commit 42616e0f09fb4e9a6c59892a227f7bdefbd2d6d3 Author: Greg Kroah-Hartman Date: Fri Mar 3 11:52:25 2023 +0100 Linux 6.1.15 Link: https://lore.kernel.org/r/20230301180657.003689969@linuxfoundation.org Tested-by: Conor Dooley Tested-by: Florian Fainelli Tested-by: Justin M. Forbes Tested-by: Shuah Khan Tested-by: Bagas Sanjaya Tested-by: Jon Hunter Tested-by: Sudip Mukherjee Tested-by: Linux Kernel Functional Testing Tested-by: Slade Watkins Tested-by: Rudi Heitbaum Tested-by: Guenter Roeck Tested-by: Ron Economos Signed-off-by: Greg Kroah-Hartman commit c87fb861ec185fdc578b4fdc6a05920b6a843840 Author: Alan Stern Date: Tue Jan 31 15:49:04 2023 -0500 USB: core: Don't hold device lock while reading the "descriptors" sysfs file commit 45bf39f8df7f05efb83b302c65ae3b9bc92b7065 upstream. Ever since commit 83e83ecb79a8 ("usb: core: get config and string descriptors for unauthorized devices") was merged in 2013, there has been no mechanism for reallocating the rawdescriptors buffers in struct usb_device after the initial enumeration. Before that commit, the buffers would be deallocated when a device was deauthorized and reallocated when it was authorized and enumerated. This means that the locking in the read_descriptors() routine is not needed, since the buffers it reads will never be reallocated while the routine is running. This locking can interfere with user programs trying to read a hub's descriptors via sysfs while new child devices of the hub are being initialized, since the hub is locked during this procedure. Since the locking in read_descriptors() hasn't been needed for over nine years, we can remove it. Reported-and-tested-by: Troels Liebe Bentsen Signed-off-by: Alan Stern CC: stable@vger.kernel.org Link: https://lore.kernel.org/r/Y9l+wDTRbuZABzsE@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman commit c49bd6c2dd1bd67abd2b638ae10deb65c4f4031e Author: Carlos Llamas Date: Wed Feb 15 18:38:50 2023 +0000 scripts/tags.sh: fix incompatibility with PCRE2 commit 6ec363fc6142226b9ab5a6528f65333d729d2b6b upstream. Starting with release 10.38 PCRE2 drops default support for using \K in lookaround patterns as described in [1]. Unfortunately, scripts/tags.sh relies on such functionality to collect all_compiled_soures() leading to the following error: $ make COMPILED_SOURCE=1 tags GEN tags grep: \K is not allowed in lookarounds (but see PCRE2_EXTRA_ALLOW_LOOKAROUND_BSK) The usage of \K for this pattern was introduced in commit 4f491bb6ea2a ("scripts/tags.sh: collect compiled source precisely") which speeds up the generation of tags significantly. In order to fix this issue without compromising the performance we can switch over to an equivalent sed expression. The same matching pattern is preserved here except \K is replaced with a backreference \1. [1] https://www.pcre.org/current/doc/html/pcre2syntax.html#SEC11 Cc: Greg Kroah-Hartman Cc: Cristian Ciocaltea Cc: Masahiro Yamada Cc: Jialu Xu Cc: Vipin Sharma Cc: stable@vger.kernel.org Fixes: 4f491bb6ea2a ("scripts/tags.sh: collect compiled source precisely") Signed-off-by: Carlos Llamas Link: https://lore.kernel.org/r/20230215183850.3353198-1-cmllamas@google.com Signed-off-by: Greg Kroah-Hartman commit a591d9fd7001f9a71d648ef17a42aef19a3fd9f1 Author: Christian Brauner Date: Tue Nov 22 11:40:32 2022 +0100 fs: use consistent setgid checks in is_sxid() commit 8d84e39d76bd83474b26cb44f4b338635676e7e8 upstream. Now that we made the VFS setgid checking consistent an inode can't be marked security irrelevant even if the setgid bit is still set. Make this function consistent with all other helpers. Note that enforcing consistent setgid stripping checks for file modification and mode- and ownership changes will cause the setgid bit to be lost in more cases than useed to be the case. If an unprivileged user wrote to a non-executable setgid file that they don't have privilege over the setgid bit will be dropped. This will lead to temporary failures in some xfstests until they have been updated. Reported-by: Miklos Szeredi Signed-off-by: Christian Brauner (Microsoft) Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit 89f5f21b960ee81f2cdffdb0c862e500b7d1d902 Author: Christian Brauner Date: Mon Oct 17 17:06:37 2022 +0200 attr: use consistent sgid stripping checks commit ed5a7047d2011cb6b2bf84ceb6680124cc6a7d95 upstream. Currently setgid stripping in file_remove_privs()'s should_remove_suid() helper is inconsistent with other parts of the vfs. Specifically, it only raises ATTR_KILL_SGID if the inode is S_ISGID and S_IXGRP but not if the inode isn't in the caller's groups and the caller isn't privileged over the inode although we require this already in setattr_prepare() and setattr_copy() and so all filesystem implement this requirement implicitly because they have to use setattr_{prepare,copy}() anyway. But the inconsistency shows up in setgid stripping bugs for overlayfs in xfstests (e.g., generic/673, generic/683, generic/685, generic/686, generic/687). For example, we test whether suid and setgid stripping works correctly when performing various write-like operations as an unprivileged user (fallocate, reflink, write, etc.): echo "Test 1 - qa_user, non-exec file $verb" setup_testfile chmod a+rws $junk_file commit_and_check "$qa_user" "$verb" 64k 64k The test basically creates a file with 6666 permissions. While the file has the S_ISUID and S_ISGID bits set it does not have the S_IXGRP set. On a regular filesystem like xfs what will happen is: sys_fallocate() -> vfs_fallocate() -> xfs_file_fallocate() -> file_modified() -> __file_remove_privs() -> dentry_needs_remove_privs() -> should_remove_suid() -> __remove_privs() newattrs.ia_valid = ATTR_FORCE | kill; -> notify_change() -> setattr_copy() In should_remove_suid() we can see that ATTR_KILL_SUID is raised unconditionally because the file in the test has S_ISUID set. But we also see that ATTR_KILL_SGID won't be set because while the file is S_ISGID it is not S_IXGRP (see above) which is a condition for ATTR_KILL_SGID being raised. So by the time we call notify_change() we have attr->ia_valid set to ATTR_KILL_SUID | ATTR_FORCE. Now notify_change() sees that ATTR_KILL_SUID is set and does: ia_valid = attr->ia_valid |= ATTR_MODE attr->ia_mode = (inode->i_mode & ~S_ISUID); which means that when we call setattr_copy() later we will definitely update inode->i_mode. Note that attr->ia_mode still contains S_ISGID. Now we call into the filesystem's ->setattr() inode operation which will end up calling setattr_copy(). Since ATTR_MODE is set we will hit: if (ia_valid & ATTR_MODE) { umode_t mode = attr->ia_mode; vfsgid_t vfsgid = i_gid_into_vfsgid(mnt_userns, inode); if (!vfsgid_in_group_p(vfsgid) && !capable_wrt_inode_uidgid(mnt_userns, inode, CAP_FSETID)) mode &= ~S_ISGID; inode->i_mode = mode; } and since the caller in the test is neither capable nor in the group of the inode the S_ISGID bit is stripped. But assume the file isn't suid then ATTR_KILL_SUID won't be raised which has the consequence that neither the setgid nor the suid bits are stripped even though it should be stripped because the inode isn't in the caller's groups and the caller isn't privileged over the inode. If overlayfs is in the mix things become a bit more complicated and the bug shows up more clearly. When e.g., ovl_setattr() is hit from ovl_fallocate()'s call to file_remove_privs() then ATTR_KILL_SUID and ATTR_KILL_SGID might be raised but because the check in notify_change() is questioning the ATTR_KILL_SGID flag again by requiring S_IXGRP for it to be stripped the S_ISGID bit isn't removed even though it should be stripped: sys_fallocate() -> vfs_fallocate() -> ovl_fallocate() -> file_remove_privs() -> dentry_needs_remove_privs() -> should_remove_suid() -> __remove_privs() newattrs.ia_valid = ATTR_FORCE | kill; -> notify_change() -> ovl_setattr() // TAKE ON MOUNTER'S CREDS -> ovl_do_notify_change() -> notify_change() // GIVE UP MOUNTER'S CREDS // TAKE ON MOUNTER'S CREDS -> vfs_fallocate() -> xfs_file_fallocate() -> file_modified() -> __file_remove_privs() -> dentry_needs_remove_privs() -> should_remove_suid() -> __remove_privs() newattrs.ia_valid = attr_force | kill; -> notify_change() The fix for all of this is to make file_remove_privs()'s should_remove_suid() helper to perform the same checks as we already require in setattr_prepare() and setattr_copy() and have notify_change() not pointlessly requiring S_IXGRP again. It doesn't make any sense in the first place because the caller must calculate the flags via should_remove_suid() anyway which would raise ATTR_KILL_SGID. While we're at it we move should_remove_suid() from inode.c to attr.c where it belongs with the rest of the iattr helpers. Especially since it returns ATTR_KILL_S{G,U}ID flags. We also rename it to setattr_should_drop_suidgid() to better reflect that it indicates both setuid and setgid bit removal and also that it returns attr flags. Running xfstests with this doesn't report any regressions. We should really try and use consistent checks. Reviewed-by: Amir Goldstein Signed-off-by: Christian Brauner (Microsoft) Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit c1df288f4495fa4b0e0224b2c413684d14c9cedb Author: Christian Brauner Date: Mon Oct 17 17:06:36 2022 +0200 attr: add setattr_should_drop_sgid() commit 72ae017c5451860443a16fb2a8c243bff3e396b8 upstream. The current setgid stripping logic during write and ownership change operations is inconsistent and strewn over multiple places. In order to consolidate it and make more consistent we'll add a new helper setattr_should_drop_sgid(). The function retains the old behavior where we remove the S_ISGID bit unconditionally when S_IXGRP is set but also when it isn't set and the caller is neither in the group of the inode nor privileged over the inode. We will use this helper both in write operation permission removal such as file_remove_privs() as well as in ownership change operations. Reviewed-by: Amir Goldstein Signed-off-by: Christian Brauner (Microsoft) Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit e44f23ef91605b61cb2f01994ab5d89e7daaf0ea Author: Christian Brauner Date: Mon Oct 17 17:06:35 2022 +0200 fs: move should_remove_suid() commit e243e3f94c804ecca9a8241b5babe28f35258ef4 upstream. Move the helper from inode.c to attr.c. This keeps the the core of the set{g,u}id stripping logic in one place when we add follow-up changes. It is the better place anyway, since should_remove_suid() returns ATTR_KILL_S{G,U}ID flags. Reviewed-by: Amir Goldstein Signed-off-by: Christian Brauner (Microsoft) Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit 18c2750856dc907ccff05c747e079495f75ea35c Author: Christian Brauner Date: Mon Oct 17 17:06:34 2022 +0200 attr: add in_group_or_capable() commit 11c2a8700cdcabf9b639b7204a1e38e2a0b6798e upstream. In setattr_{copy,prepare}() we need to perform the same permission checks to determine whether we need to drop the setgid bit or not. Instead of open-coding it twice add a simple helper the encapsulates the logic. We will reuse this helpers to make dropping the setgid bit during write operations more consistent in a follow up patch. Reviewed-by: Amir Goldstein Signed-off-by: Christian Brauner (Microsoft) Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit 118ad80d27d938868299ef184f7483b21f011f0b Author: Stylon Wang Date: Tue Jan 10 14:38:33 2023 +0800 drm/amd/display: Properly reuse completion structure commit 0cf8307adbc6beb5ff3b8a76afedc6e4e0b536a9 upstream. [Why] Connecting displays to TBT3 docks often produces invalid replies for DPIA AUX requests. It turns out the completion structure was not re-initialized before reusing it, resulting in immature wake up to completion. [How] Properly call reinit_completion() on reused completion structure. Cc: stable@vger.kernel.org Reviewed-by: Solomon Chiu Acked-by: Alan Liu Signed-off-by: Stylon Wang Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Cc: "Limonciello, Mario" Signed-off-by: Greg Kroah-Hartman commit c9d3eb6151b3c6d0c777f1b4586d90db0ae6ebc3 Author: Saranya Gopal Date: Tue Feb 14 17:15:42 2023 +0530 usb: typec: pd: Remove usb_suspend_supported sysfs from sink PDO commit e4e7b2dc27c4bb877d850eaff69d41410b2f4237 upstream. As per USB PD specification, 28th bit of fixed supply sink PDO represents "higher capability" attribute and not "usb suspend supported" attribute. So, this patch removes the usb_suspend_supported attribute from sink PDO. Fixes: 662a60102c12 ("usb: typec: Separate USB Power Delivery from USB Type-C") Cc: stable Reported-by: Rajaram Regupathy Signed-off-by: Saranya Gopal Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20230214114543.205103-1-saranya.gopal@intel.com Signed-off-by: Greg Kroah-Hartman commit fb9a79557942c843c3e127725fb1300c77480368 Author: Kunihiko Hayashi Date: Tue Feb 7 11:14:29 2023 +0900 arm64: dts: uniphier: Fix property name in PXs3 USB node commit 2508d5efd7a588d07915a762e1731173854525f9 upstream. The property "snps,usb2_gadget_lpm_disable" is wrong. It should be fixed to "snps,usb2-gadget-lpm-disable". Cc: stable@vger.kernel.org Fixes: 19fee1a1096d ("arm64: dts: uniphier: Add USB-device support for PXs3 reference board") Signed-off-by: Kunihiko Hayashi Link: https://lore.kernel.org/r/20230207021429.28925-1-hayashi.kunihiko@socionext.com Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit ec357cd3e8af614855d286dd378725cdc7264df6 Author: Prashanth K Date: Mon Feb 13 23:00:38 2023 +0530 usb: gadget: u_serial: Add null pointer check in gserial_resume commit 5ec63fdbca604568890c577753c6f66c5b3ef0b5 upstream. Consider a case where gserial_disconnect has already cleared gser->ioport. And if a wakeup interrupt triggers afterwards, gserial_resume gets called, which will lead to accessing of gser->ioport and thus causing null pointer dereference.Add a null pointer check to prevent this. Added a static spinlock to prevent gser->ioport from becoming null after the newly added check. Fixes: aba3a8d01d62 ("usb: gadget: u_serial: add suspend resume callbacks") Cc: stable Signed-off-by: Prashanth K Acked-by: Alan Stern Link: https://lore.kernel.org/r/1676309438-14922-1-git-send-email-quic_prashk@quicinc.com Signed-off-by: Greg Kroah-Hartman commit ad5914431b7056a601c7db25c450e360f82b5c06 Author: Florian Zumbiehl Date: Mon Feb 6 02:04:28 2023 +0100 USB: serial: option: add support for VW/Skoda "Carstick LTE" commit 617c331d91077f896111044628c096802551dc66 upstream. Add support for VW/Skoda "Carstick LTE" D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1c9e ProdID=7605 Rev=02.00 S: Manufacturer=USB Modem S: Product=USB Modem C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) The stick has AT command interfaces on interfaces 1, 2, and 3, and does PPP on interface 3. Signed-off-by: Florian Zumbiehl Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit d9651c258d667305602ab785faa9dd6dfa0485a8 Author: Heikki Krogerus Date: Wed Feb 15 15:27:11 2023 +0200 usb: dwc3: pci: add support for the Intel Meteor Lake-M commit 8e5248c3a8778f3e394e9a19195bc7a48f567ca2 upstream. This patch adds the necessary PCI IDs for Intel Meteor Lake-M devices. Signed-off-by: Heikki Krogerus Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230215132711.35668-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 075e2099c32cf4486b27266d2aecf61e95499ea4 Author: Stylon Wang Date: Thu Nov 10 21:53:01 2022 +0800 drm/amd/display: Fix race condition in DPIA AUX transfer commit ead08b95fa50f40618c72b93a849c4ae30c9cd50 upstream. [Why] This fix was intended for improving on coding style but in the process uncovers a race condition, which explains why we are getting incorrect length in DPIA AUX replies. Due to the call path of DPIA AUX going from DC back to DM layer then again into DC and the added complexities on top of current DC AUX implementation, a proper fix to rely on current dc_lock to address the race condition is difficult without a major overhual on how DPIA AUX is implemented. [How] - Add a mutex dpia_aux_lock to protect DPIA AUX transfers - Remove DMUB_ASYNC_TO_SYNC_ACCESS_* codes and rely solely on aux_return_code_type for error reporting and handling - Separate SET_CONFIG from DPIA AUX transfer because they have quiet different processing logic - Remove unnecessary type casting to and from void * type Reviewed-by: Nicholas Kazlauskas Acked-by: Jasdeep Dhillon Signed-off-by: Stylon Wang Signed-off-by: Alex Deucher Cc: "Limonciello, Mario" Signed-off-by: Greg Kroah-Hartman commit 4da108082a3290804ebbd42d70ce8535c00e4637 Author: Nicholas Kazlauskas Date: Mon Jan 23 14:59:28 2023 -0500 drm/amd/display: Move DCN314 DOMAIN power control to DMCUB commit e383b12709e32d6494c948422070c2464b637e44 upstream. [Why] DOMAIN power gating control is now required to be done via firmware due to interlock with other power features. This is to avoid intermittent issues in the LB memories. [How] If the firmware supports the command then use the new firmware as the sequence can avoid potential display corruption issues. The command will be ignored on firmware that does not support DOMAIN power control and the pipes will remain always on - frequent PG cycling can cause the issue to occur on the old sequence, so we should avoid it. Reviewed-by: Hansen Dsouza Acked-by: Qingqing Zhuo Signed-off-by: Nicholas Kazlauskas Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Cc: "Limonciello, Mario" Signed-off-by: Greg Kroah-Hartman commit a595a81df673c69b9d2cb31f7b2ad8fdcf402d2d Author: Thomas Weißschuh Date: Mon Feb 20 06:46:12 2023 +0000 vc_screen: don't clobber return value in vcs_read commit ae3419fbac845b4d3f3a9fae4cc80c68d82cdf6e upstream. Commit 226fae124b2d ("vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF") moved the call to vcs_vc() into the loop. While doing this it also moved the unconditional assignment of ret = -ENXIO; This unconditional assignment was valid outside the loop but within it it clobbers the actual value of ret. To avoid this only assign "ret = -ENXIO" when actually needed. [ Also, the 'goto unlock_out" needs to be just a "break", so that it does the right thing when it exits on later iterations when partial success has happened - Linus ] Reported-by: Storm Dragon Link: https://lore.kernel.org/lkml/Y%2FKS6vdql2pIsCiI@hotmail.com/ Fixes: 226fae124b2d ("vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF") Signed-off-by: Thomas Weißschuh Link: https://lore.kernel.org/lkml/64981d94-d00c-4b31-9063-43ad0a384bde@t-8ch.de/ Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ea4c208efea491be93e37a85b1acd973dbe8594f Author: Kuniyuki Iwashima Date: Thu Feb 9 16:22:02 2023 -0800 net: Remove WARN_ON_ONCE(sk->sk_forward_alloc) from sk_stream_kill_queues(). commit 62ec33b44e0f7168ff2886520fec6fb62d03b5a3 upstream. Christoph Paasch reported that commit b5fc29233d28 ("inet6: Remove inet6_destroy_sock() in sk->sk_prot->destroy().") started triggering WARN_ON_ONCE(sk->sk_forward_alloc) in sk_stream_kill_queues(). [0 - 2] Also, we can reproduce it by a program in [3]. In the commit, we delay freeing ipv6_pinfo.pktoptions from sk->destroy() to sk->sk_destruct(), so sk->sk_forward_alloc is no longer zero in inet_csk_destroy_sock(). The same check has been in inet_sock_destruct() from at least v2.6, we can just remove the WARN_ON_ONCE(). However, among the users of sk_stream_kill_queues(), only CAIF is not calling inet_sock_destruct(). Thus, we add the same WARN_ON_ONCE() to caif_sock_destructor(). [0]: https://lore.kernel.org/netdev/39725AB4-88F1-41B3-B07F-949C5CAEFF4F@icloud.com/ [1]: https://github.com/multipath-tcp/mptcp_net-next/issues/341 [2]: WARNING: CPU: 0 PID: 3232 at net/core/stream.c:212 sk_stream_kill_queues+0x2f9/0x3e0 Modules linked in: CPU: 0 PID: 3232 Comm: syz-executor.0 Not tainted 6.2.0-rc5ab24eb4698afbe147b424149c529e2a43ec24eb5 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:sk_stream_kill_queues+0x2f9/0x3e0 Code: 03 0f b6 04 02 84 c0 74 08 3c 03 0f 8e ec 00 00 00 8b ab 08 01 00 00 e9 60 ff ff ff e8 d0 5f b6 fe 0f 0b eb 97 e8 c7 5f b6 fe <0f> 0b eb a0 e8 be 5f b6 fe 0f 0b e9 6a fe ff ff e8 02 07 e3 fe e9 RSP: 0018:ffff88810570fc68 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff888101f38f40 RSI: ffffffff8285e529 RDI: 0000000000000005 RBP: 0000000000000ce0 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000ce0 R11: 0000000000000001 R12: ffff8881009e9488 R13: ffffffff84af2cc0 R14: 0000000000000000 R15: ffff8881009e9458 FS: 00007f7fdfbd5800(0000) GS:ffff88811b600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b32923000 CR3: 00000001062fc006 CR4: 0000000000170ef0 Call Trace: inet_csk_destroy_sock+0x1a1/0x320 __tcp_close+0xab6/0xe90 tcp_close+0x30/0xc0 inet_release+0xe9/0x1f0 inet6_release+0x4c/0x70 __sock_release+0xd2/0x280 sock_close+0x15/0x20 __fput+0x252/0xa20 task_work_run+0x169/0x250 exit_to_user_mode_prepare+0x113/0x120 syscall_exit_to_user_mode+0x1d/0x40 do_syscall_64+0x48/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f7fdf7ae28d Code: c1 20 00 00 75 10 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 ee fb ff ff 48 89 04 24 b8 03 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2 e8 37 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01 RSP: 002b:00000000007dfbb0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003 RAX: 0000000000000000 RBX: 0000000000000004 RCX: 00007f7fdf7ae28d RDX: 0000000000000000 RSI: ffffffffffffffff RDI: 0000000000000003 RBP: 0000000000000000 R08: 000000007f338e0f R09: 0000000000000e0f R10: 000000007f338e13 R11: 0000000000000293 R12: 00007f7fdefff000 R13: 00007f7fdefffcd8 R14: 00007f7fdefffce0 R15: 00007f7fdefffcd8 [3]: https://lore.kernel.org/netdev/20230208004245.83497-1-kuniyu@amazon.com/ Fixes: b5fc29233d28 ("inet6: Remove inet6_destroy_sock() in sk->sk_prot->destroy().") Reported-by: syzbot Reported-by: Christoph Paasch Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit d879a777d148835b34a9aeb239eaf0f9571856c0 Author: Martin KaFai Lau Date: Thu Feb 16 16:41:48 2023 -0800 bpf: bpf_fib_lookup should not return neigh in NUD_FAILED state commit 1fe4850b34ab512ff911e2c035c75fb6438f7307 upstream. The bpf_fib_lookup() helper does not only look up the fib (ie. route) but it also looks up the neigh. Before returning the neigh, the helper does not check for NUD_VALID. When a neigh state (neigh->nud_state) is in NUD_FAILED, its dmac (neigh->ha) could be all zeros. The helper still returns SUCCESS instead of NO_NEIGH in this case. Because of the SUCCESS return value, the bpf prog directly uses the returned dmac and ends up filling all zero in the eth header. This patch checks for NUD_VALID and returns NO_NEIGH if the neigh is not valid. Signed-off-by: Martin KaFai Lau Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20230217004150.2980689-3-martin.lau@linux.dev Signed-off-by: Greg Kroah-Hartman commit f2173508b195958c97c4a1da28389dc7544d1bc1 Author: Rafael J. Wysocki Date: Thu Dec 1 19:33:09 2022 +0100 PM: sleep: Avoid using pr_cont() in the tasks freezing code commit a449dfbfc0894676ad0aa1873383265047529e3a upstream. Using pr_cont() in the tasks freezing code related to system-wide suspend and hibernation is problematic, because the continuation messages printed there are susceptible to interspersing with other unrelated messages which results in output that is hard to understand. Address this issue by modifying try_to_freeze_tasks() to print messages that don't require continuations and adjusting its callers accordingly. Reported-by: Thomas Weißschuh Signed-off-by: Rafael J. Wysocki Reviewed-by: Petr Mladek Cc: Paul Menzel Signed-off-by: Greg Kroah-Hartman commit 0c2f28f01fce6d5eb34f3e664824d50d563ee720 Author: Kan Liang Date: Wed Feb 8 09:23:40 2023 -0800 x86/cpu: Add Lunar Lake M [ Upstream commit f545e8831e70065e127f903fc7aca09aa50422c7 ] Intel confirmed the existence of this CPU in Q4'2022 earnings presentation. Add the CPU model number. [ dhansen: Merging these as soon as possible makes it easier on all the folks developing model-specific features. ] Signed-off-by: Kan Liang Signed-off-by: Tony Luck Signed-off-by: Dave Hansen Link: https://lore.kernel.org/all/20230208172340.158548-1-tony.luck%40intel.com Signed-off-by: Sasha Levin commit bcc84443631267ae49418e922584cd50ad04025c Author: Vladimir Oltean Date: Sun Feb 5 21:24:09 2023 +0200 selftests: ocelot: tc_flower_chains: make test_vlan_ingress_modify() more comprehensive [ Upstream commit bbb253b206b9c417928a6c827d038e457f3012e9 ] We have two IS1 filters of the OCELOT_VCAP_KEY_ANY key type (the one with "action vlan pop" and the one with "action vlan modify") and one of the OCELOT_VCAP_KEY_IPV4 key type (the one with "action skbedit priority"). But we have no IS1 filter with the OCELOT_VCAP_KEY_ETYPE key type, and there was an uncaught breakage there. To increase test coverage, convert one of the OCELOT_VCAP_KEY_ANY filters to OCELOT_VCAP_KEY_ETYPE, by making the filter also match on the MAC SA of the traffic sent by mausezahn, $h1_mac. Signed-off-by: Vladimir Oltean Link: https://lore.kernel.org/r/20230205192409.1796428-2-vladimir.oltean@nxp.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 56b6ea55f1dcd6e5cd1266df27cb4d54c1b19d8b Author: Luka Guzenko Date: Fri Jan 20 23:37:41 2023 +0100 HID: Ignore battery for ELAN touchscreen 29DF on HP [ Upstream commit ebebf05a4b06a1be49788ca0edf990de01c4b0d0 ] The touchscreen reports a battery status of 0% and jumps to 1% when a stylus is used. The device ID was added and the battery ignore quirk was enabled for it. Signed-off-by: Luka Guzenko Link: https://lore.kernel.org/r/20230120223741.3007-1-l.guzenko@web.de Signed-off-by: Benjamin Tissoires Signed-off-by: Sasha Levin commit a03cc84f70a0cf13d5d29590fe7b699fba906415 Author: Alexey Firago Date: Sat Feb 4 22:51:06 2023 +0300 ASoC: codecs: es8326: Fix DTS properties reading [ Upstream commit fe1e7e8ce2c47bd8fd9885eab63fca0a522e94c9 ] Seems like properties parsing and reading was copy-pasted, so "everest,interrupt-src" and "everest,interrupt-clk" are saved into the es8326->jack_pol variable. This might lead to wrong settings being saved into the reg 57 (ES8326_HP_DET). Fix this by using proper variables while reading properties. Signed-off-by: Alexey Firago Reviewed-by: Yang Yingliang Signed-off-by: Sasha Levin commit 0412fe1deab1789185e9a744c051ca262b3ee6b7 Author: Xin Zhao Date: Mon Jan 30 21:29:47 2023 +0000 HID: core: Fix deadloop in hid_apply_multiplier. [ Upstream commit ea427a222d8bdf2bc1a8a6da3ebe247f7dced70c ] The initial value of hid->collection[].parent_idx if 0. When Report descriptor doesn't contain "HID Collection", the value remains as 0. In the meanwhile, when the Report descriptor fullfill all following conditions, it will trigger hid_apply_multiplier function call. 1. Usage page is Generic Desktop Ctrls (0x01) 2. Usage is RESOLUTION_MULTIPLIER (0x48) 3. Contain any FEATURE items The while loop in hid_apply_multiplier will search the top-most collection by searching parent_idx == -1. Because all parent_idx is 0. The loop will run forever. There is a Report Descriptor triggerring the deadloop 0x05, 0x01, // Usage Page (Generic Desktop Ctrls) 0x09, 0x48, // Usage (0x48) 0x95, 0x01, // Report Count (1) 0x75, 0x08, // Report Size (8) 0xB1, 0x01, // Feature Signed-off-by: Xin Zhao Link: https://lore.kernel.org/r/20230130212947.1315941-1-xnzhao@google.com Signed-off-by: Benjamin Tissoires Signed-off-by: Sasha Levin commit b7641733a4a18c6142b88098f9839fd67c37dcff Author: Julian Anastasov Date: Thu Feb 2 17:25:51 2023 +0200 neigh: make sure used and confirmed times are valid [ Upstream commit c1d2ecdf5e38e3489ce8328238b558b3b2866fe1 ] Entries can linger in cache without timer for days, thanks to the gc_thresh1 limit. As result, without traffic, the confirmed time can be outdated and to appear to be in the future. Later, on traffic, NUD_STALE entries can switch to NUD_DELAY and start the timer which can see the invalid confirmed time and wrongly switch to NUD_REACHABLE state instead of NUD_PROBE. As result, timer is set many days in the future. This is more visible on 32-bit platforms, with higher HZ value. Why this is a problem? While we expect unused entries to expire, such entries stay in REACHABLE state for too long, locked in cache. They are not expired normally, only when cache is full. Problem and the wrong state change reported by Zhang Changzhong: 172.16.1.18 dev bond0 lladdr 0a:0e:0f:01:12:01 ref 1 used 350521/15994171/350520 probes 4 REACHABLE 350520 seconds have elapsed since this entry was last updated, but it is still in the REACHABLE state (base_reachable_time_ms is 30000), preventing lladdr from being updated through probe. Fix it by ensuring timer is started with valid used/confirmed times. Considering the valid time range is LONG_MAX jiffies, we try not to go too much in the past while we are in DELAY/PROBE state. There are also places that need used/updated times to be validated while timer is not running. Reported-by: Zhang Changzhong Signed-off-by: Julian Anastasov Tested-by: Zhang Changzhong Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6595071a36045e503b575818cfc5f6d102b7da98 Author: Dmitry Torokhov Date: Fri Sep 30 09:00:41 2022 -0700 ARM: dts: stihxxx-b2120: fix polarity of reset line of tsin0 port [ Upstream commit 4722dd4029c63f10414ffd8d3ffdd6c748391cd7 ] According to c8sectpfe driver code we first drive reset line low and then high to reset the port, therefore the reset line is supposed to be annotated as "active low". This will be important when we convert the driver to gpiod API. Reviewed-by: Patrice Chotard Signed-off-by: Dmitry Torokhov Signed-off-by: Patrice Chotard Signed-off-by: Sasha Levin commit 39cdf021fa05ee695ea459a3d190e15426c1c053 Author: V sujith kumar Reddy Date: Fri Feb 3 18:02:52 2023 +0530 ASoC: SOF: amd: Fix for handling spurious interrupts from DSP [ Upstream commit 2e7c6652f9b86c01cbd4e988057a746a3a461969 ] As interrupts are Level-triggered,unless and until we deassert the register the interrupts are generated which causes spurious interrupts unhandled. Now we deasserted the interrupt at top half which solved the below "nobody cared" warning. warning reported in dmesg: irq 80: nobody cared (try booting with the "irqpoll" option) CPU: 5 PID: 2735 Comm: irq/80-AudioDSP Not tainted 5.15.86-15817-g4c19f3e06d49 #1 1bd3fd932cf58caacc95b0504d6ea1e3eab22289 Hardware name: Google Skyrim/Skyrim, BIOS Google_Skyrim.15303.0.0 01/03/2023 Call Trace: dump_stack_lvl+0x69/0x97 __report_bad_irq+0x3a/0xae note_interrupt+0x1a9/0x1e3 handle_irq_event_percpu+0x4b/0x6e handle_irq_event+0x36/0x5b handle_fasteoi_irq+0xae/0x171 __common_interrupt+0x48/0xc4 handlers: acp_irq_handler [snd_sof_amd_acp] threaded [<000000007e089f34>] acp_irq_thread [snd_sof_amd_acp] Disabling IRQ #80 Signed-off-by: V sujith kumar Reddy Link: https://lore.kernel.org/r/20230203123254.1898794-1-Vsujithkumar.Reddy@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8988889aaeb5b352f358d1d93ddd331a0999daef Author: Michael Ellerman Date: Thu Feb 2 21:27:35 2023 +1100 powerpc: Don't select ARCH_WANTS_NO_INSTR [ Upstream commit e33416fca8a2313b8650bd5807aaf34354d39a4c ] Commit 41b7a347bf14 ("powerpc: Book3S 64-bit outline-only KASAN support") added a select of ARCH_WANTS_NO_INSTR, because it also added some uses of noinstr. However noinstr is always defined, regardless of ARCH_WANTS_NO_INSTR, so there's no need to select it just for that. As PeterZ says [1]: Note that by selecting ARCH_WANTS_NO_INSTR you effectively state to abide by its rules. As of now the powerpc code does not abide by those rules, and trips some new warnings added by Peter in linux-next. So until the code can be fixed to avoid those warnings, disable ARCH_WANTS_NO_INSTR. Note that ARCH_WANTS_NO_INSTR is also used to gate building KCOV and parts of KCSAN. However none of the noinstr annotations in powerpc were added for KCOV or KCSAN, instead instrumentation is blocked at the file level using KCOV_INSTRUMENT_foo.o := n. [1]: https://lore.kernel.org/linuxppc-dev/Y9t6yoafrO5YqVgM@hirez.programming.kicks-ass.net Reported-by: Sachin Sant Suggested-by: Peter Zijlstra Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit ce77f44cb9ad1b30af68f7ff0f4421df4a5d6dbc Author: Dean Luick Date: Mon Jan 9 14:04:08 2023 -0500 IB/hfi1: Assign npages earlier [ Upstream commit f9c47b2caa7ffc903ec950b454b59c209afe3182 ] Improve code clarity and enable earlier use of tidbuf->npages by moving its assignment to structure creation time. Signed-off-by: Dean Luick Signed-off-by: Dennis Dalessandro Link: https://lore.kernel.org/r/167329104884.1472990.4639750192433251493.stgit@awfm-02.cornelisnetworks.com Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit d06e776698adf02ea23463568e4952a303eeb5f2 Author: Jack Yu Date: Mon Jan 30 02:43:25 2023 +0000 ASoC: rt715-sdca: fix clock stop prepare timeout issue [ Upstream commit 2036890282d56bcbf7f915ba9e04bf77967ab231 ] Modify clock_stop_timeout value for rt715-sdca according to the requirement of internal clock trimming. Signed-off-by: Jack Yu Link: https://lore.kernel.org/r/574b6586267a458cac78c5ac4d5b10bd@realtek.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 46abcdf96db26c2d90272100b3a76e9c8ade7445 Author: Krzysztof Kozlowski Date: Thu Jan 19 13:46:31 2023 +0100 arm64: dts: rockchip: align rk3399 DMC OPP table with bindings [ Upstream commit b67b09733d8a41eec33d5d37be2f8cff8af82a5e ] Bindings expect certain pattern for OPP table node name and underscores are not allowed: rk3399-rock-pi-4a-plus.dtb: dmc_opp_table: $nodename:0: 'dmc_opp_table' does not match '^opp-table(-[a-z0-9]+)?$' Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20230119124631.91080-1-krzysztof.kozlowski@linaro.org Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 07c5877e14441f259177a77c48535661a8eb8358 Author: David Sterba Date: Tue Jan 24 20:32:10 2023 +0100 btrfs: send: limit number of clones and allocated memory size [ Upstream commit 33e17b3f5ab74af12aca58c515bc8424ff69a343 ] The arg->clone_sources_count is u64 and can trigger a warning when a huge value is passed from user space and a huge array is allocated. Limit the allocated memory to 8MiB (can be increased if needed), which in turn limits the number of clone sources to 8M / sizeof(struct clone_root) = 8M / 40 = 209715. Real world number of clones is from tens to hundreds, so this is future proof. Reported-by: syzbot+4376a9a073770c173269@syzkaller.appspotmail.com Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 91210aca68f32c9c81587fbb711ff40ff11a144f Author: Mario Limonciello Date: Sat Jan 21 07:48:10 2023 -0600 pinctrl: amd: Fix debug output for debounce time [ Upstream commit c6e0679b8381bf03315e6660cf5370f916c1a1c6 ] If one GPIO has debounce enabled but future GPIOs in the list don't have debounce the time never gets reset and shows wrong value. Signed-off-by: Mario Limonciello Link: https://lore.kernel.org/r/20230121134812.16637-2-mario.limonciello@amd.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit fdbcacfe495dc3faa9d49872a2c40f25fc069f27 Author: Vishal Verma Date: Wed Jan 25 11:34:18 2023 -0700 ACPI: NFIT: fix a potential deadlock during NFIT teardown [ Upstream commit fb6df4366f86dd252bfa3049edffa52d17e7b895 ] Lockdep reports that acpi_nfit_shutdown() may deadlock against an opportune acpi_nfit_scrub(). acpi_nfit_scrub () is run from inside a 'work' and therefore has already acquired workqueue-internal locks. It also acquiires acpi_desc->init_mutex. acpi_nfit_shutdown() first acquires init_mutex, and was subsequently attempting to cancel any pending workqueue items. This reversed locking order causes a potential deadlock: ====================================================== WARNING: possible circular locking dependency detected 6.2.0-rc3 #116 Tainted: G O N ------------------------------------------------------ libndctl/1958 is trying to acquire lock: ffff888129b461c0 ((work_completion)(&(&acpi_desc->dwork)->work)){+.+.}-{0:0}, at: __flush_work+0x43/0x450 but task is already holding lock: ffff888129b460e8 (&acpi_desc->init_mutex){+.+.}-{3:3}, at: acpi_nfit_shutdown+0x87/0xd0 [nfit] which lock already depends on the new lock. ... Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&acpi_desc->init_mutex); lock((work_completion)(&(&acpi_desc->dwork)->work)); lock(&acpi_desc->init_mutex); lock((work_completion)(&(&acpi_desc->dwork)->work)); *** DEADLOCK *** Since the workqueue manipulation is protected by its own internal locking, the cancellation of pending work doesn't need to be done under acpi_desc->init_mutex. Move cancel_delayed_work_sync() outside the init_mutex to fix the deadlock. Any work that starts after acpi_nfit_shutdown() drops the lock will see ARS_CANCEL, and the cancel_delayed_work_sync() will safely flush it out. Reported-by: Dan Williams Signed-off-by: Vishal Verma Link: https://lore.kernel.org/r/20230112-acpi_nfit_lockdep-v1-1-660be4dd10be@intel.com Signed-off-by: Dan Williams Signed-off-by: Sasha Levin commit 1b7730f203559481edefb06dca743bea01a6e138 Author: marco.rodolfi@tuta.io Date: Tue Jan 10 15:54:26 2023 +0100 HID: Ignore battery for Elan touchscreen on Asus TP420IA [ Upstream commit cb963b2c011a62838852c902eccb3f72e5d3dbb6 ] This device has a touchscreen thats report a battery even if it doesn't have one. Ask Linux to ignore the battery so it will not always report it as low. [jkosina@suse.cz: fix whitespace damage] Signed-off-by: Marco Rodolfi Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 0773ecf7bcda9cea57e28ffc55297ea2c16bca3a Author: Takahiro Fujii Date: Fri Jan 20 03:30:02 2023 +0900 HID: elecom: add support for TrackBall 056E:011C [ Upstream commit 29f316a1d7e0a570be9a47fa283ece53a67cebb7 ] Make function buttons on ELECOM M-HT1DRBK trackball mouse work. This model has two devices with different device IDs (010D and 011C). Both of them misreports the number of buttons as 5 in the report descriptor, even though they have 8 buttons. hid-elecom overwrites the report to fix them, but supports only on 010D and does not work on 011C. This patch fixes 011C in the similar way but with specialized position parameters. In fact, it is sufficient to rewrite only 17th byte (05 -> 08). However I followed the existing way. Signed-off-by: Takahiro Fujii Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 860a9c0509dbcd287cf54704b9d11e3a0b476694 Author: Jonas Karlman Date: Sun Jan 15 21:15:56 2023 +0000 arm64: dts: rockchip: fix probe of analog sound card on rock-3a [ Upstream commit 1104693cdfcd337e73ab585a225f05445ff7a864 ] The following was observed on my Radxa ROCK 3 Model A board: rockchip-pinctrl pinctrl: pin gpio1-9 already requested by vcc-cam-regulator; cannot claim for fe410000.i2s ... platform rk809-sound: deferred probe pending Fix this by supplying a board specific pinctrl with the i2s1 pins used by pmic codec according to the schematic [1]. [1] https://dl.radxa.com/rock3/docs/hw/3a/ROCK-3A-V1.3-SCH.pdf Signed-off-by: Jonas Karlman Acked-by: Michael Riesch Link: https://lore.kernel.org/r/20230115211553.445007-1-jonas@kwiboo.se Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 6a63f9795f6ef82098e271669829654dbda1442e Author: Jensen Huang Date: Fri Jan 13 14:44:57 2023 +0800 arm64: dts: rockchip: add missing #interrupt-cells to rk356x pcie2x1 [ Upstream commit a323e6b5737bb6e3d3946369b97099abb7dde695 ] This fixes the following issue: pcieport 0000:00:00.0: of_irq_parse_pci: failed with rc=-22 Signed-off-by: Jensen Huang Link: https://lore.kernel.org/r/20230113064457.7105-1-jensenhuang@friendlyarm.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 59770f4b5237d2fa86746a43162b77833a59e01d Author: Johan Jonker Date: Wed Dec 28 21:17:32 2022 +0100 ARM: dts: rockchip: add power-domains property to dp node on rk3288 [ Upstream commit 80422339a75088322b4d3884bd12fa0fe5d11050 ] The clocks in the Rockchip rk3288 DisplayPort node are included in the power-domain@RK3288_PD_VIO logic, but the power-domains property in the dp node is missing, so fix it. Signed-off-by: Johan Jonker Link: https://lore.kernel.org/r/dab85bfb-9f55-86a1-5cd5-7388c43e0ec5@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 69eca8dd3c610099217bd723f9402a4578cd2634 Author: Krzysztof Kozlowski Date: Fri Nov 25 15:41:34 2022 +0100 arm64: dts: rockchip: drop unused LED mode property from rk3328-roc-cc [ Upstream commit 1692bffec674551163a7a4be32f59fdde04ecd27 ] GPIO LEDs do not have a 'mode' property: rockchip/rk3328-roc-pc.dtb: leds: led-0: Unevaluated properties are not allowed ('mode' was unexpected) Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20221125144135.477144-1-krzysztof.kozlowski@linaro.org Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit fd606d611560435adbbdac54a766555c9b785072 Author: Jarrah Gosbell Date: Wed Dec 7 11:32:13 2022 +0000 arm64: dts: rockchip: reduce thermal limits on rk3399-pinephone-pro [ Upstream commit 33e24f0738b922b6f5f4118dbdc26cac8400d7b9 ] While this device uses the rk3399 it is also enclosed in a tight package and cooled through the screen and back case. The default rk3399 thermal limits can result in a burnt screen. These lower limits have resulted in the existing burn not expanding and will hopefully result in future devices not experiencing the issue. Signed-off-by: Jarrah Gosbell Link: https://lore.kernel.org/r/20221207113212.8216-1-kernel@undef.tools Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 0b892d8fe90b82bbfbb8619e7ecf1ec91fb5256c Author: Benedict Wong Date: Thu Jan 5 21:28:12 2023 +0000 Fix XFRM-I support for nested ESP tunnels [ Upstream commit b0355dbbf13c0052931dd14c38c789efed64d3de ] This change adds support for nested IPsec tunnels by ensuring that XFRM-I verifies existing policies before decapsulating a subsequent policies. Addtionally, this clears the secpath entries after policies are verified, ensuring that previous tunnels with no-longer-valid do not pollute subsequent policy checks. This is necessary especially for nested tunnels, as the IP addresses, protocol and ports may all change, thus not matching the previous policies. In order to ensure that packets match the relevant inbound templates, the xfrm_policy_check should be done before handing off to the inner XFRM protocol to decrypt and decapsulate. Notably, raw ESP/AH packets did not perform policy checks inherently, whereas all other encapsulated packets (UDP, TCP encapsulated) do policy checks after calling xfrm_input handling in the respective encapsulation layer. Test: Verified with additional Android Kernel Unit tests Signed-off-by: Benedict Wong Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin