user/sven/linux.git/security, branch v3.8.10

selinux: use GFP_ATOMIC under spin_lock

2013-03-20T20:10:56Z

commit 4502403dcf8f5c76abd4dbab8726c8e4ecb5cd34 upstream. The call tree here is: sk_clone_lock() <- takes bh_lock_sock(newsk); xfrm_sk_clone_policy() __xfrm_sk_clone_policy() clone_policy() <- uses GFP_ATOMIC for allocations security_xfrm_policy_clone() security_ops->xfrm_policy_clone_security() selinux_xfrm_policy_clone() Signed-off-by: Dan Carpenter Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman

Fix: compat_rw_copy_check_uvector() misuse in aio, readv, writev, and security keys

2013-03-14T18:26:36Z

commit 8aec0f5d4137532de14e6554fd5dd201ff3a3c49 upstream. Looking at mm/process_vm_access.c:process_vm_rw() and comparing it to compat_process_vm_rw() shows that the compatibility code requires an explicit "access_ok()" check before calling compat_rw_copy_check_uvector(). The same difference seems to appear when we compare fs/read_write.c:do_readv_writev() to fs/compat.c:compat_do_readv_writev(). This subtle difference between the compat and non-compat requirements should probably be debated, as it seems to be error-prone. In fact, there are two others sites that use this function in the Linux kernel, and they both seem to get it wrong: Now shifting our attention to fs/aio.c, we see that aio_setup_iocb() also ends up calling compat_rw_copy_check_uvector() through aio_setup_vectored_rw(). Unfortunately, the access_ok() check appears to be missing. Same situation for security/keys/compat.c:compat_keyctl_instantiate_key_iov(). I propose that we add the access_ok() check directly into compat_rw_copy_check_uvector(), so callers don't have to worry about it, and it therefore makes the compat call code similar to its non-compat counterpart. Place the access_ok() check in the same location where copy_from_user() can trigger a -EFAULT error in the non-compat code, so the ABI behaviors are alike on both compat and non-compat. While we are here, fix compat_do_readv_writev() so it checks for compat_rw_copy_check_uvector() negative return values. And also, fix a memory leak in compat_keyctl_instantiate_key_iov() error handling. Acked-by: Linus Torvalds Acked-by: Al Viro Signed-off-by: Mathieu Desnoyers Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

keys: fix race with concurrent install_user_keyrings()

2013-03-14T18:26:36Z

commit 0da9dfdd2cd9889201bc6f6f43580c99165cd087 upstream. This fixes CVE-2013-1792. There is a race in install_user_keyrings() that can cause a NULL pointer dereference when called concurrently for the same user if the uid and uid-session keyrings are not yet created. It might be possible for an unprivileged user to trigger this by calling keyctl() from userspace in parallel immediately after logging in. Assume that we have two threads both executing lookup_user_key(), both looking for KEY_SPEC_USER_SESSION_KEYRING. THREAD A THREAD B =============================== =============================== ==>call install_user_keyrings(); if (!cred->user->session_keyring) ==>call install_user_keyrings() ... user->uid_keyring = uid_keyring; if (user->uid_keyring) return 0; <== key = cred->user->session_keyring [== NULL] user->session_keyring = session_keyring; atomic_inc(&key->usage); [oops] At the point thread A dereferences cred->user->session_keyring, thread B hasn't updated user->session_keyring yet, but thread A assumes it is populated because install_user_keyrings() returned ok. The race window is really small but can be exploited if, for example, thread B is interrupted or preempted after initializing uid_keyring, but before doing setting session_keyring. This couldn't be reproduced on a stock kernel. However, after placing systemtap probe on 'user->session_keyring = session_keyring;' that introduced some delay, the kernel could be crashed reliably. Fix this by checking both pointers before deciding whether to return. Alternatively, the test could be done away with entirely as it is checked inside the mutex - but since the mutex is global, that may not be the best way. Signed-off-by: David Howells Reported-by: Mateusz Guzik Signed-off-by: Andrew Morton Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman

userns: Stop oopsing in key_change_session_keyring

2013-03-14T18:26:26Z

commit ba0e3427b03c3d1550239779eca5c1c5a53a2152 upstream. Dave Jones writes: > Just hit this on Linus' current tree. > > [ 89.621770] BUG: unable to handle kernel NULL pointer dereference at 00000000000000c8 > [ 89.623111] IP: [] commit_creds+0x250/0x2f0 > [ 89.624062] PGD 122bfd067 PUD 122bfe067 PMD 0 > [ 89.624901] Oops: 0000 [#1] PREEMPT SMP > [ 89.625678] Modules linked in: caif_socket caif netrom bridge hidp 8021q garp stp mrp rose llc2 af_rxrpc phonet af_key binfmt_misc bnep l2tp_ppp can_bcm l2tp_core pppoe pppox can_raw scsi_transport_iscsi ppp_generic slhc nfnetlink can ipt_ULOG ax25 decnet irda nfc rds x25 crc_ccitt appletalk atm ipx p8023 psnap p8022 llc lockd sunrpc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack nf_conntrack ip6table_filter ip6_tables btusb bluetooth snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_pcm vhost_net snd_page_alloc snd_timer tun macvtap usb_debug snd rfkill microcode macvlan edac_core pcspkr serio_raw kvm_amd soundcore kvm r8169 mii > [ 89.637846] CPU 2 > [ 89.638175] Pid: 782, comm: trinity-main Not tainted 3.8.0+ #63 Gigabyte Technology Co., Ltd. GA-MA78GM-S2H/GA-MA78GM-S2H > [ 89.639850] RIP: 0010:[] [] commit_creds+0x250/0x2f0 > [ 89.641161] RSP: 0018:ffff880115657eb8 EFLAGS: 00010207 > [ 89.641984] RAX: 00000000000003e8 RBX: ffff88012688b000 RCX: 0000000000000000 > [ 89.643069] RDX: 0000000000000000 RSI: ffffffff81c32960 RDI: ffff880105839600 > [ 89.644167] RBP: ffff880115657ed8 R08: 0000000000000000 R09: 0000000000000000 > [ 89.645254] R10: 0000000000000001 R11: 0000000000000246 R12: ffff880105839600 > [ 89.646340] R13: ffff88011beea490 R14: ffff88011beea490 R15: 0000000000000000 > [ 89.647431] FS: 00007f3ac063b740(0000) GS:ffff88012b200000(0000) knlGS:0000000000000000 > [ 89.648660] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > [ 89.649548] CR2: 00000000000000c8 CR3: 0000000122bfc000 CR4: 00000000000007e0 > [ 89.650635] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 89.651723] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > [ 89.652812] Process trinity-main (pid: 782, threadinfo ffff880115656000, task ffff88011beea490) > [ 89.654128] Stack: > [ 89.654433] 0000000000000000 ffff8801058396a0 ffff880105839600 ffff88011beeaa78 > [ 89.655769] ffff880115657ef8 ffffffff812c7d9b ffffffff82079be0 0000000000000000 > [ 89.657073] ffff880115657f28 ffffffff8106c665 0000000000000002 ffff880115657f58 > [ 89.658399] Call Trace: > [ 89.658822] [] key_change_session_keyring+0xfb/0x140 > [ 89.659845] [] task_work_run+0xa5/0xd0 > [ 89.660698] [] do_notify_resume+0x71/0xb0 > [ 89.661581] [] int_signal+0x12/0x17 > [ 89.662385] Code: 24 90 00 00 00 48 8b b3 90 00 00 00 49 8b 4c 24 40 48 39 f2 75 08 e9 83 00 00 00 48 89 ca 48 81 fa 60 29 c3 81 0f 84 41 fe ff ff <48> 8b 8a c8 00 00 00 48 39 ce 75 e4 3b 82 d0 00 00 00 0f 84 4b > [ 89.667778] RIP [] commit_creds+0x250/0x2f0 > [ 89.668733] RSP > [ 89.669301] CR2: 00000000000000c8 > > My fastest trinity induced oops yet! > > > Appears to be.. > > if ((set_ns == subset_ns->parent) && > 850: 48 8b 8a c8 00 00 00 mov 0xc8(%rdx),%rcx > > from the inlined cred_cap_issubset By historical accident we have been reading trying to set new->user_ns from new->user_ns. Which is totally silly as new->user_ns is NULL (as is every other field in new except session_keyring at that point). The intent is clearly to copy all of the fields from old to new so copy old->user_ns into into new->user_ns. Reported-by: Dave Jones Tested-by: Dave Jones Acked-by: Serge Hallyn Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman

KEYS: Revert one application of "Fix unreachable code" patch

2013-02-28T13:38:32Z

commit fe9453a1dcb5fb146f9653267e78f4a558066f6f upstream. A patch to fix some unreachable code in search_my_process_keyrings() got applied twice by two different routes upstream as commits e67eab39bee2 and b010520ab3d2 (both "fix unreachable code"). Unfortunately, the second application removed something it shouldn't have and this wasn't detected by GIT. This is due to the patch not having sufficient lines of context to distinguish the two places of application. The effect of this is relatively minor: inside the kernel, the keyring search routines may search multiple keyrings and then prioritise the errors if no keys or negative keys are found in any of them. With the extra deletion, the presence of a negative key in the thread keyring (causing ENOKEY) is incorrectly overridden by an error searching the process keyring. So revert the second application of the patch. Signed-off-by: David Howells Cc: Jiri Kosina Cc: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2013-01-28T19:41:37Z

Pull networking updates from David Miller: "Much more accumulated than I would have liked due to an unexpected bout with a nasty flu: 1) AH and ESP input don't set ECN field correctly because the transport head of the SKB isn't set correctly, fix from Li RongQing. 2) If netfilter conntrack zones are disabled, we can return an uninitialized variable instead of the proper error code. Fix from Borislav Petkov. 3) Fix double SKB free in ath9k driver beacon handling, from Felix Feitkau. 4) Remove bogus assumption about netns cleanup ordering in nf_conntrack, from Pablo Neira Ayuso. 5) Remove a bogus BUG_ON in the new TCP fastopen code, from Eric Dumazet. It uses spin_is_locked() in it's test and is therefore unsuitable for UP. 6) Fix SELINUX labelling regressions added by the tuntap multiqueue changes, from Paul Moore. 7) Fix CRC errors with jumbo frame receive in tg3 driver, from Nithin Nayak Sujir. 8) CXGB4 driver sets interrupt coalescing parameters only on first queue, rather than all of them. Fix from Thadeu Lima de Souza Cascardo. 9) Fix regression in the dispatch of read/write registers in dm9601 driver, from Tushar Behera. 10) ipv6_append_data miscalculates header length, from Romain KUNTZ. 11) Fix PMTU handling regressions on ipv4 routes, from Steffen Klassert, Timo Teräs, and Julian Anastasov. 12) In 3c574_cs driver, add necessary parenthesis to "x << y & z" expression. From Nickolai Zeldovich. 13) macvlan_get_size() causes underallocation netlink message space, fix from Eric Dumazet. 14) Avoid division by zero in xfrm_replay_advance_bmp(), from Nickolai Zeldovich. Amusingly the zero check was already there, we were just performing it after the modulus :-) 15) Some more splice bug fixes from Eric Dumazet, which fix things mostly eminating from how we now more aggressively use high-order pages in SKBs. 16) Fix size calculation bug when freeing hash tables in the IPSEC xfrm code, from Michal Kubecek. 17) Fix PMTU event propagation into socket cached routes, from Steffen Klassert. 18) Fix off by one in TX buffer release in netxen driver, from Eric Dumazet. 19) Fix rediculous memory allocation requirements introduced by the tuntap multiqueue changes, from Jason Wang. 20) Remove bogus AMD platform workaround in r8169 driver that causes major problems in normal operation, from Timo Teräs. 21) virtio-net set affinity and select queue don't handle discontiguous cpu numbers properly, fix from Wanlong Gao. 22) Fix a route refcounting issue in loopback driver, from Eric Dumazet. There's a similar fix coming that we might add to the macvlan driver as well. 23) Fix SKB leaks in batman-adv's distributed arp table code, from Matthias Schiffer. 24) r8169 driver gives descriptor ownership back the hardware before we're done reading the VLAN tag out of it, fix from Francois Romieu. 25) Checksums not calculated properly in GRE tunnel driver fix from Pravin B Shelar. 26) Fix SCTP memory leak on namespace exit." * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (101 commits) dm9601: support dm9620 variant SCTP: Free the per-net sysctl table on net exit. v2 net: phy: icplus: fix broken INTR pin settings net: phy: icplus: Use the RGMII interface mode to configure clock delays IP_GRE: Fix kernel panic in IP_GRE with GRE csum. sctp: set association state to established in dupcook_a handler ip6mr: limit IPv6 MRT_TABLE identifiers r8169: fix vlan tag read ordering. net: cdc_ncm: use IAD provided by the USB core batman-adv: filter ARP packets with invalid MAC addresses in DAT batman-adv: check for more types of invalid IP addresses in DAT batman-adv: fix skb leak in batadv_dat_snoop_incoming_arp_reply() net: loopback: fix a dst refcounting issue virtio-net: reset virtqueue affinity when doing cpu hotplug virtio-net: split out clean affinity function virtio-net: fix the set affinity bug when CPU IDs are not consecutive can: pch_can: fix invalid error codes can: ti_hecc: fix invalid error codes can: c_can: fix invalid error codes r8169: remove the obsolete and incorrect AMD workaround ...

security/device_cgroup: lock assert fails in dev_exception_clean()

2013-01-21T13:27:55Z

devcgroup_css_free() calls dev_exception_clean() without the devcgroup_mutex being locked. Shutting down a kvm virt was giving me the following trace: [36280.732764] ------------[ cut here ]------------ [36280.732778] WARNING: at /home/snits/dev/linux/security/device_cgroup.c:172 dev_exception_clean+0xa9/0xc0() [36280.732782] Hardware name: Studio XPS 8100 [36280.732785] Modules linked in: xt_REDIRECT fuse ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat xt_CHECKSUM iptable_mangle bridge stp llc nf_conntrack_ipv4 ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 nf_defrag_ipv4 ip6table_filter it87 hwmon_vid xt_state nf_conntrack ip6_tables snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq coretemp snd_seq_device crc32c_intel snd_pcm snd_page_alloc snd_timer snd broadcom tg3 serio_raw i7core_edac edac_core ptp pps_core lpc_ich pcspkr mfd_core soundcore microcode i2c_i801 nfsd auth_rpcgss nfs_acl lockd vhost_net sunrpc tun macvtap macvlan kvm_intel kvm uinput binfmt_misc autofs4 usb_storage firewire_ohci firewire_core crc_itu_t radeon drm_kms_helper ttm [36280.732921] Pid: 933, comm: libvirtd Tainted: G W 3.8.0-rc3-00307-g4c217de #1 [36280.732922] Call Trace: [36280.732927] [] warn_slowpath_common+0x93/0xc0 [36280.732930] [] warn_slowpath_null+0x1a/0x20 [36280.732932] [] dev_exception_clean+0xa9/0xc0 [36280.732934] [] devcgroup_css_free+0x1a/0x30 [36280.732938] [] cgroup_diput+0x76/0x210 [36280.732941] [] d_delete+0x120/0x180 [36280.732943] [] vfs_rmdir+0xef/0x130 [36280.732945] [] do_rmdir+0x107/0x1c0 [36280.732949] [] ? trace_hardirqs_on_thunk+0x3a/0x3f [36280.732951] [] sys_rmdir+0x16/0x20 [36280.732954] [] system_call_fastpath+0x16/0x1b [36280.732956] ---[ end trace ca39dced899a7d9f ]--- Signed-off-by: Jerry Snitselaar Cc: stable@kernel.org Signed-off-by: James Morris

evm: checking if removexattr is not a NULL

2013-01-21T13:27:50Z

The following lines of code produce a kernel oops. fd = socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0); fchmod(fd, 0666); [ 139.922364] BUG: unable to handle kernel NULL pointer dereference at (null) [ 139.924982] IP: [< (null)>] (null) [ 139.924982] *pde = 00000000 [ 139.924982] Oops: 0000 [#5] SMP [ 139.924982] Modules linked in: fuse dm_crypt dm_mod i2c_piix4 serio_raw evdev binfmt_misc button [ 139.924982] Pid: 3070, comm: acpid Tainted: G D 3.8.0-rc2-kds+ #465 Bochs Bochs [ 139.924982] EIP: 0060:[<00000000>] EFLAGS: 00010246 CPU: 0 [ 139.924982] EIP is at 0x0 [ 139.924982] EAX: cf5ef000 EBX: cf5ef000 ECX: c143d600 EDX: c15225f2 [ 139.924982] ESI: cf4d2a1c EDI: cf4d2a1c EBP: cc02df10 ESP: cc02dee4 [ 139.924982] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 139.924982] CR0: 80050033 CR2: 00000000 CR3: 0c059000 CR4: 000006d0 [ 139.924982] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 [ 139.924982] DR6: ffff0ff0 DR7: 00000400 [ 139.924982] Process acpid (pid: 3070, ti=cc02c000 task=d7705340 task.ti=cc02c000) [ 139.924982] Stack: [ 139.924982] c1203c88 00000000 cc02def4 cf4d2a1c ae21eefa 471b60d5 1083c1ba c26a5940 [ 139.924982] e891fb5e 00000041 00000004 cc02df1c c1203964 00000000 cc02df4c c10e20c3 [ 139.924982] 00000002 00000000 00000000 22222222 c1ff2222 cf5ef000 00000000 d76efb08 [ 139.924982] Call Trace: [ 139.924982] [] ? evm_update_evmxattr+0x5b/0x62 [ 139.924982] [] evm_inode_post_setattr+0x22/0x26 [ 139.924982] [] notify_change+0x25f/0x281 [ 139.924982] [] chmod_common+0x59/0x76 [ 139.924982] [] ? put_unused_fd+0x33/0x33 [ 139.924982] [] sys_fchmod+0x39/0x5c [ 139.924982] [] syscall_call+0x7/0xb [ 139.924982] Code: Bad EIP value. This happens because sockets do not define the removexattr operation. Before removing the xattr, verify the removexattr function pointer is not NULL. Signed-off-by: Dmitry Kasatkin Signed-off-by: Mimi Zohar Cc: stable@vger.kernel.org Signed-off-by: James Morris

tun: fix LSM/SELinux labeling of tun/tap devices

2013-01-14T23:16:59Z

This patch corrects some problems with LSM/SELinux that were introduced with the multiqueue patchset. The problem stems from the fact that the multiqueue work changed the relationship between the tun device and its associated socket; before the socket persisted for the life of the device, however after the multiqueue changes the socket only persisted for the life of the userspace connection (fd open). For non-persistent devices this is not an issue, but for persistent devices this can cause the tun device to lose its SELinux label. We correct this problem by adding an opaque LSM security blob to the tun device struct which allows us to have the LSM security state, e.g. SELinux labeling information, persist for the lifetime of the tun device. In the process we tweak the LSM hooks to work with this new approach to TUN device/socket labeling and introduce a new LSM hook, security_tun_dev_attach_queue(), to approve requests to attach to a TUN queue via TUNSETQUEUE. The SELinux code has been adjusted to match the new LSM hooks, the other LSMs do not make use of the LSM TUN controls. This patch makes use of the recently added "tun_socket:attach_queue" permission to restrict access to the TUNSETQUEUE operation. On older SELinux policies which do not define the "tun_socket:attach_queue" permission the access control decision for TUNSETQUEUE will be handled according to the SELinux policy's unknown permission setting. Signed-off-by: Paul Moore Acked-by: Eric Paris Tested-by: Jason Wang Signed-off-by: David S. Miller

selinux: add the "attach_queue" permission to the "tun_socket" class

2013-01-14T23:16:59Z

Add a new permission to align with the new TUN multiqueue support, "tun_socket:attach_queue". The corresponding SELinux reference policy patch is show below: diff --git a/policy/flask/access_vectors b/policy/flask/access_vectors index 28802c5..a0664a1 100644 --- a/policy/flask/access_vectors +++ b/policy/flask/access_vectors @@ -827,6 +827,9 @@ class kernel_service class tun_socket inherits socket +{ + attach_queue +} class x_pointer inherits x_device Signed-off-by: Paul Moore Acked-by: Eric Paris Tested-by: Jason Wang Signed-off-by: David S. Miller