It's been about a week since I posted this bug report, and I haven't gotten any responses. Is there someone I should contact directly? Can someone please point me in the right direction?

Thanks,
Ollie

Ollie Wild wrote:

There's a bug in Hitachi SuperH csum_partial_copy_generic() implementation. If the supplied length is 1 (and several alignment conditions are met), the function immediately branches to label 4. However, the assembly at label 4 expects the length to be stored in register r2. Since this has not occurred, subsequent behavior is undefined.

This can cause bad payload checksums in TCP connections.

I've fixed the problem by initializing register r2 prior to the branch instruction.

Ollie

------------------------------------------------------------------------

diff --git a/arch/sh/lib/checksum.S b/arch/sh/lib/checksum.S
--- a/arch/sh/lib/checksum.S
+++ b/arch/sh/lib/checksum.S
@@ -202,8 +202,9 @@ ENTRY(csum_partial_copy_generic)
        cmp/pz  r6              ! Jump if we had at least two bytes.
        bt/s    1f
         clrt
+       add     #2,r6           ! r6 was < 2.        Deal with it.
        bra     4f
-        add    #2,r6           ! r6 was < 2.        Deal with it.
+        mov    r6,r2

3:      ! Handle different src and dest alignments.
        ! This is not common, so simple byte by byte copy will do.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to