linux-toradex.git, branch v2.6.32.62

Linux 2.6.32.62

2014-05-19T05:54:39+00:00

Signed-off-by: Willy Tarreau

floppy: don't write kernel-only members to FDRAWCMD ioctl output

2014-05-19T05:54:39+00:00

Do not leak kernel-only floppy_raw_cmd structure members to userspace.
This includes the linked-list pointer and the pointer to the allocated
DMA space.

Signed-off-by: Matthew Daley 
Signed-off-by: Linus Torvalds 
(cherry picked from commit 2145e15e0557a01b9195d1c7199a1b92cb9be81f)
Signed-off-by: Willy Tarreau

floppy: ignore kernel-only members in FDRAWCMD ioctl input

2014-05-19T05:54:38+00:00

Always clear out these floppy_raw_cmd struct members after copying the
entire structure from userspace so that the in-kernel version is always
valid and never left in an interdeterminate state.

Signed-off-by: Matthew Daley 
Signed-off-by: Linus Torvalds 
(cherry picked from commit ef87dbe7614341c2e7bfe8d32fcb7028cc97442c)
[wt: be careful in 2.6.32 we still have the ugly macros everywhere]
Signed-off-by: Willy Tarreau

netfilter: nf_conntrack_dccp: fix skb_header_pointer API usages

2014-05-19T05:54:37+00:00

commit b22f5126a24b3b2f15448c3f2a254fc10cbc2b92 upstream

Some occurences in the netfilter tree use skb_header_pointer() in
the following way ...

  struct dccp_hdr _dh, *dh;
  ...
  skb_header_pointer(skb, dataoff, sizeof(_dh), &dh);

... where dh itself is a pointer that is being passed as the copy
buffer. Instead, we need to use &_dh as the forth argument so that
we're copying the data into an actual buffer that sits on the stack.

Currently, we probably could overwrite memory on the stack (e.g.
with a possibly mal-formed DCCP packet), but unintentionally, as
we only want the buffer to be placed into _dh variable.

Fixes: 2bc780499aa3 ("[NETFILTER]: nf_conntrack: add DCCP protocol support")
Signed-off-by: Daniel Borkmann 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Willy Tarreau

s390: fix kernel crash due to linkage stack instructions

2014-05-19T05:54:37+00:00

commit 8d7f6690cedb83456edd41c9bd583783f0703bf0 upstream

The kernel currently crashes with a low-address-protection exception
if a user space process executes an instruction that tries to use the
linkage stack. Set the base-ASTE origin and the subspace-ASTE origin
of the dispatchable-unit-control-table to point to a dummy ASTE.
Set up control register 15 to point to an empty linkage stack with no
room left.

A user space process with a linkage stack instruction will still crash
but with a different exception which is correctly translated to a
segmentation fault instead of a kernel oops.

Signed-off-by: Martin Schwidefsky 
[dannf: backported to Debian's 2.6.32]
Signed-off-by: Willy Tarreau

SELinux: Fix kernel BUG on empty security contexts.

2014-05-19T05:54:36+00:00

commit 2172fa709ab32ca60e86179dc67d0857be8e2c98 upstream

Setting an empty security context (length=0) on a file will
lead to incorrectly dereferencing the type and other fields
of the security context structure, yielding a kernel BUG.
As a zero-length security context is never valid, just reject
all such security contexts whether coming from userspace
via setxattr or coming from the filesystem upon a getxattr
request by SELinux.

Setting a security context value (empty or otherwise) unknown to
SELinux in the first place is only possible for a root process
(CAP_MAC_ADMIN), and, if running SELinux in enforcing mode, only
if the corresponding SELinux mac_admin permission is also granted
to the domain by policy.  In Fedora policies, this is only allowed for
specific domains such as livecd for setting down security contexts
that are not defined in the build host policy.

Reproducer:
su
setenforce 0
touch foo
setfattr -n security.selinux foo

Caveat:
Relabeling or removing foo after doing the above may not be possible
without booting with SELinux disabled.  Any subsequent access to foo
after doing the above will also trigger the BUG.

BUG output from Matthew Thode:
[  473.893141] ------------[ cut here ]------------
[  473.962110] kernel BUG at security/selinux/ss/services.c:654!
[  473.995314] invalid opcode: 0000 [#6] SMP
[  474.027196] Modules linked in:
[  474.058118] CPU: 0 PID: 8138 Comm: ls Tainted: G      D   I
3.13.0-grsec #1
[  474.116637] Hardware name: Supermicro X8ST3/X8ST3, BIOS 2.0
07/29/10
[  474.149768] task: ffff8805f50cd010 ti: ffff8805f50cd488 task.ti:
ffff8805f50cd488
[  474.183707] RIP: 0010:[]  []
context_struct_compute_av+0xce/0x308
[  474.219954] RSP: 0018:ffff8805c0ac3c38  EFLAGS: 00010246
[  474.252253] RAX: 0000000000000000 RBX: ffff8805c0ac3d94 RCX:
0000000000000100
[  474.287018] RDX: ffff8805e8aac000 RSI: 00000000ffffffff RDI:
ffff8805e8aaa000
[  474.321199] RBP: ffff8805c0ac3cb8 R08: 0000000000000010 R09:
0000000000000006
[  474.357446] R10: 0000000000000000 R11: ffff8805c567a000 R12:
0000000000000006
[  474.419191] R13: ffff8805c2b74e88 R14: 00000000000001da R15:
0000000000000000
[  474.453816] FS:  00007f2e75220800(0000) GS:ffff88061fc00000(0000)
knlGS:0000000000000000
[  474.489254] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  474.522215] CR2: 00007f2e74716090 CR3: 00000005c085e000 CR4:
00000000000207f0
[  474.556058] Stack:
[  474.584325]  ffff8805c0ac3c98 ffffffff811b549b ffff8805c0ac3c98
ffff8805f1190a40
[  474.618913]  ffff8805a6202f08 ffff8805c2b74e88 00068800d0464990
ffff8805e8aac860
[  474.653955]  ffff8805c0ac3cb8 000700068113833a ffff880606c75060
ffff8805c0ac3d94
[  474.690461] Call Trace:
[  474.723779]  [] ? lookup_fast+0x1cd/0x22a
[  474.778049]  [] security_compute_av+0xf4/0x20b
[  474.811398]  [] avc_compute_av+0x2a/0x179
[  474.843813]  [] avc_has_perm+0x45/0xf4
[  474.875694]  [] inode_has_perm+0x2a/0x31
[  474.907370]  [] selinux_inode_getattr+0x3c/0x3e
[  474.938726]  [] security_inode_getattr+0x1b/0x22
[  474.970036]  [] vfs_getattr+0x19/0x2d
[  475.000618]  [] vfs_fstatat+0x54/0x91
[  475.030402]  [] vfs_lstat+0x19/0x1b
[  475.061097]  [] SyS_newlstat+0x15/0x30
[  475.094595]  [] ? __audit_syscall_entry+0xa1/0xc3
[  475.148405]  [] system_call_fastpath+0x16/0x1b
[  475.179201] Code: 00 48 85 c0 48 89 45 b8 75 02 0f 0b 48 8b 45 a0 48
8b 3d 45 d0 b6 00 8b 40 08 89 c6 ff ce e8 d1 b0 06 00 48 85 c0 49 89 c7
75 02 <0f> 0b 48 8b 45 b8 4c 8b 28 eb 1e 49 8d 7d 08 be 80 01 00 00 e8
[  475.255884] RIP  []
context_struct_compute_av+0xce/0x308
[  475.296120]  RSP 
[  475.328734] ---[ end trace f076482e9d754adc ]---

Reported-by:  Matthew Thode 
Signed-off-by: Stephen Smalley 
Cc: stable@vger.kernel.org
Signed-off-by: Paul Moore 
Signed-off-by: Willy Tarreau

aacraid: missing capable() check in compat ioctl

2014-05-19T05:54:35+00:00

commit f856567b930dfcdbc3323261bf77240ccdde01f5 upstream

In commit d496f94d22d1 ('[SCSI] aacraid: fix security weakness') we
added a check on CAP_SYS_RAWIO to the ioctl.  The compat ioctls need the
check as well.

Signed-off-by: Dan Carpenter 
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds 
Signed-off-by: Willy Tarreau

xfs: underflow bug in xfs_attrlist_by_handle()

2014-05-19T05:54:35+00:00

If we allocate less than sizeof(struct attrlist) then we end up
corrupting memory or doing a ZERO_PTR_SIZE dereference.

This can only be triggered with CAP_SYS_ADMIN.

Reported-by: Nico Golde 
Reported-by: Fabian Yamaguchi 
Signed-off-by: Dan Carpenter 
Reviewed-by: Dave Chinner 
Signed-off-by: Ben Myers 

(cherry picked from commit 071c529eb672648ee8ca3f90944bcbcc730b4c06)
[dannf: backported to Debian's 2.6.32]
Signed-off-by: Willy Tarreau

qeth: avoid buffer overflow in snmp ioctl

2014-05-19T05:54:34+00:00

commit 6fb392b1a63ae36c31f62bc3fc8630b49d602b62 upstream

Check user-defined length in snmp ioctl request and allow request
only if it fits into a qeth command buffer.

Signed-off-by: Ursula Braun 
Signed-off-by: Frank Blaschka 
Reviewed-by: Heiko Carstens 
Reported-by: Nico Golde 
Reported-by: Fabian Yamaguchi 
Cc: 
Signed-off-by: David S. Miller 
[jmm: backport 2.6.32]
Signed-off-by: Willy Tarreau

KVM: x86: Fix potential divide by 0 in lapic (CVE-2013-6367)

2014-05-19T05:54:34+00:00

commit b963a22e6d1a266a67e9eecc88134713fd54775c upstream

Under guest controllable circumstances apic_get_tmcct will execute a
divide by zero and cause a crash.  If the guest cpuid support
tsc deadline timers and performs the following sequence of requests
the host will crash.
- Set the mode to periodic
- Set the TMICT to 0
- Set the mode bits to 11 (neither periodic, nor one shot, nor tsc deadline)
- Set the TMICT to non-zero.
Then the lapic_timer.period will be 0, but the TMICT will not be.  If the
guest then reads from the TMCCT then the host will perform a divide by 0.

This patch ensures that if the lapic_timer.period is 0, then the division
does not occur.

Reported-by: Andrew Honig 
Cc: stable@vger.kernel.org
Signed-off-by: Andrew Honig 
Signed-off-by: Paolo Bonzini 
[dannf: backported to Debian's 2.6.32]
Signed-off-by: Willy Tarreau