shinys000114/linux
1
0
Fork 0
mirror of https://github.com/hardkernel/linux.git synced 2026-06-05 10:31:46 +09:00
Code Issues Packages Projects Releases Wiki Activity
1,149,748 Commits 55 Branches 2,486 Tags
1c4d2aa0c7120ab303d98f5fdacefd13a4e8ced2
Commit Graph

1149748 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
Zheng Wang
1c4d2aa0c7 UPSTREAM: memstick: r592: Fix UAF bug in r592_remove due to race condition 
[ Upstream commit 6326442278 ]

In r592_probe, dev->detect_timer was bound with r592_detect_timer.
In r592_irq function, the timer function will be invoked by mod_timer.

If we remove the module which will call hantro_release to make cleanup,
there may be a unfinished work. The possible sequence is as follows,
which will cause a typical UAF bug.

Fix it by canceling the work before cleanup in r592_remove.

CPU0                  CPU1

                    |r592_detect_timer
r592_remove         |
  memstick_free_host|
  put_device;       |
  kfree(host);      |
                    |
                    | queue_work
                    |   &host->media_checker //use

Bug: 287729043
Signed-off-by: Zheng Wang <zyytlz.wz@163.com>
Link: https://lore.kernel.org/r/20230307164338.1246287-1-zyytlz.wz@163.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 9a342d4eb9)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Idb15f593287ebaeec294b3e276126306fa6743ba
 2023-06-19 14:56:51 +00:00
Darrick J. Wong
8aea35f109 UPSTREAM: xfs: verify buffer contents when we skip log replay 
commit 22ed903eee upstream.

syzbot detected a crash during log recovery:

XFS (loop0): Mounting V5 Filesystem bfdc47fc-10d8-4eed-a562-11a831b3f791
XFS (loop0): Torn write (CRC failure) detected at log block 0x180. Truncating head block from 0x200.
XFS (loop0): Starting recovery (logdev: internal)
==================================================================
BUG: KASAN: slab-out-of-bounds in xfs_btree_lookup_get_block+0x15c/0x6d0 fs/xfs/libxfs/xfs_btree.c:1813
Read of size 8 at addr ffff88807e89f258 by task syz-executor132/5074

CPU: 0 PID: 5074 Comm: syz-executor132 Not tainted 6.2.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x1b1/0x290 lib/dump_stack.c:106
 print_address_description+0x74/0x340 mm/kasan/report.c:306
 print_report+0x107/0x1f0 mm/kasan/report.c:417
 kasan_report+0xcd/0x100 mm/kasan/report.c:517
 xfs_btree_lookup_get_block+0x15c/0x6d0 fs/xfs/libxfs/xfs_btree.c:1813
 xfs_btree_lookup+0x346/0x12c0 fs/xfs/libxfs/xfs_btree.c:1913
 xfs_btree_simple_query_range+0xde/0x6a0 fs/xfs/libxfs/xfs_btree.c:4713
 xfs_btree_query_range+0x2db/0x380 fs/xfs/libxfs/xfs_btree.c:4953
 xfs_refcount_recover_cow_leftovers+0x2d1/0xa60 fs/xfs/libxfs/xfs_refcount.c:1946
 xfs_reflink_recover_cow+0xab/0x1b0 fs/xfs/xfs_reflink.c:930
 xlog_recover_finish+0x824/0x920 fs/xfs/xfs_log_recover.c:3493
 xfs_log_mount_finish+0x1ec/0x3d0 fs/xfs/xfs_log.c:829
 xfs_mountfs+0x146a/0x1ef0 fs/xfs/xfs_mount.c:933
 xfs_fs_fill_super+0xf95/0x11f0 fs/xfs/xfs_super.c:1666
 get_tree_bdev+0x400/0x620 fs/super.c:1282
 vfs_get_tree+0x88/0x270 fs/super.c:1489
 do_new_mount+0x289/0xad0 fs/namespace.c:3145
 do_mount fs/namespace.c:3488 [inline]
 __do_sys_mount fs/namespace.c:3697 [inline]
 __se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674
 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:0x7f89fa3f4aca
Code: 83 c4 08 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fffd5fb5ef8 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00646975756f6e2c RCX: 00007f89fa3f4aca
RDX: 0000000020000100 RSI: 0000000020009640 RDI: 00007fffd5fb5f10
RBP: 00007fffd5fb5f10 R08: 00007fffd5fb5f50 R09: 000000000000970d
R10: 0000000000200800 R11: 0000000000000206 R12: 0000000000000004
R13: 0000555556c6b2c0 R14: 0000000000200800 R15: 00007fffd5fb5f50
 </TASK>

The fuzzed image contains an AGF with an obviously garbage
agf_refcount_level value of 32, and a dirty log with a buffer log item
for that AGF.  The ondisk AGF has a higher LSN than the recovered log
item.  xlog_recover_buf_commit_pass2 reads the buffer, compares the
LSNs, and decides to skip replay because the ondisk buffer appears to be
newer.

Unfortunately, the ondisk buffer is corrupt, but recovery just read the
buffer with no buffer ops specified:

	error = xfs_buf_read(mp->m_ddev_targp, buf_f->blf_blkno,
			buf_f->blf_len, buf_flags, &bp, NULL);

Skipping the buffer leaves its contents in memory unverified.  This sets
us up for a kernel crash because xfs_refcount_recover_cow_leftovers
reads the buffer (which is still around in XBF_DONE state, so no read
verification) and creates a refcountbt cursor of height 32.  This is
impossible so we run off the end of the cursor object and crash.

Fix this by invoking the verifier on all skipped buffers and aborting
log recovery if the ondisk buffer is corrupt.  It might be smarter to
force replay the log item atop the buffer and then see if it'll pass the
write verifier (like ext4 does) but for now let's go with the
conservative option where we stop immediately.

Bug: 284409747
Link: https://syzkaller.appspot.com/bug?extid=7e9494b8b399902e994e
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Reported-by: Danila Chernetsov <listdansp@mail.ru>
Link: https://lore.kernel.org/linux-xfs/20230601164439.15404-1-listdansp@mail.ru
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Acked-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit a2961463d7)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Ie5e156221966323a9cb7cc261b4ed17593cfaabd
 2023-06-19 13:21:31 +00:00
Ruihan Li
04b6079eae UPSTREAM: bluetooth: Perform careful capability checks in hci_sock_ioctl() 
commit 25c150ac10 upstream.

Previously, capability was checked using capable(), which verified that the
caller of the ioctl system call had the required capability. In addition,
the result of the check would be stored in the HCI_SOCK_TRUSTED flag,
making it persistent for the socket.

However, malicious programs can abuse this approach by deliberately sharing
an HCI socket with a privileged task. The HCI socket will be marked as
trusted when the privileged task occasionally makes an ioctl call.

This problem can be solved by using sk_capable() to check capability, which
ensures that not only the current task but also the socket opener has the
specified capability, thus reducing the risk of privilege escalation
through the previously identified vulnerability.

Bug: 286456284
Cc: stable@vger.kernel.org
Fixes: f81f5b2db8 ("Bluetooth: Send control open and close messages for HCI raw sockets")
Signed-off-by: Ruihan Li <lrh2000@pku.edu.cn>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 47e6893a5b)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I9a4b20c7b1e9b4e6bbd6371264aec039770a52ff
 2023-06-19 11:37:23 +00:00
Liam R. Howlett
8f5a220975 FROMLIST: maple_tree: Adjust node allocation on mas_rebalance() 
mas_rebalance() is called to rebalance an insufficient node into a
single node or two sufficient nodes.  The preallocation estimate is
always too many in this case as the height of the tree will never grow
and there is no possibility to have a three way split in this case, so
revise the node allocation count.

Change-Id: I04ba0674da381c06d4f8077f9f59d64b7d1a8312
Signed-off-by: Liam R. Howlett <Liam.Howlett@oracle.com>
Link: https://lore.kernel.org/all/20230612203953.2093911-9-Liam.Howlett@oracle.com/
Bug: 274059236
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
 2023-06-19 11:01:24 +00:00
Liam R. Howlett
e835ffdfbc FROMLIST: maple_tree: Reduce resets during store setup 
mas_prealloc() may walk partially down the tree before finding that a
split or spanning store is needed.  When the write occurs, relax the
logic on resetting the walk so that partial walks will not restart, but
walks that have gone too far (a store that affects beyond the current
node) should be restarted.

Signed-off-by: Liam R. Howlett <Liam.Howlett@oracle.com>

Link: https://lore.kernel.org/all/20230612203953.2093911-16-Liam.Howlett@oracle.com/
Bug: 274059236
Change-Id: I87dedebae085f067b08caeaf1bd19bb343ff305f
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
 2023-06-19 11:01:24 +00:00
Liam R. Howlett
708234485a FROMLIST: BACKPORT: maple_tree: Refine mas_preallocate() node calculations 
Calculate the number of nodes based on the pending write action instead
of assuming the worst case.

This addresses a performance regression introduced in platforms that
have longer allocation timing.

Signed-off-by: Liam R. Howlett <Liam.Howlett@oracle.com>

Link: https://lore.kernel.org/all/20230612203953.2093911-15-Liam.Howlett@oracle.com/
[surenb: replace mas_wr_new_end with mas_wr_node_size]

Bug: 274059236
Change-Id: I8fc22bca45fa005acf767722034a260242a4da52
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
 2023-06-19 11:01:24 +00:00
Suren Baghdasaryan
d766c8399b Revert "FROMLIST: BACKPORT: maple_tree: Refine mas_preallocate() node calculations" 
This reverts commit 133fbad5bd.

Replacing the patch with a newer version improving performance:
https://lore.kernel.org/all/20230612203953.2093911-15-Liam.Howlett@oracle.com/

Bug: 274059236
Change-Id: I0a924698c908e00d2addb9b7c90e573e72c8ba59
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
 2023-06-19 11:01:24 +00:00
Will McVicker
0a859e781c ANDROID: GKI: Include kheaders in gki_system_dlkm_modules 
This is needed to get the module on the system_dlkm image.

Bug: 276339429
Change-Id: Ib8c19d0d23f27bc3872e8d387b20cef07327c600
Signed-off-by: Will McVicker <willmcvicker@google.com>
 2023-06-18 09:06:56 +00:00
Carlos Llamas
35fe0d393f ANDROID: 6/16/2023 KMI update 
Set KMI_GENERATION=11 for 6/16 KMI update

function symbol changed from 'int __traceiter_android_rvh_schedule(void*, struct task_struct*, struct task_struct*, struct rq*)' to 'int __traceiter_android_rvh_schedule(void*, unsigned int, struct task_struct*, struct task_struct*, struct rq*)'
  CRC changed from 0x6be67582 to 0x5597e05e
  type changed from 'int(void*, struct task_struct*, struct task_struct*, struct rq*)' to 'int(void*, unsigned int, struct task_struct*, struct task_struct*, struct rq*)'
    parameter 2 type changed from 'struct task_struct*' to 'unsigned int'
    parameter 4 type changed from 'struct rq*' to 'struct task_struct*'
      pointed-to type changed from 'struct rq' to 'struct task_struct'
    parameter 5 of type 'struct rq*' was added

function symbol 'struct usb_hcd* __usb_create_hcd(const struct hc_driver*, struct device*, struct device*, const char*, struct usb_hcd*)' changed
  CRC changed from 0xab3fbd7 to 0x44b8d338

function symbol 'struct usb_phy* devm_usb_get_phy(struct device*, enum usb_phy_type)' changed
  CRC changed from 0x976fe01c to 0x3b6c04cd

function symbol 'struct usb_phy* devm_usb_get_phy_by_node(struct device*, struct device_node*, struct notifier_block*)' changed
  CRC changed from 0xaaf602d1 to 0x9225cdfb

... 25 omitted; 28 symbols have only CRC changes

type 'struct usb_phy' changed
  byte size changed from 360 to 392
  member 'u64 android_kabi_reserved0' was added
  member 'u64 android_kabi_reserved1' changed
    offset changed by 64
  member 'u64 android_kabi_reserved2' was added
  member 'u64 android_kabi_reserved3' was added
  member 'u64 android_kabi_reserved4' was added

Bug: 287162457
Change-Id: I82bd766a4ac81bb8fdaca4d95e95c8c413ac7485
Signed-off-by: Carlos Llamas <cmllamas@google.com>
 2023-06-16 20:49:51 +00:00
Dezhi Huang
fcc5e942e0 ANDROID: sched: Add parameter to android_rvh_schedule. 
Checking whether the ui and render threads are preempted
during frame drawing,then adjusting the prority and core
selection if they are preempted,because we expect the
threads to be executed first.By introducing the
sched_mode parameter, we can check the prev thread
preemption status in the hook, and judging important
threads for executing business logic.

Bug: 285166029
Change-Id: I6af31dff4c9032940c7f1c991a25a49ebbeac7a8
Signed-off-by: Dezhi Huang <huangdezhi@hihonor.com>
 2023-06-16 20:18:45 +00:00
Greg Kroah-Hartman
d4dd4d9f19 ANDROID: GKI: provide more padding for struct usb_phy 
There is at least one pending change for struct usb_phy that is not
going to make the ABI freeze deadline, but has already been submitted
upstream and is under active development.  So reserve a spot for that
new callback to be added, and provide a bit more buffer here to the
structure for any future LTS changes that might be coming in this area
of the kernel

Bug: 151154716
Cc: Stanley Chang <stanley_chang@realtek.com>
Change-Id: I992a46fa35502fd491ee24d503290119c9b9f655
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
 2023-06-16 20:18:33 +00:00
Vignesh Saravanaperumal
bb9c879726 ANDROID: GKI enable CONFIG_NETFILTER_XT_MATCH_CONNBYTES=y 
Match by how many bytes or packets a connection has transferred so far, or by average bytes per packet.

Bug: 284571311
Signed-off-by: Vignesh Saravanaperumal <vignesh1.s@samsung.com>
Change-Id: I352bc42ab0da321e29a8cef1069565b7a5f182e7
(cherry picked from commit d80f39a5aed79ae81eb92f009829905da8e4f7a0)
 2023-06-16 09:19:53 +00:00
Youngmin Nam
a7b1da66a2 FROMGIT: arm64: set __exception_irq_entry with __irq_entry as a default 
filter_irq_stacks() is supposed to cut entries which are related irq entries
from its call stack.
And in_irqentry_text() which is called by filter_irq_stacks()
uses __irqentry_text_start/end symbol to find irq entries in callstack.

But it doesn't work correctly as without "CONFIG_FUNCTION_GRAPH_TRACER",
arm64 kernel doesn't include gic_handle_irq which is entry point of arm64 irq
between __irqentry_text_start and __irqentry_text_end as we discussed in below link.
https://lore.kernel.org/all/CACT4Y+aReMGLYua2rCLHgFpS9io5cZC04Q8GLs-uNmrn1ezxYQ@mail.gmail.com/#t

This problem can makes unintentional deep call stack entries especially
in KASAN enabled situation as below.

[ 2479.383395]I[0:launcher-loader: 1719] Stack depot reached limit capacity
[ 2479.383538]I[0:launcher-loader: 1719] WARNING: CPU: 0 PID: 1719 at lib/stackdepot.c:129 __stack_depot_save+0x464/0x46c
[ 2479.385693]I[0:launcher-loader: 1719] pstate: 624000c5 (nZCv daIF +PAN -UAO +TCO -DIT -SSBS BTYPE=--)
[ 2479.385724]I[0:launcher-loader: 1719] pc : __stack_depot_save+0x464/0x46c
[ 2479.385751]I[0:launcher-loader: 1719] lr : __stack_depot_save+0x460/0x46c
[ 2479.385774]I[0:launcher-loader: 1719] sp : ffffffc0080073c0
[ 2479.385793]I[0:launcher-loader: 1719] x29: ffffffc0080073e0 x28: ffffffd00b78a000 x27: 0000000000000000
[ 2479.385839]I[0:launcher-loader: 1719] x26: 000000000004d1dd x25: ffffff891474f000 x24: 00000000ca64d1dd
[ 2479.385882]I[0:launcher-loader: 1719] x23: 0000000000000200 x22: 0000000000000220 x21: 0000000000000040
[ 2479.385925]I[0:launcher-loader: 1719] x20: ffffffc008007440 x19: 0000000000000000 x18: 0000000000000000
[ 2479.385969]I[0:launcher-loader: 1719] x17: 2065726568207475 x16: 000000000000005e x15: 2d2d2d2d2d2d2d20
[ 2479.386013]I[0:launcher-loader: 1719] x14: 5d39313731203a72 x13: 00000000002f6b30 x12: 00000000002f6af8
[ 2479.386057]I[0:launcher-loader: 1719] x11: 00000000ffffffff x10: ffffffb90aacf000 x9 : e8a74a6c16008800
[ 2479.386101]I[0:launcher-loader: 1719] x8 : e8a74a6c16008800 x7 : 00000000002f6b30 x6 : 00000000002f6af8
[ 2479.386145]I[0:launcher-loader: 1719] x5 : ffffffc0080070c8 x4 : ffffffd00b192380 x3 : ffffffd0092b313c
[ 2479.386189]I[0:launcher-loader: 1719] x2 : 0000000000000001 x1 : 0000000000000004 x0 : 0000000000000022
[ 2479.386231]I[0:launcher-loader: 1719] Call trace:
[ 2479.386248]I[0:launcher-loader: 1719]  __stack_depot_save+0x464/0x46c
[ 2479.386273]I[0:launcher-loader: 1719]  kasan_save_stack+0x58/0x70
[ 2479.386303]I[0:launcher-loader: 1719]  save_stack_info+0x34/0x138
[ 2479.386331]I[0:launcher-loader: 1719]  kasan_save_free_info+0x18/0x24
[ 2479.386358]I[0:launcher-loader: 1719]  ____kasan_slab_free+0x16c/0x170
[ 2479.386385]I[0:launcher-loader: 1719]  __kasan_slab_free+0x10/0x20
[ 2479.386410]I[0:launcher-loader: 1719]  kmem_cache_free+0x238/0x53c
[ 2479.386435]I[0:launcher-loader: 1719]  mempool_free_slab+0x1c/0x28
[ 2479.386460]I[0:launcher-loader: 1719]  mempool_free+0x7c/0x1a0
[ 2479.386484]I[0:launcher-loader: 1719]  bvec_free+0x34/0x80
[ 2479.386514]I[0:launcher-loader: 1719]  bio_free+0x60/0x98
[ 2479.386540]I[0:launcher-loader: 1719]  bio_put+0x50/0x21c
[ 2479.386567]I[0:launcher-loader: 1719]  f2fs_write_end_io+0x4ac/0x4d0
[ 2479.386594]I[0:launcher-loader: 1719]  bio_endio+0x2dc/0x300
[ 2479.386622]I[0:launcher-loader: 1719]  __dm_io_complete+0x324/0x37c
[ 2479.386650]I[0:launcher-loader: 1719]  dm_io_dec_pending+0x60/0xa4
[ 2479.386676]I[0:launcher-loader: 1719]  clone_endio+0xf8/0x2f0
[ 2479.386700]I[0:launcher-loader: 1719]  bio_endio+0x2dc/0x300
[ 2479.386727]I[0:launcher-loader: 1719]  blk_update_request+0x258/0x63c
[ 2479.386754]I[0:launcher-loader: 1719]  scsi_end_request+0x50/0x304
[ 2479.386782]I[0:launcher-loader: 1719]  scsi_io_completion+0x88/0x160
[ 2479.386808]I[0:launcher-loader: 1719]  scsi_finish_command+0x17c/0x194
[ 2479.386833]I[0:launcher-loader: 1719]  scsi_complete+0xcc/0x158
[ 2479.386859]I[0:launcher-loader: 1719]  blk_mq_complete_request+0x4c/0x5c
[ 2479.386885]I[0:launcher-loader: 1719]  scsi_done_internal+0xf4/0x1e0
[ 2479.386910]I[0:launcher-loader: 1719]  scsi_done+0x14/0x20
[ 2479.386935]I[0:launcher-loader: 1719]  ufshcd_compl_one_cqe+0x578/0x71c
[ 2479.386963]I[0:launcher-loader: 1719]  ufshcd_mcq_poll_cqe_nolock+0xc8/0x150
[ 2479.386991]I[0:launcher-loader: 1719]  ufshcd_intr+0x868/0xc0c
[ 2479.387017]I[0:launcher-loader: 1719]  __handle_irq_event_percpu+0xd0/0x348
[ 2479.387044]I[0:launcher-loader: 1719]  handle_irq_event_percpu+0x24/0x74
[ 2479.387068]I[0:launcher-loader: 1719]  handle_irq_event+0x74/0xe0
[ 2479.387091]I[0:launcher-loader: 1719]  handle_fasteoi_irq+0x174/0x240
[ 2479.387118]I[0:launcher-loader: 1719]  handle_irq_desc+0x7c/0x2c0
[ 2479.387147]I[0:launcher-loader: 1719]  generic_handle_domain_irq+0x1c/0x28
[ 2479.387174]I[0:launcher-loader: 1719]  gic_handle_irq+0x64/0x158
[ 2479.387204]I[0:launcher-loader: 1719]  call_on_irq_stack+0x2c/0x54
[ 2479.387231]I[0:launcher-loader: 1719]  do_interrupt_handler+0x70/0xa0
[ 2479.387258]I[0:launcher-loader: 1719]  el1_interrupt+0x34/0x68
[ 2479.387283]I[0:launcher-loader: 1719]  el1h_64_irq_handler+0x18/0x24
[ 2479.387308]I[0:launcher-loader: 1719]  el1h_64_irq+0x68/0x6c
[ 2479.387332]I[0:launcher-loader: 1719]  blk_attempt_bio_merge+0x8/0x170
[ 2479.387356]I[0:launcher-loader: 1719]  blk_mq_attempt_bio_merge+0x78/0x98
[ 2479.387383]I[0:launcher-loader: 1719]  blk_mq_submit_bio+0x324/0xa40
[ 2479.387409]I[0:launcher-loader: 1719]  __submit_bio+0x104/0x138
[ 2479.387436]I[0:launcher-loader: 1719]  submit_bio_noacct_nocheck+0x1d0/0x4a0
[ 2479.387462]I[0:launcher-loader: 1719]  submit_bio_noacct+0x618/0x804
[ 2479.387487]I[0:launcher-loader: 1719]  submit_bio+0x164/0x180
[ 2479.387511]I[0:launcher-loader: 1719]  f2fs_submit_read_bio+0xe4/0x1c4
[ 2479.387537]I[0:launcher-loader: 1719]  f2fs_mpage_readpages+0x888/0xa4c
[ 2479.387563]I[0:launcher-loader: 1719]  f2fs_readahead+0xd4/0x19c
[ 2479.387587]I[0:launcher-loader: 1719]  read_pages+0xb0/0x4ac
[ 2479.387614]I[0:launcher-loader: 1719]  page_cache_ra_unbounded+0x238/0x288
[ 2479.387642]I[0:launcher-loader: 1719]  do_page_cache_ra+0x60/0x6c
[ 2479.387669]I[0:launcher-loader: 1719]  page_cache_ra_order+0x318/0x364
[ 2479.387695]I[0:launcher-loader: 1719]  ondemand_readahead+0x30c/0x3d8
[ 2479.387722]I[0:launcher-loader: 1719]  page_cache_sync_ra+0xb4/0xc8
[ 2479.387749]I[0:launcher-loader: 1719]  filemap_read+0x268/0xd24
[ 2479.387777]I[0:launcher-loader: 1719]  f2fs_file_read_iter+0x1a0/0x62c
[ 2479.387806]I[0:launcher-loader: 1719]  vfs_read+0x258/0x34c
[ 2479.387831]I[0:launcher-loader: 1719]  ksys_pread64+0x8c/0xd0
[ 2479.387857]I[0:launcher-loader: 1719]  __arm64_sys_pread64+0x48/0x54
[ 2479.387881]I[0:launcher-loader: 1719]  invoke_syscall+0x58/0x158
[ 2479.387909]I[0:launcher-loader: 1719]  el0_svc_common+0xf0/0x134
[ 2479.387935]I[0:launcher-loader: 1719]  do_el0_svc+0x44/0x114
[ 2479.387961]I[0:launcher-loader: 1719]  el0_svc+0x2c/0x80
[ 2479.387985]I[0:launcher-loader: 1719]  el0t_64_sync_handler+0x48/0x114
[ 2479.388010]I[0:launcher-loader: 1719]  el0t_64_sync+0x190/0x194
[ 2479.388038]I[0:launcher-loader: 1719] Kernel panic - not syncing: kernel: panic_on_warn set ...

So let's set __exception_irq_entry with __irq_entry as a default.
Applying this patch, we can see gic_hande_irq is included in Systemp.map as below.

* Before
ffffffc008010000 T __do_softirq
ffffffc008010000 T __irqentry_text_end
ffffffc008010000 T __irqentry_text_start
ffffffc008010000 T __softirqentry_text_start
ffffffc008010000 T _stext
ffffffc00801066c T __softirqentry_text_end
ffffffc008010670 T __entry_text_start

* After
ffffffc008010000 T __irqentry_text_start
ffffffc008010000 T _stext
ffffffc008010000 t gic_handle_irq
ffffffc00801013c t gic_handle_irq
ffffffc008010294 T __irqentry_text_end
ffffffc008010298 T __do_softirq
ffffffc008010298 T __softirqentry_text_start
ffffffc008010904 T __softirqentry_text_end
ffffffc008010908 T __entry_text_start

Change-Id: Ia0d35e33dbaabc9cb960a83fe4ea996132b6cff5
Signed-off-by: Youngmin Nam <youngmin.nam@samsung.com>
Signed-off-by: SEO HOYOUNG <hy50.seo@samsung.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20230424010436.779733-1-youngmin.nam@samsung.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Bug: 278156426
(cherry picked from commit f6794950f0
 git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
 for-next/misc)
 2023-06-16 07:45:43 +00:00
fengqi
d73b3af21f ANDROID: GKI: update symbol list file for xiaomi 
INFO: ABI DIFFERENCES HAVE BEEN DETECTED!
INFO: 8 function symbol(s) added
  'int tty_hung_up_p(struct file*)'
  'const char* tty_name(const struct tty_struct*)'
  'int tty_port_block_til_ready(struct tty_port*, struct tty_struct*, struct file*)'
  'void tty_port_close_end(struct tty_port*, struct tty_struct*)'
  'int tty_port_close_start(struct tty_port*, struct tty_struct*, struct file*)'
  'void tty_port_lower_dtr_rts(struct tty_port*)'
  'void tty_port_tty_set(struct tty_port*, struct tty_struct*)'
  'struct device* tty_register_device(struct tty_driver*, unsigned int, struct device*)'

Bug: 287182607

Change-Id: If8d7ee235d398c05c35fef05221618ddc49a87fe
Signed-off-by: fengqi <fengqi@xiaomi.com>
 2023-06-15 14:00:39 +00:00
Matthias Maennich
73185e2d4e ANDROID: Remove all but top-level OWNERS 
Now that the branch is used to create production GKI
images, need to institute ACK DrNo for all commits.

The DrNo approvers are in the android-mainline branch
at /OWNERS_DrNo.

Bug: 287162457
Signed-off-by: Matthias Maennich <maennich@google.com>
Change-Id: Id5bb83d7add5f314df6816c1c51b4bf2d8018e79
 2023-06-15 09:54:33 +01:00
Matthias Maennich
1090306d3d ANDROID: Enable GKI Dr. No Enforcement 
This locks down OWNERS approval to a small group to guard against
unintentional breakages.

Bug: 287162457
Signed-off-by: Matthias Maennich <maennich@google.com>
Change-Id: I58ca467b1e7786e1ad0f6ad67c7a7a5845a91ec6
 2023-06-15 09:54:33 +01:00
Carlos Llamas
16c18c497d ANDROID: 6/16/2023 KMI update 
Set KMI_GENERATION=10 for 6/16 KMI update

function symbol changed from 'int devm_gh_rm_register_platform_ops(struct device*, struct gh_rm_platform_ops*)' to 'int devm_gh_rm_register_platform_ops(struct device*, const struct gh_rm_platform_ops*)'
  CRC changed from 0xec193d82 to 0xe82ea1f9
  type changed from 'int(struct device*, struct gh_rm_platform_ops*)' to 'int(struct device*, const struct gh_rm_platform_ops*)'
    parameter 2 type changed from 'struct gh_rm_platform_ops*' to 'const struct gh_rm_platform_ops*'
      pointed-to type changed from 'struct gh_rm_platform_ops' to 'const struct gh_rm_platform_ops'
        qualifier const added

function symbol changed from 'int gh_rm_register_platform_ops(struct gh_rm_platform_ops*)' to 'int gh_rm_register_platform_ops(const struct gh_rm_platform_ops*)'
  CRC changed from 0xc34a7803 to 0xfd11885c
  type changed from 'int(struct gh_rm_platform_ops*)' to 'int(const struct gh_rm_platform_ops*)'
    parameter 1 type changed from 'struct gh_rm_platform_ops*' to 'const struct gh_rm_platform_ops*'
      pointed-to type changed from 'struct gh_rm_platform_ops' to 'const struct gh_rm_platform_ops'
        qualifier const added

function symbol changed from 'void gh_rm_unregister_platform_ops(struct gh_rm_platform_ops*)' to 'void gh_rm_unregister_platform_ops(const struct gh_rm_platform_ops*)'
  CRC changed from 0xc1f09d18 to 0x57f483b
  type changed from 'void(struct gh_rm_platform_ops*)' to 'void(const struct gh_rm_platform_ops*)'
    parameter 1 type changed from 'struct gh_rm_platform_ops*' to 'const struct gh_rm_platform_ops*'
      pointed-to type changed from 'struct gh_rm_platform_ops' to 'const struct gh_rm_platform_ops'
        qualifier const added

function symbol 'int ___pskb_trim(struct sk_buff*, unsigned int)' changed
  CRC changed from 0xb8fdf4c6 to 0x45b20f13

function symbol 'struct sk_buff* __alloc_skb(unsigned int, gfp_t, int, int)' changed
  CRC changed from 0x34355489 to 0x19dd35ba

function symbol 'void __balance_callbacks(struct rq*)' changed
  CRC changed from 0x76a1a2f4 to 0x2af1f39a

... 886 omitted; 889 symbols have only CRC changes

type 'struct hci_dev' changed
  byte size changed from 6416 to 6464
  member 'struct mutex unregister_lock' was added
  106 members ('struct work_struct cmd_sync_cancel_work' .. 'u64 android_kabi_reserved4') changed
    offset changed by 384

type 'struct sock' changed
  member 'int sk_wait_pending' was added

type 'struct xhci_driver_overrides' changed
  byte size changed from 64 to 120
  member 'int(* address_device)(struct usb_hcd*, struct usb_device*)' was added
  member 'int(* bus_suspend)(struct usb_hcd*)' was added
  member 'int(* bus_resume)(struct usb_hcd*)' was added
  member 'u64 android_kabi_reserved1' was added
  member 'u64 android_kabi_reserved2' was added
  member 'u64 android_kabi_reserved3' was added
  member 'u64 android_kabi_reserved4' was added

type 'struct pneigh_entry' changed
  member changed from 'u8 key[0]' to 'u32 key[0]'
    offset changed from 232 to 256
    type changed from 'u8[0]' to 'u32[0]'
      element type changed from 'u8' = '__u8' = 'unsigned char' to 'u32' = '__u32' = 'unsigned int'
        resolved type changed from 'unsigned char' to 'unsigned int'

type 'struct usb_udc' changed
  byte size changed from 952 to 1048
  member 'bool allow_connect' was added
  member 'struct work_struct vbus_work' was added
  member 'struct mutex connect_lock' was added

type 'struct sk_psock' changed
  byte size changed from 392 to 472
  member changed from 'struct work_struct work' to 'struct delayed_work work'
    offset changed from 2176 to 2112
    type changed from 'struct work_struct' to 'struct delayed_work'
  member 'struct rcu_work rwork' changed
    offset changed by 640

type 'struct netns_sysctl_ipv6' changed
  member changed from 'bool skip_notify_on_dev_down' to 'int skip_notify_on_dev_down'
    type changed from 'bool' = '_Bool' to 'int'
      resolved type changed from '_Bool' to 'int'
  member 'u8 fib_notify_on_flag_change' changed
    offset changed by 24

type 'struct sk_psock_work_state' changed
  byte size changed from 16 to 8
  member 'struct sk_buff* skb' was removed
  2 members ('u32 len' .. 'u32 off') changed
    offset changed by -64

Bug: 287162457
Change-Id: I438a8aa2c6a38dd5d575493b2735fe4d4403a971
Signed-off-by: Carlos Llamas <cmllamas@google.com>
 2023-06-14 23:24:57 +00:00
Elliot Berman
fcc32be061 ANDROID: virt: gunyah: Sync with latest platform ops 
Const-ify the gh_rm_platform_ops.

Syncs with the latest version of the platform ops:

https://lore.kernel.org/all/20230613172054.3959700-15-quic_eberman@quicinc.com/

INFO: function symbol changed from 'int devm_gh_rm_register_platform_ops(struct device*, struct gh_rm_platform_ops*)' to 'int devm_gh_rm_register_platform_ops(struct device*, const struct gh_rm_platform_ops*)'
  CRC changed from 0xc4b20ef4 to 0x7fe0042f
  type changed from 'int(struct device*, struct gh_rm_platform_ops*)' to 'int(struct device*, const struct gh_rm_platform_ops*)'
    parameter 2 type changed from 'struct gh_rm_platform_ops*' to 'const struct gh_rm_platform_ops*'
      pointed-to type changed from 'struct gh_rm_platform_ops' to 'const struct gh_rm_platform_ops'
        qualifier const added

function symbol changed from 'int gh_rm_register_platform_ops(struct gh_rm_platform_ops*)' to 'int gh_rm_register_platform_ops(const struct gh_rm_platform_ops*)'
  CRC changed from 0xc34a7803 to 0xfd11885c
  type changed from 'int(struct gh_rm_platform_ops*)' to 'int(const struct gh_rm_platform_ops*)'
    parameter 1 type changed from 'struct gh_rm_platform_ops*' to 'const struct gh_rm_platform_ops*'
      pointed-to type changed from 'struct gh_rm_platform_ops' to 'const struct gh_rm_platform_ops'
        qualifier const added

function symbol changed from 'void gh_rm_unregister_platform_ops(struct gh_rm_platform_ops*)' to 'void gh_rm_unregister_platform_ops(const struct gh_rm_platform_ops*)'
  CRC changed from 0xc1f09d18 to 0x57f483b
  type changed from 'void(struct gh_rm_platform_ops*)' to 'void(const struct gh_rm_platform_ops*)'
    parameter 1 type changed from 'struct gh_rm_platform_ops*' to 'const struct gh_rm_platform_ops*'
      pointed-to type changed from 'struct gh_rm_platform_ops' to 'const struct gh_rm_platform_ops'
        qualifier const added

Bug: 287037804
Change-Id: Iff37610b721c344ac8c6b1737830f6d1e8674d34
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
 2023-06-14 23:05:19 +00:00
Badhri Jagan Sridharan
69a3ec73e4 FROMGIT: usb: gadget: udc: core: Prevent soft_connect_store() race 
usb_udc_connect_control(), soft_connect_store() and
usb_gadget_deactivate() can potentially race against each other to invoke
usb_gadget_connect()/usb_gadget_disconnect(). To prevent this, guard
udc->started, gadget->allow_connect, gadget->deactivate and
gadget->connect with connect_lock so that ->pullup() is only invoked when
the gadget is bound, started and not deactivated. The routines
usb_gadget_connect_locked(), usb_gadget_disconnect_locked(),
usb_udc_connect_control_locked(), usb_gadget_udc_start_locked(),
usb_gadget_udc_stop_locked() are called with this lock held.

An earlier version of this commit was reverted due to the crash reported in
https://lore.kernel.org/all/ZF4BvgsOyoKxdPFF@francesco-nb.int.toradex.com/.
commit 16737e78d190 ("usb: gadget: udc: core: Offload usb_udc_vbus_handler processing")
addresses the crash reported.

Cc: stable@vger.kernel.org
Fixes: 628ef0d273 ("usb: udc: add usb_udc_vbus_handler")
Change-Id: I33b56f9eee28059a7e113d6c8081ab6653a03c33
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Message-ID: <20230609010227.978661-2-badhri@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 286d9975a8
https: //git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ usb-linus)
 2023-06-14 23:03:53 +00:00
Badhri Jagan Sridharan
18b677ffae FROMGIT: usb: gadget: udc: core: Offload usb_udc_vbus_handler processing 
usb_udc_vbus_handler() can be invoked from interrupt context by irq
handlers of the gadget drivers, however, usb_udc_connect_control() has
to run in non-atomic context due to the following:
a. Some of the gadget driver implementations expect the ->pullup
   callback to be invoked in non-atomic context.
b. usb_gadget_disconnect() acquires udc_lock which is a mutex.

Hence offload invocation of usb_udc_connect_control()
to workqueue.

UDC should not be pulled up unless gadget driver is bound. The new flag
"allow_connect" is now set by gadget_bind_driver() and cleared by
gadget_unbind_driver(). This prevents work item to pull up the gadget
even if queued when the gadget driver is already unbound.

Cc: stable@vger.kernel.org
Fixes: 1016fc0c09 ("USB: gadget: Fix obscure lockdep violation for udc_mutex")
Change-Id: Idbe00846fc5394397567024c3081381ddec7cfae
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Message-ID: <20230609010227.978661-1-badhri@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 50966da807
https: //git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ usb-linus)
 2023-06-14 23:03:53 +00:00
Johan Hovold
a1741f9c45 UPSTREAM: Bluetooth: fix debugfs registration 
commit fe2ccc6c29 upstream.

Since commit ec6cef9cd9 ("Bluetooth: Fix SMP channel registration for
unconfigured controllers") the debugfs interface for unconfigured
controllers will be created when the controller is configured.

There is however currently nothing preventing a controller from being
configured multiple time (e.g. setting the device address using btmgmt)
which results in failed attempts to register the already registered
debugfs entries:

	debugfs: File 'features' in directory 'hci0' already present!
	debugfs: File 'manufacturer' in directory 'hci0' already present!
	debugfs: File 'hci_version' in directory 'hci0' already present!
	...
	debugfs: File 'quirk_simultaneous_discovery' in directory 'hci0' already present!

Add a controller flag to avoid trying to register the debugfs interface
more than once.

Fixes: ec6cef9cd9 ("Bluetooth: Fix SMP channel registration for unconfigured controllers")
Cc: stable@vger.kernel.org      # 4.0
Change-Id: I495feabe66fa2b294ff72fbb5dfd1bd869b1ad83
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit e5ae01fd46)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
 2023-06-14 23:02:42 +00:00
Zhengping Jiang
d890debdaf UPSTREAM: Bluetooth: hci_sync: add lock to protect HCI_UNREGISTER 
[ Upstream commit 1857c19941 ]

When the HCI_UNREGISTER flag is set, no jobs should be scheduled. Fix
potential race when HCI_UNREGISTER is set after the flag is tested in
hci_cmd_sync_queue.

Fixes: 0b94f2651f ("Bluetooth: hci_sync: Fix queuing commands when HCI_UNREGISTER is set")
Change-Id: I565a2ad87dc2ce4fd62ee0d09a5d28342fec8ad3
Signed-off-by: Zhengping Jiang <jiangzp@google.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 17aac12002)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
 2023-06-14 23:02:42 +00:00
Eric Dumazet
855c5479cb UPSTREAM: net/ipv6: fix bool/int mismatch for skip_notify_on_dev_down 
[ Upstream commit edf2e1d201 ]

skip_notify_on_dev_down ctl table expects this field
to be an int (4 bytes), not a bool (1 byte).

Because proc_dou8vec_minmax() was added in 5.13,
this patch converts skip_notify_on_dev_down to an int.

Following patch then converts the field to u8 and use proc_dou8vec_minmax().

Fixes: 7c6bb7d2fa ("net/ipv6: Add knob to skip DELROUTE message on device down")
Change-Id: I99875fad5012906099456fafa88e42e7f02133cf
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Acked-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 76e38e6e1b)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
 2023-06-14 23:02:42 +00:00
Qingfang DENG
b0fa6dd29a UPSTREAM: neighbour: fix unaligned access to pneigh_entry 
[ Upstream commit ed779fe4c9 ]

After the blamed commit, the member key is longer 4-byte aligned. On
platforms that do not support unaligned access, e.g., MIPS32R2 with
unaligned_action set to 1, this will trigger a crash when accessing
an IPv6 pneigh_entry, as the key is cast to an in6_addr pointer.

Change the type of the key to u32 to make it aligned.

Fixes: 62dd93181a ("[IPV6] NDISC: Set per-entry is_router flag in Proxy NA.")
Change-Id: I3ac6eaf9afe9210cc4d9ef2dc6181fcb0fba6d15
Signed-off-by: Qingfang DENG <qingfang.deng@siflower.com.cn>
Link: https://lore.kernel.org/r/20230601015432.159066-1-dqfext@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 8af3119388)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
 2023-06-14 23:02:42 +00:00
Eric Dumazet
1707d64dab UPSTREAM: tcp: deny tcp_disconnect() when threads are waiting 
[ Upstream commit 4faeee0cf8 ]

Historically connect(AF_UNSPEC) has been abused by syzkaller
and other fuzzers to trigger various bugs.

A recent one triggers a divide-by-zero [1], and Paolo Abeni
was able to diagnose the issue.

tcp_recvmsg_locked() has tests about sk_state being not TCP_LISTEN
and TCP REPAIR mode being not used.

Then later if socket lock is released in sk_wait_data(),
another thread can call connect(AF_UNSPEC), then make this
socket a TCP listener.

When recvmsg() is resumed, it can eventually call tcp_cleanup_rbuf()
and attempt a divide by 0 in tcp_rcv_space_adjust() [1]

This patch adds a new socket field, counting number of threads
blocked in sk_wait_event() and inet_wait_for_connect().

If this counter is not zero, tcp_disconnect() returns an error.

This patch adds code in blocking socket system calls, thus should
not hurt performance of non blocking ones.

Note that we probably could revert commit 499350a5a6 ("tcp:
initialize rcv_mss to TCP_MIN_MSS instead of 0") to restore
original tcpi_rcv_mss meaning (was 0 if no payload was ever
received on a socket)

[1]
divide error: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 13832 Comm: syz-executor.5 Not tainted 6.3.0-rc4-syzkaller-00224-g00c7b5f4ddc5 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023
RIP: 0010:tcp_rcv_space_adjust+0x36e/0x9d0 net/ipv4/tcp_input.c:740
Code: 00 00 00 00 fc ff df 4c 89 64 24 48 8b 44 24 04 44 89 f9 41 81 c7 80 03 00 00 c1 e1 04 44 29 f0 48 63 c9 48 01 e9 48 0f af c1 <49> f7 f6 48 8d 04 41 48 89 44 24 40 48 8b 44 24 30 48 c1 e8 03 48
RSP: 0018:ffffc900033af660 EFLAGS: 00010206
RAX: 4a66b76cbade2c48 RBX: ffff888076640cc0 RCX: 00000000c334e4ac
RDX: 0000000000000000 RSI: dffffc0000000000 RDI: 0000000000000001
RBP: 00000000c324e86c R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8880766417f8
R13: ffff888028fbb980 R14: 0000000000000000 R15: 0000000000010344
FS: 00007f5bffbfe700(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b32f25000 CR3: 000000007ced0000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
tcp_recvmsg_locked+0x100e/0x22e0 net/ipv4/tcp.c:2616
tcp_recvmsg+0x117/0x620 net/ipv4/tcp.c:2681
inet6_recvmsg+0x114/0x640 net/ipv6/af_inet6.c:670
sock_recvmsg_nosec net/socket.c:1017 [inline]
sock_recvmsg+0xe2/0x160 net/socket.c:1038
____sys_recvmsg+0x210/0x5a0 net/socket.c:2720
___sys_recvmsg+0xf2/0x180 net/socket.c:2762
do_recvmmsg+0x25e/0x6e0 net/socket.c:2856
__sys_recvmmsg net/socket.c:2935 [inline]
__do_sys_recvmmsg net/socket.c:2958 [inline]
__se_sys_recvmmsg net/socket.c:2951 [inline]
__x64_sys_recvmmsg+0x20f/0x260 net/socket.c:2951
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f5c0108c0f9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f5bffbfe168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b
RAX: ffffffffffffffda RBX: 00007f5c011ac050 RCX: 00007f5c0108c0f9
RDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000003
RBP: 00007f5c010e7b39 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f5c012cfb1f R14: 00007f5bffbfe300 R15: 0000000000022000
</TASK>

Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Reported-by: syzbot <syzkaller@googlegroups.com>
Reported-by: Paolo Abeni <pabeni@redhat.com>
Diagnosed-by: Paolo Abeni <pabeni@redhat.com>
Change-Id: I63f5375d7dd7d2094b30d00c48d48bb500d54e2e
Signed-off-by: Eric Dumazet <edumazet@google.com>
Tested-by: Paolo Abeni <pabeni@redhat.com>
Link: https://lore.kernel.org/r/20230526163458.2880232-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit c2251ce048)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
 2023-06-14 23:02:42 +00:00
JaeHun Jung
a7cd7a3dd7 ANDROID: sound: usb: Add vendor's hooking interface 
In mobile, a co-processor can be used with USB audio to improve power
consumption.  To support this type of hardware, hooks need to be added
to the USB audio subsystem to be able to call into the hardware when
needed.

This interface can be support multiful USB audio devices.
It is depends on co-processor's F/W.

The main operation of the call-backs are:
- Initialize the co-processor by transmitting data when initializing.
- Change the co-processor setting value through the interface
function.
- Configure sampling rate
- pcm open/close
- other housekeeping

Bug: 156315379
Signed-off-by: Oh Eomji <eomji.oh@samsung.com>
Signed-off-by: JaeHun Jung <jh0801.jung@samsung.com>
[rework api to be a bit more self-contained and obvious - gregkh]
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I39061f6cc85be7bcae8db0e612fe58396bdedb24
 2023-06-14 23:02:42 +00:00
Greg Kroah-Hartman
2c6f80378c ANDROID: GKI: USB: XHCI: add Android ABI padding to struct xhci_driver_overrides 
Given that the vendors like to hook the xhci platform driver to handle
offload functionality that is not yet upstream, add some more padding to
struct xhci_driver_overrides in order to be able to handle any future
problems easier.

Bug: 151154716
Bug: 182336717
Cc: Daehwan Jung <dh10.jung@samsung.com>
Cc: JaeHun Jung <jh0801.jung@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Iaa59f63b0777c7671292bd0839a6eb8f57bc7a59
 2023-06-14 23:02:41 +00:00
Daehwan Jung
cd3b5ff535 ANDROID: usb: host: add address_device to xhci overrides 
Co-processor needs some information about connected usb device.
It's proper to pass information after usb device gets address when
getting "Set Address" command.
It supports vendors to implement it using xhci overrides.

There're several power scenarios depending on vendors.
It gives vendors flexibilty to meet their power requirement.
They can override suspend and resume of root hub.

Bug: 183761108
Change-Id: I51e4d190a6a110f987139d394621590fa40ea6a6
Signed-off-by: Daehwan Jung <dh10.jung@samsung.com>
Signed-off-by: JaeHun Jung <jh0801.jung@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
 2023-06-14 23:02:41 +00:00
Eric Dumazet
e3ff5d6bf0 UPSTREAM: bpf, sockmap: Avoid potential NULL dereference in sk_psock_verdict_data_ready() 
[ Upstream commit b320a45638 ]

syzbot found sk_psock(sk) could return NULL when called
from sk_psock_verdict_data_ready().

Just make sure to handle this case.

[1]
general protection fault, probably for non-canonical address 0xdffffc000000005c: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x00000000000002e0-0x00000000000002e7]
CPU: 0 PID: 15 Comm: ksoftirqd/0 Not tainted 6.4.0-rc3-syzkaller-00588-g4781e965e655 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/16/2023
RIP: 0010:sk_psock_verdict_data_ready+0x19f/0x3c0 net/core/skmsg.c:1213
Code: 4c 89 e6 e8 63 70 5e f9 4d 85 e4 75 75 e8 19 74 5e f9 48 8d bb e0 02 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 07 02 00 00 48 89 ef ff 93 e0 02 00 00 e8 29 fd
RSP: 0018:ffffc90000147688 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000100
RDX: 000000000000005c RSI: ffffffff8825ceb7 RDI: 00000000000002e0
RBP: ffff888076518c40 R08: 0000000000000007 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000008000 R15: ffff888076518c40
FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f901375bab0 CR3: 000000004bf26000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
tcp_data_ready+0x10a/0x520 net/ipv4/tcp_input.c:5006
tcp_data_queue+0x25d3/0x4c50 net/ipv4/tcp_input.c:5080
tcp_rcv_established+0x829/0x1f90 net/ipv4/tcp_input.c:6019
tcp_v4_do_rcv+0x65a/0x9c0 net/ipv4/tcp_ipv4.c:1726
tcp_v4_rcv+0x2cbf/0x3340 net/ipv4/tcp_ipv4.c:2148
ip_protocol_deliver_rcu+0x9f/0x480 net/ipv4/ip_input.c:205
ip_local_deliver_finish+0x2ec/0x520 net/ipv4/ip_input.c:233
NF_HOOK include/linux/netfilter.h:303 [inline]
NF_HOOK include/linux/netfilter.h:297 [inline]
ip_local_deliver+0x1ae/0x200 net/ipv4/ip_input.c:254
dst_input include/net/dst.h:468 [inline]
ip_rcv_finish+0x1cf/0x2f0 net/ipv4/ip_input.c:449
NF_HOOK include/linux/netfilter.h:303 [inline]
NF_HOOK include/linux/netfilter.h:297 [inline]
ip_rcv+0xae/0xd0 net/ipv4/ip_input.c:569
__netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5491
__netif_receive_skb+0x1f/0x1c0 net/core/dev.c:5605
process_backlog+0x101/0x670 net/core/dev.c:5933
__napi_poll+0xb7/0x6f0 net/core/dev.c:6499
napi_poll net/core/dev.c:6566 [inline]
net_rx_action+0x8a9/0xcb0 net/core/dev.c:6699
__do_softirq+0x1d4/0x905 kernel/softirq.c:571
run_ksoftirqd kernel/softirq.c:939 [inline]
run_ksoftirqd+0x31/0x60 kernel/softirq.c:931
smpboot_thread_fn+0x659/0x9e0 kernel/smpboot.c:164
kthread+0x344/0x440 kernel/kthread.c:379
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
</TASK>

Fixes: 6df7f764cd ("bpf, sockmap: Wake up polling after data copy")
Reported-by: syzbot <syzkaller@googlegroups.com>
Change-Id: I7c0f888b35987f8019088e9232fbe0f0491f661b
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: John Fastabend <john.fastabend@gmail.com>
Link: https://lore.kernel.org/bpf/20230530195149.68145-1-edumazet@google.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 898c9a0ee7)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
 2023-06-14 23:02:41 +00:00
John Fastabend
07873e75c6 UPSTREAM: bpf, sockmap: Incorrectly handling copied_seq 
[ Upstream commit e5c6de5fa0 ]

The read_skb() logic is incrementing the tcp->copied_seq which is used for
among other things calculating how many outstanding bytes can be read by
the application. This results in application errors, if the application
does an ioctl(FIONREAD) we return zero because this is calculated from
the copied_seq value.

To fix this we move tcp->copied_seq accounting into the recv handler so
that we update these when the recvmsg() hook is called and data is in
fact copied into user buffers. This gives an accurate FIONREAD value
as expected and improves ACK handling. Before we were calling the
tcp_rcv_space_adjust() which would update 'number of bytes copied to
user in last RTT' which is wrong for programs returning SK_PASS. The
bytes are only copied to the user when recvmsg is handled.

Doing the fix for recvmsg is straightforward, but fixing redirect and
SK_DROP pkts is a bit tricker. Build a tcp_psock_eat() helper and then
call this from skmsg handlers. This fixes another issue where a broken
socket with a BPF program doing a resubmit could hang the receiver. This
happened because although read_skb() consumed the skb through sock_drop()
it did not update the copied_seq. Now if a single reccv socket is
redirecting to many sockets (for example for lb) the receiver sk will be
hung even though we might expect it to continue. The hang comes from
not updating the copied_seq numbers and memory pressure resulting from
that.

We have a slight layer problem of calling tcp_eat_skb even if its not
a TCP socket. To fix we could refactor and create per type receiver
handlers. I decided this is more work than we want in the fix and we
already have some small tweaks depending on caller that use the
helper skb_bpf_strparser(). So we extend that a bit and always set
the strparser bit when it is in use and then we can gate the
seq_copied updates on this.

Fixes: 04919bed94 ("tcp: Introduce tcp_read_skb()")
Change-Id: I8dc204d02e26975f8133d7e4d777b2194e30a6aa
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
Link: https://lore.kernel.org/bpf/20230523025618.113937-9-john.fastabend@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit fe735073a5)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
 2023-06-14 23:02:41 +00:00
John Fastabend
e218734b1b UPSTREAM: bpf, sockmap: Wake up polling after data copy 
[ Upstream commit 6df7f764cd ]

When TCP stack has data ready to read sk_data_ready() is called. Sockmap
overwrites this with its own handler to call into BPF verdict program.
But, the original TCP socket had sock_def_readable that would additionally
wake up any user space waiters with sk_wake_async().

Sockmap saved the callback when the socket was created so call the saved
data ready callback and then we can wake up any epoll() logic waiting
on the read.

Note we call on 'copied >= 0' to account for returning 0 when a FIN is
received because we need to wake up user for this as well so they
can do the recvmsg() -> 0 and detect the shutdown.

Fixes: 04919bed94 ("tcp: Introduce tcp_read_skb()")
Change-Id: Idf56c7acfeb25791dc6e5f42dce2e64b09d55cf9
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
Link: https://lore.kernel.org/bpf/20230523025618.113937-8-john.fastabend@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit dd628fc697)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
 2023-06-14 23:02:41 +00:00
John Fastabend
f9cc0b7f9b UPSTREAM: bpf, sockmap: TCP data stall on recv before accept 
[ Upstream commit ea444185a6 ]

A common mechanism to put a TCP socket into the sockmap is to hook the
BPF_SOCK_OPS_{ACTIVE_PASSIVE}_ESTABLISHED_CB event with a BPF program
that can map the socket info to the correct BPF verdict parser. When
the user adds the socket to the map the psock is created and the new
ops are assigned to ensure the verdict program will 'see' the sk_buffs
as they arrive.

Part of this process hooks the sk_data_ready op with a BPF specific
handler to wake up the BPF verdict program when data is ready to read.
The logic is simple enough (posted here for easy reading)

 static void sk_psock_verdict_data_ready(struct sock *sk)
 {
	struct socket *sock = sk->sk_socket;

	if (unlikely(!sock || !sock->ops || !sock->ops->read_skb))
		return;
	sock->ops->read_skb(sk, sk_psock_verdict_recv);
 }

The oversight here is sk->sk_socket is not assigned until the application
accepts() the new socket. However, its entirely ok for the peer application
to do a connect() followed immediately by sends. The socket on the receiver
is sitting on the backlog queue of the listening socket until its accepted
and the data is queued up. If the peer never accepts the socket or is slow
it will eventually hit data limits and rate limit the session. But,
important for BPF sockmap hooks when this data is received TCP stack does
the sk_data_ready() call but the read_skb() for this data is never called
because sk_socket is missing. The data sits on the sk_receive_queue.

Then once the socket is accepted if we never receive more data from the
peer there will be no further sk_data_ready calls and all the data
is still on the sk_receive_queue(). Then user calls recvmsg after accept()
and for TCP sockets in sockmap we use the tcp_bpf_recvmsg_parser() handler.
The handler checks for data in the sk_msg ingress queue expecting that
the BPF program has already run from the sk_data_ready hook and enqueued
the data as needed. So we are stuck.

To fix do an unlikely check in recvmsg handler for data on the
sk_receive_queue and if it exists wake up data_ready. We have the sock
locked in both read_skb and recvmsg so should avoid having multiple
runners.

Fixes: 04919bed94 ("tcp: Introduce tcp_read_skb()")
Change-Id: I82bc3eafce486a816cf8dfada1939128922ae174
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
Link: https://lore.kernel.org/bpf/20230523025618.113937-7-john.fastabend@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit ab90b68f65)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
 2023-06-14 23:02:41 +00:00
John Fastabend
028591f2c8 UPSTREAM: bpf, sockmap: Handle fin correctly 
[ Upstream commit 901546fd8f ]

The sockmap code is returning EAGAIN after a FIN packet is received and no
more data is on the receive queue. Correct behavior is to return 0 to the
user and the user can then close the socket. The EAGAIN causes many apps
to retry which masks the problem. Eventually the socket is evicted from
the sockmap because its released from sockmap sock free handling. The
issue creates a delay and can cause some errors on application side.

To fix this check on sk_msg_recvmsg side if length is zero and FIN flag
is set then set return to zero. A selftest will be added to check this
condition.

Fixes: 04919bed94 ("tcp: Introduce tcp_read_skb()")
Change-Id: I26d941790b9742534370c0447fd4a92cab55c32e
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Tested-by: William Findlay <will@isovalent.com>
Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
Link: https://lore.kernel.org/bpf/20230523025618.113937-6-john.fastabend@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 3a2129ebae)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
 2023-06-14 23:02:41 +00:00
John Fastabend
e69ad7c838 UPSTREAM: bpf, sockmap: Improved check for empty queue 
[ Upstream commit 405df89dd5 ]

We noticed some rare sk_buffs were stepping past the queue when system was
under memory pressure. The general theory is to skip enqueueing
sk_buffs when its not necessary which is the normal case with a system
that is properly provisioned for the task, no memory pressure and enough
cpu assigned.

But, if we can't allocate memory due to an ENOMEM error when enqueueing
the sk_buff into the sockmap receive queue we push it onto a delayed
workqueue to retry later. When a new sk_buff is received we then check
if that queue is empty. However, there is a problem with simply checking
the queue length. When a sk_buff is being processed from the ingress queue
but not yet on the sockmap msg receive queue its possible to also recv
a sk_buff through normal path. It will check the ingress queue which is
zero and then skip ahead of the pkt being processed.

Previously we used sock lock from both contexts which made the problem
harder to hit, but not impossible.

To fix instead of popping the skb from the queue entirely we peek the
skb from the queue and do the copy there. This ensures checks to the
queue length are non-zero while skb is being processed. Then finally
when the entire skb has been copied to user space queue or another
socket we pop it off the queue. This way the queue length check allows
bypassing the queue only after the list has been completely processed.

To reproduce issue we run NGINX compliance test with sockmap running and
observe some flakes in our testing that we attributed to this issue.

Fixes: 04919bed94 ("tcp: Introduce tcp_read_skb()")
Suggested-by: Jakub Sitnicki <jakub@cloudflare.com>
Change-Id: I076ae2689caf17afbae7d4093139407d60cf4d0d
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Tested-by: William Findlay <will@isovalent.com>
Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
Link: https://lore.kernel.org/bpf/20230523025618.113937-5-john.fastabend@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit ba4fec5bd6)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
 2023-06-14 23:02:40 +00:00
John Fastabend
ecfcbe21d7 UPSTREAM: bpf, sockmap: Reschedule is now done through backlog 
[ Upstream commit bce22552f9 ]

Now that the backlog manages the reschedule() logic correctly we can drop
the partial fix to reschedule from recvmsg hook.

Rescheduling on recvmsg hook was added to address a corner case where we
still had data in the backlog state but had nothing to kick it and
reschedule the backlog worker to run and finish copying data out of the
state. This had a couple limitations, first it required user space to
kick it introducing an unnecessary EBUSY and retry. Second it only
handled the ingress case and egress redirects would still be hung.

With the correct fix, pushing the reschedule logic down to where the
enomem error occurs we can drop this fix.

Fixes: bec217197b ("skmsg: Schedule psock work if the cached skb exists on the psock")
Change-Id: Ibf8b70dbeca5122c2ef954504dbe44724456899e
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
Link: https://lore.kernel.org/bpf/20230523025618.113937-4-john.fastabend@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 1e4e379ccd)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
 2023-06-14 23:02:40 +00:00
John Fastabend
42fcf3b6df UPSTREAM: bpf, sockmap: Convert schedule_work into delayed_work 
[ Upstream commit 29173d07f7 ]

Sk_buffs are fed into sockmap verdict programs either from a strparser
(when the user might want to decide how framing of skb is done by attaching
another parser program) or directly through tcp_read_sock. The
tcp_read_sock is the preferred method for performance when the BPF logic is
a stream parser.

The flow for Cilium's common use case with a stream parser is,

 tcp_read_sock()
  sk_psock_verdict_recv
    ret = bpf_prog_run_pin_on_cpu()
    sk_psock_verdict_apply(sock, skb, ret)
     // if system is under memory pressure or app is slow we may
     // need to queue skb. Do this queuing through ingress_skb and
     // then kick timer to wake up handler
     skb_queue_tail(ingress_skb, skb)
     schedule_work(work);

The work queue is wired up to sk_psock_backlog(). This will then walk the
ingress_skb skb list that holds our sk_buffs that could not be handled,
but should be OK to run at some later point. However, its possible that
the workqueue doing this work still hits an error when sending the skb.
When this happens the skbuff is requeued on a temporary 'state' struct
kept with the workqueue. This is necessary because its possible to
partially send an skbuff before hitting an error and we need to know how
and where to restart when the workqueue runs next.

Now for the trouble, we don't rekick the workqueue. This can cause a
stall where the skbuff we just cached on the state variable might never
be sent. This happens when its the last packet in a flow and no further
packets come along that would cause the system to kick the workqueue from
that side.

To fix we could do simple schedule_work(), but while under memory pressure
it makes sense to back off some instead of continue to retry repeatedly. So
instead to fix convert schedule_work to schedule_delayed_work and add
backoff logic to reschedule from backlog queue on errors. Its not obvious
though what a good backoff is so use '1'.

To test we observed some flakes whil running NGINX compliance test with
sockmap we attributed these failed test to this bug and subsequent issue.

>From on list discussion. This commit

 bec217197b41("skmsg: Schedule psock work if the cached skb exists on the psock")

was intended to address similar race, but had a couple cases it missed.
Most obvious it only accounted for receiving traffic on the local socket
so if redirecting into another socket we could still get an sk_buff stuck
here. Next it missed the case where copied=0 in the recv() handler and
then we wouldn't kick the scheduler. Also its sub-optimal to require
userspace to kick the internal mechanisms of sockmap to wake it up and
copy data to user. It results in an extra syscall and requires the app
to actual handle the EAGAIN correctly.

Fixes: 04919bed94 ("tcp: Introduce tcp_read_skb()")
Change-Id: I61dbe914b0abf5f0f7e16f95d246c8e4fa0f5afa
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Tested-by: William Findlay <will@isovalent.com>
Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
Link: https://lore.kernel.org/bpf/20230523025618.113937-3-john.fastabend@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 9f4d7efb33)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
 2023-06-14 23:02:40 +00:00
John Fastabend
a59051006b UPSTREAM: bpf, sockmap: Pass skb ownership through read_skb 
[ Upstream commit 78fa0d61d9 ]

The read_skb hook calls consume_skb() now, but this means that if the
recv_actor program wants to use the skb it needs to inc the ref cnt
so that the consume_skb() doesn't kfree the sk_buff.

This is problematic because in some error cases under memory pressure
we may need to linearize the sk_buff from sk_psock_skb_ingress_enqueue().
Then we get this,

 skb_linearize()
   __pskb_pull_tail()
     pskb_expand_head()
       BUG_ON(skb_shared(skb))

Because we incremented users refcnt from sk_psock_verdict_recv() we
hit the bug on with refcnt > 1 and trip it.

To fix lets simply pass ownership of the sk_buff through the skb_read
call. Then we can drop the consume from read_skb handlers and assume
the verdict recv does any required kfree.

Bug found while testing in our CI which runs in VMs that hit memory
constraints rather regularly. William tested TCP read_skb handlers.

[  106.536188] ------------[ cut here ]------------
[  106.536197] kernel BUG at net/core/skbuff.c:1693!
[  106.536479] invalid opcode: 0000 [#1] PREEMPT SMP PTI
[  106.536726] CPU: 3 PID: 1495 Comm: curl Not tainted 5.19.0-rc5 #1
[  106.537023] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ArchLinux 1.16.0-1 04/01/2014
[  106.537467] RIP: 0010:pskb_expand_head+0x269/0x330
[  106.538585] RSP: 0018:ffffc90000138b68 EFLAGS: 00010202
[  106.538839] RAX: 000000000000003f RBX: ffff8881048940e8 RCX: 0000000000000a20
[  106.539186] RDX: 0000000000000002 RSI: 0000000000000000 RDI: ffff8881048940e8
[  106.539529] RBP: ffffc90000138be8 R08: 00000000e161fd1a R09: 0000000000000000
[  106.539877] R10: 0000000000000018 R11: 0000000000000000 R12: ffff8881048940e8
[  106.540222] R13: 0000000000000003 R14: 0000000000000000 R15: ffff8881048940e8
[  106.540568] FS:  00007f277dde9f00(0000) GS:ffff88813bd80000(0000) knlGS:0000000000000000
[  106.540954] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  106.541227] CR2: 00007f277eeede64 CR3: 000000000ad3e000 CR4: 00000000000006e0
[  106.541569] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  106.541915] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  106.542255] Call Trace:
[  106.542383]  <IRQ>
[  106.542487]  __pskb_pull_tail+0x4b/0x3e0
[  106.542681]  skb_ensure_writable+0x85/0xa0
[  106.542882]  sk_skb_pull_data+0x18/0x20
[  106.543084]  bpf_prog_b517a65a242018b0_bpf_skskb_http_verdict+0x3a9/0x4aa9
[  106.543536]  ? migrate_disable+0x66/0x80
[  106.543871]  sk_psock_verdict_recv+0xe2/0x310
[  106.544258]  ? sk_psock_write_space+0x1f0/0x1f0
[  106.544561]  tcp_read_skb+0x7b/0x120
[  106.544740]  tcp_data_queue+0x904/0xee0
[  106.544931]  tcp_rcv_established+0x212/0x7c0
[  106.545142]  tcp_v4_do_rcv+0x174/0x2a0
[  106.545326]  tcp_v4_rcv+0xe70/0xf60
[  106.545500]  ip_protocol_deliver_rcu+0x48/0x290
[  106.545744]  ip_local_deliver_finish+0xa7/0x150

Fixes: 04919bed94 ("tcp: Introduce tcp_read_skb()")
Reported-by: William Findlay <will@isovalent.com>
Change-Id: I0dadf18f695e4305ba1043a7fbec7ef3f58baba7
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Tested-by: William Findlay <will@isovalent.com>
Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
Link: https://lore.kernel.org/bpf/20230523025618.113937-2-john.fastabend@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 4ae2af3e59)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
 2023-06-14 23:02:40 +00:00
Elliot Berman
86409bb4e1 ANDROID: virt: gunyah: Sync with latest Gunyah patches 
Sync changes to Gunyah stack to align with latest changes
posted to kernel.org:

https://lore.kernel.org/all/20230613172054.3959700-1-quic_eberman@quicinc.com/

Bug: 287037804
Change-Id: Ia36044894860bb94ff5518cf304254cdad14aaf5
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
 2023-06-14 22:02:31 +00:00
Elliot Berman
705a9b5feb ANDROID: virt: gunyah: Sync with latest documentation and sample 
Sync with latest documentation and sample code from v14 of Gunyah
patches:

https://lore.kernel.org/all/20230613172054.3959700-1-quic_eberman@quicinc.com/

Bug: 287037804
Change-Id: I8893922e6b8096fdd5dff1b22ebce96e72cdb7c3
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
 2023-06-14 22:02:31 +00:00
Howard Yen
60662882b7 FROMLIST: usb: xhci-plat: add xhci_plat_priv_overwrite 
Add an overwrite to platform specific callback for setting up the
xhci_vendor_ops, allow vendor to store the xhci_vendor_ops and
overwrite them when xhci_plat_probe invoked.

This change is depend on Commit in this patch series
("usb: host: add xhci hooks for USB offload"), vendor needs
to invoke xhci_plat_register_vendor_ops() to register the vendor specific
vendor_ops. And the vendor_ops will overwrite the vendor_ops inside
xhci_plat_priv in xhci_vendor_init() during xhci-plat-hcd probe.

Change-Id: I8030fe3bd274615f5926f19014c3a3e066ca9dba
Signed-off-by: Howard Yen <howardyen@google.com>
Bug: 175358363
Link: https://lore.kernel.org/r/20210119101044.1637023-1-howardyen@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Signed-off-by: JaeHun Jung <jh0801.jung@samsung.com>
 2023-06-14 17:35:00 +00:00
Howard Yen
6496f6cfbb ANDROID: usb: host: export symbols for xhci hooks usage 
Export symbols for xhci hooks usage:
xhci_ring_free
	- Allow xhci hook to free xhci_ring.
xhci_get_slot_ctx
	- Allow xhci hook to get slot_ctx from the xhci_container_ctx
	for getting the slot_ctx information to know which slot is
	offloading and compare the context in remote subsystem memory
	if needed.
xhci_get_ep_ctx
	- Allow xhci hook to get ep_ctx from the xhci_container_ctx for
	getting the ep_ctx information to know which ep is offloading and
	comparing the context in remote subsystem memory if needed.

Export below xhci symbols for vendor modules to manage additional secondary rings.
These will be used to manage the secondary ring for usb audio offload.

xhci_segment_free
	- Free a segment struct.
xhci_remove_stream_mapping
	- Free for sram
xhci_link_segments
	- Make the prev segment point to the next segment.
xhci_initialze_ring_info
	- Initialze a ring struct.
xhci_check_trb_in_td_math
	- Check TRB math for validation.
xhci_address_device
	- Issue an address device command
xhci_bus_suspend
xhci_bus_resume
	- Suspend and resume for power scenario

Change-Id: I2d99bded67024b2a7c625f934567e39ac03a6e5f
Signed-off-by: Howard Yen <howardyen@google.com>
Bug: 175358363
Bug: 183761108
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Signed-off-by: Daehwan Jung <dh10.jung@samsung.com>
Signed-off-by: JaeHun Jung <jh0801.jung@samsung.com>
 2023-06-14 17:35:00 +00:00
Howard Yen
90ab8e7f98 ANDROID: usb: host: add xhci hooks for USB offload 
To enable supporting for USB offload, define "offload" in usb controller
node of device tree. "offload" value can be used to determine which type
of offload was been enabled in the SoC.

For example:

&usbdrd_dwc3 {
	...
		/* support usb offloading, 0: disabled, 1: audio */
		offload = <1>;
	...
};

There are several vendor_ops introduced by this patch:

c - function callbacks for vendor specific operations
{
	@vendor_init:
		- called for vendor init process during xhci-plat-hcd
		probe.
		@vendor_cleanup:
		- called for vendor cleanup process during xhci-plat-hcd
		remove.
		@is_usb_offload_enabled:
		- called to check if usb offload enabled.
		@queue_irq_work:
		- called to queue vendor specific irq work.
		@alloc_dcbaa:
		- called when allocating vendor specific dcbaa during
		memory initializtion.
		@free_dcbaa:
		- called to free vendor specific dcbaa when cleanup the
		memory.
		@alloc_transfer_ring:
		- called when vendor specific transfer ring allocation is required
		@free_transfer_ring:
		- called to free vendor specific transfer ring
		@sync_dev_ctx:
		- called when synchronization for device context is required
		@usb_offload_skip_urb:
		- skip urb control for offloading
		@alloc_container_ctx:
		@free_container_ctx:
		- called to alloc and free vendor specific container context
}

The xhci hooks with prefix "xhci_vendor_" on the ops in xhci_vendor_ops.
For example, vendor_init ops will be invoked by xhci_vendor_init() hook,
is_usb_offload_enabled ops will be invoked by
xhci_vendor_is_usb_offload_enabled(), and so on.

Change-Id: Ib7f6952e6d44a2fcfe9d19a78f1d9f5093417613
Signed-off-by: Howard Yen <howardyen@google.com>
Bug: 175358363
Signed-off-by: Greg Kroah-Harktman <gregkh@google.com>
Signed-off-by: Puma Hsu <pumahsu@google.com>
Signed-off-by: J. Avila <elavila@google.com>
Signed-off-by: Daehwan Jung <dh10.jung@samsung.com>
Signed-off-by: JaeHun Jung <jh0801.jung@samsung.com>
 2023-06-14 17:35:00 +00:00
Carlos Llamas
88959a53f4 ANDROID: 6/16/2023 KMI update 
Set KMI_GENERATION=9 for 6/16 KMI update

function symbol 'struct block_device* I_BDEV(struct inode*)' changed
  CRC changed from 0xb3d19fd2 to 0xc8597fa

function symbol 'void __ClearPageMovable(struct page*)' changed
  CRC changed from 0x66921e4f to 0xb4e74d22

function symbol 'void __SetPageMovable(struct page*, const struct movable_operations*)' changed
  CRC changed from 0x2b34667d to 0xe8b6d861

... 4484 omitted; 4487 symbols have only CRC changes

type 'struct request' changed
  byte size changed from 312 to 320
  member 'u64 alloc_time_ns' was added
  19 members ('u64 start_time_ns' .. 'u64 android_kabi_reserved1') changed
    offset changed by 64

type 'struct bio' changed
  byte size changed from 152 to 160
  member 'u64 bi_iocost_cost' was added
  12 members ('struct bio_crypt_ctx* bi_crypt_context' .. 'struct bio_vec bi_inline_vecs[0]') changed
    offset changed by 64

type 'enum cpuhp_state' changed
  enumerator 'CPUHP_AP_ARM_SDEI_STARTING' (116) was removed
  enumerator 'CPUHP_AP_ARM_VFP_STARTING' value changed from 117 to 116
  enumerator 'CPUHP_AP_ARM64_DEBUG_MONITORS_STARTING' value changed from 118 to 117
  enumerator 'CPUHP_AP_PERF_ARM_HW_BREAKPOINT_STARTING' value changed from 119 to 118
  enumerator 'CPUHP_AP_PERF_ARM_ACPI_STARTING' value changed from 120 to 119
  enumerator 'CPUHP_AP_PERF_ARM_STARTING' value changed from 121 to 120
  enumerator 'CPUHP_AP_PERF_RISCV_STARTING' value changed from 122 to 121
  enumerator 'CPUHP_AP_ARM_L2X0_STARTING' value changed from 123 to 122
  enumerator 'CPUHP_AP_EXYNOS4_MCT_TIMER_STARTING' value changed from 124 to 123
  enumerator 'CPUHP_AP_ARM_ARCH_TIMER_STARTING' value changed from 125 to 124
  enumerator 'CPUHP_AP_ARM_GLOBAL_TIMER_STARTING' value changed from 126 to 125
  enumerator 'CPUHP_AP_JCORE_TIMER_STARTING' value changed from 127 to 126
  enumerator 'CPUHP_AP_ARM_TWD_STARTING' value changed from 128 to 127
  enumerator 'CPUHP_AP_QCOM_TIMER_STARTING' value changed from 129 to 128
  enumerator 'CPUHP_AP_TEGRA_TIMER_STARTING' value changed from 130 to 129
  enumerator 'CPUHP_AP_ARMADA_TIMER_STARTING' value changed from 131 to 130
  enumerator 'CPUHP_AP_MARCO_TIMER_STARTING' value changed from 132 to 131
  enumerator 'CPUHP_AP_MIPS_GIC_TIMER_STARTING' value changed from 133 to 132
  enumerator 'CPUHP_AP_ARC_TIMER_STARTING' value changed from 134 to 133
  enumerator 'CPUHP_AP_RISCV_TIMER_STARTING' value changed from 135 to 134
  enumerator 'CPUHP_AP_CLINT_TIMER_STARTING' value changed from 136 to 135
  enumerator 'CPUHP_AP_CSKY_TIMER_STARTING' value changed from 137 to 136
  enumerator 'CPUHP_AP_TI_GP_TIMER_STARTING' value changed from 138 to 137
  enumerator 'CPUHP_AP_HYPERV_TIMER_STARTING' value changed from 139 to 138
  enumerator 'CPUHP_AP_KVM_STARTING' value changed from 140 to 139
  enumerator 'CPUHP_AP_KVM_ARM_VGIC_INIT_STARTING' value changed from 141 to 140
  enumerator 'CPUHP_AP_KVM_ARM_VGIC_STARTING' value changed from 142 to 141
  enumerator 'CPUHP_AP_KVM_ARM_TIMER_STARTING' value changed from 143 to 142
  enumerator 'CPUHP_AP_DUMMY_TIMER_STARTING' value changed from 144 to 143
  enumerator 'CPUHP_AP_ARM_XEN_STARTING' value changed from 145 to 144
  enumerator 'CPUHP_AP_ARM_CORESIGHT_STARTING' value changed from 146 to 145
  enumerator 'CPUHP_AP_ARM_CORESIGHT_CTI_STARTING' value changed from 147 to 146
  enumerator 'CPUHP_AP_ARM64_ISNDEP_STARTING' value changed from 148 to 147
  enumerator 'CPUHP_AP_SMPCFD_DYING' value changed from 149 to 148
  enumerator 'CPUHP_AP_X86_TBOOT_DYING' value changed from 150 to 149
  enumerator 'CPUHP_AP_ARM_CACHE_B15_RAC_DYING' value changed from 151 to 150
  enumerator 'CPUHP_AP_ONLINE' value changed from 152 to 151
  enumerator 'CPUHP_TEARDOWN_CPU' value changed from 153 to 152
  enumerator 'CPUHP_AP_ONLINE_IDLE' value changed from 154 to 153
  enumerator 'CPUHP_AP_SCHED_WAIT_EMPTY' value changed from 155 to 154
  enumerator 'CPUHP_AP_SMPBOOT_THREADS' value changed from 156 to 155
  enumerator 'CPUHP_AP_X86_VDSO_VMA_ONLINE' value changed from 157 to 156
  enumerator 'CPUHP_AP_IRQ_AFFINITY_ONLINE' value changed from 158 to 157
  enumerator 'CPUHP_AP_BLK_MQ_ONLINE' value changed from 159 to 158
  enumerator 'CPUHP_AP_ARM_MVEBU_SYNC_CLOCKS' value changed from 160 to 159
  enumerator 'CPUHP_AP_X86_INTEL_EPB_ONLINE' value changed from 161 to 160
  enumerator 'CPUHP_AP_PERF_ONLINE' value changed from 162 to 161
  enumerator 'CPUHP_AP_PERF_X86_ONLINE' value changed from 163 to 162
  enumerator 'CPUHP_AP_PERF_X86_UNCORE_ONLINE' value changed from 164 to 163
  enumerator 'CPUHP_AP_PERF_X86_AMD_UNCORE_ONLINE' value changed from 165 to 164
  enumerator 'CPUHP_AP_PERF_X86_AMD_POWER_ONLINE' value changed from 166 to 165
  enumerator 'CPUHP_AP_PERF_X86_RAPL_ONLINE' value changed from 167 to 166
  enumerator 'CPUHP_AP_PERF_X86_CQM_ONLINE' value changed from 168 to 167
  enumerator 'CPUHP_AP_PERF_X86_CSTATE_ONLINE' value changed from 169 to 168
  enumerator 'CPUHP_AP_PERF_X86_IDXD_ONLINE' value changed from 170 to 169
  enumerator 'CPUHP_AP_PERF_S390_CF_ONLINE' value changed from 171 to 170
  enumerator 'CPUHP_AP_PERF_S390_SF_ONLINE' value changed from 172 to 171
  enumerator 'CPUHP_AP_PERF_ARM_CCI_ONLINE' value changed from 173 to 172
  enumerator 'CPUHP_AP_PERF_ARM_CCN_ONLINE' value changed from 174 to 173
  enumerator 'CPUHP_AP_PERF_ARM_HISI_CPA_ONLINE' value changed from 175 to 174
  enumerator 'CPUHP_AP_PERF_ARM_HISI_DDRC_ONLINE' value changed from 176 to 175
  enumerator 'CPUHP_AP_PERF_ARM_HISI_HHA_ONLINE' value changed from 177 to 176
  enumerator 'CPUHP_AP_PERF_ARM_HISI_L3_ONLINE' value changed from 178 to 177
  enumerator 'CPUHP_AP_PERF_ARM_HISI_PA_ONLINE' value changed from 179 to 178
  enumerator 'CPUHP_AP_PERF_ARM_HISI_SLLC_ONLINE' value changed from 180 to 179
  enumerator 'CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE' value changed from 181 to 180
  enumerator 'CPUHP_AP_PERF_ARM_HNS3_PMU_ONLINE' value changed from 182 to 181
  enumerator 'CPUHP_AP_PERF_ARM_L2X0_ONLINE' value changed from 183 to 182
  enumerator 'CPUHP_AP_PERF_ARM_QCOM_L2_ONLINE' value changed from 184 to 183
  enumerator 'CPUHP_AP_PERF_ARM_QCOM_L3_ONLINE' value changed from 185 to 184
  enumerator 'CPUHP_AP_PERF_ARM_APM_XGENE_ONLINE' value changed from 186 to 185
  enumerator 'CPUHP_AP_PERF_ARM_CAVIUM_TX2_UNCORE_ONLINE' value changed from 187 to 186
  enumerator 'CPUHP_AP_PERF_ARM_MARVELL_CN10K_DDR_ONLINE' value changed from 188 to 187
  enumerator 'CPUHP_AP_PERF_POWERPC_NEST_IMC_ONLINE' value changed from 189 to 188
  enumerator 'CPUHP_AP_PERF_POWERPC_CORE_IMC_ONLINE' value changed from 190 to 189
  enumerator 'CPUHP_AP_PERF_POWERPC_THREAD_IMC_ONLINE' value changed from 191 to 190
  enumerator 'CPUHP_AP_PERF_POWERPC_TRACE_IMC_ONLINE' value changed from 192 to 191
  enumerator 'CPUHP_AP_PERF_POWERPC_HV_24x7_ONLINE' value changed from 193 to 192
  enumerator 'CPUHP_AP_PERF_POWERPC_HV_GPCI_ONLINE' value changed from 194 to 193
  enumerator 'CPUHP_AP_PERF_CSKY_ONLINE' value changed from 195 to 194
  enumerator 'CPUHP_AP_WATCHDOG_ONLINE' value changed from 196 to 195
  enumerator 'CPUHP_AP_WORKQUEUE_ONLINE' value changed from 197 to 196
  enumerator 'CPUHP_AP_RANDOM_ONLINE' value changed from 198 to 197
  enumerator 'CPUHP_AP_RCUTREE_ONLINE' value changed from 199 to 198
  enumerator 'CPUHP_AP_BASE_CACHEINFO_ONLINE' value changed from 200 to 199
  enumerator 'CPUHP_AP_ONLINE_DYN' value changed from 201 to 200
  enumerator 'CPUHP_AP_ONLINE_DYN_END' value changed from 231 to 230
  enumerator 'CPUHP_AP_MM_DEMOTION_ONLINE' value changed from 232 to 231
  enumerator 'CPUHP_AP_X86_HPET_ONLINE' value changed from 233 to 232
  enumerator 'CPUHP_AP_X86_KVM_CLK_ONLINE' value changed from 234 to 233
  enumerator 'CPUHP_AP_ACTIVE' value changed from 235 to 234
  enumerator 'CPUHP_ANDROID_RESERVED_1' value changed from 236 to 235
  enumerator 'CPUHP_ANDROID_RESERVED_2' value changed from 237 to 236
  enumerator 'CPUHP_ANDROID_RESERVED_3' value changed from 238 to 237
  enumerator 'CPUHP_ANDROID_RESERVED_4' value changed from 239 to 238
  enumerator 'CPUHP_ONLINE' value changed from 240 to 239

type 'struct task_struct' changed
  byte size changed from 4736 to 4800
  104 members ('const struct cred* ptracer_cred' .. 'struct thread_struct thread') changed
    offset changed by 384

type 'struct platform_driver' changed
  byte size changed from 240 to 248
  member 'void(* remove_new)(struct platform_device*)' was added
  8 members ('void(* shutdown)(struct platform_device*)' .. 'u64 android_kabi_reserved1') changed
    offset changed by 64

type 'struct tipc_bearer' changed
  member 'u16 encap_hlen' was added

type 'struct posix_cputimers_work' changed
  byte size changed from 24 to 72
  member 'struct mutex mutex' was added
  member 'unsigned int scheduled' changed
    offset changed by 384

type 'struct binder_alloc' changed
  member 'struct vm_area_struct* vma' was added
  member 'unsigned long vma_addr' was removed

type 'struct usb_udc' changed
  byte size changed from 1000 to 952
  member 'struct mutex connect_lock' was removed

type 'enum kvm_pgtable_prot' changed
  enumerator 'KVM_PGTABLE_PROT_PXN' (32) was added
  enumerator 'KVM_PGTABLE_PROT_UXN' (64) was added

Bug: 287162457
Change-Id: Ic3aad43bd3a6083cf91e71e79ece713bef0e8172
Signed-off-by: Carlos Llamas <cmllamas@google.com>
 2023-06-14 16:40:59 +00:00
Carlos Llamas
21bc72f339 UPSTREAM: binder: fix UAF of alloc->vma in race with munmap() 
commit d1d8875c8c upstream.

[ cmllamas: clean forward port from commit 015ac18be7 ("binder: fix
  UAF of alloc->vma in race with munmap()") in 5.10 stable. It is needed
  in mainline after the revert of commit a43cfc87ca ("android: binder:
  stop saving a pointer to the VMA") as pointed out by Liam. The commit
  log and tags have been tweaked to reflect this. ]

In commit 720c241924 ("ANDROID: binder: change down_write to
down_read") binder assumed the mmap read lock is sufficient to protect
alloc->vma inside binder_update_page_range(). This used to be accurate
until commit dd2283f260 ("mm: mmap: zap pages with read mmap_sem in
munmap"), which now downgrades the mmap_lock after detaching the vma
from the rbtree in munmap(). Then it proceeds to teardown and free the
vma with only the read lock held.

This means that accesses to alloc->vma in binder_update_page_range() now
will race with vm_area_free() in munmap() and can cause a UAF as shown
in the following KASAN trace:

  ==================================================================
  BUG: KASAN: use-after-free in vm_insert_page+0x7c/0x1f0
  Read of size 8 at addr ffff16204ad00600 by task server/558

  CPU: 3 PID: 558 Comm: server Not tainted 5.10.150-00001-gdc8dcf942daa #1
  Hardware name: linux,dummy-virt (DT)
  Call trace:
   dump_backtrace+0x0/0x2a0
   show_stack+0x18/0x2c
   dump_stack+0xf8/0x164
   print_address_description.constprop.0+0x9c/0x538
   kasan_report+0x120/0x200
   __asan_load8+0xa0/0xc4
   vm_insert_page+0x7c/0x1f0
   binder_update_page_range+0x278/0x50c
   binder_alloc_new_buf+0x3f0/0xba0
   binder_transaction+0x64c/0x3040
   binder_thread_write+0x924/0x2020
   binder_ioctl+0x1610/0x2e5c
   __arm64_sys_ioctl+0xd4/0x120
   el0_svc_common.constprop.0+0xac/0x270
   do_el0_svc+0x38/0xa0
   el0_svc+0x1c/0x2c
   el0_sync_handler+0xe8/0x114
   el0_sync+0x180/0x1c0

  Allocated by task 559:
   kasan_save_stack+0x38/0x6c
   __kasan_kmalloc.constprop.0+0xe4/0xf0
   kasan_slab_alloc+0x18/0x2c
   kmem_cache_alloc+0x1b0/0x2d0
   vm_area_alloc+0x28/0x94
   mmap_region+0x378/0x920
   do_mmap+0x3f0/0x600
   vm_mmap_pgoff+0x150/0x17c
   ksys_mmap_pgoff+0x284/0x2dc
   __arm64_sys_mmap+0x84/0xa4
   el0_svc_common.constprop.0+0xac/0x270
   do_el0_svc+0x38/0xa0
   el0_svc+0x1c/0x2c
   el0_sync_handler+0xe8/0x114
   el0_sync+0x180/0x1c0

  Freed by task 560:
   kasan_save_stack+0x38/0x6c
   kasan_set_track+0x28/0x40
   kasan_set_free_info+0x24/0x4c
   __kasan_slab_free+0x100/0x164
   kasan_slab_free+0x14/0x20
   kmem_cache_free+0xc4/0x34c
   vm_area_free+0x1c/0x2c
   remove_vma+0x7c/0x94
   __do_munmap+0x358/0x710
   __vm_munmap+0xbc/0x130
   __arm64_sys_munmap+0x4c/0x64
   el0_svc_common.constprop.0+0xac/0x270
   do_el0_svc+0x38/0xa0
   el0_svc+0x1c/0x2c
   el0_sync_handler+0xe8/0x114
   el0_sync+0x180/0x1c0

  [...]
  ==================================================================

To prevent the race above, revert back to taking the mmap write lock
inside binder_update_page_range(). One might expect an increase of mmap
lock contention. However, binder already serializes these calls via top
level alloc->mutex. Also, there was no performance impact shown when
running the binder benchmark tests.

Fixes: c0fd210178 ("Revert "android: binder: stop saving a pointer to the VMA"")
Fixes: dd2283f260 ("mm: mmap: zap pages with read mmap_sem in munmap")
Reported-by: Jann Horn <jannh@google.com>
Closes: https://lore.kernel.org/all/20230518144052.xkj6vmddccq4v66b@revolver
Cc: <stable@vger.kernel.org>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Yang Shi <yang.shi@linux.alibaba.com>
Cc: Liam Howlett <liam.howlett@oracle.com>
Change-Id: I4215750a81e94bccf5340e4d79f7b26bb039c573
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Acked-by: Todd Kjos <tkjos@google.com>
Link: https://lore.kernel.org/r/20230519195950.1775656-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 931ea1ed31)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
 2023-06-14 16:40:59 +00:00
Carlos Llamas
62c6dbdccd UPSTREAM: binder: add lockless binder_alloc_(set|get)_vma() 
commit 0fa53349c3 upstream.

Bring back the original lockless design in binder_alloc to determine
whether the buffer setup has been completed by the ->mmap() handler.
However, this time use smp_load_acquire() and smp_store_release() to
wrap all the ordering in a single macro call.

Also, add comments to make it evident that binder uses alloc->vma to
determine when the binder_alloc has been fully initialized. In these
scenarios acquiring the mmap_lock is not required.

Fixes: a43cfc87ca ("android: binder: stop saving a pointer to the VMA")
Cc: Liam Howlett <liam.howlett@oracle.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: stable@vger.kernel.org
Change-Id: I2a8040417790b6b82bf44e838146fd68403fdb51
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20230502201220.1756319-3-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit d7cee853bc)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
 2023-06-14 16:40:59 +00:00
Carlos Llamas
3cac174682 UPSTREAM: Revert "android: binder: stop saving a pointer to the VMA" 
commit c0fd210178 upstream.

This reverts commit a43cfc87ca.

This patch fixed an issue reported by syzkaller in [1]. However, this
turned out to be only a band-aid in binder. The root cause, as bisected
by syzkaller, was fixed by commit 5789151e48 ("mm/mmap: undo ->mmap()
when mas_preallocate() fails"). We no longer need the patch for binder.

Reverting such patch allows us to have a lockless access to alloc->vma
in specific cases where the mmap_lock is not required. This approach
avoids the contention that caused a performance regression.

[1] https://lore.kernel.org/all/0000000000004a0dbe05e1d749e0@google.com

[cmllamas: resolved conflicts with rework of alloc->mm and removal of
 binder_alloc_set_vma() also fixed comment section]

Fixes: a43cfc87ca ("android: binder: stop saving a pointer to the VMA")
Cc: Liam Howlett <liam.howlett@oracle.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: stable@vger.kernel.org
Change-Id: I208b4ebf832790eb155d52ec3115e1e6c58f6f80
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20230502201220.1756319-2-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 72a94f8c14)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
 2023-06-14 16:40:59 +00:00
Carlos Llamas
dadb40b436 UPSTREAM: Revert "binder_alloc: add missing mmap_lock calls when using the VMA" 
commit b15655b12d upstream.

This reverts commit 44e602b4e5.

This caused a performance regression particularly when pages are getting
reclaimed. We don't need to acquire the mmap_lock to determine when the
binder buffer has been fully initialized. A subsequent patch will bring
back the lockless approach for this.

[cmllamas: resolved trivial conflicts with renaming of alloc->mm]

Fixes: 44e602b4e5 ("binder_alloc: add missing mmap_lock calls when using the VMA")
Cc: Liam Howlett <liam.howlett@oracle.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: stable@vger.kernel.org
Change-Id: If26447c08c59fbbc43731ecbd8b501c928ffbe2d
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20230502201220.1756319-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 7e6b854854)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
 2023-06-14 16:40:59 +00:00
Xin Long
fcdbf469c5 UPSTREAM: tipc: check the bearer min mtu properly when setting it by netlink 
[ Upstream commit 35a089b5d7 ]

Checking the bearer min mtu with tipc_udp_mtu_bad() only works for
IPv4 UDP bearer, and IPv6 UDP bearer has a different value for the
min mtu. This patch checks with encap_hlen + TIPC_MIN_BEARER_MTU
for min mtu, which works for both IPv4 and IPv6 UDP bearer.

Note that tipc_udp_mtu_bad() is still used to check media min mtu
in __tipc_nl_media_set(), as m->mtu currently is only used by the
IPv4 UDP bearer as its default mtu value.

Fixes: 682cd3cf94 ("tipc: confgiure and apply UDP bearer MTU on running links")
Change-Id: I384afae6ffa9c43f72c1cda34ad2f1dd611fc675
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Jon Maloy <jmaloy@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit f215b62f59)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
 2023-06-14 16:40:59 +00:00
Xin Long
e48a801737 UPSTREAM: tipc: do not update mtu if msg_max is too small in mtu negotiation 
[ Upstream commit 56077b56cd ]

When doing link mtu negotiation, a malicious peer may send Activate msg
with a very small mtu, e.g. 4 in Shuang's testing, without checking for
the minimum mtu, l->mtu will be set to 4 in tipc_link_proto_rcv(), then
n->links[bearer_id].mtu is set to 4294967228, which is a overflow of
'4 - INT_H_SIZE - EMSG_OVERHEAD' in tipc_link_mss().

With tipc_link.mtu = 4, tipc_link_xmit() kept printing the warning:

 tipc: Too large msg, purging xmit list 1 5 0 40 4!
 tipc: Too large msg, purging xmit list 1 15 0 60 4!

And with tipc_link_entry.mtu 4294967228, a huge skb was allocated in
named_distribute(), and when purging it in tipc_link_xmit(), a crash
was even caused:

  general protection fault, probably for non-canonical address 0x2100001011000dd: 0000 [#1] PREEMPT SMP PTI
  CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted 6.3.0.neta #19
  RIP: 0010:kfree_skb_list_reason+0x7e/0x1f0
  Call Trace:
   <IRQ>
   skb_release_data+0xf9/0x1d0
   kfree_skb_reason+0x40/0x100
   tipc_link_xmit+0x57a/0x740 [tipc]
   tipc_node_xmit+0x16c/0x5c0 [tipc]
   tipc_named_node_up+0x27f/0x2c0 [tipc]
   tipc_node_write_unlock+0x149/0x170 [tipc]
   tipc_rcv+0x608/0x740 [tipc]
   tipc_udp_recv+0xdc/0x1f0 [tipc]
   udp_queue_rcv_one_skb+0x33e/0x620
   udp_unicast_rcv_skb.isra.72+0x75/0x90
   __udp4_lib_rcv+0x56d/0xc20
   ip_protocol_deliver_rcu+0x100/0x2d0

This patch fixes it by checking the new mtu against tipc_bearer_min_mtu(),
and not updating mtu if it is too small.

Fixes: ed193ece26 ("tipc: simplify link mtu negotiation")
Reported-by: Shuang Li <shuali@redhat.com>
Change-Id: I95f28cbfaf6dc4899e0695ba6168c7c58737f06b
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Jon Maloy <jmaloy@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 259683001d)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
 2023-06-14 16:40:59 +00:00
Xin Long
461038ba5c UPSTREAM: tipc: add tipc_bearer_min_mtu to calculate min mtu 
[ Upstream commit 3ae6d66b60 ]

As different media may requires different min mtu, and even the
same media with different net family requires different min mtu,
add tipc_bearer_min_mtu() to calculate min mtu accordingly.

This API will be used to check the new mtu when doing the link
mtu negotiation in the next patch.

Change-Id: I960cf07506388294eb6028938025e1073a2c4be5
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Jon Maloy <jmaloy@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Stable-dep-of: 56077b56cd ("tipc: do not update mtu if msg_max is too small in mtu negotiation")
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 735c64ea88)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
 2023-06-14 16:40:59 +00:00