Re: lib/mpi: BUG: sleeping function called from invalid context on next-20160726
On Wed, Jul 27, 2016 at 11:05:05PM +0200, Nicolai Stange wrote:
>
> with linux-next-20160726, I get this:
>
> BUG: sleeping function called from invalid context at
> /mnt/scratch/nic/linux-next/mm/slab.h:388
Does this patch help?
> I would have sent a patch, but there is another point which puzzles me
> in mpi_read_raw_from_sgl():
>
> [...]
> const u8 *buff;
> [...]
> sg_miter_start(&miter, sgl, ents, SG_MITER_ATOMIC | SG_MITER_FROM_SG);
>
> lzeros = 0;
> len = 0;
> while (nbytes > 0) {
> while (len && !*buff) {
> lzeros++;
> len--;
> buff++;
> }
>
>
> Thus, buff isn't initialized before its first use? Or am I misreading
> something here?
On the first entry len is zero therefore we will go to the end of the
loop and initialise buff. Anyway, it will no longer be as confusing
with this patch applied.
Thanks,
---8<---
Subject: lib/mpi: Fix SG miter leak
In mpi_read_raw_from_sgl we may leak the SG miter resouces after
reading the leading zeroes. This patch fixes this by stopping the
iteration once the leading zeroes have been read.
Fixes: 127827b9c295 ("lib/mpi: Do not do sg_virt")
Reported-by: Nicolai Stange
Signed-off-by: Herbert Xu
diff --git a/lib/mpi/mpicoder.c b/lib/mpi/mpicoder.c
index c6272ae..5a0f75a 100644
--- a/lib/mpi/mpicoder.c
+++ b/lib/mpi/mpicoder.c
@@ -363,6 +363,9 @@ MPI mpi_read_raw_from_sgl(struct scatterlist *sgl, unsigned
int nbytes)
lzeros = 0;
}
+ miter.consumed = lzeros;
+ sg_miter_stop(&miter);
+
nbytes -= lzeros;
nbits = nbytes * 8;
if (nbits > MAX_EXTERN_MPI_BITS) {
@@ -390,7 +393,10 @@ MPI mpi_read_raw_from_sgl(struct scatterlist *sgl,
unsigned int nbytes)
z = BYTES_PER_MPI_LIMB - nbytes % BYTES_PER_MPI_LIMB;
z %= BYTES_PER_MPI_LIMB;
- for (;;) {
+ while (sg_miter_next(&miter)) {
+ buff = miter.addr;
+ len = miter.length;
+
for (x = 0; x < len; x++) {
a <<= 8;
a |= *buff++;
@@ -400,12 +406,6 @@ MPI mpi_read_raw_from_sgl(struct scatterlist *sgl,
unsigned int nbytes)
}
}
z += x;
-
- if (!sg_miter_next(&miter))
- break;
-
- buff = miter.addr;
- len = miter.length;
}
return val;
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: marvell - Update cache with input sg only when it is unmapped
Romain Perier wrote:
> So far, the cache of the ahash requests was updated from the 'complete'
> operation. This complete operation is called from mv_cesa_tdma_process
> before the cleanup operation, which means that the content of req->src
> can be read and copied when it is still mapped. This commit fixes the
> issue by moving this cache update from mv_cesa_ahash_complete to
> mv_cesa_ahash_req_cleanup, so the copy is done once the sglist is
> unmapped.
>
> Fixes: 1bf6682cb31d ("crypto: marvell - Add a complete operation for..")
> Signed-off-by: Romain Perier
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: marvell - Fix memory leaks in TDMA chain for cipher requests
Romain Perier wrote:
> So far in mv_cesa_ablkcipher_dma_req_init, if an error is thrown while
> the tdma chain is built there is a memory leak. This issue exists
> because the chain is assigned later at the end of the function, so the
> cleanup function is called with the wrong version of the chain.
>
> Fixes: db509a45339f ("crypto: marvell/cesa - add TDMA support")
> Signed-off-by: Romain Perier
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: marvell - Don't chain at DMA level when backlog is disabled
Romain Perier wrote:
> The flag CRYPTO_TFM_REQ_MAY_BACKLOG is optional and can be set from the
> user to put requests into the backlog queue when the main cryptographic
> queue is full. Before calling mv_cesa_tdma_chain we must check the value
> of the return status to be sure that the current request has been
> correctly queued or added to the backlog.
>
> Fixes: 85030c5168f1 ("crypto: marvell - Add support for chaining...")
> Signed-off-by: Romain Perier
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Loan Offer
Instant cash Loan with same day payout on all kinds of Loan are available at Quick Financial Home were loan is offered at 2% per annul. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] /dev/random driver changes for 4.8
On Wed, Jul 27, 2016 at 6:12 AM, Theodore Ts'o wrote: > > Are you planning on pulling the random tree this cycle? I'm not sure > if you wanted to let it soak for a few days in linux-next, or whether > you want to wait another full release cycle It's next in line in my queue, so unless it blows up spectacularly in my face I'm pulling it this cycle. It's not liek the pull request looks particularly scary, Linus -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
lib/mpi: BUG: sleeping function called from invalid context on next-20160726
Hi,
with linux-next-20160726, I get this:
BUG: sleeping function called from invalid context at
/mnt/scratch/nic/linux-next/mm/slab.h:388
in_atomic(): 1, irqs_disabled(): 0, pid: 369, name: systemd-udevd
no locks held by systemd-udevd/369.
CPU: 2 PID: 369 Comm: systemd-udevd Not tainted 4.7.0-rc1+ #248
Hardware name: Dell Inc. Latitude E6540/0725FP, BIOS A10 06/26/2014
0286 899a9b52 88003f53b8f8 814472d5
8800c0752680 81c557d8 88003f53b920 810dfba9
81c557d8 0184 88003f53b948
Call Trace:
[] dump_stack+0x86/0xc1
[] ___might_sleep+0x179/0x230
[] __might_sleep+0x49/0x80
[] kmem_cache_alloc_trace+0x1d1/0x2e0
[] ? mpi_alloc+0x20/0x80
[] mpi_alloc+0x20/0x80
[] mpi_read_raw_from_sgl+0xd5/0x1e0
[] rsa_verify+0x66/0x100
[] pkcs1pad_verify+0xae/0xf0
[] public_key_verify_signature+0x1f9/0x290
[] public_key_verify_signature_2+0x15/0x20
[] verify_signature+0x3c/0x50
[] pkcs7_validate_trust+0x11d/0x230
[] verify_pkcs7_signature+0xa2/0x150
[] mod_verify_sig+0xdd/0x130
[] load_module+0x16c/0x2970
[] ? vfs_read+0x11b/0x130
[] ? kernel_read_file+0x152/0x170
[] SYSC_finit_module+0xe6/0x120
[] SyS_finit_module+0xe/0x10
[] do_syscall_64+0x67/0x190
[] entry_SYSCALL64_slow_path+0x25/0x25
Reason is 127827b9c295 ("lib/mpi: Do not do sg_virt") which makes
mpi_read_raw_from_sgl() calling mpi_alloc() while having a sg entry
mapped via kmap_atomic() and thus, preemption disabled.
I would have sent a patch, but there is another point which puzzles me
in mpi_read_raw_from_sgl():
[...]
const u8 *buff;
[...]
sg_miter_start(&miter, sgl, ents, SG_MITER_ATOMIC | SG_MITER_FROM_SG);
lzeros = 0;
len = 0;
while (nbytes > 0) {
while (len && !*buff) {
lzeros++;
len--;
buff++;
}
Thus, buff isn't initialized before its first use? Or am I misreading
something here?
Thanks,
Nicolai
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] /dev/random driver changes for 4.8
On Mon, Jul 25, 2016 at 02:44:24AM -0400, Theodore Ts'o wrote: > The following changes since commit 1a695a905c18548062509178b98bc91e67510864: > > Linux 4.7-rc1 (2016-05-29 09:29:24 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random.git > tags/random_for_linus > > for you to fetch changes up to 86a574de4590ffe6fd3f3ca34cdcf655a78e36ec: > > random: strengthen input validation for RNDADDTOENTCNT (2016-07-03 17:09:33 > -0400) Hi Linus, Are you planning on pulling the random tree this cycle? I'm not sure if you wanted to let it soak for a few days in linux-next, or whether you want to wait another full release cycle, given that the random tree had gotten dropped from linux-next some time ago without my realizing it. (The code has actually been soaking for 1.5 releases, since I wanted to give it lots of soak time, but of course, it would have been more helpful if it actually was in linux-next. Sigh...) - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] DH support: add KDF handling support
Am Mittwoch, 27. Juli 2016, 08:55:31 CEST schrieb David Howells: Hi David, > Mat Martineau wrote: > > > Though, shall I stuff the wrapper code back into the existing dh_compute > > > functions or can I leave them as separate functions? > > > > I'm not sure. In the existing code there's one keyctl wrapper per keyctl > > command. A combined wrapper would need some extra logic to decide whether > > kdfparams is passed in or not, which is different from existing code. > > You shouldn't change the existing keyctl wrappers. Feel free to add another > one with extra arguments. I created dh_compute_kdf and dh_compute_kdf_oi where the latter takes the other information from STDIN. > > David Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] DH support: add KDF handling support
Mat Martineau wrote: > > Though, shall I stuff the wrapper code back into the existing dh_compute > > functions or can I leave them as separate functions? > > I'm not sure. In the existing code there's one keyctl wrapper per keyctl > command. A combined wrapper would need some extra logic to decide whether > kdfparams is passed in or not, which is different from existing code. You shouldn't change the existing keyctl wrappers. Feel free to add another one with extra arguments. David -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
