08 Apr, 2022
40 commits
-
commit 590bfb57b2328951d5833979e7ca1d5fde2e609a upstream.
It is insecure to allow arbitrary hash algorithms and signature
encodings to be used with arbitrary signature algorithms. Notably,
ECDSA, ECRDSA, and SM2 all sign/verify raw hash values and don't
disambiguate between different hash algorithms like RSA PKCS#1 v1.5
padding does. Therefore, they need to be restricted to certain sets of
hash algorithms (ideally just one, but in practice small sets are used).
Additionally, the encoding is an integral part of modern signature
algorithms, and is not supposed to vary.Therefore, tighten the checks of hash_algo and encoding done by
software_key_determine_akcipher().Also rearrange the parameters to software_key_determine_akcipher() to
put the public_key first, as this is the most important parameter and it
often determines everything else.Fixes: 299f561a6693 ("x509: Add support for parsing x509 certs with ECDSA keys")
Fixes: 215525639631 ("X.509: support OSCCA SM2-with-SM3 certificate verification")
Fixes: 0d7a78643f69 ("crypto: ecrdsa - add EC-RDSA (GOST 34.10) algorithm")
Cc: stable@vger.kernel.org
Tested-by: Stefan Berger
Tested-by: Tianjia Zhang
Signed-off-by: Eric Biggers
Reviewed-by: Vitaly Chikunov
Reviewed-by: Jarkko Sakkinen
Signed-off-by: Jarkko Sakkinen
Signed-off-by: Greg Kroah-Hartman -
commit 2abc9c246e0548e52985b10440c9ea3e9f65f793 upstream.
Most callers of public_key_verify_signature(), including most indirect
callers via verify_signature() as well as pkcs7_verify_sig_chain(),
don't check that public_key_signature::pkey_algo matches
public_key::pkey_algo. These should always match. However, a malicious
signature could intentionally declare an unintended algorithm. It is
essential that such signatures be rejected outright, or that the
algorithm of the *key* be used -- not the algorithm of the signature as
that would allow attackers to choose the algorithm used.Currently, public_key_verify_signature() correctly uses the key's
algorithm when deciding which akcipher to allocate. That's good.
However, it uses the signature's algorithm when deciding whether to do
the first step of SM2, which is incorrect. Also, v4.19 and older
kernels used the signature's algorithm for the entire process.Prevent such errors by making public_key_verify_signature() enforce that
the signature's algorithm (if given) matches the key's algorithm.Also remove two checks of this done by callers, which are now redundant.
Cc: stable@vger.kernel.org
Tested-by: Stefan Berger
Tested-by: Tianjia Zhang
Signed-off-by: Eric Biggers
Reviewed-by: Vitaly Chikunov
Reviewed-by: Jarkko Sakkinen
Signed-off-by: Jarkko Sakkinen
Signed-off-by: Greg Kroah-Hartman -
commit c51abd96837f600d8fd940b6ab8e2da578575504 upstream.
In many cases, keyctl_pkey_params_get_2() is validating the user buffer
lengths against the wrong algorithm properties. Fix it to check against
the correct properties.Probably this wasn't noticed before because for all asymmetric keys of
the "public_key" subtype, max_data_size == max_sig_size == max_enc_size
== max_dec_size. However, this isn't necessarily true for the
"asym_tpm" subtype (it should be, but it's not strictly validated). Of
course, future key types could have different values as well.Fixes: 00d60fd3b932 ("KEYS: Provide keyctls to drive the new key type ops for asymmetric keys [ver #2]")
Cc: # v4.20+
Signed-off-by: Eric Biggers
Reviewed-by: Jarkko Sakkinen
Signed-off-by: Jarkko Sakkinen
Signed-off-by: Greg Kroah-Hartman -
commit 9a14b65d590105d393b63f5320e1594edda7c672 upstream.
Remove the spinlock around the tree traversal as we are calling possibly
sleeping functions.
We do not need a spinlock here as there will be no modifications to this
tree at this point.This prevents warnings like this to occur in dmesg:
[ 653.774996] BUG: sleeping function called from invalid context at kernel/loc\
king/mutex.c:280
[ 653.775088] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1827, nam\
e: umount
[ 653.775152] preempt_count: 1, expected: 0
[ 653.775191] CPU: 0 PID: 1827 Comm: umount Tainted: G W OE 5.17.0\
-rc7-00006-g4eb628dd74df #135
[ 653.775195] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-\
1.fc33 04/01/2014
[ 653.775197] Call Trace:
[ 653.775199]
[ 653.775202] dump_stack_lvl+0x34/0x44
[ 653.775209] __might_resched.cold+0x13f/0x172
[ 653.775213] mutex_lock+0x75/0xf0
[ 653.775217] ? __mutex_lock_slowpath+0x10/0x10
[ 653.775220] ? _raw_write_lock_irq+0xd0/0xd0
[ 653.775224] ? dput+0x6b/0x360
[ 653.775228] cifs_kill_sb+0xff/0x1d0 [cifs]
[ 653.775285] deactivate_locked_super+0x85/0x130
[ 653.775289] cleanup_mnt+0x32c/0x4d0
[ 653.775292] ? path_umount+0x228/0x380
[ 653.775296] task_work_run+0xd8/0x180
[ 653.775301] exit_to_user_mode_loop+0x152/0x160
[ 653.775306] exit_to_user_mode_prepare+0x89/0xd0
[ 653.775315] syscall_exit_to_user_mode+0x12/0x30
[ 653.775322] do_syscall_64+0x48/0x90
[ 653.775326] entry_SYSCALL_64_after_hwframe+0x44/0xaeFixes: 187af6e98b44e5d8f25e1d41a92db138eb54416f ("cifs: fix handlecache and multiuser")
Reported-by: kernel test robot
Cc: stable@vger.kernel.org
Signed-off-by: Ronnie Sahlberg
Signed-off-by: Steve French
Signed-off-by: Greg Kroah-Hartman -
commit 47178c7722ac528ea08aa82c3ef9ffa178962d7a upstream.
In multiuser each individual user has their own tcon structure for the
share and thus their own handle for a cached directory.
When we umount such a share we much make sure to release the pinned down dentry
for each such tcon and not just the master tcon.Otherwise we will get nasty warnings on umount that dentries are still in use:
[ 3459.590047] BUG: Dentry 00000000115c6f41{i=12000000019d95,n=/} still in use\
(2) [unmount of cifs cifs]
...
[ 3459.590492] Call Trace:
[ 3459.590500] d_walk+0x61/0x2a0
[ 3459.590518] ? shrink_lock_dentry.part.0+0xe0/0xe0
[ 3459.590526] shrink_dcache_for_umount+0x49/0x110
[ 3459.590535] generic_shutdown_super+0x1a/0x110
[ 3459.590542] kill_anon_super+0x14/0x30
[ 3459.590549] cifs_kill_sb+0xf5/0x104 [cifs]
[ 3459.590773] deactivate_locked_super+0x36/0xa0
[ 3459.590782] cleanup_mnt+0x131/0x190
[ 3459.590789] task_work_run+0x5c/0x90
[ 3459.590798] exit_to_user_mode_loop+0x151/0x160
[ 3459.590809] exit_to_user_mode_prepare+0x83/0xd0
[ 3459.590818] syscall_exit_to_user_mode+0x12/0x30
[ 3459.590828] do_syscall_64+0x48/0x90
[ 3459.590833] entry_SYSCALL_64_after_hwframe+0x44/0xaeSigned-off-by: Ronnie Sahlberg
Acked-by: Paulo Alcantara (SUSE)
Cc: stable@vger.kernel.org
Signed-off-by: Steve French
Signed-off-by: Greg Kroah-Hartman -
commit ee1fee900537b5d9560e9f937402de5ddc8412f3 upstream.
Setting PTRACE_O_SUSPEND_SECCOMP is supposed to be a highly privileged
operation because it allows the tracee to completely bypass all seccomp
filters on kernels with CONFIG_CHECKPOINT_RESTORE=y. It is only supposed to
be settable by a process with global CAP_SYS_ADMIN, and only if that
process is not subject to any seccomp filters at all.However, while these permission checks were done on the PTRACE_SETOPTIONS
path, they were missing on the PTRACE_SEIZE path, which also sets
user-specified ptrace flags.Move the permissions checks out into a helper function and let both
ptrace_attach() and ptrace_setoptions() call it.Cc: stable@kernel.org
Fixes: 13c4a90119d2 ("seccomp: add ptrace options for suspend/resume")
Signed-off-by: Jann Horn
Link: https://lkml.kernel.org/r/20220319010838.1386861-1-jannh@google.com
Signed-off-by: Eric W. Biederman
Signed-off-by: Greg Kroah-Hartman -
commit ca85a66710a8a1f6b0719397225c3e9ee0abb692 upstream.
Fixed-rate clocks in UniPhier don't have any parent clocks, however,
initial data "init.flags" isn't initialized, so it might be determined
that there is a parent clock for fixed-rate clock.This sets init.flags to zero as initialization.
Cc:
Fixes: 734d82f4a678 ("clk: uniphier: add core support code for UniPhier clock driver")
Signed-off-by: Kunihiko Hayashi
Link: https://lore.kernel.org/r/1646808918-30899-1-git-send-email-hayashi.kunihiko@socionext.com
Signed-off-by: Stephen Boyd
Signed-off-by: Greg Kroah-Hartman -
commit 10b74af310735860510a533433b1d3ab2e05a138 upstream.
In commit 4e7cf74fa3b2 ("clk: fractional-divider: Export approximation
algorithm to the CCF users"), the code handling the rational best
approximation algorithm was replaced by a call to the core
clk_fractional_divider_general_approximation function which did the same
thing back then.However, in commit 82f53f9ee577 ("clk: fractional-divider: Introduce
POWER_OF_TWO_PS flag"), this common code was made conditional on
CLK_FRAC_DIVIDER_POWER_OF_TWO_PS flag which was not added back to the
rockchip clock driver.This broke the ltk050h3146w-a2 MIPI DSI display present on a PX30-based
downstream board.Let's add the flag to the fractional divider flags so that the original
and intended behavior is brought back to the rockchip clock drivers.Fixes: 82f53f9ee577 ("clk: fractional-divider: Introduce POWER_OF_TWO_PS flag")
Cc: stable@vger.kernel.org
Cc: Quentin Schulz
Signed-off-by: Quentin Schulz
Link: https://lore.kernel.org/r/20220131163224.708002-1-quentin.schulz@theobroma-systems.com
Signed-off-by: Heiko Stuebner
Signed-off-by: Greg Kroah-Hartman -
commit 5f8583a3b7552092582a92e7bbd2153319929ad7 upstream.
Cleanup if gb_svc_queue_deferred_request() fails.
Link: https://lore.kernel.org/r/20220202072016.GA6748@kili
Fixes: ee2f2074fdb2 ("greybus: svc: reconfig APBridgeA-Switch link to handle required load")
Cc: stable@vger.kernel.org # 4.9
[johan: fix commit summary prefix and rename label ]
Signed-off-by: Dan Carpenter
Signed-off-by: Johan Hovold
Link: https://lore.kernel.org/r/20220202113347.1288-2-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit ca85123354e1a65a22170286387b4791997fe864 upstream.
iio_convert_raw_to_processed_unlocked() assumes the offset is an
integer. Make a best effort to get a valid offset value for fractional
cases without breaking implicit truncations.Fixes: 48e44ce0f881 ("iio:inkern: Add function to read the processed value")
Signed-off-by: Liam Beguin
Reviewed-by: Peter Rosin
Reviewed-by: Andy Shevchenko
Link: https://lore.kernel.org/r/20220108205319.2046348-4-liambeguin@gmail.com
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit 14b457fdde38de594a4bc4bd9075019319d978da upstream.
When a consumer calls iio_read_channel_processed() and no channel scale
is available, it's assumed that the scale is one and the raw value is
returned as expected.On the other hand, if the consumer calls iio_convert_raw_to_processed()
the scaling factor requested by the consumer is not applied.This for example causes the consumer to process mV when expecting uV.
Make sure to always apply the scaling factor requested by the consumer.Fixes: adc8ec5ff183 ("iio: inkern: pass through raw values if no scaling")
Signed-off-by: Liam Beguin
Reviewed-by: Peter Rosin
Reviewed-by: Andy Shevchenko
Link: https://lore.kernel.org/r/20220108205319.2046348-3-liambeguin@gmail.com
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit 1bca97ff95c732a516ebb68da72814194980e0a5 upstream.
When a consumer calls iio_read_channel_processed() and the channel has
an integer scale, the scale channel scale is applied and the processed
value is returned as expected.On the other hand, if the consumer calls iio_convert_raw_to_processed()
the scaling factor requested by the consumer is not applied.This for example causes the consumer to process mV when expecting uV.
Make sure to always apply the scaling factor requested by the consumer.Fixes: 48e44ce0f881 ("iio:inkern: Add function to read the processed value")
Signed-off-by: Liam Beguin
Reviewed-by: Peter Rosin
Reviewed-by: Andy Shevchenko
Link: https://lore.kernel.org/r/20220108205319.2046348-2-liambeguin@gmail.com
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit 51593106b608ae4247cc8da928813347da16d025 upstream.
All four scaling coefficients can take signed values.
Make tmp a signed 64-bit integer and switch to div_s64() to preserve
signs during 64-bit divisions.Fixes: 8b74816b5a9a ("iio: afe: rescale: new driver")
Signed-off-by: Liam Beguin
Reviewed-by: Peter Rosin
Reviewed-by: Andy Shevchenko
Link: https://lore.kernel.org/r/20220108205319.2046348-5-liambeguin@gmail.com
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit cfa5dbcdd7aece76f3415284569f2f384aff0253 upstream.
device_register() calls device_initialize(),
according to doc of device_initialize:Use put_device() to give up your reference instead of freeing
* @dev directly once you have called this function.To prevent potential memleak, use put_device() for error handling.
Signed-off-by: Miaoqian Lin
Fixes: 85e2414c518a ("coresight: syscfg: Initial coresight system configuration")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20220124124121.8888-1-linmq006@gmail.com
Signed-off-by: Mathieu Poirier
Signed-off-by: Suzuki K Poulose
Signed-off-by: Greg Kroah-Hartman -
commit ea75a342aed5ed72c87f38fbe0df2f5df7eae374 upstream.
It's impossible to program a valid value for TRCCONFIGR.QE
when TRCIDR0.QSUPP==0b10. In that case the following is true:Q element support is implemented, and only supports Q elements without
instruction counts. TRCCONFIGR.QE can only take the values 0b00 or 0b11.Currently the low bit of QSUPP is checked to see if the low bit of QE can
be written to, but as you can see when QSUPP==0b10 the low bit is cleared
making it impossible to ever write the only valid value of 0b11 to QE.
0b10 would be written instead, which is a reserved QE value even for all
values of QSUPP.The fix is to allow writing the low bit of QE for any non zero value of
QSUPP.This change also ensures that the low bit is always set, even when the
user attempts to only set the high bit.Signed-off-by: James Clark
Reviewed-by: Mike Leach
Fixes: d8c66962084f ("coresight-etm4x: Controls pertaining to the reset, mode, pe and events")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20220120113047.2839622-2-james.clark@arm.com
Signed-off-by: Mathieu Poirier
Signed-off-by: Suzuki K Poulose
Signed-off-by: Greg Kroah-Hartman -
commit be78837ca3c88eebd405103a7a2ce891c466b0db upstream.
jinja2 release 3.1.0 (March 24, 2022) broke Sphinx
Cc: Mauro Carvalho Chehab
Cc: stable@vger.kernel.org # v5.15+
Link: https://lore.kernel.org/r/7dbff8a0-f4ff-34a0-71c7-1987baf471f9@gmail.com
Signed-off-by: Jonathan Corbet
Signed-off-by: Greg Kroah-Hartman -
commit ed2d980503235829aa3e0c7ae3b82374c30a081c upstream.
The MHI driver does not work on big endian architectures. The
controller never transitions into mission mode. This appears to be due
to the modem device expecting the various contexts and transfer rings to
have fields in little endian order in memory, but the driver constructs
them in native endianness.Fix MHI event, channel and command contexts and TRE handling macros to
use explicit conversion to little endian. Mark fields in relevant
structures as little endian to document this requirement.Fixes: a6e2e3522f29 ("bus: mhi: core: Add support for PM state transitions")
Fixes: 6cd330ae76ff ("bus: mhi: core: Add support for ringing channel/event ring doorbells")
Cc: stable@vger.kernel.org
Reviewed-by: Manivannan Sadhasivam
Reviewed-by: Alex Elder
Signed-off-by: Paul Davey
Signed-off-by: Manivannan Sadhasivam
Link: https://lore.kernel.org/r/20220301160308.107452-4-manivannan.sadhasivam@linaro.org
Signed-off-by: Greg Kroah-Hartman -
commit 2413ffbf19a95cfcd7adf63135c5a9343a66d0a2 upstream.
For default mechanism, the driver uses default MRU 3500 if mru_default
is not initialized. The Qualcomm configured the MRU size to 32768 in the
WWAN device FW. So, we align the driver setting with Qualcomm FW setting.Link: https://lore.kernel.org/r/MEYP282MB2374EE345DADDB591AFDA6AFFD2E9@MEYP282MB2374.AUSP282.PROD.OUTLOOK.COM
Fixes: ac4bf60bbaa0 ("bus: mhi: pci_generic: Introduce quectel EM1XXGR-L support")
Cc: stable@vger.kernel.org
Reviewed-by: Manivannan Sadhasivam
Signed-off-by: Yonglin Tan
Signed-off-by: Manivannan Sadhasivam
Link: https://lore.kernel.org/r/20220301160308.107452-2-manivannan.sadhasivam@linaro.org
Signed-off-by: Greg Kroah-Hartman -
commit c10187b1c5ebb8681ca467ab7b0ded5ea415d258 upstream.
Usage of the iterator outside of the list_for_each_entry
is considered harmful. https://lkml.org/lkml/2022/2/17/1032Do not reference the loop variable outside of the loop,
by rearranging the orders of execution.
Instead of performing search loop and checking outside the loop
if the end of the list was hit and no matching element was found,
the execution is performed inside the loop upon a successful match
followed by a goto statement to the next step,
therefore no condition has to be performed after the loop has ended.Cc:
Signed-off-by: Alexander Usyskin
Signed-off-by: Tomas Winkler
Link: https://lore.kernel.org/r/20220308095926.300412-1-tomas.winkler@intel.com
Signed-off-by: Greg Kroah-Hartman -
commit 7bbbd0845818cffa9fa8ccfe52fa1cad58e7e4f2 upstream.
Add Alder Lake N device ID.
Cc:
Signed-off-by: Alexander Usyskin
Signed-off-by: Tomas Winkler
Link: https://lore.kernel.org/r/20220301071115.96145-1-tomas.winkler@intel.com
Signed-off-by: Greg Kroah-Hartman -
commit ccdf6f806fbf559f7c29ed9302a7c1b4da7fd37f upstream.
Add a quirk to disable MEI interface on Intel PCH Ignition (IGN)
as the IGN firmware doesn't support the protocol.Cc:
Signed-off-by: Alexander Usyskin
Signed-off-by: Tomas Winkler
Link: https://lore.kernel.org/r/20220215080438.264876-1-tomas.winkler@intel.com
Signed-off-by: Greg Kroah-Hartman -
commit 05519b8589a679edb8fa781259893d20bece04ad upstream.
xhci_decode_ctrl_ctx() returns the untouched buffer as-is if both "drop"
and "add" parameters are zero.Fix the function to return an empty string in that case.
It was not immediately clear from the possible call chains whether this
issue is currently actually triggerable or not.Note that before commit 4843b4b5ec64 ("xhci: fix even more unsafe memory
usage in xhci tracing") the result effect in the failure case was different
as a static buffer was used here, but the code still worked incorrectly.Fixes: 90d6d5731da7 ("xhci: Add tracing for input control context")
Cc: stable@vger.kernel.org
Signed-off-by: Anssi Hannula
Signed-off-by: Mathias Nyman
commit 4843b4b5ec64 ("xhci: fix even more unsafe memory usage in xhci tracing")
Link: https://lore.kernel.org/r/20220303110903.1662404-4-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman -
commit 14073ce951b5919da450022c050772902f24f054 upstream.
xhci_reset() timeout was increased from 250ms to 10 seconds in order to
give Renesas 720201 xHC enough time to get ready in probe.xhci_reset() is called with interrupts disabled in other places, and
waiting for 10 seconds there is not acceptable.Add a timeout parameter to xhci_reset(), and adjust it back to 250ms
when called from xhci_stop() or xhci_shutdown() where interrupts are
disabled, and successful reset isn't that critical.
This solves issues when deactivating host mode on platforms like SM8450.For now don't change the timeout if xHC is reset in xhci_resume().
No issues are reported for it, and we need the reset to succeed.
Locking around that reset needs to be revisited later.Additionally change the signed integer timeout parameter in
xhci_handshake() to a u64 to match the timeout value we pass to
readl_poll_timeout_atomic()Fixes: 22ceac191211 ("xhci: Increase reset timeout for Renesas 720201 host.")
Cc: stable@vger.kernel.org
Reported-by: Sergey Shtylyov
Reported-by: Pavan Kondeti
Tested-by: Pavan Kondeti
Signed-off-by: Mathias Nyman
Link: https://lore.kernel.org/r/20220303110903.1662404-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman -
commit 70c05e4cf63054cd755ca66c1819327b22cb085f upstream.
A race between system resume and device-initiated resume may result in
runtime PM imbalance on USB2 root hub. If a device-initiated resume
starts and system resume xhci_bus_resume() directs U0 before hub driver
sees the resuming device in RESUME state, device-initiated resume will
not be finished in xhci_handle_usb2_port_link_resume(). In this case,
usb_hcd_end_port_resume() call is missing.This changes calls usb_hcd_end_port_resume() if resuming device reaches
U0 to keep runtime PM balance.Fixes: a231ec41e6f6 ("xhci: refactor U0 link state handling in get_port_status")
Cc: stable@vger.kernel.org
Signed-off-by: Henry Lin
Signed-off-by: Mathias Nyman
Link: https://lore.kernel.org/r/20220303110903.1662404-5-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman -
commit 3105bc977d7cbf2edc35e24cc7e009686f6e4a56 upstream.
xhci_decode_usbsts() is expected to return a zero-terminated string by
its only caller, xhci_stop_endpoint_command_watchdog(), which directly
logs the return value:xhci_warn(xhci, "USBSTS:%s\n", xhci_decode_usbsts(str, usbsts));
However, if no recognized bits are set in usbsts, the function will
return without having called any sprintf() and therefore return an
untouched non-zero-terminated caller-provided buffer, causing garbage
to be output to log.Fix that by always including the raw value in the output.
Note that before commit 4843b4b5ec64 ("xhci: fix even more unsafe memory
usage in xhci tracing") the result effect in the failure case was different
as a static buffer was used here, but the code still worked incorrectly.Fixes: 9c1aa36efdae ("xhci: Show host status when watchdog triggers and host is assumed dead.")
Cc: stable@vger.kernel.org
Signed-off-by: Anssi Hannula
Signed-off-by: Mathias Nyman
Link: https://lore.kernel.org/r/20220303110903.1662404-3-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman -
commit 1892bf90677abcad7f06e897e308f5c3e3618dd4 upstream.
The kernel test robot found a problem with the ene_ub6250 subdriver in
usb-storage: It uses structures containing bitfields to represent
hardware bits in its SD_STATUS, MS_STATUS, and SM_STATUS bytes. This
is not safe; it presumes a particular bit ordering and it assumes the
compiler will not insert padding, neither of which is guaranteed.This patch fixes the problem by changing the structures to simple u8
values, with the bitfields replaced by bitmask constants.CC:
Signed-off-by: Alan Stern
Link: https://lore.kernel.org/r/YjOcbuU106UpJ/V8@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman -
commit 676748389f5db74e7d28f9d630eebd75cb8a11b4 upstream.
In order to bring up the USB3 PHY on the Apple M1 we need to know the
orientation of the Type-C cable. Extract it from the status register and
forward it to the typec subsystem.Reviewed-by: Heikki Krogerus
Cc: stable
Signed-off-by: Sven Peter
Link: https://lore.kernel.org/r/20220226125912.59828-1-sven@svenpeter.dev
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Greg Kroah-Hartman -
commit 7e0438f83dc769465ee663bb5dcf8cc154940712 upstream.
The following sequence of operations results in a refcount warning:
1. Open device /dev/tpmrm.
2. Remove module tpm_tis_spi.
3. Write a TPM command to the file descriptor opened at step 1.------------[ cut here ]------------
WARNING: CPU: 3 PID: 1161 at lib/refcount.c:25 kobject_get+0xa0/0xa4
refcount_t: addition on 0; use-after-free.
Modules linked in: tpm_tis_spi tpm_tis_core tpm mdio_bcm_unimac brcmfmac
sha256_generic libsha256 sha256_arm hci_uart btbcm bluetooth cfg80211 vc4
brcmutil ecdh_generic ecc snd_soc_core crc32_arm_ce libaes
raspberrypi_hwmon ac97_bus snd_pcm_dmaengine bcm2711_thermal snd_pcm
snd_timer genet snd phy_generic soundcore [last unloaded: spi_bcm2835]
CPU: 3 PID: 1161 Comm: hold_open Not tainted 5.10.0ls-main-dirty #2
Hardware name: BCM2711
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0xc4/0xd8)
[] (dump_stack) from [] (__warn+0x104/0x108)
[] (__warn) from [] (warn_slowpath_fmt+0x74/0xb8)
[] (warn_slowpath_fmt) from [] (kobject_get+0xa0/0xa4)
[] (kobject_get) from [] (tpm_try_get_ops+0x14/0x54 [tpm])
[] (tpm_try_get_ops [tpm]) from [] (tpm_common_write+0x38/0x60 [tpm])
[] (tpm_common_write [tpm]) from [] (vfs_write+0xc4/0x3c0)
[] (vfs_write) from [] (ksys_write+0x58/0xcc)
[] (ksys_write) from [] (ret_fast_syscall+0x0/0x4c)
Exception stack(0xc226bfa8 to 0xc226bff0)
bfa0: 00000000 000105b4 00000003 beafe664 00000014 00000000
bfc0: 00000000 000105b4 000103f8 00000004 00000000 00000000 b6f9c000 beafe684
bfe0: 0000006c beafe648 0001056c b6eb6944
---[ end trace d4b8409def9b8b1f ]---The reason for this warning is the attempt to get the chip->dev reference
in tpm_common_write() although the reference counter is already zero.Since commit 8979b02aaf1d ("tpm: Fix reference count to main device") the
extra reference used to prevent a premature zero counter is never taken,
because the required TPM_CHIP_FLAG_TPM2 flag is never set.Fix this by moving the TPM 2 character device handling from
tpm_chip_alloc() to tpm_add_char_device() which is called at a later point
in time when the flag has been set in case of TPM2.Commit fdc915f7f719 ("tpm: expose spaces via a device link /dev/tpmrm")
already introduced function tpm_devs_release() to release the extra
reference but did not implement the required put on chip->devs that results
in the call of this function.Fix this by putting chip->devs in tpm_chip_unregister().
Finally move the new implementation for the TPM 2 handling into a new
function to avoid multiple checks for the TPM_CHIP_FLAG_TPM2 flag in the
good case and error cases.Cc: stable@vger.kernel.org
Fixes: fdc915f7f719 ("tpm: expose spaces via a device link /dev/tpmrm")
Fixes: 8979b02aaf1d ("tpm: Fix reference count to main device")
Co-developed-by: Jason Gunthorpe
Signed-off-by: Jason Gunthorpe
Signed-off-by: Lino Sanfilippo
Tested-by: Stefan Berger
Reviewed-by: Jason Gunthorpe
Reviewed-by: Jarkko Sakkinen
Signed-off-by: Jarkko Sakkinen
Signed-off-by: Greg Kroah-Hartman -
commit 57a13a5b8157d9a8606490aaa1b805bafe6c37e1 upstream.
The block layer can't support a block size larger than
page size yet. And a block size that's too small or
not a power of two won't work either. If a misconfigured
device presents an invalid block size in configuration space,
it will result in the kernel crash something like below:[ 506.154324] BUG: kernel NULL pointer dereference, address: 0000000000000008
[ 506.160416] RIP: 0010:create_empty_buffers+0x24/0x100
[ 506.174302] Call Trace:
[ 506.174651] create_page_buffers+0x4d/0x60
[ 506.175207] block_read_full_page+0x50/0x380
[ 506.175798] ? __mod_lruvec_page_state+0x60/0xa0
[ 506.176412] ? __add_to_page_cache_locked+0x1b2/0x390
[ 506.177085] ? blkdev_direct_IO+0x4a0/0x4a0
[ 506.177644] ? scan_shadow_nodes+0x30/0x30
[ 506.178206] ? lru_cache_add+0x42/0x60
[ 506.178716] do_read_cache_page+0x695/0x740
[ 506.179278] ? read_part_sector+0xe0/0xe0
[ 506.179821] read_part_sector+0x36/0xe0
[ 506.180337] adfspart_check_ICS+0x32/0x320
[ 506.180890] ? snprintf+0x45/0x70
[ 506.181350] ? read_part_sector+0xe0/0xe0
[ 506.181906] bdev_disk_changed+0x229/0x5c0
[ 506.182483] blkdev_get_whole+0x6d/0x90
[ 506.183013] blkdev_get_by_dev+0x122/0x2d0
[ 506.183562] device_add_disk+0x39e/0x3c0
[ 506.184472] virtblk_probe+0x3f8/0x79b [virtio_blk]
[ 506.185461] virtio_dev_probe+0x15e/0x1d0 [virtio]So let's use a block layer helper to validate the block size.
Signed-off-by: Xie Yongji
Acked-by: Michael S. Tsirkin
Link: https://lore.kernel.org/r/20211026144015.188-5-xieyongji@bytedance.com
Signed-off-by: Jens Axboe
Signed-off-by: Lee Jones
Signed-off-by: Greg Kroah-Hartman -
commit 5b61343b50590fb04a3f6be2cdc4868091757262 upstream.
For various reasons based on the allocator behaviour and typical
use-cases at the time, when the max32_alloc_size optimisation was
introduced it seemed reasonable to couple the reset of the tracked
size to the update of cached32_node upon freeing a relevant IOVA.
However, since subsequent optimisations focused on helping genuine
32-bit devices make best use of even more limited address spaces, it
is now a lot more likely for cached32_node to be anywhere in a "full"
32-bit address space, and as such more likely for space to become
available from IOVAs below that node being freed.At this point, the short-cut in __cached_rbnode_delete_update() really
doesn't hold up any more, and we need to fix the logic to reliably
provide the expected behaviour. We still want cached32_node to only move
upwards, but we should reset the allocation size if *any* 32-bit space
has become available.Reported-by: Yunfei Wang
Signed-off-by: Robin Murphy
Reviewed-by: Miles Chen
Link: https://lore.kernel.org/r/033815732d83ca73b13c11485ac39336f15c3b40.1646318408.git.robin.murphy@arm.com
Signed-off-by: Joerg Roedel
Cc: Miles Chen
Signed-off-by: Greg Kroah-Hartman -
commit 85ac2021fe3ace59cc0afd6edf005abad35625b0 upstream.
We don't support runtime pm on APUs. They support more
dynamic power savings using clock and powergating.Reviewed-by: Mario Limonciello
Tested-by: Mario Limonciello
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 901e2be20dc55079997ea1885ea77fc72e6826e7 upstream.
We need to set the APU flag from IP discovery before
we evaluate this code.Acked-by: Evan Quan
Signed-off-by: Alex Deucher
Signed-off-by: Mario Limonciello
Signed-off-by: Greg Kroah-Hartman -
commit 61cc4534b6550997c97a03759ab46b29d44c0017 upstream.
It was found that reading /proc/lockdep after a lockdep splat may
potentially cause an access to freed memory if lockdep_unregister_key()
is called after the splat but before access to /proc/lockdep [1]. This
is due to the fact that graph_lock() call in lockdep_unregister_key()
fails after the clearing of debug_locks by the splat process.After lockdep_unregister_key() is called, the lock_name may be freed
but the corresponding lock_class structure still have a reference to
it. That invalid memory pointer will then be accessed when /proc/lockdep
is read by a user and a use-after-free (UAF) error will be reported if
KASAN is enabled.To fix this problem, lockdep_unregister_key() is now modified to always
search for a matching key irrespective of the debug_locks state and
zap the corresponding lock class if a matching one is found.[1] https://lore.kernel.org/lkml/77f05c15-81b6-bddd-9650-80d5f23fe330@i-love.sakura.ne.jp/
Fixes: 8b39adbee805 ("locking/lockdep: Make lockdep_unregister_key() honor 'debug_locks' again")
Reported-by: Tetsuo Handa
Signed-off-by: Waiman Long
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Bart Van Assche
Cc: Cheng-Jui Wang
Link: https://lkml.kernel.org/r/20220103023558.1377055-1-longman@redhat.com
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 1c4debc443ef7037dcb7c4f08c33b9caebd21d2e ]
When building the vm selftests using clang, some errors are seen due to
having headers in the compilation command:clang -Wall -I ../../../../usr/include -no-pie gup_test.c ../../../../mm/gup_test.h -lrt -lpthread -o .../tools/testing/selftests/vm/gup_test
clang: error: cannot specify -o when generating multiple output files
make[1]: *** [../lib.mk:146: .../tools/testing/selftests/vm/gup_test] Error 1Rework to add the header files to LOCAL_HDRS before including ../lib.mk,
since the dependency is evaluated in '$(OUTPUT)/%:%.c $(LOCAL_HDRS)' in
file lib.mk.Link: https://lkml.kernel.org/r/20220304000645.1888133-1-yosryahmed@google.com
Signed-off-by: Yosry Ahmed
Cc: Shuah Khan
Cc: Nathan Chancellor
Cc: Nick Desaulniers
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin -
[ Upstream commit e981bc74aefc6a177b50c16cfa7023599799cf74 ]
Add spi_device_id tables to avoid logs like "SPI driver ksz9477-switch
has no spi_device_id".Signed-off-by: Claudiu Beznea
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin -
[ Upstream commit 9a564bccb78a76740ea9d75a259942df8143d02c ]
Add __GFP_ZERO flag for compose_sadb_supported in function pfkey_register
to initialize the buffer of supp_skb to fix a kernel-info-leak issue.
1) Function pfkey_register calls compose_sadb_supported to request
a sk_buff. 2) compose_sadb_supported calls alloc_sbk to allocate
a sk_buff, but it doesn't zero it. 3) If auth_len is greater 0, then
compose_sadb_supported treats the memory as a struct sadb_supported and
begins to initialize. But it just initializes the field sadb_supported_len
and field sadb_supported_exttype without field sadb_supported_reserved.Reported-by: TCS Robot
Signed-off-by: Haimin Zhang
Signed-off-by: Steffen Klassert
Signed-off-by: Sasha Levin -
[ Upstream commit e941dc13fd3717122207d74539ab95da07ef797f ]
I observed the following problem with the BT404 touch pad
running the Phosh UI:When e.g. typing on the virtual keyboard pressing "g" would
produce "ggg".After some analysis it turns out the firmware reports that three
fingers hit that coordinate at the same time, finger 0, 2 and
4 (of the five available 0,1,2,3,4).DOWN
Zinitix-TS 3-0020: finger 0 down (246, 395)
Zinitix-TS 3-0020: finger 1 up (0, 0)
Zinitix-TS 3-0020: finger 2 down (246, 395)
Zinitix-TS 3-0020: finger 3 up (0, 0)
Zinitix-TS 3-0020: finger 4 down (246, 395)
UP
Zinitix-TS 3-0020: finger 0 up (246, 395)
Zinitix-TS 3-0020: finger 2 up (246, 395)
Zinitix-TS 3-0020: finger 4 up (246, 395)This is one touch and release: i.e. this is all reported on
touch (down) and release.There is a field in the struct touch_event called finger_cnt
which is actually a bitmask of the fingers active in the
event.Rename this field finger_mask as this matches the use contents
better, then use for_each_set_bit() to iterate over just the
fingers that are actally active.Factor out a finger reporting function zinitix_report_fingers()
to handle all fingers.Also be more careful in reporting finger down/up: we were
reporting every event with input_mt_report_slot_state(..., true);
but this should only be reported on finger down or move,
not on finger up, so also add code to check p->sub_status
to see what is happening and report correctly.After this my Zinitix BT404 touchscreen report fingers
flawlessly.The vendor drive I have notably does not use the "finger_cnt"
and contains obviously incorrect code like this:if (touch_dev->touch_info.finger_cnt > MAX_SUPPORTED_FINGER_NUM)
touch_dev->touch_info.finger_cnt = MAX_SUPPORTED_FINGER_NUM;As MAX_SUPPORTED_FINGER_NUM is an ordinal and the field is
a bitmask this seems quite confused.Signed-off-by: Linus Walleij
Link: https://lore.kernel.org/r/20220228233017.2270599-1-linus.walleij@linaro.org
Signed-off-by: Dmitry Torokhov
Signed-off-by: Sasha Levin -
[ Upstream commit ebc4cb43ea5ada3db46c80156fca58a54b9bbca8 ]
While computing sgs in spi_map_buf(), the data type
used in min_t() for max_seg_size is 'unsigned int' where
as that of ctlr->max_dma_len is 'size_t'.min_t(unsigned int,x,y) gives wrong results if one of x/y is
'size_t'Consider the below examples on a 64-bit machine (ie size_t is
64-bits, and unsigned int is 32-bit).
case 1) min_t(unsigned int, 5, 0x100000001);
case 2) min_t(size_t, 5, 0x100000001);Case 1 returns '1', where as case 2 returns '5'. As you can see
the result from case 1 is wrong.This patch fixes the above issue by using the data type of the
parameters that are used in min_t with maximum data length.Fixes: commit 1a4e53d2fc4f68aa ("spi: Fix invalid sgs value")
Reported-by: Linus Torvalds
Suggested-by: Geert Uytterhoeven
Signed-off-by: Biju Das
Reviewed-by: Lad Prabhakar
Link: https://lore.kernel.org/r/20220316175317.465-1-biju.das.jz@bp.renesas.com
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin -
[ Upstream commit 56e337f2cf1326323844927a04e9dbce9a244835 ]
This reverts commit fc328a7d1fcce263db0b046917a66f3aa6e68719.
This commit - while attempting to fix a regression - has caused a number
of other problems. As the fallout from it is more significant than the
initial problem itself, revert it for now before we find a correct
solution.Link: https://lore.kernel.org/all/20220314192522.GA3031157@roeck-us.net/
Link: https://lore.kernel.org/stable/20220314155509.552218-1-michael@walle.cc/
Link: https://lore.kernel.org/all/20211217153555.9413-1-marcelo.jimenez@gmail.com/
Signed-off-by: Bartosz Golaszewski
Reported-and-bisected-by: Guenter Roeck
Reported-by: Michael Walle
Cc: Thorsten Leemhuis
Cc: Marcelo Roberto Jimenez
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin -
[ Upstream commit 2a760554dcba450d3ad61b32375b50ed6d59a87c ]
It is not recommened to use platform_get_resource(pdev, IORESOURCE_IRQ)
for requesting IRQ's resources any more, as they can be not ready yet in
case of DT-booting.platform_get_irq() instead is a recommended way for getting IRQ even if
it was not retrieved earlier.It also makes code simpler because we're getting "int" value right away
and no conversion from resource to int is required.Reported-by: Zeal Robot
Signed-off-by: Minghao Chi (CGEL ZTE)
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
