A transaction complete work is allocated and queued for each
transaction. Under certain conditions the work->type might be marked as
BINDER_WORK_TRANSACTION_ONEWAY_SPAM_SUSPECT to notify userspace about
potential spamming threads or as BINDER_WORK_TRANSACTION_PENDING when
the target is currently frozen.
However, these work types are not being handled in binder_release_work()
so they will leak during a cleanup. This was reported by syzkaller with
the following kmemleak dump:
BUG: memory leak
unreferenced object 0xffff88810e2d6de0 (size 32):
comm "syz-executor338", pid 5046, jiffies 4294968230 (age 13.590s)
hex dump (first 32 bytes):
e0 6d 2d 0e 81 88 ff ff e0 6d 2d 0e 81 88 ff ff .m-......m-.....
04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff81573b75>] kmalloc_trace+0x25/0x90 mm/slab_common.c:1114
[<ffffffff83d41873>] kmalloc include/linux/slab.h:599 [inline]
[<ffffffff83d41873>] kzalloc include/linux/slab.h:720 [inline]
[<ffffffff83d41873>] binder_transaction+0x573/0x4050 drivers/android/binder.c:3152
[<ffffffff83d45a05>] binder_thread_write+0x6b5/0x1860 drivers/android/binder.c:4010
[<ffffffff83d486dc>] binder_ioctl_write_read drivers/android/binder.c:5066 [inline]
[<ffffffff83d486dc>] binder_ioctl+0x1b2c/0x3cf0 drivers/android/binder.c:5352
[<ffffffff816b25f2>] vfs_ioctl fs/ioctl.c:51 [inline]
[<ffffffff816b25f2>] __do_sys_ioctl fs/ioctl.c:871 [inline]
[<ffffffff816b25f2>] __se_sys_ioctl fs/ioctl.c:857 [inline]
[<ffffffff816b25f2>] __x64_sys_ioctl+0xf2/0x140 fs/ioctl.c:857
[<ffffffff84b30008>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
[<ffffffff84b30008>] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
[<ffffffff84c0008b>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
Fix the leaks by kfreeing these work types in binder_release_work() and
handle them as a BINDER_WORK_TRANSACTION_COMPLETE cleanup.
Cc: stable@vger.kernel.org
Fixes: 0567461a7a ("binder: return pending info for frozen async txns")
Fixes: a7dc1e6f99 ("binder: tell userspace to dump current backtrace when detected oneway spamming")
Reported-by: syzbot+7f10c1653e35933c0f1e@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=7f10c1653e35933c0f1e
Suggested-by: Alice Ryhl <aliceryhl@google.com>
Change-Id: I8e1ee7af87ef5706544e4f320e9498b8f4855a6b
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Todd Kjos <tkjos@google.com>
Link: https://lore.kernel.org/r/20230922175138.230331-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 1aa3aaf895)
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Kfence only needs its pool to be mapped as page granularity, if it is
inited early. Previous judgement was a bit over protected. From [1], Mark
suggested to "just map the KFENCE region a page granularity". So I
decouple it from judgement and do page granularity mapping for kfence
pool only. Need to be noticed that late init of kfence pool still requires
page granularity mapping.
Page granularity mapping in theory cost more(2M per 1GB) memory on arm64
platform. Like what I've tested on QEMU(emulated 1GB RAM) with
gki_defconfig, also turning off rodata protection:
Before:
[root@liebao ]# cat /proc/meminfo
MemTotal: 999484 kB
After:
[root@liebao ]# cat /proc/meminfo
MemTotal: 1001480 kB
To implement this, also relocate the kfence pool allocation before the
linear mapping setting up, arm64_kfence_alloc_pool is to allocate phys
addr, __kfence_pool is to be set after linear mapping set up.
LINK: [1] https://lore.kernel.org/linux-arm-kernel/Y+IsdrvDNILA59UN@FVFF77S0Q05N/
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Zhenhua Huang <quic_zhenhuah@quicinc.com>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: Marco Elver <elver@google.com>
Link: https://lore.kernel.org/r/1679066974-690-1-git-send-email-quic_zhenhuah@quicinc.com
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 284812202
Change-Id: I8e7c565d3f4d6349a028a6a060259d62cf5beee7
(cherry picked from commit bfa7965b33)
Signed-off-by: Zhenhua Huang <quic_zhenhuah@quicinc.com>
KFENCE requires linear map to be mapped at page granularity, so that it
is possible to protect/unprotect single pages, just like with
rodata_full and DEBUG_PAGEALLOC.
Instead of repating
can_set_direct_map() || IS_ENABLED(CONFIG_KFENCE)
make can_set_direct_map() handle the KFENCE case.
This also prevents potential false positives in kernel_page_present()
that may return true for non-present page if CONFIG_KFENCE is enabled.
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Link: https://lore.kernel.org/r/20220921074841.382615-1-rppt@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
(cherry picked from commit b9dd04a20f)
Bug: 284812202
Change-Id: Ie87b2184b5aac2c34a05dd9b832b937786e367ff
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
5.15.138 Dragonboard 845c because of recently added symbol,
rpmsg_register_device_override.
So add it to the symbol list and update the abi definitions.
Bug: 313495196
Change-Id: I3a3504b6d2061bfce0abe9801e2ecb210c337b9f
Signed-off-by: Yongqin Liu <yongqin.liu@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
(cherry picked from commit 02ca2ae2af)
Signed-off-by: Lee Jones <joneslee@google.com>
In commit e70898ae1a ("rpmsg: Fix kfree() of static memory on setting
driver_override") a pointer was changed to const, which messes with the
CRC and ABI checks. As the code is fine if this is left as not-const,
just put it back to preserve the abi.
Bug: 161946584
Fixes: e70898ae1a ("rpmsg: Fix kfree() of static memory on setting driver_override")
Change-Id: I9a87b9cf412191d9872b48f1f876a81df6701de0
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
(cherry picked from commit 4f2270e2bca1854ebe8be23a82f665eaa27ee831)
Signed-off-by: Lee Jones <joneslee@google.com>
In commit 389190b254 ("driver: platform: Add helper for safer setting
of driver_override"), a pointer was changed to const, which messes with
the CRC and ABI checks. As the code is fine if this is left as
not-const, just put it back to preserve the abi.
Bug: 161946584
Fixes: 389190b254 ("driver: platform: Add helper for safer setting of driver_override")
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ieb4a730a6a5767d31fbec2f1ba683617f5cda7a9
(cherry picked from commit 1202da82c0)
Signed-off-by: Lee Jones <joneslee@google.com>
commit bb17d110cb upstream.
driver_set_override() helper uses device_lock() so it should not be
called before rpmsg_register_device() (which calls device_register()).
Effect can be seen with CONFIG_DEBUG_MUTEXES:
DEBUG_LOCKS_WARN_ON(lock->magic != lock)
WARNING: CPU: 3 PID: 57 at kernel/locking/mutex.c:582 __mutex_lock+0x1ec/0x430
...
Call trace:
__mutex_lock+0x1ec/0x430
mutex_lock_nested+0x44/0x50
driver_set_override+0x124/0x150
qcom_glink_native_probe+0x30c/0x3b0
glink_rpm_probe+0x274/0x350
platform_probe+0x6c/0xe0
really_probe+0x17c/0x3d0
__driver_probe_device+0x114/0x190
driver_probe_device+0x3c/0xf0
...
Refactor the rpmsg_register_device() function to use two-step device
registering (initialization + add) and call driver_set_override() in
proper moment.
This moves the code around, so while at it also NULL-ify the
rpdev->driver_override in error path to be sure it won't be kfree()
second time.
Bug: 295334746
Fixes: 42cd402b8f ("rpmsg: Fix kfree() of static memory on setting driver_override")
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20220429195946.1061725-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit bfd4a664dd)
[Lee: Git was confused that the hunk being removed had changed]
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Ic07d9ff669e88a50354ad8e978ae8e93316a2a5e
commit 6c2f421174 upstream.
Several core drivers and buses expect that driver_override is a
dynamically allocated memory thus later they can kfree() it.
However such assumption is not documented, there were in the past and
there are already users setting it to a string literal. This leads to
kfree() of static memory during device release (e.g. in error paths or
during unbind):
kernel BUG at ../mm/slub.c:3960!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
...
(kfree) from [<c058da50>] (platform_device_release+0x88/0xb4)
(platform_device_release) from [<c0585be0>] (device_release+0x2c/0x90)
(device_release) from [<c0a69050>] (kobject_put+0xec/0x20c)
(kobject_put) from [<c0f2f120>] (exynos5_clk_probe+0x154/0x18c)
(exynos5_clk_probe) from [<c058de70>] (platform_drv_probe+0x6c/0xa4)
(platform_drv_probe) from [<c058b7ac>] (really_probe+0x280/0x414)
(really_probe) from [<c058baf4>] (driver_probe_device+0x78/0x1c4)
(driver_probe_device) from [<c0589854>] (bus_for_each_drv+0x74/0xb8)
(bus_for_each_drv) from [<c058b48c>] (__device_attach+0xd4/0x16c)
(__device_attach) from [<c058a638>] (bus_probe_device+0x88/0x90)
(bus_probe_device) from [<c05871fc>] (device_add+0x3dc/0x62c)
(device_add) from [<c075ff10>] (of_platform_device_create_pdata+0x94/0xbc)
(of_platform_device_create_pdata) from [<c07600ec>] (of_platform_bus_create+0x1a8/0x4fc)
(of_platform_bus_create) from [<c0760150>] (of_platform_bus_create+0x20c/0x4fc)
(of_platform_bus_create) from [<c07605f0>] (of_platform_populate+0x84/0x118)
(of_platform_populate) from [<c0f3c964>] (of_platform_default_populate_init+0xa0/0xb8)
(of_platform_default_populate_init) from [<c01031f8>] (do_one_initcall+0x8c/0x404)
Provide a helper which clearly documents the usage of driver_override.
This will allow later to reuse the helper and reduce the amount of
duplicated code.
Convert the platform driver to use a new helper and make the
driver_override field const char (it is not modified by the core).
Bug: 95334746
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220419113435.246203-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 389190b254)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I1ef85ee1f3828e947adec4a45363d8434876aade
Fix some merging errors. Quells the following WARN() output:
Duplicate entry for capability 62
WARNING: CPU: 0 PID: 0 at arch/arm64/kernel/cpufeature.c:958 init_cpu_hwcaps_indirect_list_from_array+0x7c/0x98
Bug: 315739115
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I4e8798cc6395050a54222ec68432fae3c286dd87
CPU errata 2441007 (Cortex-A55) and 2441009 (Cortex-A510) are categorised
as "rare" by Arm and consequently the workaround is not intended to be
deployed in practice as the issue is not expected to occur in real-world
environments.
Given that the cost of the workaround, which issues additional broadcast
TLB invalidation requests, has been shown to impact kswapd significantly
on Pixel devices, disable the workaround following Arm's recommendation.
Bug: 306231846
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I39b6d9736cfa79827321151b45774f62c8d1a747
INFO: type 'struct fscrypt_info' changed
member 'u8 ci_data_unit_bits' was added
member 'u8 ci_data_units_per_block_bits' was added
type 'struct fscrypt_policy_v2' changed
member '__u8 log2_data_unit_size' was added
member changed from '__u8 __reserved[4]' to '__u8 __reserved[3]'
offset changed from 32 to 40
type changed from '__u8[4]' to '__u8[3]'
number of elements changed from 4 to 3
Bug: 299136786
Bug: 302588300
Change-Id: Idbbc2123961a41d395323c72cef67d94bdd17ab0
Signed-off-by: Eric Biggers <ebiggers@google.com>
Until now, fscrypt has always used the filesystem block size as the
granularity of file contents encryption. Two scenarios have come up
where a sub-block granularity of contents encryption would be useful:
1. Inline crypto hardware that only supports a crypto data unit size
that is less than the filesystem block size.
2. Support for direct I/O at a granularity less than the filesystem
block size, for example at the block device's logical block size in
order to match the traditional direct I/O alignment requirement.
(1) first came up with older eMMC inline crypto hardware that only
supports a crypto data unit size of 512 bytes. That specific case
ultimately went away because all systems with that hardware continued
using out of tree code and never actually upgraded to the upstream
inline crypto framework. But, now it's coming back in a new way: some
current UFS controllers only support a data unit size of 4096 bytes, and
there is a proposal to increase the filesystem block size to 16K.
(2) was discussed as a "nice to have" feature, though not essential,
when support for direct I/O on encrypted files was being upstreamed.
Still, the fact that this feature has come up several times does suggest
it would be wise to have available. Therefore, this patch implements it
by using one of the reserved bytes in fscrypt_policy_v2 to allow users
to select a sub-block data unit size. Supported data unit sizes are
powers of 2 between 512 and the filesystem block size, inclusively.
Support is implemented for both the FS-layer and inline crypto cases.
This patch focuses on the basic support for sub-block data units. Some
things are out of scope for this patch but may be addressed later:
- Supporting sub-block data units in combination with
FSCRYPT_POLICY_FLAG_IV_INO_LBLK_64, in most cases. Unfortunately this
combination usually causes data unit indices to exceed 32 bits, and
thus fscrypt_supported_policy() correctly disallows it. The users who
potentially need this combination are using f2fs. To support it, f2fs
would need to provide an option to slightly reduce its max file size.
- Supporting sub-block data units in combination with
FSCRYPT_POLICY_FLAG_IV_INO_LBLK_32. This has the same problem
described above, but also it will need special code to make DUN
wraparound still happen on a FS block boundary.
- Supporting use case (2) mentioned above. The encrypted direct I/O
code will need to stop requiring and assuming FS block alignment.
This won't be hard, but it belongs in a separate patch.
- Supporting this feature on filesystems other than ext4 and f2fs.
(Filesystems declare support for it via their fscrypt_operations.)
On UBIFS, sub-block data units don't make sense because UBIFS encrypts
variable-length blocks as a result of compression. CephFS could
support it, but a bit more work would be needed to make the
fscrypt_*_block_inplace functions play nicely with sub-block data
units. I don't think there's a use case for this on CephFS anyway.
Link: https://lore.kernel.org/r/20230925055451.59499-6-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Bug: 299136786
Bug: 302588300
(cherry picked from commit 5b11888471806edf699316d4dcb9b426caebbef2)
(Reworked this commit to not change struct fscrypt_operations and not
depend on other commits that changed struct fscrypt_operations. Also
resolved conflicts with the HW-wrapped key support. Also use pages
instead of folios, since older kernels don't have folios.)
Change-Id: Ic3dc56ef3f42d123f812e9037e2cc6f0b24bacc1
Signed-off-by: Eric Biggers <ebiggers@google.com>
Android has carried custom patches not allowing file-backed page
allocation from CMA area since it could cause CMA allocation
failure/slowness. However, Compaction could allow migrating
file-backed pages to CMA area so causes CMA allocation's trouble.
This patch checks whether there are file-backed migration source
pages or not in compaction. If there are, compaction allows only
MIGRATE_MOVABLE's pageblock, not MIGRATE_CMA's one for selecting
migration target pages(i.e., free pages).
[surenb: original patch reworked using compact_control_ext to avoid
breaking frozen ABI]
Bug: 207498240
Bug: 305594365
Change-Id: Ibf30eea6bf24aafa2a75a73cef6084b1c837bd06
Signed-off-by: Minchan Kim <minchan@google.com>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
[ Upstream commit 93995bf4af2c5a99e2a87f0cd5ce547d31eb7630 ]
The expired catchall element is not deactivated and removed from GC sync
path. This path holds mutex so just call nft_setelem_data_deactivate()
and nft_setelem_catchall_remove() before queueing the GC work.
Bug: 310691882
Fixes: 4a9e12ea7e ("netfilter: nft_set_pipapo: call nft_trans_gc_queue_sync() in catchall GC")
Reported-by: lonial con <kongln9170@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 13e2d49647)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Ic5d1d98fe5a749e759869f0789cbb77c4ab5e6c2
readpages will be triggered on the fuse fs in passthrough mode though
system calls like fadvise. If the daemon isn't aware of the file, this
will likely cause a hang.
For the moment, simply ignore fadvise in this situation
Bug: 301201239
Test: fuse_test, atest ScopedStorageDeviceTest both pass
Signed-off-by: Paul Lawrence <paullawrence@google.com>
(cherry picked from https://android-review.googlesource.com/q/commit:ac9071df3ba6715219a16a44d4711f041b0c25de)
Merged-In: I524a84aeeb1b1593e51264fcc37f7cfa66757168
Change-Id: I524a84aeeb1b1593e51264fcc37f7cfa66757168
Adding the following symbols:
- __traceiter_android_vh_ptep_clear_flush_young
- __tracepoint_android_vh_ptep_clear_flush_young
Bug: 312692863
Change-Id: I5e6232bb1121d3d59ea57380c7950412b1652208
Signed-off-by: Martin Liu <liumartin@google.com>
Add a vendor hook to be able to skip ptep tlb flush.
Bug: 312692863
Test: boot
Change-Id: Ifbc7a52111616d0542b866532a9bf82368e6c8f1
Signed-off-by: Martin Liu <liumartin@google.com>
We will need vendor hook of set_user_nice with lock to avoid race
condition.
Bug: 300872872
Change-Id: I24fc1e13cc6578dcc418d956a5146ad29ff76a56
Signed-off-by: Rick Yiu <rickyiu@google.com>
Vendor module code needs to ensure that pushes to the balance
callback queue are handled prior to releasing rq locks.
Export __balance_callbacks to facilitate this.
Bug: 241223356
Change-Id: I86a3f5cb6cc7b97d87bd2db3e11cb7a8d99d4aef
Signed-off-by: Stephen Dickey <quic_dickey@quicinc.com>
(cherry picked from commit a2f552f49c9084dcc48b2066888d06a324e34b98)
This structure is at the heart of the module support for pKVM. Add a
description to help anyone trying to create a module.
Bug: 312200309
Change-Id: Ie1d9043a6a94d15dd8ef25c6f0f8d442da26bc1f
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
(cherry picked from commit af85ead8ce)
It is possible that typec_register_partner() returns ERR_PTR on failure.
When port->partner is an error, a NULL pointer dereference may occur as
shown below.
[91222.095236][ T319] typec port0: failed to register partner (-17)
...
[91225.061491][ T319] Unable to handle kernel NULL pointer dereference
at virtual address 000000000000039f
[91225.274642][ T319] pc : tcpm_pd_data_request+0x310/0x13fc
[91225.274646][ T319] lr : tcpm_pd_data_request+0x298/0x13fc
[91225.308067][ T319] Call trace:
[91225.308070][ T319] tcpm_pd_data_request+0x310/0x13fc
[91225.308073][ T319] tcpm_pd_rx_handler+0x100/0x9e8
[91225.355900][ T319] kthread_worker_fn+0x178/0x58c
[91225.355902][ T319] kthread+0x150/0x200
[91225.355905][ T319] ret_from_fork+0x10/0x30
Add a check for port->partner to avoid dereferencing a NULL pointer.
Fixes: 5e1d4c49fb ("usb: typec: tcpm: Determine common SVDM Version")
Cc: stable@vger.kernel.org
Signed-off-by: Jimmy Hu <hhhuuu@google.com>
Link: https://lore.kernel.org/r/20231020012132.100960-1-hhhuuu@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 280207787
(cherry picked from commit 4987daf86c152ff882d51572d154ad12e4ff3a4b)
Change-Id: I609640ff70258b8fd0e7f9eaad9eb60db35ccfad
Signed-off-by: Kyle Tso <kyletso@google.com>
commit ff33299ec8 upstream.
Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors():
BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011
CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351
print_report mm/kasan/report.c:462 [inline]
kasan_report+0x11c/0x130 mm/kasan/report.c:572
read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
...
Allocated by task 758:
...
__do_kmalloc_node mm/slab_common.c:966 [inline]
__kmalloc+0x5e/0x190 mm/slab_common.c:979
kmalloc include/linux/slab.h:563 [inline]
kzalloc include/linux/slab.h:680 [inline]
usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887
usb_enumerate_device drivers/usb/core/hub.c:2407 [inline]
usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545
As analyzed by Khazhy Kumykov, the cause of this bug is a race between
read_descriptors() and hub_port_init(): The first routine uses a field
in udev->descriptor, not expecting it to change, while the second
overwrites it.
Prior to commit 45bf39f8df ("USB: core: Don't hold device lock while
reading the "descriptors" sysfs file") this race couldn't occur,
because the routines were mutually exclusive thanks to the device
locking. Removing that locking from read_descriptors() exposed it to
the race.
The best way to fix the bug is to keep hub_port_init() from changing
udev->descriptor once udev has been initialized and registered.
Drivers expect the descriptors stored in the kernel to be immutable;
we should not undermine this expectation. In fact, this change should
have been made long ago.
So now hub_port_init() will take an additional argument, specifying a
buffer in which to store the device descriptor it reads. (If udev has
not yet been initialized, the buffer pointer will be NULL and then
hub_port_init() will store the device descriptor in udev as before.)
This eliminates the data race responsible for the out-of-bounds read.
The changes to hub_port_init() appear more extensive than they really
are, because of indentation changes resulting from an attempt to avoid
writing to other parts of the usb_device structure after it has been
initialized. Similar changes should be made to the code that reads
the BOS descriptor, but that can be handled in a separate patch later
on. This patch is sufficient to fix the bug found by syzbot.
Bug: 290990909
Reported-and-tested-by: syzbot+18996170f8096c6174d0@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-usb/000000000000c0ffe505fe86c9ca@google.com/#r
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Khazhy Kumykov <khazhy@google.com>
Fixes: 45bf39f8df ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/b958b47a-9a46-4c22-a9f9-e42e42c31251@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 7fe9d87996)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Ia5e4a65cd5d895bf0d85a5aa5efa1c4d1368d069
commit de28e469da upstream.
The usb_get_device_descriptor() routine reads the device descriptor
from the udev device and stores it directly in udev->descriptor. This
interface is error prone, because the USB subsystem expects in-memory
copies of a device's descriptors to be immutable once the device has
been initialized.
The interface is changed so that the device descriptor is left in a
kmalloc-ed buffer, not copied into the usb_device structure. A
pointer to the buffer is returned to the caller, who is then
responsible for kfree-ing it. The corresponding changes needed in the
various callers are fairly small.
Bug: 290990909
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/d0111bb6-56c1-4f90-adf2-6cfe152f6561@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit eda9a29665)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I7c4be5b5dd06f7d5ba8aacad33ecf78f4a3b49e6
commit 85d07c5562 upstream.
In preparation for reworking the usb_get_device_descriptor() routine,
it is desirable to unite the two different code paths responsible for
initially determining endpoint 0's maximum packet size in a newly
discovered USB device. Making this determination presents a
chicken-and-egg sort of problem, in that the only way to learn the
maxpacket value is to get it from the device descriptor retrieved from
the device, but communicating with the device to retrieve a descriptor
requires us to know beforehand the ep0 maxpacket size.
In practice this problem is solved in two different ways, referred to
in hub.c as the "old scheme" and the "new scheme". The old scheme
(which is the approach recommended by the USB-2 spec) involves asking
the device to send just the first eight bytes of its device
descriptor. Such a transfer uses packets containing no more than
eight bytes each, and every USB device must have an ep0 maxpacket size
>= 8, so this should succeed. Since the bMaxPacketSize0 field of the
device descriptor lies within the first eight bytes, this is all we
need.
The new scheme is an imitation of the technique used in an early
Windows USB implementation, giving it the happy advantage of working
with a wide variety of devices (some of them at the time would not
work with the old scheme, although that's probably less true now). It
involves making an initial guess of the ep0 maxpacket size, asking the
device to send up to 64 bytes worth of its device descriptor (which is
only 18 bytes long), and then resetting the device to clear any error
condition that might have resulted from the guess being wrong. The
initial guess is determined by the connection speed; it should be
correct in all cases other than full speed, for which the allowed
values are 8, 16, 32, and 64 (in this case the initial guess is 64).
The reason for this patch is that the old- and new-scheme parts of
hub_port_init() use different code paths, one involving
usb_get_device_descriptor() and one not, for their initial reads of
the device descriptor. Since these reads have essentially the same
purpose and are made under essentially the same circumstances, this is
illogical. It makes more sense to have both of them use a common
subroutine.
This subroutine does basically what the new scheme's code did, because
that approach is more general than the one used by the old scheme. It
only needs to know how many bytes to transfer and whether or not it is
being called for the first iteration of a retry loop (in case of
certain time-out errors). There are two main differences from the
former code:
We initialize the bDescriptorType field of the transfer buffer
to 0 before performing the transfer, to avoid possibly
accessing an uninitialized value afterward.
We read the device descriptor into a temporary buffer rather
than storing it directly into udev->descriptor, which the old
scheme implementation used to do.
Since the whole point of this first read of the device descriptor is
to determine the bMaxPacketSize0 value, that is what the new routine
returns (or an error code). The value is stored in a local variable
rather than in udev->descriptor. As a side effect, this necessitates
moving a section of code that checks the bcdUSB field for SuperSpeed
devices until after the full device descriptor has been retrieved.
Bug: 290990909
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Oliver Neukum <oneukum@suse.com>
Link: https://lore.kernel.org/r/495cb5d4-f956-4f4a-a875-1e67e9489510@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 56c49a3328)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I2ffdb9ee11219fca6aeb2cda7867ea53fd6ca61c
When we use an async work queue to perform the function of pumping
usb requests to the usb controller, it is possible that amongst other
factors, thread scheduling affects at what cadence we're able to pump
requests. This could mean isoc usb requests miss their uframes - resulting
in video stream flickers on the host device.
To avoid this, we make the async_wq thread only produce isoc usb_requests
with uvc buffers encoded into them. The process of queueing to the
endpoint is done by the uvc_video_complete() handler. In case no
usb_requests are ready with encoded information, we just queue a zero
length request to the endpoint from the complete handler.
For bulk endpoints the async_wq thread still queues usb requests to the
endpoint.
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
Suggested-by: Avichal Rakesh <arakesh@google.com>
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20231120062026.3759463-1-jchowdhary@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 301915972
(cherry picked from commit 6acba0345b68772830582ca1ca369a2f45631275
https://kernel.googlesource.com/pub/scm/linux/kernel/git/gregkh/usb usb-next)
Change-Id: I5597cc29e9caec69e4f3575938d7d640857aaa28
Signed-off-by: Avichal Rakesh <arakesh@google.com>
Currently, the uvc gadget driver allocates all uvc_requests as one array
and deallocates them all when the video stream stops. This includes
de-allocating all the usb_requests associated with those uvc_requests.
This can lead to use-after-free issues if any of those de-allocated
usb_requests were still owned by the usb controller.
This is patch 2 of 2 in fixing the use-after-free issue. It adds a new
flag to uvc_video to track when frames and requests should be flowing.
When disabling the video stream, the flag is tripped and, instead
of de-allocating all uvc_requests and usb_requests, the gadget
driver only de-allocates those usb_requests that are currently
owned by it (as present in req_free). Other usb_requests are left
untouched until their completion handler is called which takes care
of freeing the usb_request and its corresponding uvc_request.
Now that uvc_video does not depends on uvc->state, this patch removes
unnecessary upates to uvc->state that were made to accommodate uvc_video
logic. This should ensure that uvc gadget driver never accidentally
de-allocates a usb_request that it doesn't own.
Link: https://lore.kernel.org/7cd81649-2795-45b6-8c10-b7df1055020d@google.com
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Suggested-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Tested-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: Avichal Rakesh <arakesh@google.com>
Link: https://lore.kernel.org/r/20231109004104.3467968-4-arakesh@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 296925310
(cherry picked from commit da324ffce34c521b239f319d4051260444a3eb4a
https://kernel.googlesource.com/pub/scm/linux/kernel/git/gregkh/usb usb-next)
Change-Id: Ib0378394dc20e894507f60c70f71c579d046cd7a
Signed-off-by: Avichal Rakesh <arakesh@google.com>
Add trace hook so modules can track thermal changes to process
vendor value adds.
Bug: 203763121
Change-Id: I5c54b313d3c92c0514f18b07797dd20c9c6f5161
Signed-off-by: Shaleen Agrawal <shalagra@codeaurora.org>
Update vendor hook symbols for lenovo
Bug: 312392542
Change-Id: I1e596bee5a7c776ab4c2af12fd473bf0e6fb2db8
Signed-off-by: vincent wang <vincentwang3@lenovo.com>
In this vendor hook, we can register the energy model before sending the
notification to avoid pd_init failure for some clusters.
more detail info about pd_init failure, pls refer to the link:
https://lore.kernel.org/lkml/20230118044733.29391-1-bhuwz@163.com/T/
But the change patch cannot be submitted upstream due to differences in the
cpufreq code, the failure only appears on the aosp kernel.
Bug: 312392542
Change-Id: Ied4c72d73083d794ad6d8af1eb305be4fb382de3
Signed-off-by: vincent wang <vincentwang3@lenovo.com>
Currently, uinput doesn't use the input_set_timestamp API, so any
event injected using uinput is not accurately timestamped in terms of
measuring when the actual event happened. Hence, call the
input_set_timestamp API from uinput in order to provide a more
accurate sense of time for the event. Propagate only the timestamps
which are a) positive, b) within a pre-defined offset (10 secs) from
the current time, and c) not in the future.
Bug: 271946580
Bug: 277040837
Change-Id: I928be61d0114b78e2098995ee49eeb0376bef2a3
(cherry picked from commit 3a2df60200https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git master)
Signed-off-by: Biswarup Pal <biswarupp@google.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Siarhei Vishniakou <svv@google.com>
Link: https://lore.kernel.org/r/20230427000152.1407471-1-biswarupp@google.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
(cherry picked from commit ee1f5fc55cc7bf1bca78edbb8a1f9d989d4ea03e)
Carlos Llamas