linux-toradex.git, branch v2.6.21.6

Linux 2.6.21.6

2007-07-07T04:47:55+00:00

nf_conntrack_h323: add checking of out-of-range on choices' index values

2007-07-07T04:47:05+00:00

[NETFILTER]: nf_conntrack_h323: add checking of out-of-range on choices' index values

Choices' index values may be out of range while still encoded in the fixed
length bit-field. This bug may cause access to undefined types (NULL
pointers) and thus crashes (Reported by Zhongling Wen).

This patch also adds checking of decode flag when decoding SEQUENCEs.

Signed-off-by: Jing Min Zhao 
Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Linux 2.6.21.5

2007-06-11T18:37:06+00:00

[PATCH] BLUETOOTH: Fix locking in hci_sock_dev_event().

2007-06-11T18:36:54+00:00

We presently use lock_sock() to acquire a lock on a socket in
hci_sock_dev_event(), but this goes BUG because lock_sock()
can sleep and we're already holding a read-write spinlock at
that point. So, we must use the non-sleeping BH version,
bh_lock_sock().

However, hci_sock_dev_event() is called from user context and
hence using simply bh_lock_sock() will deadlock against a
concurrent softirq that tries to acquire a lock on the same
socket. Hence, disabling BH's before acquiring the socket lock
and enable them afterwards, is the proper solution to fix
socket locking in hci_sock_dev_event().

Signed-off-by: Satyam Sharma 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Jiri Kosina 
Signed-off-by: David S. Miller 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

[PATCH] TCP: Use default 32768-61000 outgoing port range in all cases.

2007-06-11T18:36:54+00:00

This diff changes the default port range used for outgoing connections,
from "use 32768-61000 in most cases, but use N-4999 on small boxes
(where N is a multiple of 1024, depending on just *how* small the box
is)" to just "use 32768-61000 in all cases".

I don't believe there are any drawbacks to this change, and it keeps
outgoing connection ports farther away from the mess of
IANA-registered ports.

Signed-off-by: Mark Glines 
Signed-off-by: David S. Miller 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

[PATCH] SPARC64: Don't be picky about virtual-dma values on sun4v.

2007-06-11T18:36:53+00:00

Handle arbitrary base and length values as long as they
are multiples of IO_PAGE_SIZE.

Bug found by Arun Kumar Rao.

Signed-off-by: David S. Miller 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

[PATCH] SPARC64: Fix _PAGE_EXEC_4U check in sun4u I-TLB miss handler.

2007-06-11T18:36:53+00:00

It was using an immediate _PAGE_EXEC_4U value in an 'and'
instruction to perform the test.  This doesn't work because
the immediate field is signed 13-bit, this the mask being
tested against the PTE was 0x1000 sign-extended to 32-bits
instead of just plain 0x1000.

Signed-off-by: David S. Miller 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

[PATCH] SPARC64: Fix two bugs wrt. kernel 4MB TSB.

2007-06-11T18:36:53+00:00

1) The TSB lookup was not using the correct hash mask.

2) It was not aligned on a boundary equal to it's size,
   which is required by the sun4v Hypervisor.

wasn't having it's return value checked, and that bug will be fixed up
as well in a subsequent changeset.

Signed-off-by: David S. Miller 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

[PATCH] NET: "wrong timeout value" in sk_wait_data() v2

2007-06-11T18:36:53+00:00

sys_setsockopt() do not check properly timeout values for
SO_RCVTIMEO/SO_SNDTIMEO, for example it's possible to set negative timeout
values. POSIX do not defines behaviour for sys_setsockopt in case negative
timeouts, but requires that setsockopt() shall fail with -EDOM if the send and
receive timeout values are too big to fit into the timeout fields in the socket
structure.
In current implementation negative timeout can lead to error messages like
"schedule_timeout: wrong timeout value".

Proposed patch:
- checks tv_usec and returns -EDOM if it is wrong
- do not allows to set negative timeout values (sets 0 instead) and outputs
ratelimited information message about such attempts.

Signed-off-By: Vasily Averin 
Signed-off-by: David S. Miller 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

[PATCH] SPARC: Linux always started with 9600 8N1

2007-06-11T18:36:52+00:00

The Linux kernel ignored the PROM's serial settings (115200,n,8,1 in
my case). This was because mode_prop remained "ttyX-mode" (expected:
"ttya-mode") due to the constness of string literals when used with
"char *". Since there is no "ttyX-mode" property in the PROM, Linux
always used the default 9600.

[ Investigation of the suncore.s assembler reveals that gcc optimizied
  away the stores, yet did not emit a warning, which is a pretty
  anti-social thing to do and is the only reason this bug lived for
  so long -DaveM ]

Signed-off-by: Jan Engelhardt 
Signed-off-by: David S. Miller 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman