From: Alexander Nyberg <alexn@telia.com>
To: vandep01@student.ucr.edu
Cc: linux-kernel@vger.kernel.org, ruschein@infomine.ucr.edu
Subject: Re: Kernel Bug Report
Date: Tue, 19 Jul 2005 11:32:26 +0200 [thread overview]
Message-ID: <1121765546.1121.2.camel@localhost.localdomain> (raw)
In-Reply-To: <1121362211.2043.3.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2225 bytes --]
> > It looks like it panics during a mem_cpy but I know its
> > difficult to tell just by the output.
> >
> > I get a code: f3 a4 c3 66 66 66 90 66 66 66 90 66 66 66 90 66
> >
> > The problem appears very reproducable so I can provide more
> > information upon request.
>
> What does the rest of the panic say? There should be text above this
> that tells where the panic occured and why. Can you please send that
> here?
Ok, could you please try the this patch, I'll attach it aswell:
From: Andreas Steinmetz <ast@domdv.de>
from include/linux/kernel.h:
#define ALIGN(x,a) (((x)+(a)-1)&~((a)-1))
from crypto/cipher.c:
unsigned int alignmask = ...
u8 *src = (u8 *)ALIGN((unsigned long)buffer, alignmask + 1);
...
unsigned int alignmask = ...
u8 *tmp = (u8 *)ALIGN((unsigned long)buffer, alignmask + 1);
...
unsigned int align;
addr = ALIGN(addr, align);
addr += ALIGN(tfm->__crt_alg->cra_ctxsize, align);
The compiler first does ~((a)-1)) and then expands the unsigned int to
unsigned long for the & operation. So we end up with only the lower 32
bits of the address. Who did smoke what to do this? Patch attached.
--
Andreas Steinmetz SPAMmers use robotrap@domdv.de
--- linux.orig/crypto/cipher.c 2005-07-17 13:35:15.000000000 +0200
+++ linux/crypto/cipher.c 2005-07-17 14:04:00.000000000 +0200
@@ -41,7 +41,7 @@
struct scatter_walk *in,
struct scatter_walk *out, unsigned int bsize)
{
- unsigned int alignmask = crypto_tfm_alg_alignmask(desc->tfm);
+ unsigned long alignmask = crypto_tfm_alg_alignmask(desc->tfm);
u8 buffer[bsize * 2 + alignmask];
u8 *src = (u8 *)ALIGN((unsigned long)buffer, alignmask + 1);
u8 *dst = src + bsize;
@@ -160,7 +160,7 @@
unsigned int nbytes)
{
struct crypto_tfm *tfm = desc->tfm;
- unsigned int alignmask = crypto_tfm_alg_alignmask(tfm);
+ unsigned long alignmask = crypto_tfm_alg_alignmask(tfm);
u8 *iv = desc->info;
if (unlikely(((unsigned long)iv & alignmask))) {
@@ -424,7 +424,7 @@
}
if (ops->cit_mode == CRYPTO_TFM_MODE_CBC) {
- unsigned int align;
+ unsigned long align;
unsigned long addr;
switch (crypto_tfm_alg_blocksize(tfm)) {
--------------080406080505060706090703--
-
[-- Attachment #2: crypto_64bit_align_masks.patch --]
[-- Type: message/rfc822, Size: 1901 bytes --]
From: Andreas Steinmetz <ast@domdv.de>
Subject: No Subject
Date: Tue, 19 Jul 2005 11:32:26 +0200
Message-ID: <1121765546.1121.3.camel@localhost.localdomain>
from include/linux/kernel.h:
#define ALIGN(x,a) (((x)+(a)-1)&~((a)-1))
from crypto/cipher.c:
unsigned int alignmask = ...
u8 *src = (u8 *)ALIGN((unsigned long)buffer, alignmask + 1);
...
unsigned int alignmask = ...
u8 *tmp = (u8 *)ALIGN((unsigned long)buffer, alignmask + 1);
...
unsigned int align;
addr = ALIGN(addr, align);
addr += ALIGN(tfm->__crt_alg->cra_ctxsize, align);
The compiler first does ~((a)-1)) and then expands the unsigned int to
unsigned long for the & operation. So we end up with only the lower 32
bits of the address. Who did smoke what to do this? Patch attached.
--
Andreas Steinmetz SPAMmers use robotrap@domdv.de
--- linux.orig/crypto/cipher.c 2005-07-17 13:35:15.000000000 +0200
+++ linux/crypto/cipher.c 2005-07-17 14:04:00.000000000 +0200
@@ -41,7 +41,7 @@
struct scatter_walk *in,
struct scatter_walk *out, unsigned int bsize)
{
- unsigned int alignmask = crypto_tfm_alg_alignmask(desc->tfm);
+ unsigned long alignmask = crypto_tfm_alg_alignmask(desc->tfm);
u8 buffer[bsize * 2 + alignmask];
u8 *src = (u8 *)ALIGN((unsigned long)buffer, alignmask + 1);
u8 *dst = src + bsize;
@@ -160,7 +160,7 @@
unsigned int nbytes)
{
struct crypto_tfm *tfm = desc->tfm;
- unsigned int alignmask = crypto_tfm_alg_alignmask(tfm);
+ unsigned long alignmask = crypto_tfm_alg_alignmask(tfm);
u8 *iv = desc->info;
if (unlikely(((unsigned long)iv & alignmask))) {
@@ -424,7 +424,7 @@
}
if (ops->cit_mode == CRYPTO_TFM_MODE_CBC) {
- unsigned int align;
+ unsigned long align;
unsigned long addr;
switch (crypto_tfm_alg_blocksize(tfm)) {
--------------080406080505060706090703--
-
next prev parent reply other threads:[~2005-07-19 9:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-14 17:10 Kernel Bug Report Paul Vander Griend
2005-07-14 17:30 ` Alexander Nyberg
2005-07-19 9:32 ` Alexander Nyberg [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-07-15 19:04 Lee
2005-07-15 19:19 ` Lee Revell
2005-07-15 19:24 ` Lee
2005-07-15 19:38 ` Lee Revell
2005-07-15 19:41 ` Lee
2004-06-19 19:34 David Michael Leo Brown Jr.
2004-06-20 8:50 ` Arjan van de Ven
2002-04-19 0:53 vinny.k
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1121765546.1121.2.camel@localhost.localdomain \
--to=alexn@telia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ruschein@infomine.ucr.edu \
--cc=vandep01@student.ucr.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox