Skip to content
  1. Jan 19, 2008
  3. Jan 16, 2008
  5. Jan 15, 2008
  7. Jan 06, 2008
  9. Dec 09, 2007
    • Adrian Bunk's avatar
      ipv4/arp.c:arp_process(): remove bogus #ifdef mess · 86c4424d
      Adrian Bunk authored 
      

The #ifdef's in arp_process() were not only a mess, they were also wrong
in the CONFIG_NET_ETHERNET=n and (CONFIG_NETDEV_1000=y or
CONFIG_NETDEV_10000=y) cases.

Since they are not required this patch removes them.

Also removed are some #ifdef's around #include's that caused compile
errors after this change.

Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      86c4424d
  11. Nov 13, 2007
    • Patrick McHardy's avatar
      [NETLINK]: Fix unicast timeouts · 47d5d333
      Patrick McHardy authored 
      

[ Upstream commit: c3d8d1e3 ]

Commit ed6dcf4a in the history.git tree broke netlink_unicast timeouts
by moving the schedule_timeout() call to a new function that doesn't
propagate the remaining timeout back to the caller. This means on each
retry we start with the full timeout again.

ipc/mqueue.c seems to actually want to wait indefinitely so this
behaviour is retained.

Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      47d5d333
    • Florian Zumbiehl's avatar
      PPPOE: fix memory leak (local DoS) (CVE-2007-2525) · 624e4ff6
      Florian Zumbiehl authored 
      

This patch fixes a memory leak when a PPPoE socket is release()d after
it has been connect()ed, but before the PPPIOCGCHAN ioctl ever has been
called on it.

This is somewhat of a security problem, too, since PPPoE sockets can be
created by any user, so any user can easily allocate all the machine's
RAM to non-swappable address space and thus DoS the system.

Is there any specific reason for PPPoE sockets being available to any
unprivileged process, BTW? After all, you need a packet socket for the
discovery stage anyway, so it's unlikely that any unprivileged process
will ever need to create a PPPoE socket, no? Allocating all session IDs
for a known AC is a kind of DoS, too, after all - with Juniper ERXes,
this is really easy, actually, since they don't ever assign session ids
above 8000 ...

Signed-off-by: default avatarFlorian Zumbiehl <florz@florz.de>
Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      624e4ff6
    • Radu Rendec's avatar
      [PKT_SCHED] CLS_U32: Fix endianness problem with u32 classifier hash masks. · 07c24203
      Radu Rendec authored 
      

While trying to implement u32 hashes in my shaping machine I ran into
a possible bug in the u32 hash/bucket computing algorithm
(net/sched/cls_u32.c).

The problem occurs only with hash masks that extend over the octet
boundary, on little endian machines (where htonl() actually does
something).

Let's say that I would like to use 0x3fc0 as the hash mask. This means
8 contiguous "1" bits starting at b6. With such a mask, the expected
(and logical) behavior is to hash any address in, for instance,
192.168.0.0/26 in bucket 0, then any address in 192.168.0.64/26 in
bucket 1, then 192.168.0.128/26 in bucket 2 and so on.

This is exactly what would happen on a big endian machine, but on
little endian machines, what would actually happen with current
implementation is 0x3fc0 being reversed (into 0xc03f0000) by htonl()
in the userspace tool and then applied to 192.168.x.x in the u32
classifier. When shifting right by 16 bits (rank of first "1" bit in
the reversed mask) and applying the divisor mask (0xff for divisor
256), what would actually remain is 0x3f applied on the "168" octet of
the address.

One could say is this can be easily worked around by taking endianness
into account in userspace and supplying an appropriate mask (0xfc03)
that would be turned into contiguous "1" bits when reversed
(0x03fc0000). But the actual problem is the network address (inside
the packet) not being converted to host order, but used as a
host-order value when computing the bucket.

Let's say the network address is written as n31 n30 ... n0, with n0
being the least significant bit. When used directly (without any
conversion) on a little endian machine, it becomes n7 ... n0 n8 ..n15
etc in the machine's registers. Thus bits n7 and n8 would no longer be
adjacent and 192.168.64.0/26 and 192.168.128.0/26 would no longer be
consecutive.

The fix is to apply ntohl() on the hmask before computing fshift,
and in u32_hash_fold() convert the packet data to host order before
shifting down by fshift.

With helpful feedback from Jamal Hadi Salim and Jarek Poplawski.

Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      07c24203
    • Evgeniy Polyakov's avatar
      [PKT_SCHED]: Fix OOPS when removing devices from a teql queuing discipline · 526d19a5
      Evgeniy Polyakov authored 
      

[ Upstream commit: 4f9f8311 ]

tecl_reset() is called from deactivate and qdisc is set to noop already,
but subsequent teql_xmit does not know about it and dereference private
data as teql qdisc and thus oopses.
not catch it first :)

Signed-off-by: default avatarEvgeniy Polyakov <johnpol@2ka.mipt.ru>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      526d19a5
    • Peter Zijlstra's avatar
      i386: fixup TRACE_IRQ breakage · 9c78b87b
      Peter Zijlstra authored 
      

The TRACE_IRQS_ON function in iret_exc: calls a C function without
ensuring that the segments are set properly. Move the trace function and
the enabling of interrupt into the C stub.

Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      9c78b87b
    • Roland McGrath's avatar
      Handle bogus %cs selector in single-step instruction decoding (CVE-2007-3731) · 08cdcb56
      Roland McGrath authored 
      

The code for LDT segment selectors was not robust in the face of a bogus
selector set in %cs via ptrace before the single-step was done.

Signed-off-by: default avatarRoland McGrath <roland@redhat.com>
Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      08cdcb56
    • Ben Collins's avatar
      [ATM]: Add CPPFLAGS to byteorder.h check · d4f042f0
      Ben Collins authored 
      

O= builds produced errors in the shell command because of unfound headers.

Signed-off-by: default avatarBen Collins <bcollins@ubuntu.com>
Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      d4f042f0
    • Michal Schmidt's avatar
      [PPP_MPPE]: Don't put InterimKey on the stack · 6833f471
      Michal Schmidt authored 
      

ppp_mppe puts a crypto key on the kernel stack, then passes the
address of that into the crypto layer.  That doesn't work because the
crypto layer needs to be able to do virt_to_*() on the address which
does not universally work for the kernel stack on all platforms.

Adrian Bunk:
Backported to 2.6.16.

Signed-off-by: default avatarMichal Schmidt <mschmidt@redhat.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      6833f471
  13. Nov 12, 2007
    • Patrick McHardy's avatar
      [INET_DIAG]: Fix oops in netlink_rcv_skb · 674ce0f3
      Patrick McHardy authored 
      

netlink_run_queue() doesn't handle multiple processes processing the
queue concurrently. Serialize queue processing in inet_diag to fix
a oops in netlink_rcv_skb caused by netlink_run_queue passing a
NULL for the skb.

BUG: unable to handle kernel NULL pointer dereference at virtual address 00000054
[349587.500454]  printing eip:
[349587.500457] c03318ae
[349587.500459] *pde = 00000000
[349587.500464] Oops: 0000 [#1]
[349587.500466] PREEMPT SMP
[349587.500474] Modules linked in: w83627hf hwmon_vid i2c_isa
[349587.500483] CPU:    0
[349587.500485] EIP:    0060:[<c03318ae>]    Not tainted VLI
[349587.500487] EFLAGS: 00010246   (2.6.22.3 #1)
[349587.500499] EIP is at netlink_rcv_skb+0xa/0x7e
[349587.500506] eax: 00000000   ebx: 00000000   ecx: c148d2a0   edx: c0398819
[349587.500510] esi: 00000000   edi: c0398819   ebp: c7a21c8c   esp: c7a21c80
[349587.500517] ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
[349587.500521] Process oidentd (pid: 17943, ti=c7a20000 task=cee231c0 task.ti=c7a20000)
[349587.500527] Stack: 00000000 c7a21cac f7c8ba78 c7a21ca4 c0331962 c0398819 f7c8ba00 0000004c
[349587.500542]        f736f000 c7a21cb4 c03988e3 00000001 f7c8ba00 c7a21cc4 c03312a5 0000004c
[349587.500558]        f7c8ba00 c7a21cd4 c0330681 f7c8ba00 e4695280 c7a21d00 c03307c6 7fffffff
[349587.500578] Call Trace:
[349587.500581]  [<c010361a>] show_trace_log_lvl+0x1c/0x33
[349587.500591]  [<c01036d4>] show_stack_log_lvl+0x8d/0xaa
[349587.500595]  [<c010390e>] show_registers+0x1cb/0x321
[349587.500604]  [<c0103bff>] die+0x112/0x1e1
[349587.500607]  [<c01132d2>] do_page_fault+0x229/0x565
[349587.500618]  [<c03c8d3a>] error_code+0x72/0x78
[349587.500625]  [<c0331962>] netlink_run_queue+0x40/0x76
[349587.500632]  [<c03988e3>] inet_diag_rcv+0x1f/0x2c
[349587.500639]  [<c03312a5>] netlink_data_ready+0x57/0x59
[349587.500643]  [<c0330681>] netlink_sendskb+0x24/0x45
[349587.500651]  [<c03307c6>] netlink_unicast+0x100/0x116
[349587.500656]  [<c0330f83>] netlink_sendmsg+0x1c2/0x280
[349587.500664]  [<c02fcce9>] sock_sendmsg+0xba/0xd5
[349587.500671]  [<c02fe4d1>] sys_sendmsg+0x17b/0x1e8
[349587.500676]  [<c02fe92d>] sys_socketcall+0x230/0x24d
[349587.500684]  [<c01028d2>] syscall_call+0x7/0xb
[349587.500691]  =======================
[349587.500693] Code: f0 ff 4e 18 0f 94 c0 84 c0 0f 84 66 ff ff ff 89 f0 e8 86 e2 fc ff e9 5a ff ff ff f0 ff 40 10 eb be 55 89 e5 57 89 d7 56 89 c6 53 <8b> 50 54 83 fa 10 72 55 8b 9e 9c 00 00 00 31 c9 8b 03 83 f8 0f

Reported by Athanasius <link@miggy.org>

Adrian Bunk:
Backported to 2.6.16 based on a suggestion by David S. Miller.

Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      674ce0f3
    • YOSHIFUJI Hideaki's avatar
      [IPV6]: Fix unbalanced socket reference with MSG_CONFIRM. · 70b0f728
      YOSHIFUJI Hideaki authored 
      

Signed-off-by: default avatarYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      70b0f728
  15. Nov 05, 2007
  17. Nov 02, 2007
    • Adrian Bunk's avatar
      Linux 2.6.16.57-rc1 · d2a51c3a
      Adrian Bunk authored
      v2.6.16.57-rc1
      d2a51c3a
    • NeilBrown's avatar
      knfsd: allow nfsd READDIR to return 64bit cookies · 776a0f3d
      NeilBrown authored 
      

->readdir passes lofft_t offsets (used as nfs cookies) to
nfs3svc_encode_entry{,_plus}, but when they pass it on to encode_entry it
becomes an 'off_t', which isn't good.

So filesystems that returned 64bit offsets would lose.

Signed-off-by: default avatarNeil Brown <neilb@suse.de>
Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      776a0f3d
    • Nicholas Piggin's avatar
      buffer: memorder fix · 5ef24c68
      Nicholas Piggin authored 
      

unlock_buffer(), like unlock_page(), must not clear the lock without
ensuring that the critical section is closed.

Mingming later sent the same patch, saying:

We are running SDET benchmark and saw double free issue for ext3 extended
attributes block, which complains the same xattr block already being freed (in
ext3_xattr_release_block()).  The problem could also been triggered by
multiple threads loop untar/rm a kernel tree.

The race is caused by missing a memory barrier at unlock_buffer() before the
lock bit being cleared, resulting in possible concurrent h_refcounter update.
That causes a reference counter leak, then later leads to the double free that
we have seen.

Inside unlock_buffer(), there is a memory barrier is placed *after* the lock
bit is being cleared, however, there is no memory barrier *before* the bit is
cleared.  On some arch the h_refcount update instruction and the clear bit
instruction could be reordered, thus leave the critical section re-entered.

The race is like this: For example, if the h_refcount is initialized as 1,

cpu 0:                                   cpu1
--------------------------------------   -----------------------------------
lock_buffer() /* test_and_set_bit */
clear_buffer_locked(bh);
                                        lock_buffer() /* test_and_set_bit */
h_refcount = h_refcount+1; /* = 2*/     h_refcount = h_refcount + 1; /*= 2 */
                                        clear_buffer_locked(bh);
....                                    ......

We lost a h_refcount here.  We need a memory barrier before the buffer head
lock bit being cleared to force the order of the two writes.  Please apply.

Signed-off-by: default avatarNick Piggin <npiggin@suse.de>
Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      5ef24c68