mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-10-07 04:12:04 -04:00
897,966 commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Takashi Iwai
|
e55bdca2cb |
UPSTREAM: media: dvb-core: Fix UAF due to refcount races at releasing
commit fd3d91ab1c6ab0628fe642dd570b56302c30a792 upstream. The dvb-core tries to sync the releases of opened files at dvb_dmxdev_release() with two refcounts: dvbdev->users and dvr_dvbdev->users. A problem is present in those two syncs: when yet another dvb_demux_open() is called during those sync waits, dvb_demux_open() continues to process even if the device is being closed. This includes the increment of the former refcount, resulting in the leftover refcount after the sync of the latter refcount at dvb_dmxdev_release(). It ends up with use-after-free, since the function believes that all usages were gone and releases the resources. This patch addresses the problem by adding the check of dmxdev->exit flag at dvb_demux_open(), just like dvb_dvr_open() already does. With the exit flag check, the second call of dvb_demux_open() fails, hence the further corruption can be avoided. Also for avoiding the races of the dmxdev->exit flag reference, this patch serializes the dmxdev->exit set up and the sync waits with the dmxdev->mutex lock at dvb_dmxdev_release(). Without the mutex lock, dvb_demux_open() (or dvb_dvr_open()) may run concurrently with dvb_dmxdev_release(), which allows to skip the exit flag check and continue the open process that is being closed. CVE-2022-41218 is assigned to those bugs above. Bug: 248356119 Reported-by: Hyunwoo Kim <imv4bel@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/20220908132754.30532-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Lee Jones <joneslee@google.com> Change-Id: I5a0dd4444ca25d07a050dcb07609c7c7ccf658af |
||
Srinivasarao Pathipati
|
d72fdcc709 |
ANDROID: abi_gki_aarch64_qcom: Add hrtimer_sleeper_start_expires
The commit
|
||
Clement Lecigne
|
b63a7aff8a |
UPSTREAM: ALSA: pcm: Move rwsem lock inside snd_ctl_elem_read to prevent UAF
[ Note: this is a fix that works around the bug equivalently as the
two upstream commits:
1fa4445f9adf ("ALSA: control - introduce snd_ctl_notify_one() helper")
56b88b50565c ("ALSA: pcm: Move rwsem lock inside snd_ctl_elem_read to prevent UAF")
but in a simpler way to fit with older stable trees -- tiwai ]
Add missing locking in ctl_elem_read_user/ctl_elem_write_user which can be
easily triggered and turned into an use-after-free.
Example code paths with SNDRV_CTL_IOCTL_ELEM_READ:
64-bits:
snd_ctl_ioctl
snd_ctl_elem_read_user
[takes controls_rwsem]
snd_ctl_elem_read [lock properly held, all good]
[drops controls_rwsem]
32-bits (compat):
snd_ctl_ioctl_compat
snd_ctl_elem_write_read_compat
ctl_elem_write_read
snd_ctl_elem_read [missing lock, not good]
CVE-2023-0266 was assigned for this issue.
Bug: 265303544
Signed-off-by: Clement Lecigne <clecigne@google.com>
Cc: stable@kernel.org # 5.12 and older
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit df02234e6b87d2a9a82acd3198e44bdeff8488c7)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Ibe891cdcb9eaf0dfc7bd771689c85c32b5c0d1f7
|
||
Lee Jones
|
d0f21836e3 |
ANDROID: Revert "tracing/ring-buffer: Have polling block on watermark"
This reverts commit
|
||
Treehugger Robot
|
5a8d108cc6 | Merge "Merge tag 'android11-5.4.226_r00' into android11-5.4" into android11-5.4 | ||
John Keeping
|
c429b23536 |
UPSTREAM: usb: gadget: f_hid: fix f_hidg lifetime vs cdev
[ Upstream commit 89ff3dfac604614287ad5aad9370c3f984ea3f4b ]
The embedded struct cdev does not have its lifetime correctly tied to
the enclosing struct f_hidg, so there is a use-after-free if /dev/hidgN
is held open while the gadget is deleted.
This can readily be replicated with libusbgx's example programs (for
conciseness - operating directly via configfs is equivalent):
gadget-hid
exec 3<> /dev/hidg0
gadget-vid-pid-remove
exec 3<&-
Pull the existing device up in to struct f_hidg and make use of the
cdev_device_{add,del}() helpers. This changes the lifetime of the
device object to match struct f_hidg, but note that it is still added
and deleted at the same time.
Bug: 176850153
Fixes:
|
||
Maxim Devaev
|
28b985f146 |
UPSTREAM: usb: gadget: f_hid: optional SETUP/SET_REPORT mode
[ Upstream commit d7428bc26fc767942c38d74b80299bcd4f01e7cb ]
f_hid provides the OUT Endpoint as only way for receiving reports
from the host. SETUP/SET_REPORT method is not supported, and this causes
a number of compatibility problems with various host drivers, especially
in the case of keyboard emulation using f_hid.
- Some hosts do not support the OUT Endpoint and ignore it,
so it becomes impossible for the gadget to receive a report
from the host. In the case of a keyboard, the gadget loses
the ability to receive the status of the LEDs.
- Some BIOSes/UEFIs can't work with HID devices with the OUT Endpoint
at all. This may be due to their bugs or incomplete implementation
of the HID standard.
For example, absolutely all Apple UEFIs can't handle the OUT Endpoint
if it goes after IN Endpoint in the descriptor and require the reverse
order (OUT, IN) which is a violation of the standard.
Other hosts either do not initialize gadgets with a descriptor
containing the OUT Endpoint completely (like some HP and DELL BIOSes
and embedded firmwares like on KVM switches), or initialize them,
but will not poll the IN Endpoint.
This patch adds configfs option no_out_endpoint=1 to disable
the OUT Endpoint and allows f_hid to receive reports from the host
via SETUP/SET_REPORT.
Previously, there was such a feature in f_hid, but it was replaced
by the OUT Endpoint [1] in the commit
|
||
Steve Muckle
|
15a5e4ad4f |
ANDROID: add TEST_MAPPING for net/, include/net
Run CtsNetTestCases in presubmit for changes in net/ and include/net/. Bug: 186664401 Change-Id: I3cf942bd0418ad55a6559d6933927b0da86da595 Signed-off-by: Steve Muckle <smuckle@google.com> (cherry picked from commit 55415d7022a8835d8979e09a74da3df29c9091ec) |
||
Jialiang Wang
|
f5b4a7be57 |
UPSTREAM: nfp: fix use-after-free in area_cache_get()
commit 02e1a114fdb71e59ee6770294166c30d437bf86a upstream. area_cache_get() is used to distribute cache->area and set cache->id, and if cache->id is not 0 and cache->area->kref refcount is 0, it will release the cache->area by nfp_cpp_area_release(). area_cache_get() set cache->id before cpp->op->area_init() and nfp_cpp_area_acquire(). But if area_init() or nfp_cpp_area_acquire() fails, the cache->id is is already set but the refcount is not increased as expected. At this time, calling the nfp_cpp_area_release() will cause use-after-free. To avoid the use-after-free, set cache->id after area_init() and nfp_cpp_area_acquire() complete successfully. Note: This vulnerability is triggerable by providing emulated device equipped with specified configuration. BUG: KASAN: use-after-free in nfp6000_area_init (drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c:760) Write of size 4 at addr ffff888005b7f4a0 by task swapper/0/1 Call Trace: <TASK> nfp6000_area_init (drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c:760) area_cache_get.constprop.8 (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:884) Allocated by task 1: nfp_cpp_area_alloc_with_name (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:303) nfp_cpp_area_cache_add (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:802) nfp6000_init (drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c:1230) nfp_cpp_from_operations (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:1215) nfp_pci_probe (drivers/net/ethernet/netronome/nfp/nfp_main.c:744) Freed by task 1: kfree (mm/slub.c:4562) area_cache_get.constprop.8 (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:873) nfp_cpp_read (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:924 drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:973) nfp_cpp_readl (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cpplib.c:48) Bug: 254471126 Signed-off-by: Jialiang Wang <wangjialiang0806@163.com> Reviewed-by: Yinjun Zhang <yinjun.zhang@corigine.com> Acked-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20220810073057.4032-1-wangjialiang0806@163.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Lee Jones <joneslee@google.com> Change-Id: Iad626deee45edc6bdf7a095d3de1defc5c6ad996 Signed-off-by: Lee Jones <joneslee@google.com> |
||
Linus Torvalds
|
5a9d35543f |
UPSTREAM: proc: avoid integer type confusion in get_proc_long
commit e6cfaf34be9fcd1a8285a294e18986bfc41a409c upstream. proc_get_long() is passed a size_t, but then assigns it to an 'int' variable for the length. Let's not do that, even if our IO paths are limited to MAX_RW_COUNT (exactly because of these kinds of type errors). So do the proper test in the rigth type. Bug: 261488859 Reported-by: Kyle Zeng <zengyhkyle@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Lee Jones <joneslee@google.com> Change-Id: I75a06fe777c638b82ef3fbd1346e985065ab17f2 Signed-off-by: Lee Jones <joneslee@google.com> |
||
|
Linus Torvalds
|
cffda199e1 |
UPSTREAM: proc: proc_skip_spaces() shouldn't think it is working on C strings
commit bce9332220bd677d83b19d21502776ad555a0e73 upstream. proc_skip_spaces() seems to think it is working on C strings, and ends up being just a wrapper around skip_spaces() with a really odd calling convention. Instead of basing it on skip_spaces(), it should have looked more like proc_skip_char(), which really is the exact same function (except it skips a particular character, rather than whitespace). So use that as inspiration, odd coding and all. Now the calling convention actually makes sense and works for the intended purpose. Bug: 261488859 Reported-and-tested-by: Kyle Zeng <zengyhkyle@gmail.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Lee Jones <joneslee@google.com> Change-Id: Ie21bf20f3b92b78c5f31093b354a77b4133810e7 Signed-off-by: Lee Jones <joneslee@google.com> |
||
|
Lee Jones
|
e418b27c0c |
ANDROID: usb: f_accessory: Check buffer size when initialised via composite
When communicating with accessory devices via USBFS, the initialisation call-stack looks like: ConfigFS > Gadget ConfigFS > UDC > Gadget ConfigFS > Composite Eventually ending up in composite_dev_prepare() where memory for the data buffer is allocated and initialised. The default size used for the allocation is USB_COMP_EP0_BUFSIZ (4k). When handling bulk transfers, acc_ctrlrequest() needs to be able to handle buffers up to BULK_BUFFER_SIZE (16k). Instead of adding new generic attributes to 'struct usb_request' to track the size of the allocated buffer, we can simply split off the affected thread of execution to travel via a knowledgeable abstracted function acc_ctrlrequest_composite() where we can complete the necessary specific checks. Bug: 264029575 Signed-off-by: Lee Jones <joneslee@google.com> Change-Id: Ia1280f85499621d3fa57f7262b4a2c80f4be7773 Signed-off-by: Lee Jones <joneslee@google.com> |
||
Greg Kroah-Hartman
|
98d8600199 |
Merge tag 'android11-5.4.226_r00' into android11-5.4
This is the merge of the upstream LTS release of 5.4.226 into the android11-5.4 branch. It contains the following commits: |
||
Minchan Kim
|
8912db2538 |
BACKPORT: mm: don't be stuck to rmap lock on reclaim path
The rmap locks(i_mmap_rwsem and anon_vma->root->rwsem) could be contended
under memory pressure if processes keep working on their vmas(e.g., fork,
mmap, munmap). It makes reclaim path stuck. In our real workload traces,
we see kswapd is waiting the lock for 300ms+(worst case, a sec) and it
makes other processes entering direct reclaim, which were also stuck on
the lock.
This patch makes lru aging path try_lock mode like shink_page_list so the
reclaim context will keep working with next lru pages without being stuck.
if it found the rmap lock contended, it rotates the page back to head of
lru in both active/inactive lrus to make them consistent behavior, which
is basic starting point rather than adding more heristic.
Since this patch introduces a new "contended" field as out-param along
with try_lock in-param in rmap_walk_control, it's not immutable any longer
if the try_lock is set so remove const keywords on rmap related functions.
Since rmap walking is already expensive operation, I doubt the const
would help sizable benefit( And we didn't have it until 5.17).
In a heavy app workload in Android, trace shows following statistics. It
almost removes rmap lock contention from reclaim path.
Martin Liu reported:
Before:
max_dur(ms) min_dur(ms) max-min(dur)ms avg_dur(ms) sum_dur(ms) count blocked_function
1632 0 1631 151.542173 31672 209 page_lock_anon_vma_read
601 0 601 145.544681 28817 198 rmap_walk_file
After:
max_dur(ms) min_dur(ms) max-min(dur)ms avg_dur(ms) sum_dur(ms) count blocked_function
NaN NaN NaN NaN NaN 0.0 NaN
0 0 0 0.127645 1 12 rmap_walk_file
[minchan@kernel.org: add comment, per Matthew]
Link: https://lkml.kernel.org/r/YnNqeB5tUf6LZ57b@google.com
Link: https://lkml.kernel.org/r/20220510215423.164547-1-minchan@kernel.org
Signed-off-by: Minchan Kim <minchan@kernel.org>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: John Dias <joaodias@google.com>
Cc: Tim Murray <timmurray@google.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: Martin Liu <liumartin@google.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Matthew Wilcox <willy@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Conflicts:
folio->page
(cherry picked from commit 6d4675e601357834dadd2ba1d803f6484596015c)
Bug: 239681156
Bug: 252333201
Bug: 265247508
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: I0c63e0291120c8a1b5f2d83b8a7b210cb56c27a2
Signed-off-by: chenxin <chenxinxin@xiaomi.corp-partner.google.com>
Signed-off-by: guchongchong <guchongchong@xiaomi.corp-partner.google.com>
(cherry picked from commit a0eae55f26a0cbdd828db226592093ad2142889c)
|
||
A. Cody Schuffelen
|
a69a8cd3c5 |
ANDROID: Add more hvc devices for virtio-console.
This allows creating more TTY devices bound to virtio-console devices. Bug: 170149708 Test: ls /dev/hvc* on a cuttlefish device Change-Id: Id07c25bded35dac5d17736731bfd8b8f4f1d463b Signed-off-by: A. Cody Schuffelen <schuffelen@google.com> |
||
Roderick Colenbrander
|
7b7c361b98 |
UPSTREAM: HID: playstation: support updated DualSense rumble mode.
Newer DualSense firmware supports a revised classic rumble mode, which feels more similar to rumble as supported on previous PlayStation controllers. It has been made the default on PlayStation and non-PlayStation devices now (e.g. iOS and Windows). Default to this new mode when supported. Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20221010212313.78275-4-roderick.colenbrander@sony.com Bug: 260685629 (cherry picked from commit 9fecab247ed15e6145c126fc56ee1e89860741a7) Change-Id: Icd330111a4d1b1e76a04cd11c623d0982ce3d66f Signed-off-by: Farid Chahla <farid.chahla@sony.com> |
||
|
Roderick Colenbrander
|
ff79b92f34 |
UPSTREAM: HID: playstation: add initial DualSense Edge controller support
Provide initial support for the DualSense Edge controller. The brings support up to the level of the original DualSense, but won't yet provide support for new features (e.g. reprogrammable buttons). Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com> CC: stable@vger.kernel.org Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20221010212313.78275-3-roderick.colenbrander@sony.com Bug: 260685629 (cherry picked from commit b8a968efab301743fd659b5649c5d7d3e30e63a6) Change-Id: I5b95de806e823085d1144f016d8cfd76e4a933ef Signed-off-by: Farid Chahla <farid.chahla@sony.com> |
||
|
Roderick Colenbrander
|
9c127a4a06 |
UPSTREAM: HID: playstation: stop DualSense output work on remove.
Ensure we don't schedule any new output work on removal and wait for any existing work to complete. If we don't do this e.g. rumble work can get queued during deletion and we trigger a kernel crash. Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com> CC: stable@vger.kernel.org Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20221010212313.78275-2-roderick.colenbrander@sony.com Bug: 260685629 (cherry picked from commit 182934a1e93b17f4edf71f4fcc8d19b19a6fe67a) Change-Id: I40cadfde5765cdabf45def929860258d6019bf10 Signed-off-by: Farid Chahla <farid.chahla@sony.com> |
||
Greg Kroah-Hartman
|
b32bdd3e88 |
UPSTREAM: HID: playstation: convert to use dev_groups
There is no need for a driver to individually add/create device groups, the driver core will do it automatically for you. Convert the hid-playstation driver to use the dev_groups pointer instead of manually calling the driver core to create the group and have it be cleaned up later on by the devm core. Cc: Roderick Colenbrander <roderick.colenbrander@sony.com> Cc: Jiri Kosina <jikos@kernel.org> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: linux-input@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Roderick Colenbrander <roderick.colenbrander@sony.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Bug: 260685629 (cherry picked from commit b4a9af9be628e4f9d09997e0bdef30f6718e88ec) Change-Id: I516a1b0ef7f4f8545e0c1b9485b49879dd7a3136 Signed-off-by: Farid Chahla <farid.chahla@sony.com> |
||
Jiri Kosina
|
c1ac1f8001 |
UPSTREAM: HID: playstation: fix return from dualsense_player_led_set_brightness()
brightness_set_blocking() callback expects function returning int. This fixes the follwoing build failure: drivers/hid/hid-playstation.c: In function ‘dualsense_player_led_set_brightness’: drivers/hid/hid-playstation.c:885:1: error: no return statement in function returning non-void [-Werror=return-type] } ^ Signed-off-by: Jiri Kosina <jkosina@suse.cz> Bug: 260685629 (cherry picked from commit 3c92cb4cb60c71b574e47108ead8b6f0470850db) Change-Id: Id16b960826a26ac22c1a14572444f9af29689ed6 Signed-off-by: Farid Chahla <farid.chahla@sony.com> |
||
|
Roderick Colenbrander
|
d44545535e |
UPSTREAM: HID: playstation: expose DualSense player LEDs through LED class.
The DualSense player LEDs were so far not adjustable from user-space. This patch exposes each LED individually through the LED class. Each LED uses the new 'player' function resulting in a name like: 'inputX:white:player-1' for the first LED. Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Bug: 260685629 (cherry picked from commit 8c0ab553b072025530308f74b2c0223ec50dffe5) Change-Id: I49c699a99b0b8a7bb7980560e3ea7a12faf646aa Signed-off-by: Farid Chahla <farid.chahla@sony.com> |
||
|
Roderick Colenbrander
|
07dd46d289 |
BACKPORT: leds: add new LED_FUNCTION_PLAYER for player LEDs for game controllers.
Player LEDs are commonly found on game controllers from Nintendo and Sony to indicate a player ID across a number of LEDs. For example, "Player 2" might be indicated as "-x--" on a device with 4 LEDs where "x" means on. This patch introduces LED_FUNCTION_PLAYER1-5 defines to properly indicate player LEDs from the kernel. Until now there was no good standard, which resulted in inconsistent behavior across xpad, hid-sony, hid-wiimote and other drivers. Moving forward new drivers should use LED_FUNCTION_PLAYERx. Note: management of Player IDs is left to user space, though a kernel driver may pick a default value. Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Bug: 260685629 (cherry picked from commit 61177c088a57bed259122f3c7bc6d61984936a12) [Farid: Fixed minor conflict due to skipped commits outside scope of hid-playstation] Change-Id: I696f62cda377be1523e74e92b66b28f3c0716c43 Signed-off-by: Farid Chahla <farid.chahla@sony.com> |
||
|
Roderick Colenbrander
|
f91c45c176 |
UPSTREAM: HID: playstation: expose DualSense lightbar through a multi-color LED.
The DualSense lightbar has so far been supported, but it was not yet adjustable from user space. This patch exposes it through a multi-color LED. Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Bug: 260685629 (cherry picked from commit fc97b4d6a1a6d418fd4053fd7716eca746fdd163) Change-Id: I48204113da804b13ad5bed2f651a5826ab5a86f7 Signed-off-by: Farid Chahla <farid.chahla@sony.com> |
||
Gene Chen
|
749207d940 |
UPSTREAM: leds: flash: Fix multicolor no-ops registration by return 0
Fix multicolor no-ops registration by return 0, and move the same registration functions outside of #ifdef block. Signed-off-by: Gene Chen <gene_chen@richtek.com> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by: Pavel Machek <pavel@ucw.cz> Bug: 260685629 (cherry picked from commit 6039b7e87be0b350a5f8fc135adfb5d1f4ba66ad) Change-Id: Ieb8cace2978f61bd2de5c576e851987c6ba31e2c Signed-off-by: Farid Chahla <farid.chahla@sony.com> |
||
Dan Murphy
|
3e667a0854 |
UPSTREAM: leds: multicolor: Introduce a multicolor class definition
Introduce a multicolor class that groups colored LEDs within a LED node. The multicolor class groups monochrome LEDs and allows controlling two aspects of the final combined color: hue and lightness. The former is controlled via the intensity file and the latter is controlled via brightness file. Signed-off-by: Dan Murphy <dmurphy@ti.com> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by: Pavel Machek <pavel@ucw.cz> [squashed leds: multicolor: Fix camel case in documentation in] Bug: 260685629 (cherry picked from commit 55d5d3b46b08a4dc0b05343d24640744e7430ed7) Change-Id: Ib1f41d74ace8e3a9c1071d52202c8d8b70a912e0 Signed-off-by: Farid Chahla <farid.chahla@sony.com> |
||
Farid Chahla
|
0b5ee17e7d |
ANDROID: GKI: enable mulitcolor-led
To enable newer version of DualSense driver, i.e. hid-playstation, we need to set LEDS_CLASS_MULTICOLOR to "y". Bug: 260685629 Change-Id: I52b0b1b6a061457e009b62a6bd6b66a91c8c37a2 Signed-off-by: Farid Chahla <farid.chahla@sony.com> |
||
Lee Jones
|
0ce03d1655 |
BACKPORT: Kconfig.debug: provide a little extra FRAME_WARN leeway when KASAN is enabled
[ Upstream commit 152fe65f300e1819d59b80477d3e0999b4d5d7d2 ] When enabled, KASAN enlarges function's stack-frames. Pushing quite a few over the current threshold. This can mainly be seen on 32-bit architectures where the present limit (when !GCC) is a lowly 1024-Bytes. Bug: 261962742 Link: https://lkml.kernel.org/r/20221125120750.3537134-3-lee@kernel.org Signed-off-by: Lee Jones <lee@kernel.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@gmail.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Leo Li <sunpeng.li@amd.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: "Pan, Xinhui" <Xinhui.Pan@amd.com> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Tom Rix <trix@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Change-Id: I505a5187220b426fe49c0f15bf1704198082f63d Signed-off-by: Lee Jones <joneslee@google.com> |
||
|
Greg Kroah-Hartman
|
94bdbb0042 |
Revert "mmc: sdhci: Fix voltage switch delay"
This reverts commit
|
||
|
Greg Kroah-Hartman
|
b0e3bda187 |
ANDROID: gki_defconfig: add CONFIG_FUNCTION_ERROR_INJECTION
Commit |
||
|
Greg Kroah-Hartman
|
39c4c9c65c |
This is the 5.4.226 stable release
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmORuw8ACgkQONu9yGCS
aT4qeRAAjtp+p7ECcaXqZ4vHIka9IGcwRhjWbeB/xFCOgKKbOOLmZP9Cql1pJdEp
grdcp/tjNAwi1ec80+G/3AaAWqGRFHYi/Tboe+ZSHIp4Oot78fSclMp6lCMh/bzC
eR6niNNNlrEUC/lj0h5lWRJvQd6MK4orSCOCybeJ+HRmrLcm1pGSuJmssHoBn7Xk
JHg3RR5OW4BU4UHQHmcJfeH+J5zfNH0ygu1L3MRqzoINWUJ7PtSrIdR5xCm/4ibr
oyOH0nenC3hkOM4atui/92dX3HsNxazuA51Ch0AANFRiKYjJBIXMitapi1BvpqfB
Ny1I95j37Tuys4OQhJhNlbvHgxdNmouEHH06SwY8+yaU6LPkrFtdD0AxIDofakBZ
Npy9AkYmvj14ARAeyqzswxSQGWuuvlDjJR3dId/kIuP8wcRcNWsrFefHs0YZxhjn
o0LKmpkw5QgjW7Gh8TKEdl4saAXZwLXV00gHN9DD6UOr4eYNHtBHUJg6zMN5aR19
Dco+UTJj1NlmlEBDP6pFp9LTAcTsjVh6FVpX+uMRs18+kXS3SxzPgB9qEwjerU5m
HA0pzc+BgZqHpu3LhkbC4JfGNJ9fHnVZe6fT6/kTt3SiaEtLx8JKvH6VsCHVgEv6
whY3hlS4bWII8Jey0ZS8BtyKJiku3zfGDXAQ3rpwGbX1ddDn+d8=
=qI32
-----END PGP SIGNATURE-----
Merge 5.4.226 into android11-5.4-lts
Changes in 5.4.226
wifi: mac80211: fix memory free error when registering wiphy fail
wifi: mac80211_hwsim: fix debugfs attribute ps with rc table support
audit: fix undefined behavior in bit shift for AUDIT_BIT
wifi: mac80211: Fix ack frame idr leak when mesh has no route
spi: stm32: fix stm32_spi_prepare_mbr() that halves spi clk for every run
drm: panel-orientation-quirks: Add quirk for Acer Switch V 10 (SW5-017)
block, bfq: fix null pointer dereference in bfq_bio_bfqg()
arm64/syscall: Include asm/ptrace.h in syscall_wrapper header.
RISC-V: vdso: Do not add missing symbols to version section in linker script
MIPS: pic32: treat port as signed integer
af_key: Fix send_acquire race with pfkey_register
ARM: dts: am335x-pcm-953: Define fixed regulators in root node
ASoC: sgtl5000: Reset the CHIP_CLK_CTRL reg on remove
regulator: core: fix kobject release warning and memory leak in regulator_register()
regulator: core: fix UAF in destroy_regulator()
bus: sunxi-rsb: Support atomic transfers
tee: optee: fix possible memory leak in optee_register_device()
ARM: dts: at91: sam9g20ek: enable udc vbus gpio pinctrl
net: liquidio: simplify if expression
nfc/nci: fix race with opening and closing
net: pch_gbe: fix potential memleak in pch_gbe_tx_queue()
9p/fd: fix issue of list_del corruption in p9_fd_cancel()
ARM: mxs: fix memory leak in mxs_machine_init()
net/mlx4: Check retval of mlx4_bitmap_init
net/qla3xxx: fix potential memleak in ql3xxx_send()
net: pch_gbe: fix pci device refcount leak while module exiting
nfp: add port from netdev validation for EEPROM access
Drivers: hv: vmbus: fix double free in the error path of vmbus_add_channel_work()
Drivers: hv: vmbus: fix possible memory leak in vmbus_device_register()
net/mlx5: Fix FW tracer timestamp calculation
tipc: set con sock in tipc_conn_alloc
tipc: add an extra conn_get in tipc_conn_alloc
tipc: check skb_linearize() return value in tipc_disc_rcv()
xfrm: Fix ignored return value in xfrm6_init()
NFC: nci: fix memory leak in nci_rx_data_packet()
regulator: twl6030: re-add TWL6032_SUBCLASS
bnx2x: fix pci device refcount leak in bnx2x_vf_is_pcie_pending()
dccp/tcp: Reset saddr on failure after inet6?_hash_connect().
s390/dasd: fix no record found for raw_track_access
nfc: st-nci: fix incorrect validating logic in EVT_TRANSACTION
nfc: st-nci: fix memory leaks in EVT_TRANSACTION
net: thunderx: Fix the ACPI memory leak
s390/crashdump: fix TOD programmable field size
lib/vdso: use "grep -E" instead of "egrep"
usb: dwc3: exynos: Fix remove() function
arm64: dts: rockchip: lower rk3399-puma-haikou SD controller clock frequency
iio: light: apds9960: fix wrong register for gesture gain
iio: core: Fix entry not deleted when iio_register_sw_trigger_type() fails
init/Kconfig: fix CC_HAS_ASM_GOTO_TIED_OUTPUT test with dash
nios2: add FORCE for vmlinuz.gz
iio: ms5611: Simplify IO callback parameters
iio: pressure: ms5611: fixed value compensation bug
ceph: do not update snapshot context when there is no new snapshot
ceph: avoid putting the realm twice when decoding snaps fails
firmware: google: Release devices before unregistering the bus
firmware: coreboot: Register bus in module init
nilfs2: fix nilfs_sufile_mark_dirty() not set segment usage as dirty
gcov: clang: fix the buffer overflow issue
Input: synaptics - switch touchpad on HP Laptop 15-da3001TU to RMI mode
ASoC: Intel: bytcht_es8316: Add quirk for the Nanote UMPC-01
serial: 8250: 8250_omap: Avoid RS485 RTS glitch on ->set_termios()
xen/platform-pci: add missing free_irq() in error path
platform/x86: asus-wmi: add missing pci_dev_put() in asus_wmi_set_xusb2pr()
platform/x86: acer-wmi: Enable SW_TABLET_MODE on Switch V 10 (SW5-017)
platform/x86: hp-wmi: Ignore Smart Experience App event
tcp: configurable source port perturb table size
net: usb: qmi_wwan: add Telit 0x103a composition
dm integrity: flush the journal on suspend
binder: avoid potential data leakage when copying txn
binder: read pre-translated fds from sender buffer
binder: defer copies of pre-patched txn data
binder: fix pointer cast warning
binder: Address corner cases in deferred copy and fixup
binder: Gracefully handle BINDER_TYPE_FDA objects with num_fds=0
btrfs: free btrfs_path before copying root refs to userspace
btrfs: free btrfs_path before copying fspath to userspace
btrfs: free btrfs_path before copying subvol info to userspace
btrfs: sysfs: normalize the error handling branch in btrfs_init_sysfs()
drm/amd/dc/dce120: Fix audio register mapping, stop triggering KASAN
drm/amdgpu: always register an MMU notifier for userptr
drm/i915: fix TLB invalidation for Gen12 video and compute engines
fuse: lock inode unconditionally in fuse_fallocate()
btrfs: free btrfs_path before copying inodes to userspace
spi: spi-imx: Fix spi_bus_clk if requested clock is higher than input clock
btrfs: move QUOTA_ENABLED check to rescan_should_stop from btrfs_qgroup_rescan_worker
drm/amdgpu: update drm_display_info correctly when the edid is read
drm/amdgpu: Partially revert "drm/amdgpu: update drm_display_info correctly when the edid is read"
btrfs: qgroup: fix sleep from invalid context bug in btrfs_qgroup_inherit()
iio: health: afe4403: Fix oob read in afe4403_read_raw
iio: health:
|
||
|
Greg Kroah-Hartman
|
316cdfc48d |
Linux 5.4.226
Link: https://lore.kernel.org/r/20221205190808.733996403@linuxfoundation.org Tested-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Allen Pais <apais@linux.microsoft.com> Link: https://lore.kernel.org/r/20221206124054.310184563@linuxfoundation.org Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Allen Pais <apais@linux.microsoft.com> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Hulk Robot <hulkrobot@huawei.com> Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
||
Jann Horn
|
3ab84e8913 |
ipc/sem: Fix dangling sem_array access in semtimedop race
[ Upstream commit b52be557e24c47286738276121177a41f54e3b83 ]
When __do_semtimedop() goes to sleep because it has to wait for a
semaphore value becoming zero or becoming bigger than some threshold, it
links the on-stack sem_queue to the sem_array, then goes to sleep
without holding a reference on the sem_array.
When __do_semtimedop() comes back out of sleep, one of two things must
happen:
a) We prove that the on-stack sem_queue has been disconnected from the
(possibly freed) sem_array, making it safe to return from the stack
frame that the sem_queue exists in.
b) We stabilize our reference to the sem_array, lock the sem_array, and
detach the sem_queue from the sem_array ourselves.
sem_array has RCU lifetime, so for case (b), the reference can be
stabilized inside an RCU read-side critical section by locklessly
checking whether the sem_queue is still connected to the sem_array.
However, the current code does the lockless check on sem_queue before
starting an RCU read-side critical section, so the result of the
lockless check immediately becomes useless.
Fix it by doing rcu_read_lock() before the lockless check. Now RCU
ensures that if we observe the object being on our queue, the object
can't be freed until rcu_read_unlock().
This bug is only hittable on kernel builds with full preemption support
(either CONFIG_PREEMPT or PREEMPT_DYNAMIC with preempt=full).
Fixes:
|
||
|
Linus Torvalds
|
210f96fb7e |
v4l2: don't fall back to follow_pfn() if pin_user_pages_fast() fails
commit 6647e76ab623b2b3fb2efe03a86e9c9046c52c33 upstream.
The V4L2_MEMORY_USERPTR interface is long deprecated and shouldn't be
used (and is discouraged for any modern v4l drivers). And Seth Jenkins
points out that the fallback to VM_PFNMAP/VM_IO is fundamentally racy
and dangerous.
Note that it's not even a case that should trigger, since any normal
user pointer logic ends up just using the pin_user_pages_fast() call
that does the proper page reference counting. That's not the problem
case, only if you try to use special device mappings do you have any
issues.
Normally I'd just remove this during the merge window, but since Seth
pointed out the problem cases, we really want to know as soon as
possible if there are actually any users of this odd special case of a
legacy interface. Neither Hans nor Mauro seem to think that such
mis-uses of the old legacy interface should exist. As Mauro says:
"See, V4L2 has actually 4 streaming APIs:
- Kernel-allocated mmap (usually referred simply as just mmap);
- USERPTR mmap;
- read();
- dmabuf;
The USERPTR is one of the oldest way to use it, coming from V4L
version 1 times, and by far the least used one"
And Hans chimed in on the USERPTR interface:
"To be honest, I wouldn't mind if it goes away completely, but that's a
bit of a pipe dream right now"
but while removing this legacy interface entirely may be a pipe dream we
can at least try to remove the unlikely (and actively broken) case of
using special device mappings for USERPTR accesses.
This replaces it with a WARN_ONCE() that we can remove once we've
hopefully confirmed that no actual users exist.
NOTE! Longer term, this means that a 'struct frame_vector' only ever
contains proper page pointers, and all the games we have with converting
them to pages can go away (grep for 'frame_vector_to_pages()' and the
uses of 'vec->is_pfns'). But this is just the first step, to verify
that this code really is all dead, and do so as quickly as possible.
Reported-by: Seth Jenkins <sethjenkins@google.com>
Acked-by: Hans Verkuil <hverkuil@xs4all.nl>
Acked-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: David Hildenbrand <david@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||
|
Linus Torvalds
|
0390da0565 |
proc: proc_skip_spaces() shouldn't think it is working on C strings
commit bce9332220bd677d83b19d21502776ad555a0e73 upstream. proc_skip_spaces() seems to think it is working on C strings, and ends up being just a wrapper around skip_spaces() with a really odd calling convention. Instead of basing it on skip_spaces(), it should have looked more like proc_skip_char(), which really is the exact same function (except it skips a particular character, rather than whitespace). So use that as inspiration, odd coding and all. Now the calling convention actually makes sense and works for the intended purpose. Reported-and-tested-by: Kyle Zeng <zengyhkyle@gmail.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
||
|
Linus Torvalds
|
dd3124a051 |
proc: avoid integer type confusion in get_proc_long
commit e6cfaf34be9fcd1a8285a294e18986bfc41a409c upstream. proc_get_long() is passed a size_t, but then assigns it to an 'int' variable for the length. Let's not do that, even if our IO paths are limited to MAX_RW_COUNT (exactly because of these kinds of type errors). So do the proper test in the rigth type. Reported-by: Kyle Zeng <zengyhkyle@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
||
Adrian Hunter
|
1061bf5d01 |
mmc: sdhci: Fix voltage switch delay
commit c981cdfb9925f64a364f13c2b4f98f877308a408 upstream. Commit |
||
Masahiro Yamada
|
9a5f49c0f5 |
mmc: sdhci: use FIELD_GET for preset value bit masks
commit fa0910107a9fea170b817f31da2a65463e00e80e upstream. Use the FIELD_GET macro to get access to the register fields. Delete the shift macros. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Link: https://lore.kernel.org/r/20200312110050.21732-1-yamada.masahiro@socionext.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
||
Jan Dabros
|
d699373ac5 |
char: tpm: Protect tpm_pm_suspend with locks
commit 23393c6461422df5bf8084a086ada9a7e17dc2ba upstream.
Currently tpm transactions are executed unconditionally in
tpm_pm_suspend() function, which may lead to races with other tpm
accessors in the system.
Specifically, the hw_random tpm driver makes use of tpm_get_random(),
and this function is called in a loop from a kthread, which means it's
not frozen alongside userspace, and so can race with the work done
during system suspend:
tpm tpm0: tpm_transmit: tpm_recv: error -52
tpm tpm0: invalid TPM_STS.x 0xff, dumping stack for forensics
CPU: 0 PID: 1 Comm: init Not tainted 6.1.0-rc5+ #135
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014
Call Trace:
tpm_tis_status.cold+0x19/0x20
tpm_transmit+0x13b/0x390
tpm_transmit_cmd+0x20/0x80
tpm1_pm_suspend+0xa6/0x110
tpm_pm_suspend+0x53/0x80
__pnp_bus_suspend+0x35/0xe0
__device_suspend+0x10f/0x350
Fix this by calling tpm_try_get_ops(), which itself is a wrapper around
tpm_chip_start(), but takes the appropriate mutex.
Signed-off-by: Jan Dabros <jsd@semihalf.com>
Reported-by: Vlastimil Babka <vbabka@suse.cz>
Tested-by: Jason A. Donenfeld <Jason@zx2c4.com>
Tested-by: Vlastimil Babka <vbabka@suse.cz>
Link: https://lore.kernel.org/all/c5ba47ef-393f-1fba-30bd-1230d1b4b592@suse.cz/
Cc: stable@vger.kernel.org
Fixes:
|
||
Conor Dooley
|
9decec2993 |
Revert "clocksource/drivers/riscv: Events are stopped during CPU suspend"
[ Upstream commit d9f15a9de44affe733e34f93bc184945ba277e6d ]
This reverts commit 232ccac1bd9b5bfe73895f527c08623e7fa0752d.
On the subject of suspend, the RISC-V SBI spec states:
This does not cover whether any given events actually reach the hart or
not, just what the hart will do if it receives an event. On PolarFire
SoC, and potentially other SiFive based implementations, events from the
RISC-V timer do reach a hart during suspend. This is not the case for the
implementation on the Allwinner D1 - there timer events are not received
during suspend.
To fix this, the CLOCK_EVT_FEAT_C3STOP (mis)feature was enabled for the
timer driver - but this has broken both RCU stall detection and timers
generally on PolarFire SoC and potentially other SiFive based
implementations.
If an AXI read to the PCIe controller on PolarFire SoC times out, the
system will stall, however, with CLOCK_EVT_FEAT_C3STOP active, the system
just locks up without RCU stalling:
io scheduler mq-deadline registered
io scheduler kyber registered
microchip-pcie 2000000000.pcie: host bridge /soc/pcie@2000000000 ranges:
microchip-pcie 2000000000.pcie: MEM 0x2008000000..0x2087ffffff -> 0x0008000000
microchip-pcie 2000000000.pcie: sec error in pcie2axi buffer
microchip-pcie 2000000000.pcie: ded error in pcie2axi buffer
microchip-pcie 2000000000.pcie: axi read request error
microchip-pcie 2000000000.pcie: axi read timeout
microchip-pcie 2000000000.pcie: sec error in pcie2axi buffer
microchip-pcie 2000000000.pcie: ded error in pcie2axi buffer
microchip-pcie 2000000000.pcie: sec error in pcie2axi buffer
microchip-pcie 2000000000.pcie: ded error in pcie2axi buffer
microchip-pcie 2000000000.pcie: sec error in pcie2axi buffer
microchip-pcie 2000000000.pcie: ded error in pcie2axi buffer
Freeing initrd memory: 7332K
Similarly issues were reported with clock_nanosleep() - with a test app
that sleeps each cpu for 6, 5, 4, 3 ms respectively, HZ=250 & the blamed
commit in place, the sleep times are rounded up to the next jiffy:
== CPU: 1 == == CPU: 2 == == CPU: 3 == == CPU: 4 ==
Mean: 7.974992 Mean: 7.976534 Mean: 7.962591 Mean: 3.952179
Std Dev: 0.154374 Std Dev: 0.156082 Std Dev: 0.171018 Std Dev: 0.076193
Hi: 9.472000 Hi: 10.495000 Hi: 8.864000 Hi: 4.736000
Lo: 6.087000 Lo: 6.380000 Lo: 4.872000 Lo: 3.403000
Samples: 521 Samples: 521 Samples: 521 Samples: 521
Fortunately, the D1 has a second timer, which is "currently used in
preference to the RISC-V/SBI timer driver" so a revert here does not
hurt operation of D1 in its current form.
Ultimately, a DeviceTree property (or node) will be added to encode the
behaviour of the timers, but until then revert the addition of
CLOCK_EVT_FEAT_C3STOP.
Fixes: 232ccac1bd9b ("clocksource/drivers/riscv: Events are stopped during CPU suspend")
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
Acked-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/linux-riscv/YzYTNQRxLr7Q9JR0@spud/
Link: https://github.com/riscv-non-isa/riscv-sbi-doc/issues/98/
Link: https://lore.kernel.org/linux-riscv/bf6d3b1f-f703-4a25-833e-972a44a04114@sholland.org/
Link: https://lore.kernel.org/r/20221122121620.3522431-1-conor.dooley@microchip.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
||
Michael Kelley
|
e67e119adf |
x86/ioremap: Fix page aligned size calculation in __ioremap_caller()
[ Upstream commit 4dbd6a3e90e03130973688fd79e19425f720d999 ]
Current code re-calculates the size after aligning the starting and
ending physical addresses on a page boundary. But the re-calculation
also embeds the masking of high order bits that exceed the size of
the physical address space (via PHYSICAL_PAGE_MASK). If the masking
removes any high order bits, the size calculation results in a huge
value that is likely to immediately fail.
Fix this by re-calculating the page-aligned size first. Then mask any
high order bits using PHYSICAL_PAGE_MASK.
Fixes:
|
||
Luiz Augusto von Dentz
|
0d87bb6070 |
Bluetooth: L2CAP: Fix accepting connection request for invalid SPSM
commit 711f8c3fb3db61897080468586b970c87c61d9e4 upstream. The Bluetooth spec states that the valid range for SPSM is from 0x0001-0x00ff so it is invalid to accept values outside of this range: BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 3, Part A page 1059: Table 4.15: L2CAP_LE_CREDIT_BASED_CONNECTION_REQ SPSM ranges CVE: CVE-2022-42896 CC: stable@vger.kernel.org Reported-by: Tamás Koczka <poprdi@google.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Reviewed-by: Tedd Ho-Jeong An <tedd.an@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
||
Pawan Gupta
|
b5041a3daa |
x86/pm: Add enumeration check before spec MSRs save/restore setup
commit 50bcceb7724e471d9b591803889df45dcbb584bc upstream.
pm_save_spec_msr() keeps a list of all the MSRs which _might_ need
to be saved and restored at hibernate and resume. However, it has
zero awareness of CPU support for these MSRs. It mostly works by
unconditionally attempting to manipulate these MSRs and relying on
rdmsrl_safe() being able to handle a #GP on CPUs where the support is
unavailable.
However, it's possible for reads (RDMSR) to be supported for a given MSR
while writes (WRMSR) are not. In this case, msr_build_context() sees
a successful read (RDMSR) and marks the MSR as valid. Then, later, a
write (WRMSR) fails, producing a nasty (but harmless) error message.
This causes restore_processor_state() to try and restore it, but writing
this MSR is not allowed on the Intel Atom N2600 leading to:
unchecked MSR access error: WRMSR to 0x122 (tried to write 0x0000000000000002) \
at rIP: 0xffffffff8b07a574 (native_write_msr+0x4/0x20)
Call Trace:
<TASK>
restore_processor_state
x86_acpi_suspend_lowlevel
acpi_suspend_enter
suspend_devices_and_enter
pm_suspend.cold
state_store
kernfs_fop_write_iter
vfs_write
ksys_write
do_syscall_64
? do_syscall_64
? up_read
? lock_is_held_type
? asm_exc_page_fault
? lockdep_hardirqs_on
entry_SYSCALL_64_after_hwframe
To fix this, add the corresponding X86_FEATURE bit for each MSR. Avoid
trying to manipulate the MSR when the feature bit is clear. This
required adding a X86_FEATURE bit for MSRs that do not have one already,
but it's a small price to pay.
[ bp: Move struct msr_enumeration inside the only function that uses it. ]
[Pawan: Resolve build issue in backport]
Fixes: 73924ec4d560 ("x86/pm: Save the MSR validity status at context setup")
Reported-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: <stable@kernel.org>
Link: https://lore.kernel.org/r/c24db75d69df6e66c0465e13676ad3f2837a2ed8.1668539735.git.pawan.kumar.gupta@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||
|
Pawan Gupta
|
3b28594576 |
x86/tsx: Add a feature bit for TSX control MSR support
commit aaa65d17eec372c6a9756833f3964ba05b05ea14 upstream.
Support for the TSX control MSR is enumerated in MSR_IA32_ARCH_CAPABILITIES.
This is different from how other CPU features are enumerated i.e. via
CPUID. Currently, a call to tsx_ctrl_is_supported() is required for
enumerating the feature. In the absence of a feature bit for TSX control,
any code that relies on checking feature bits directly will not work.
In preparation for adding a feature bit check in MSR save/restore
during suspend/resume, set a new feature bit X86_FEATURE_TSX_CTRL when
MSR_IA32_TSX_CTRL is present.
[ bp: Remove tsx_ctrl_is_supported()]
[Pawan: Resolved conflicts in backport; Removed parts of commit message
referring to removed function tsx_ctrl_is_supported()]
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: <stable@kernel.org>
Link: https://lore.kernel.org/r/de619764e1d98afbb7a5fa58424f1278ede37b45.1668539735.git.pawan.kumar.gupta@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||
Keith Busch
|
99c59256ea |
nvme: ensure subsystem reset is single threaded
commit 1e866afd4bcdd01a70a5eddb4371158d3035ce03 upstream. The subsystem reset writes to a register, so we have to ensure the device state is capable of handling that otherwise the driver may access unmapped registers. Use the state machine to ensure the subsystem reset doesn't try to write registers on a device already undergoing this type of reset. Link: https://bugzilla.kernel.org/show_bug.cgi?id=214771 Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
||
|
Keith Busch
|
dc85ff0a5f |
nvme: restrict management ioctls to admin
commit 23e085b2dead13b51fe86d27069895b740f749c0 upstream. The passthrough commands already have this restriction, but the other operations do not. Require the same capabilities for all users as all of these operations, which include resets and rescans, can be disruptive. Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com> |
||
Soheil Hassas Yeganeh
|
c41a89af7b |
epoll: check for events when removing a timed out thread from the wait queue
commit 289caf5d8f6c61c6d2b7fd752a7f483cd153f182 upstream. Patch series "simplify ep_poll". This patch series is a followup based on the suggestions and feedback by Linus: https://lkml.kernel.org/r/CAHk-=wizk=OxUyQPbO8MS41w2Pag1kniUV5WdD5qWL-gq1kjDA@mail.gmail.com The first patch in the series is a fix for the epoll race in presence of timeouts, so that it can be cleanly backported to all affected stable kernels. The rest of the patch series simplify the ep_poll() implementation. Some of these simplifications result in minor performance enhancements as well. We have kept these changes under self tests and internal benchmarks for a few days, and there are minor (1-2%) performance enhancements as a result. This patch (of 8): After |
||
Roman Penyaev
|
b8e803cda5 |
epoll: call final ep_events_available() check under the lock
commit 65759097d804d2a9ad2b687db436319704ba7019 upstream.
There is a possible race when ep_scan_ready_list() leaves ->rdllist and
->obflist empty for a short period of time although some events are
pending. It is quite likely that ep_events_available() observes empty
lists and goes to sleep.
Since commit 339ddb53d373 ("fs/epoll: remove unnecessary wakeups of
nested epoll") we are conservative in wakeups (there is only one place
for wakeup and this is ep_poll_callback()), thus ep_events_available()
must always observe correct state of two lists.
The easiest and correct way is to do the final check under the lock.
This does not impact the performance, since lock is taken anyway for
adding a wait entry to the wait queue.
The discussion of the problem can be found here:
https://lore.kernel.org/linux-fsdevel/a2f22c3c-c25a-4bda-8339-a7bdaf17849e@akamai.com/
In this patch barrierless __set_current_state() is used. This is safe
since waitqueue_active() is called under the same lock on wakeup side.
Short-circuit for fatal signals (i.e. fatal_signal_pending() check) is
moved to the line just before actual events harvesting routine. This is
fully compliant to what is said in the comment of the patch where the
actual fatal_signal_pending() check was added:
|
||
Steven Rostedt (Google)
|
e65ac2bdda |
tracing/ring-buffer: Have polling block on watermark
commit 42fb0a1e84ff525ebe560e2baf9451ab69127e2b upstream.
Currently the way polling works on the ring buffer is broken. It will
return immediately if there's any data in the ring buffer whereas a read
will block until the watermark (defined by the tracefs buffer_percent file)
is hit.
That is, a select() or poll() will return as if there's data available,
but then the following read will block. This is broken for the way
select()s and poll()s are supposed to work.
Have the polling on the ring buffer also block the same way reads and
splice does on the ring buffer.
Link: https://lkml.kernel.org/r/20221020231427.41be3f26@gandalf.local.home
Cc: Linux Trace Kernel <linux-trace-kernel@vger.kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Primiano Tucci <primiano@google.com>
Cc: stable@vger.kernel.org
Fixes:
|
||
Ido Schimmel
|
899e148171 |
ipv4: Fix route deletion when nexthop info is not specified
[ Upstream commit d5082d386eee7e8ec46fa8581932c81a4961dcef ]
When the kernel receives a route deletion request from user space it
tries to delete a route that matches the route attributes specified in
the request.
If only prefix information is specified in the request, the kernel
should delete the first matching FIB alias regardless of its associated
FIB info. However, an error is currently returned when the FIB info is
backed by a nexthop object:
# ip nexthop add id 1 via 192.0.2.2 dev dummy10
# ip route add 198.51.100.0/24 nhid 1
# ip route del 198.51.100.0/24
RTNETLINK answers: No such process
Fix by matching on such a FIB info when legacy nexthop attributes are
not specified in the request. An earlier check already covers the case
where a nexthop ID is specified in the request.
Add tests that cover these flows. Before the fix:
# ./fib_nexthops.sh -t ipv4_fcnal
...
TEST: Delete route when not specifying nexthop attributes [FAIL]
Tests passed: 11
Tests failed: 1
After the fix:
# ./fib_nexthops.sh -t ipv4_fcnal
...
TEST: Delete route when not specifying nexthop attributes [ OK ]
Tests passed: 12
Tests failed: 0
No regressions in other tests:
# ./fib_nexthops.sh
...
Tests passed: 228
Tests failed: 0
# ./fib_tests.sh
...
Tests passed: 186
Tests failed: 0
Cc: stable@vger.kernel.org
Reported-by: Jonas Gorski <jonas.gorski@gmail.com>
Tested-by: Jonas Gorski <jonas.gorski@gmail.com>
Fixes:
|
||
David Ahern
|
cc3cd130ec |
ipv4: Handle attempt to delete multipath route when fib_info contains an nh reference
[ Upstream commit 61b91eb33a69c3be11b259c5ea484505cd79f883 ]
Gwangun Jung reported a slab-out-of-bounds access in fib_nh_match:
fib_nh_match+0xf98/0x1130 linux-6.0-rc7/net/ipv4/fib_semantics.c:961
fib_table_delete+0x5f3/0xa40 linux-6.0-rc7/net/ipv4/fib_trie.c:1753
inet_rtm_delroute+0x2b3/0x380 linux-6.0-rc7/net/ipv4/fib_frontend.c:874
Separate nexthop objects are mutually exclusive with the legacy
multipath spec. Fix fib_nh_match to return if the config for the
to be deleted route contains a multipath spec while the fib_info
is using a nexthop object.
Fixes:
|