GitHub PushEvent at 2014-06-26 20:18:07
Repository: tuxonice-kernel
Actor: NigelCunningham
Payload: {"shas":[["d3c8656bc29be81894dc78a300c37b84d281ec03","2cc0d0d76de2e6f37b92deeb83c85cb306fc5dc1@amacapital.net","fs,userns: Change inode_capable to capable_wrt_inode_uidgid\n\ncommit 23adbe12ef7d3d4195e80800ab36b37bee28cd03 upstream.\n\nThe kernel has no concept of capabilities with respect to inodes; inodes\nexist independently of namespaces.  For example, inode_capable(inode,\nCAP_LINUX_IMMUTABLE) would be nonsense.\n\nThis patch changes inode_capable to check for uid and gid mappings and\nrenames it to capable_wrt_inode_uidgid, which should make it more\nobvious what it does.\n\nFixes CVE-2014-4014.\n\nCc: Theodore Ts'o <tytso@mit.edu>\nCc: Serge Hallyn <serge.hallyn@ubuntu.com>\nCc: \"Eric W. Biederman\" <ebiederm@xmission.com>\nCc: Dave Chinner <david@fromorbit.com>\nSigned-off-by: Andy Lutomirski <luto@amacapital.net>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Andy Lutomirski",false],["4e358517b2810788777196f038f5a0b3b9936a6a","de609eb4d5d70b1d38ec6642adbfc33a2781f63c@zeniv.linux.org.uk","lock_parent: don't step on stale ->d_parent of all-but-freed one\n\ncommit c2338f2dc7c1e9f6202f370c64ffd7f44f3d4b51 upstream.\n\nDentry that had been through (or into) __dentry_kill() might be seen\nby shrink_dentry_list(); that's normal, it'll be taken off the shrink\nlist and freed if __dentry_kill() has already finished.  The problem\nis, its ->d_parent might be pointing to already freed dentry, so\nlock_parent() needs to be careful.\n\nWe need to check that dentry hasn't already gone into __dentry_kill()\n*and* grab rcu_read_lock() before dropping ->d_lock - the latter makes\nsure that whatever we see in ->d_parent after dropping ->d_lock it\nwon't be freed until we drop rcu_read_lock().\n\nSigned-off-by: Al Viro <viro@zeniv.linux.org.uk>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Al Viro",false],["e015cef70226c6b94ee575895fde595d925b42c0","2cc0d0d76de2e6f37b92deeb83c85cb306fc5dc1@amacapital.net","auditsc: audit_krule mask accesses need bounds checking\n\ncommit a3c54931199565930d6d84f4c3456f6440aefd41 upstream.\n\nFixes an easy DoS and possible information disclosure.\n\nThis does nothing about the broken state of x32 auditing.\n\neparis: If the admin has enabled auditd and has specifically loaded\naudit rules.  This bug has been around since before git.  Wow...\n\nSigned-off-by: Andy Lutomirski <luto@amacapital.net>\nSigned-off-by: Eric Paris <eparis@redhat.com>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Andy Lutomirski",false],["f15e38fc0fc5bacc0b983d762364ecc78758c4d0","c24c0248770ae98831f8a654310d4c2e07514c61@plumgrid.com","PCI/MSI: Fix memory leak in free_msi_irqs()\n\ncommit b701c0b1fe819a2083fc6ec5332e0e4492b9516d upstream.\n\nfree_msi_irqs() is leaking memory, since list_for_each_entry(entry,\n&dev->msi_list, list) {...} is never executed, because dev->msi_list is\nmade empty by the loop just above this one.\n\nFix it by relying on zero termination of attribute array like\npopulate_msi_sysfs() does.\n\nFixes: 1c51b50c2995 (\"PCI/MSI: Export MSI mode using attributes, not kobjects\")\nSigned-off-by: Alexei Starovoitov <ast@plumgrid.com>\nSigned-off-by: Bjorn Helgaas <bhelgaas@google.com>\nAcked-by: Neil Horman <nhorman@tuxdriver.com>\nAcked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Alexei Starovoitov",false],["b1b94ac553e0ab8182d63e5b36f7633c4c3c20a7","002a8af089113a6510dbc00453be711ac350fd80@intel.com","mei: me: fix hw ready reset flow\n\ncommit b04ada92ffaabb868497a1fce8e4f6bf74e5488f upstream.\n\nWe cleared H_RST for H_CSR on spurious interrupt generated when ME_RDY\nwhile cleared and not while  ME_RDY is set. The spurious interrupt\nis not delivered on all platforms in this case the\ndriver may fail to initialize.\n\nSigned-off-by: Tomas Winkler <tomas.winkler@intel.com>\nSigned-off-by: Alexander Usyskin <alexander.usyskin@intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Tomas Winkler",false],["4f104ed166d1039950a6fbebcffbde92543bd2eb","002a8af089113a6510dbc00453be711ac350fd80@intel.com","mei: me: drop harmful wait optimization\n\ncommit 07cd7be3d92eeeae1f92a017f2cfe4fdd9256526 upstream.\n\nIt my take time till ME_RDY will be cleared after the reset,\nso we cannot check the bit before we got the interrupt\n\nSigned-off-by: Tomas Winkler <tomas.winkler@intel.com>\nSigned-off-by: Alexander Usyskin <alexander.usyskin@intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Tomas Winkler",false],["0cb62c9a241d67bf555971224757e11f0e2da294","002a8af089113a6510dbc00453be711ac350fd80@intel.com","mei: me: read H_CSR after asserting reset\n\ncommit c40765d919d25d2d44d99c4ce39e48808f137e1e upstream.\n\nAccording the spec the host should read H_CSR again\nafter asserting reset H_RST to ensure that reset was\nread by the firmware\n\nSigned-off-by: Tomas Winkler <tomas.winkler@intel.com>\nSigned-off-by: Alexander Usyskin <alexander.usyskin@intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Tomas Winkler",false],["b1947d698fa8899f31c26ab1de8c732c0d053781","aafe034d782e68c1e458425f900779b324458d1a@gmail.com","rtl28xxu: add 1b80:d395 Peak DVB-T USB\n\ncommit 9ca24ae4083665bda38da45f4b5dc9bbaf936bc0 upstream.\n\nAdd USB ID for Peak DVB-T USB.\n\n[crope@iki.fi: fix Brian email address and indentation]\nSigned-off-by: Brian Healy <healybrian@gmail.com>\nSigned-off-by: Antti Palosaari <crope@iki.fi>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\n\nSigned-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>","Brian Healy",false],["8bc4154c9a32eef14220cfaecd641dfc156b7988","c256cad1b9e6b374197cd9f8c0fbf8afa23de027@gmail.com","rtl28xxu: add [1b80:d39d] Sveon STV20\n\ncommit f27f5b0ee4967babfb8b03511f5e76b79d781014 upstream.\n\nAdded Sveon STV20 device based on Realtek RTL2832U and FC0012 tuner\n\nSigned-off-by: Alessandro Miceli <angelofsky1980@gmail.com>\nSigned-off-by: Antti Palosaari <crope@iki.fi>\nSigned-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Alessandro Miceli",false],["6dcfd1f5d42e1b5f33d45f55186b961270420f00","c256cad1b9e6b374197cd9f8c0fbf8afa23de027@gmail.com","rtl28xxu: add [1b80:d3af] Sveon STV27\n\ncommit 74a86272f05c3dae40f2d7b17ff09a0608cf3304 upstream.\n\nAdded support for Sveon STV27 device (rtl2832u + FC0013 tuner)\n\nSigned-off-by: Alessandro Miceli <angelofsky1980@gmail.com>\nSigned-off-by: Antti Palosaari <crope@iki.fi>\nSigned-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Alessandro Miceli",false],["72591c3023fa2da2a1bee182c97637bb4740e043","94654f0fb8a11d0e0f8ea667735b395db581ca27@zougloub.eu","ahci: Add Device ID for HighPoint RocketRaid 642L\n\ncommit d251836508fb26cd1a22b41381739835ee23728d upstream.\n\nThis device normally comes with a proprietary driver, using a web GUI\nto configure RAID:\n http://www.highpoint-tech.com/USA_new/series_rr600-download.htm\nBut thankfully it also works out of the box with the AHCI driver,\nbeing just a Marvell 88SE9235.\n\nDevices 640L, 644L, 644LS should also be supported but not tested here.\n\nSigned-off-by: Jérôme Carretero <cJ-ko@zougloub.eu>\nSigned-off-by: Tejun Heo <tj@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Jérôme Carretero",false],["a6543e29682bfdf11b3fe36162b8226e7e9f90fb","91bfcefd0ba1195a75c5f5e92c82bf71153f2dc3@gmail.com","ahci: add PCI ID for Marvell 88SE91A0 SATA Controller\n\ncommit 754a292fe6b08196cb135c03b404444e17de520a upstream.\n\nAdd support for Marvell Technology Group Ltd. 88SE91A0 SATA 6Gb/s\nController by adding its PCI ID.\n\nSigned-off-by: Andreas Schrägle <ajs124.ajs124@gmail.com>\nSigned-off-by: Tejun Heo <tj@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Andreas Schrägle",false],["41b67d8f304f0c414b41eee2ede98caf897012a8","4645f7897fd33786a2ee1264d590b3c400559d85@linuxfoundation.org","Linux 3.15.1","Greg Kroah-Hartman",false],["563d5546698587b95b3a1cdbfd0d92e250e9b6f5","4e91513d4f418754031d3d36b3fc73980c40a38c@free-electrons.com","rtc: rtc-at91rm9200: fix infinite wait for ACKUPD irq\n\ncommit 2fe121e1f5aa3bf31b418a9790db6c400e922291 upstream.\n\nThe rtc user must wait at least 1 sec between each time/calandar update\n(see atmel's datasheet chapter \"Updating Time/Calendar\").\n\nUse the 1Hz interrupt to update the at91_rtc_upd_rdy flag and wait for\nthe at91_rtc_wait_upd_rdy event if the rtc is not ready.\n\nThis patch fixes a deadlock in an uninterruptible wait when the RTC is\nupdated more than once every second.  AFAICT the bug is here from the\nbeginning, but I think we should at least backport this fix to 3.10 and\nthe following longterm and stable releases.\n\nSigned-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com>\nReported-by: Bryan Evenson <bevenson@melinkcorp.com>\nTested-by: Bryan Evenson <bevenson@melinkcorp.com>\nCc: Andrew Victor <linux@maxim.org.za>\nCc: Nicolas Ferre <nicolas.ferre@atmel.com>\nCc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>\nCc: Alessandro Zummo <a.zummo@towertech.it>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Boris BREZILLON",false],["af653349f7bce703c3d63afbfc6e423345022463","978acd1567d5598152161fdf8bf3ca568f950c9b@linux-iscsi.org","target: Fix NULL pointer dereference for XCOPY in target_put_sess_cmd\n\ncommit 0ed6e189e3f6ac3a25383ed5cc8b0ac24c9b97b7 upstream.\n\nThis patch fixes a NULL pointer dereference regression bug that was\nintroduced with:\n\ncommit 1e1110c43b1cda9fe77fc4a04835e460550e6b3c\nAuthor: Mikulas Patocka <mpatocka@redhat.com>\nDate:   Sat May 17 06:49:22 2014 -0400\n\n    target: fix memory leak on XCOPY\n\nNow that target_put_sess_cmd() -> kref_put_spinlock_irqsave() is\ncalled with a valid se_cmd->cmd_kref, a NULL pointer dereference\nis triggered because the XCOPY passthrough commands don't have\nan associated se_session pointer.\n\nTo address this bug, go ahead and checking for a NULL se_sess pointer\nwithin target_put_sess_cmd(), and call se_cmd->se_tfo->release_cmd()\nto release the XCOPY's xcopy_pt_cmd memory.\n\nReported-by: Thomas Glanzmann <thomas@glanzmann.de>\nCc: Thomas Glanzmann <thomas@glanzmann.de>\nCc: Mikulas Patocka <mpatocka@redhat.com>\nSigned-off-by: Nicholas Bellinger <nab@linux-iscsi.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Nicholas Bellinger",false],["50db1fe232c0d869c2a967f5863de28af848d6b5","978acd1567d5598152161fdf8bf3ca568f950c9b@linux-iscsi.org","iscsi-target: Reject mutual authentication with reflected CHAP_C\n\ncommit 1d2b60a5545942b1376cb48c1d55843d71e3a08f upstream.\n\nThis patch adds an explicit check in chap_server_compute_md5() to ensure\nthe CHAP_C value received from the initiator during mutual authentication\ndoes not match the original CHAP_C provided by the target.\n\nThis is in line with RFC-3720, section 8.2.1:\n\n   Originators MUST NOT reuse the CHAP challenge sent by the Responder\n   for the other direction of a bidirectional authentication.\n   Responders MUST check for this condition and close the iSCSI TCP\n   connection if it occurs.\n\nReported-by: Tejas Vaykole <tejas.vaykole@calsoftinc.com>\nSigned-off-by: Nicholas Bellinger <nab@linux-iscsi.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Nicholas Bellinger",false],["47873220e74263c9631c0e0afb1ca6d54e6aa556","f02992f7c171053741caa6b515d9896745b37477@linux.vnet.ibm.com","ima: audit log files opened with O_DIRECT flag\n\ncommit f9b2a735bdddf836214b5dca74f6ca7712e5a08c upstream.\n\nFiles are measured or appraised based on the IMA policy.  When a\nfile, in policy, is opened with the O_DIRECT flag, a deadlock\noccurs.\n\nThe first attempt at resolving this lockdep temporarily removed the\nO_DIRECT flag and restored it, after calculating the hash.  The\nsecond attempt introduced the O_DIRECT_HAVELOCK flag. Based on this\nflag, do_blockdev_direct_IO() would skip taking the i_mutex a second\ntime.  The third attempt, by Dmitry Kasatkin, resolves the i_mutex\nlocking issue, by re-introducing the IMA mutex, but uncovered\nanother problem.  Reading a file with O_DIRECT flag set, writes\ndirectly to userspace pages.  A second patch allocates a user-space\nlike memory.  This works for all IMA hooks, except ima_file_free(),\nwhich is called on __fput() to recalculate the file hash.\n\nUntil this last issue is addressed, do not 'collect' the\nmeasurement for measuring, appraising, or auditing files opened\nwith the O_DIRECT flag set.  Based on policy, permit or deny file\naccess.  This patch defines a new IMA policy rule option named\n'permit_directio'.  Policy rules could be defined, based on LSM\nor other criteria, to permit specific applications to open files\nwith the O_DIRECT flag set.\n\nChangelog v1:\n- permit or deny file access based IMA policy rules\n\nSigned-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>\nAcked-by: Dmitry Kasatkin <d.kasatkin@samsung.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Mimi Zohar",false],["51678ceba9aafdd1b24e416b474813517866cff2","c116bc32ce0fd3cd5ab78828b5c5c631dc6f63d8@samsung.com","ima: introduce ima_kernel_read()\n\ncommit 0430e49b6e7c6b5e076be8fefdee089958c9adad upstream.\n\nCommit 8aac62706 \"move exit_task_namespaces() outside of exit_notify\"\nintroduced the kernel opps since the kernel v3.10, which happens when\nApparmor and IMA-appraisal are enabled at the same time.\n\n----------------------------------------------------------------------\n[  106.750167] BUG: unable to handle kernel NULL pointer dereference at\n0000000000000018\n[  106.750221] IP: [<ffffffff811ec7da>] our_mnt+0x1a/0x30\n[  106.750241] PGD 0\n[  106.750254] Oops: 0000 [#1] SMP\n[  106.750272] Modules linked in: cuse parport_pc ppdev bnep rfcomm\nbluetooth rpcsec_gss_krb5 nfsd auth_rpcgss nfs_acl nfs lockd sunrpc\nfscache dm_crypt intel_rapl x86_pkg_temp_thermal intel_powerclamp\nkvm_intel snd_hda_codec_hdmi kvm crct10dif_pclmul crc32_pclmul\nghash_clmulni_intel aesni_intel aes_x86_64 glue_helper lrw gf128mul\nablk_helper cryptd snd_hda_codec_realtek dcdbas snd_hda_intel\nsnd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_seq_midi\nsnd_seq_midi_event snd_rawmidi psmouse snd_seq microcode serio_raw\nsnd_timer snd_seq_device snd soundcore video lpc_ich coretemp mac_hid lp\nparport mei_me mei nbd hid_generic e1000e usbhid ahci ptp hid libahci\npps_core\n[  106.750658] CPU: 6 PID: 1394 Comm: mysqld Not tainted 3.13.0-rc7-kds+ #15\n[  106.750673] Hardware name: Dell Inc. OptiPlex 9010/0M9KCM, BIOS A08\n09/19/2012\n[  106.750689] task: ffff8800de804920 ti: ffff880400fca000 task.ti:\nffff880400fca000\n[  106.750704] RIP: 0010:[<ffffffff811ec7da>]  [<ffffffff811ec7da>]\nour_mnt+0x1a/0x30\n[  106.750725] RSP: 0018:ffff880400fcba60  EFLAGS: 00010286\n[  106.750738] RAX: 0000000000000000 RBX: 0000000000000100 RCX:\nffff8800d51523e7\n[  106.750764] RDX: ffffffffffffffea RSI: ffff880400fcba34 RDI:\nffff880402d20020\n[  106.750791] RBP: ffff880400fcbae0 R08: 0000000000000000 R09:\n0000000000000001\n[  106.750817] R10: 0000000000000000 R11: 0000000000000001 R12:\nffff8800d5152300\n[  106.750844] R13: ffff8803eb8df510 R14: ffff880400fcbb28 R15:\nffff8800d51523e7\n[  106.750871] FS:  0000000000000000(0000) GS:ffff88040d200000(0000)\nknlGS:0000000000000000\n[  106.750910] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  106.750935] CR2: 0000000000000018 CR3: 0000000001c0e000 CR4:\n00000000001407e0\n[  106.750962] Stack:\n[  106.750981]  ffffffff813434eb ffff880400fcbb20 ffff880400fcbb18\n0000000000000000\n[  106.751037]  ffff8800de804920 ffffffff8101b9b9 0001800000000000\n0000000000000100\n[  106.751093]  0000010000000000 0000000000000002 000000000000000e\nffff8803eb8df500\n[  106.751149] Call Trace:\n[  106.751172]  [<ffffffff813434eb>] ? aa_path_name+0x2ab/0x430\n[  106.751199]  [<ffffffff8101b9b9>] ? sched_clock+0x9/0x10\n[  106.751225]  [<ffffffff8134a68d>] aa_path_perm+0x7d/0x170\n[  106.751250]  [<ffffffff8101b945>] ? native_sched_clock+0x15/0x80\n[  106.751276]  [<ffffffff8134aa73>] aa_file_perm+0x33/0x40\n[  106.751301]  [<ffffffff81348c5e>] common_file_perm+0x8e/0xb0\n[  106.751327]  [<ffffffff81348d78>] apparmor_file_permission+0x18/0x20\n[  106.751355]  [<ffffffff8130c853>] security_file_permission+0x23/0xa0\n[  106.751382]  [<ffffffff811c77a2>] rw_verify_area+0x52/0xe0\n[  106.751407]  [<ffffffff811c789d>] vfs_read+0x6d/0x170\n[  106.751432]  [<ffffffff811cda31>] kernel_read+0x41/0x60\n[  106.751457]  [<ffffffff8134fd45>] ima_calc_file_hash+0x225/0x280\n[  106.751483]  [<ffffffff8134fb52>] ? ima_calc_file_hash+0x32/0x280\n[  106.751509]  [<ffffffff8135022d>] ima_collect_measurement+0x9d/0x160\n[  106.751536]  [<ffffffff810b552d>] ? trace_hardirqs_on+0xd/0x10\n[  106.751562]  [<ffffffff8134f07c>] ? ima_file_free+0x6c/0xd0\n[  106.751587]  [<ffffffff81352824>] ima_update_xattr+0x34/0x60\n[  106.751612]  [<ffffffff8134f0d0>] ima_file_free+0xc0/0xd0\n[  106.751637]  [<ffffffff811c9635>] __fput+0xd5/0x300\n[  106.751662]  [<ffffffff811c98ae>] ____fput+0xe/0x10\n[  106.751687]  [<ffffffff81086774>] task_work_run+0xc4/0xe0\n[  106.751712]  [<ffffffff81066fad>] do_exit+0x2bd/0xa90\n[  106.751738]  [<ffffffff8173c958>] ? retint_swapgs+0x13/0x1b\n[  106.751763]  [<ffffffff8106780c>] do_group_exit+0x4c/0xc0\n[  106.751788]  [<ffffffff81067894>] SyS_exit_group+0x14/0x20\n[  106.751814]  [<ffffffff8174522d>] system_call_fastpath+0x1a/0x1f\n[  106.751839] Code: c3 0f 1f 44 00 00 55 48 89 e5 e8 22 fe ff ff 5d c3\n0f 1f 44 00 00 55 65 48 8b 04 25 c0 c9 00 00 48 8b 80 28 06 00 00 48 89\ne5 5d <48> 8b 40 18 48 39 87 c0 00 00 00 0f 94 c0 c3 0f 1f 80 00 00 00\n[  106.752185] RIP  [<ffffffff811ec7da>] our_mnt+0x1a/0x30\n[  106.752214]  RSP <ffff880400fcba60>\n[  106.752236] CR2: 0000000000000018\n[  106.752258] ---[ end trace 3c520748b4732721 ]---\n----------------------------------------------------------------------\n\nThe reason for the oops is that IMA-appraisal uses \"kernel_read()\" when\nfile is closed. kernel_read() honors LSM security hook which calls\nApparmor handler, which uses current->nsproxy->mnt_ns. The 'guilty'\ncommit changed the order of cleanup code so that nsproxy->mnt_ns was\nnot already available for Apparmor.\n\nDiscussion about the issue with Al Viro and Eric W. Biederman suggested\nthat kernel_read() is too high-level for IMA. Another issue, except\nsecurity checking, that was identified is mandatory locking. kernel_read\nhonors it as well and it might prevent IMA from calculating necessary hash.\nIt was suggested to use simplified version of the function without security\nand locking checks.\n\nThis patch introduces special version ima_kernel_read(), which skips security\nand mandatory locking checking. It prevents the kernel oops to happen.\n\nSigned-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com>\nSuggested-by: Eric W. Biederman <ebiederm@xmission.com>\nSigned-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Dmitry Kasatkin",false],["05d659186c65f5c5d5d777ddb2d57594325965a8","f02992f7c171053741caa6b515d9896745b37477@linux.vnet.ibm.com","evm: prohibit userspace writing 'security.evm' HMAC value\n\ncommit 2fb1c9a4f2dbc2f0bd2431c7fa64d0b5483864e4 upstream.\n\nCalculating the 'security.evm' HMAC value requires access to the\nEVM encrypted key.  Only the kernel should have access to it.  This\npatch prevents userspace tools(eg. setfattr, cp --preserve=xattr)\nfrom setting/modifying the 'security.evm' HMAC value directly.\n\nSigned-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Mimi Zohar",false],["132345b29ad8945d432479a127d46717925ff6e8","18dc2ed701c57df81c0b5498c13767c232eb398f@stealer.net","ipv6: Fix regression caused by efe4208 in udp_v6_mcast_next()\n\n[ Upstream commit 3bfdc59a6c24608ed23e903f670aaf5f58c7a6f3 ]\n\nCommit efe4208 (\"ipv6: make lookups simpler and faster\") introduced a\nregression in udp_v6_mcast_next(), resulting in multicast packets not\nreaching the destination sockets under certain conditions.\n\nThe packet's IPv6 addresses are wrongly compared to the IPv6 addresses\nfrom the function's socket argument, which indicates the starting point\nfor looping, instead of the loop variable. If the addresses from the\nfirst socket do not match the packet's addresses, no socket in the list\nwill match.\n\nSigned-off-by: Sven Wegener <sven.wegener@stealer.net>\nAcked-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Sven Wegener",false]],"size":75,"ref":"refs/heads/vanilla-3.15","head":"ee0a7915b0da249a0c07575fd5fdde2d24430083"}