Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Proximity sensor not working at all #1

Open
SuperLeo25 opened this issue Oct 5, 2022 · 0 comments
Open

Proximity sensor not working at all #1

SuperLeo25 opened this issue Oct 5, 2022 · 0 comments

Comments

@SuperLeo25
Copy link

Rom: PixelExperience Plus 12.1 (official release 2022/07/15)

On the latest release, everything seems working fine except for the proximity sensor (which doesn't seem to report data at all). This applies in scenarios like screen not turning off while calling or with whatsapp voice notes.
Official-Ayrton990 pushed a commit that referenced this issue Oct 19, 2022
qcacld-3.0: set msdu/mpdu aggr size for each vdev start
6a9129e 
The global aggregation size is only set to firmware once
when vdev is created. And the size may be modified
dynamically for a specified AP during association, according
to the OUI based aggregation size configured by ini
'cfg_tx_iot_aggr'.

If global AMSDU size is 0, considering the case as below:
1. connect to AP-1 which is included in 'cfg_tx_iot_aggr',
   the AMSDU size will be set to the specifed value.
2. connect to AP-2 which is NOT in 'cfg_tx_iot_aggr',
   it doesn't reset the AMSDU size to 0, and firmware is
   still using the value set in step #1, it's wrong.

To fix this issue, set the global size for each vdev start,
as init values for each connection.

Change-Id: I790d580fc5762e6816e840ba5484b3cd758334df
CRs-Fixed: 2918046
Official-Ayrton990 pushed a commit that referenced this issue Nov 10, 2022
FROMLIST: binder: fix UAF of alloc->vma in race with munmap()
c262d21 
In commit 720c241 ("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 dd2283f ("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.

Note this patch is specific to stable branches 5.4 and 5.10. Since in
newer kernel releases binder no longer caches a pointer to the vma.
Instead, it has been refactored to use vma_lookup() which avoids the
issue described here. This switch was introduced in commit a43cfc87caaf
("android: binder: stop saving a pointer to the VMA").

Bug: 254837884
Link: https://lore.kernel.org/all/[email protected]/
Fixes: dd2283f ("mm: mmap: zap pages with read mmap_sem in munmap")
Reported-by: Jann Horn <[email protected]>
Cc: <[email protected]> # 5.4.x
Cc: Minchan Kim <[email protected]>
Cc: Yang Shi <[email protected]>
Cc: Liam Howlett <[email protected]>
Signed-off-by: Carlos Llamas <[email protected]>
Change-Id: I87e95bf5c15069f7cb1a0b30186a5f0ed9b1b096
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@SuperLeo25