From: Eric Biggers <ebiggers(a)google.com>
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(a)vger.kernel.org
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
---
crypto/asymmetric_keys/public_key.c | 111 +++++++++++++++++++---------
1 file changed, 76 insertions(+), 35 deletions(-)
diff --git a/crypto/asymmetric_keys/public_key.c b/crypto/asymmetric_keys/public_key.c
index aba7113d86c76..a603ee8afdb8d 100644
--- a/crypto/asymmetric_keys/public_key.c
+++ b/crypto/asymmetric_keys/public_key.c
@@ -60,39 +60,83 @@ static void public_key_destroy(void *payload0, void *payload3)
}
/*
- * Determine the crypto algorithm name.
+ * Given a public_key, and an encoding and hash_algo to be used for signing
+ * and/or verification with that key, determine the name of the corresponding
+ * akcipher algorithm. Also check that encoding and hash_algo are allowed.
*/
-static
-int software_key_determine_akcipher(const char *encoding,
- const char *hash_algo,
- const struct public_key *pkey,
- char alg_name[CRYPTO_MAX_ALG_NAME])
+static int
+software_key_determine_akcipher(const struct public_key *pkey,
+ const char *encoding, const char *hash_algo,
+ char alg_name[CRYPTO_MAX_ALG_NAME])
{
int n;
- if (strcmp(encoding, "pkcs1") == 0) {
- /* The data wangled by the RSA algorithm is typically padded
- * and encoded in some manner, such as EMSA-PKCS1-1_5 [RFC3447
- * sec 8.2].
+ if (!encoding)
+ return -EINVAL;
+
+ if (strcmp(pkey->pkey_algo, "rsa") == 0) {
+ /*
+ * RSA signatures usually use EMSA-PKCS1-1_5 [RFC3447 sec 8.2].
+ */
+ if (strcmp(encoding, "pkcs1") == 0) {
+ if (!hash_algo)
+ n = snprintf(alg_name, CRYPTO_MAX_ALG_NAME,
+ "pkcs1pad(%s)",
+ pkey->pkey_algo);
+ else
+ n = snprintf(alg_name, CRYPTO_MAX_ALG_NAME,
+ "pkcs1pad(%s,%s)",
+ pkey->pkey_algo, hash_algo);
+ return n >= CRYPTO_MAX_ALG_NAME ? -EINVAL : 0;
+ }
+ if (strcmp(encoding, "raw") != 0)
+ return -EINVAL;
+ /*
+ * Raw RSA cannot differentiate between different hash
+ * algorithms.
+ */
+ if (hash_algo)
+ return -EINVAL;
+ } else if (strncmp(pkey->pkey_algo, "ecdsa", 5) == 0) {
+ if (strcmp(encoding, "x962") != 0)
+ return -EINVAL;
+ /*
+ * ECDSA signatures are taken over a raw hash, so they don't
+ * differentiate between different hash algorithms. That means
+ * that the verifier should hard-code a specific hash algorithm.
+ * Unfortunately, in practice ECDSA is used with multiple SHAs,
+ * so we have to allow all of them and not just one.
*/
if (!hash_algo)
- n = snprintf(alg_name, CRYPTO_MAX_ALG_NAME,
- "pkcs1pad(%s)",
- pkey->pkey_algo);
- else
- n = snprintf(alg_name, CRYPTO_MAX_ALG_NAME,
- "pkcs1pad(%s,%s)",
- pkey->pkey_algo, hash_algo);
- return n >= CRYPTO_MAX_ALG_NAME ? -EINVAL : 0;
- }
-
- if (strcmp(encoding, "raw") == 0 ||
- strcmp(encoding, "x962") == 0) {
- strcpy(alg_name, pkey->pkey_algo);
- return 0;
+ return -EINVAL;
+ if (strcmp(hash_algo, "sha1") != 0 &&
+ strcmp(hash_algo, "sha224") != 0 &&
+ strcmp(hash_algo, "sha256") != 0 &&
+ strcmp(hash_algo, "sha384") != 0 &&
+ strcmp(hash_algo, "sha512") != 0)
+ return -EINVAL;
+ } else if (strcmp(pkey->pkey_algo, "sm2") == 0) {
+ if (strcmp(encoding, "raw") != 0)
+ return -EINVAL;
+ if (!hash_algo)
+ return -EINVAL;
+ if (strcmp(hash_algo, "sm3") != 0)
+ return -EINVAL;
+ } else if (strcmp(pkey->pkey_algo, "ecrdsa") == 0) {
+ if (strcmp(encoding, "raw") != 0)
+ return -EINVAL;
+ if (!hash_algo)
+ return -EINVAL;
+ if (strcmp(hash_algo, "streebog256") != 0 &&
+ strcmp(hash_algo, "streebog512") != 0)
+ return -EINVAL;
+ } else {
+ /* Unknown public key algorithm */
+ return -ENOPKG;
}
-
- return -ENOPKG;
+ if (strscpy(alg_name, pkey->pkey_algo, CRYPTO_MAX_ALG_NAME) < 0)
+ return -EINVAL;
+ return 0;
}
static u8 *pkey_pack_u32(u8 *dst, u32 val)
@@ -113,9 +157,8 @@ static int software_key_query(const struct kernel_pkey_params *params,
u8 *key, *ptr;
int ret, len;
- ret = software_key_determine_akcipher(params->encoding,
- params->hash_algo,
- pkey, alg_name);
+ ret = software_key_determine_akcipher(pkey, params->encoding,
+ params->hash_algo, alg_name);
if (ret < 0)
return ret;
@@ -179,9 +222,8 @@ static int software_key_eds_op(struct kernel_pkey_params *params,
pr_devel("==>%s()\n", __func__);
- ret = software_key_determine_akcipher(params->encoding,
- params->hash_algo,
- pkey, alg_name);
+ ret = software_key_determine_akcipher(pkey, params->encoding,
+ params->hash_algo, alg_name);
if (ret < 0)
return ret;
@@ -340,9 +382,8 @@ int public_key_verify_signature(const struct public_key *pkey,
strcmp(sig->pkey_algo, "ecdsa") != 0))
return -EKEYREJECTED;
- ret = software_key_determine_akcipher(sig->encoding,
- sig->hash_algo,
- pkey, alg_name);
+ ret = software_key_determine_akcipher(pkey, sig->encoding,
+ sig->hash_algo, alg_name);
if (ret < 0)
return ret;
--
2.35.1
This is a note to let you know that I've just added the patch titled
sc16is7xx: Fix for incorrect data being transmitted
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
From eebb0f4e894f1e9577a56b337693d1051dd6ebfd Mon Sep 17 00:00:00 2001
From: Phil Elwell <phil(a)raspberrypi.com>
Date: Wed, 16 Feb 2022 16:08:02 +0000
Subject: sc16is7xx: Fix for incorrect data being transmitted
UART drivers are meant to use the port spinlock within certain
methods, to protect against reentrancy. The sc16is7xx driver does
very little locking, presumably because when added it triggers
"scheduling while atomic" errors. This is due to the use of mutexes
within the regmap abstraction layer, and the mutex implementation's
habit of sleeping the current thread while waiting for access.
Unfortunately this lack of interlocking can lead to corruption of
outbound data, which occurs when the buffer used for I2C transmission
is used simultaneously by two threads - a work queue thread running
sc16is7xx_tx_proc, and an IRQ thread in sc16is7xx_port_irq, both
of which can call sc16is7xx_handle_tx.
An earlier patch added efr_lock, a mutex that controls access to the
EFR register. This mutex is already claimed in the IRQ handler, and
all that is required is to claim the same mutex in sc16is7xx_tx_proc.
See: https://github.com/raspberrypi/linux/issues/4885
Fixes: 6393ff1c4435 ("sc16is7xx: Use threaded IRQ")
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Phil Elwell <phil(a)raspberrypi.com>
Link: https://lore.kernel.org/r/20220216160802.1026013-1-phil@raspberrypi.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/sc16is7xx.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c
index 64e7e6c8145f..38d1c0748533 100644
--- a/drivers/tty/serial/sc16is7xx.c
+++ b/drivers/tty/serial/sc16is7xx.c
@@ -734,12 +734,15 @@ static irqreturn_t sc16is7xx_irq(int irq, void *dev_id)
static void sc16is7xx_tx_proc(struct kthread_work *ws)
{
struct uart_port *port = &(to_sc16is7xx_one(ws, tx_work)->port);
+ struct sc16is7xx_port *s = dev_get_drvdata(port->dev);
if ((port->rs485.flags & SER_RS485_ENABLED) &&
(port->rs485.delay_rts_before_send > 0))
msleep(port->rs485.delay_rts_before_send);
+ mutex_lock(&s->efr_lock);
sc16is7xx_handle_tx(port);
+ mutex_unlock(&s->efr_lock);
}
static void sc16is7xx_reconf_rs485(struct uart_port *port)
--
2.35.1
hallo Greg
5.16.11-rc1
compiles, boots and runs on my x86_64
(Intel i5-11400, Fedora 35)
Thanks
Tested-by: Ronald Warsow <rwarsow(a)gmx.de>
------------------------------------------------------------------------
regards
Ronald
Hello Yonglin,
On Mon, Feb 21, 2022 at 7:21 PM 谭 永林 <yonglin.tan(a)outlook.com> wrote:
> SAHARA protocol is used not only to dump the memory but also to enable FW downloading.
> The protocol is designed primarily for transferring software images from a host to a target and provides a simple mechanism for requesting data to be transferred over any physical link.
>
> To conclude, the SAHARA port provide a mechanism to transfer messages between host and device during SBL.
>
> -----邮件原件-----
> 发件人: Loic Poulain <loic.poulain(a)linaro.org>
> 发送时间: 2022年2月22日 0:03
> 收件人: Yonglin Tan <yonglin.tan(a)outlook.com>
> 抄送: ryazanov.s.a(a)gmail.com; johannes(a)sipsolutions.net; davem(a)davemloft.net; kuba(a)kernel.org; netdev(a)vger.kernel.org; linux-kernel(a)vger.kernel.org; stable(a)vger.kernel.org
> 主题: Re: [PATCH] net: wwan: To support SAHARA port for Qualcomm WWAN module.
>
> Hi Yonglin,
>
> On Mon, 21 Feb 2022 at 13:21, Yonglin Tan <yonglin.tan(a)outlook.com> wrote:
>>
>> The SAHARA port for Qualcomm WWAN module is used to capture memory
>> dump. But now this feature has not been supported by linux kernel
>> code. Such that no SAHARA driver matched while the device entered to
>> DUMP mode. Once the device crashed due to some reasons, device will
>> enter into DUMP mode and running in SBL stage. After that, the device
>> change EE to SBL and the host will detect the EE change event and
>> re-enumerate SAHARA port.
>>
>> Cc: stable(a)vger.kernel.org
>> Fixes: fa588eba632d ("net: Add Qcom WWAN control driver")
>> Signed-off-by: Yonglin Tan <yonglin.tan(a)outlook.com>
>> Reviewed-by: Loic Poulain <loic.poulain(a)linaro.org>
>
> Sorry, but I've not yet offered that tag :-)
>
> The WWAN framework is a generic way to expose a WWAN device and its related control/data protocols, such as AT, QMI, MBIM, QCDM, etc...
> All the exposed protocols are supported by open-source user tools/daemons such as ModemManager, ofono, fwupd... SAHARA does not seem to be WWAN specific and is not something needed for controlling a modem, right?
>
> I know it would be easier to just add this channel to the WWAN ports, but we don't want to rawly expose something that could fit into an existing framework/subsystem, that's why I referred to the devcoredump framework, which 'seems' a better place for its integration. But I could be wrong, I don't know much about devcoredump and maybe SAHARA is doing much more than a firmware coredump...
>
> As a last resort, I think this kind of debug interface should go to debugfs.
Here I agree with Loic. An interface that is exported through the WWAN
subsystem should be common enough for WWAN devices. For a firmware
crash dump collection, there are better solutions like devcoredump as
already pointed out by Loic. The firmware update function can be
implemented using the devlink firmware flashing API. You could see the
use of both APIs in the IOSM driver.
If none of these interfaces can be used to utilize the SAHARA
functionality, then, as Loic has already pointed out, such an
interface should probably go to the debugfs. But I suggest to
implement the firmware management functionality using the generic
kernel API. This will save time for end users, distro maintainers and
probably for modem vendor support too.
--
Sergey