When blk_queue_enter() waits for a queue to unfreeze, or unset the
PREEMPT_ONLY flag, do not allow it to be interrupted by a signal.
The PREEMPT_ONLY flag was introduced later in commit 3a0a529971ec
("block, scsi: Make SCSI quiesce and resume work reliably"). Note the SCSI
device is resumed asynchronously, i.e. after un-freezing userspace tasks.
So that commit exposed the bug as a regression in v4.15. A mysterious
SIGBUS (or -EIO) sometimes happened during the time the device was being
resumed. Most frequently, there was no kernel log message, and we saw Xorg
or Xwayland killed by SIGBUS.[1]
[1] E.g. https://bugzilla.redhat.com/show_bug.cgi?id=1553979
Without this fix, I get an IO error in this test:
# dd if=/dev/sda of=/dev/null iflag=direct & \
while killall -SIGUSR1 dd; do sleep 0.1; done & \
echo mem > /sys/power/state ; \
sleep 5; killall dd # stop after 5 seconds
The interruptible wait was added to blk_queue_enter in
commit 3ef28e83ab15 ("block: generic request_queue reference counting").
Before then, the interruptible wait was only in blk-mq, but I don't think
it could ever have been correct.
Cc: stable(a)vger.kernel.org
Signed-off-by: Alan Jenkins <alan.christopher.jenkins(a)gmail.com>
---
block/blk-core.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index abcb8684ba67..5a6d20069364 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -915,7 +915,6 @@ int blk_queue_enter(struct request_queue *q, blk_mq_req_flags_t flags)
while (true) {
bool success = false;
- int ret;
rcu_read_lock();
if (percpu_ref_tryget_live(&q->q_usage_counter)) {
@@ -947,14 +946,12 @@ int blk_queue_enter(struct request_queue *q, blk_mq_req_flags_t flags)
*/
smp_rmb();
- ret = wait_event_interruptible(q->mq_freeze_wq,
+ wait_event(q->mq_freeze_wq,
(atomic_read(&q->mq_freeze_depth) == 0 &&
(preempt || !blk_queue_preempt_only(q))) ||
blk_queue_dying(q));
if (blk_queue_dying(q))
return -ENODEV;
- if (ret)
- return ret;
}
}
--
2.14.3
From: Fabio Estevam <fabio.estevam(a)nxp.com>
imx6ul and imx7 report the following error:
caam_jr 2142000.jr1: 40000789: DECO: desc idx 7:
Protocol Size Error - A protocol has seen an error in size. When
running RSA, pdb size N < (size of F) when no formatting is used; or
pdb size N < (F + 11) when formatting is used.
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at crypto/asymmetric_keys/public_key.c:148
public_key_verify_signature+0x27c/0x2b0
This error happens because the signature contains 257 bytes, including
a leading zero as the first element.
Fix the problem by striping off the leading zero from input data
before feeding it to the CAAM accelerator.
Fixes: 8c419778ab57e497b5 ("crypto: caam - add support for RSA algorithm")
Cc: <stable(a)vger.kernel.org>
Reported-by: Martin Townsend <mtownsend1973(a)gmail.com>
Signed-off-by: Fabio Estevam <fabio.estevam(a)nxp.com>
---
drivers/crypto/caam/caampkc.c | 43 +++++++++++++++++++++++++++++++++++--------
1 file changed, 35 insertions(+), 8 deletions(-)
diff --git a/drivers/crypto/caam/caampkc.c b/drivers/crypto/caam/caampkc.c
index 7a897209..d2ad547 100644
--- a/drivers/crypto/caam/caampkc.c
+++ b/drivers/crypto/caam/caampkc.c
@@ -166,6 +166,14 @@ static void rsa_priv_f3_done(struct device *dev, u32 *desc, u32 err,
akcipher_request_complete(req, err);
}
+static void caam_rsa_drop_leading_zeros(const u8 **ptr, size_t *nbytes)
+{
+ while (!**ptr && *nbytes) {
+ (*ptr)++;
+ (*nbytes)--;
+ }
+}
+
static struct rsa_edesc *rsa_edesc_alloc(struct akcipher_request *req,
size_t desclen)
{
@@ -178,7 +186,34 @@ static struct rsa_edesc *rsa_edesc_alloc(struct akcipher_request *req,
int sgc;
int sec4_sg_index, sec4_sg_len = 0, sec4_sg_bytes;
int src_nents, dst_nents;
+ const u8 *buffer;
+ size_t len;
+
+ buffer = kzalloc(req->src_len, GFP_ATOMIC);
+ if (!buffer)
+ return ERR_PTR(-ENOMEM);
+
+ sg_copy_to_buffer(req->src, sg_nents(req->src),
+ (void *)buffer, req->src_len);
+ len = req->src_len;
+ /*
+ * Check if the buffer contains leading zero and if
+ * it does, drop the leading zero
+ */
+ if (buffer[0] == 0) {
+ caam_rsa_drop_leading_zeros(&buffer, &len);
+ if (!buffer) {
+ kfree(buffer);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ req->src_len -= 1;
+ sg_copy_from_buffer(req->src, sg_nents(req->src),
+ (void *)buffer, req->src_len);
+ }
+
+ kfree(buffer);
src_nents = sg_nents_for_len(req->src, req->src_len);
dst_nents = sg_nents_for_len(req->dst, req->dst_len);
@@ -683,14 +718,6 @@ static void caam_rsa_free_key(struct caam_rsa_key *key)
memset(key, 0, sizeof(*key));
}
-static void caam_rsa_drop_leading_zeros(const u8 **ptr, size_t *nbytes)
-{
- while (!**ptr && *nbytes) {
- (*ptr)++;
- (*nbytes)--;
- }
-}
-
/**
* caam_read_rsa_crt - Used for reading dP, dQ, qInv CRT members.
* dP, dQ and qInv could decode to less than corresponding p, q length, as the
--
2.7.4
I Sell Sure Spamming Toolz
What we have on Stock Daily
Inbox Webmail
Inbox SMTP
Fresh USA email leads
Fresh Canada email leads
Fresh Loan email leads
Fresh Business emails leads
Real Eastate email leads
Conference delegates email leads
Fresh Job Seaker emails
cPanel HTTP and HTTPs
Shell Zip/Unzipp
Mailer
RDP
All ScamPages
Bank ScamPage
Add me on whatsapp or call me
Watsapp: +2348107268246
Only Real buyers
Hello,
Good day,
I am Mohammed, Our company is interested in your product.
We have gone through your product site online and wish to make order of your
product.
Please do send us details of your products and company to our {email} Also
provide with the recent price
We await your response with quotation and specification.
[1] Payment terms
[2] And your products Warranty
(3] Minimum Order Quantity
Mohammed /Purchasing Manager
Telephone: +966 3 867 1902
Fax: +966 3 867 3435
tr.export.import(a)outlook.com
PAN TRADING EQUIPMENT'S WORLDWIDE
Address: Dallah street, Al Rehab
Saudi Arabia
Hi Greg,
There are two important v4l2-core fixes on the patches merged this week by
Linux.
1) media: v4l2-core: fix size of devnode_nums[] bitarray
This patch correct a regression against Kernel 4.16. It affects notebooks
with advanced Synaptics mice (and similar touch devices). On those devices,
the pad produces an image with is handled via V4L2. Without this patch,
the input driver OOPSes at probing time:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
2) v4l2-compat-ioctl32: don't oops on overlay
This patch complements the security fix we've made at the V4L2 core
compat32 logic. It fixes an illegal use of an __user pointer without
first convert into a Kernel pointer with get_user(). It wasn't detect
before, as it uses an obscure streaming mode of V4L2 (overlay mode):
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
This one should go all the way down to stable Kernels. Here, I was able
to reproduce the bug with both upstream Kernel and Kernel 3.18. The
patch applied without any conflicts on both.
Could you please add both on your next set of -stable releases?
Thanks,
Mauro