{"push_id":2041959739,"size":61,"distinct_size":0,"ref":"refs/heads/linaro/linux-linaro-lsk-v3.18","head":"49a6781468f6e9ed48b13edaddf3c8e0341347ea","before":"95a8e64a288afaadb5e77210df0dfa02ffd0eb43","commits":[{"sha":"0c317759e7805e8a615e076186108754093e6d68","author":{"name":"Shu Wang","email":"de7e21144a528077d698dbd189d02929c328ef61@redhat.com"},"message":"cifs: release cifs root_cred after exit_cifs\n\ncommit 94183331e815617246b1baa97e0916f358c794bb upstream.\n\nmemory leak was found by kmemleak. exit_cifs_spnego\nshould be called before cifs module removed, or\ncifs root_cred will not be released.\n\nkmemleak report:\nunreferenced object 0xffff880070a3ce40 (size 192):\n  backtrace:\n     kmemleak_alloc+0x4a/0xa0\n     kmem_cache_alloc+0xc7/0x1d0\n     prepare_kernel_cred+0x20/0x120\n     init_cifs_spnego+0x2d/0x170 [cifs]\n     0xffffffffc07801f3\n     do_one_initcall+0x51/0x1b0\n     do_init_module+0x60/0x1fd\n     load_module+0x161e/0x1b60\n     SYSC_finit_module+0xa9/0x100\n     SyS_finit_module+0xe/0x10\n\nSigned-off-by: Shu Wang <shuwang@redhat.com>\nSigned-off-by: Steve French <smfrench@gmail.com>\nReviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-4.4/commits/0c317759e7805e8a615e076186108754093e6d68"},{"sha":"456bbdc86d18d95d389cc8012259176c09211d5b","author":{"name":"Shu Wang","email":"de7e21144a528077d698dbd189d02929c328ef61@redhat.com"},"message":"cifs: release auth_key.response for reconnect.\n\ncommit f5c4ba816315d3b813af16f5571f86c8d4e897bd upstream.\n\nThere is a race that cause cifs reconnect in cifs_mount,\n- cifs_mount\n  - cifs_get_tcp_session\n    - [ start thread cifs_demultiplex_thread\n      - cifs_read_from_socket: -ECONNABORTED\n        - DELAY_WORK smb2_reconnect_server ]\n  - cifs_setup_session\n  - [ smb2_reconnect_server ]\n\nauth_key.response was allocated in cifs_setup_session, and\nwill release when the session destoried. So when session re-\nconnect, auth_key.response should be check and released.\n\nTested with my system:\nCIFS VFS: Free previous auth_key.response = ffff8800320bbf80\n\nA simple auth_key.response allocation call trace:\n- cifs_setup_session\n- SMB2_sess_setup\n- SMB2_sess_auth_rawntlmssp_authenticate\n- build_ntlmssp_auth_blob\n- setup_ntlmv2_rsp\n\nSigned-off-by: Shu Wang <shuwang@redhat.com>\nSigned-off-by: Steve French <smfrench@gmail.com>\nReviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-4.4/commits/456bbdc86d18d95d389cc8012259176c09211d5b"},{"sha":"998173c7a119102c637506b5ecaa205821755a65","author":{"name":"Avraham Stern","email":"216d020e003f7c38de8f56f95fa371c6be70f0bb@intel.com"},"message":"mac80211: flush hw_roc_start work before cancelling the ROC\n\ncommit 6e46d8ce894374fc135c96a8d1057c6af1fef237 upstream.\n\nWhen HW ROC is supported it is possible that after the HW notified\nthat the ROC has started, the ROC was cancelled and another ROC was\nadded while the hw_roc_start worker is waiting on the mutex (since\ncancelling the ROC and adding another one also holds the same mutex).\nAs a result, the hw_roc_start worker will continue to run after the\nnew ROC is added but before it is actually started by the HW.\nThis may result in notifying userspace that the ROC has started before\nit actually does, or in case of management tx ROC, in an attempt to\ntx while not on the right channel.\n\nIn addition, when the driver will notify mac80211 that the second ROC\nhas started, mac80211 will warn that this ROC has already been\nnotified.\n\nFix this by flushing the hw_roc_start work before cancelling an ROC.\n\nSigned-off-by: Avraham Stern <avraham.stern@intel.com>\nSigned-off-by: Luca Coelho <luciano.coelho@intel.com>\nSigned-off-by: Johannes Berg <johannes.berg@intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-4.4/commits/998173c7a119102c637506b5ecaa205821755a65"},{"sha":"9b9ce7484a5f7099435ee2827acd1020edacedef","author":{"name":"Paul Mackerras","email":"b848d7d196719b06ca69c3524d28631335b2ab79@ozlabs.org"},"message":"KVM: PPC: Book3S: Fix race and leak in kvm_vm_ioctl_create_spapr_tce()\n\ncommit 47c5310a8dbe7c2cb9f0083daa43ceed76c257fa upstream, with part\nof commit edd03602d97236e8fea13cd76886c576186aa307 folded in.\n\nNixiaoming pointed out that there is a memory leak in\nkvm_vm_ioctl_create_spapr_tce() if the call to anon_inode_getfd()\nfails; the memory allocated for the kvmppc_spapr_tce_table struct\nis not freed, and nor are the pages allocated for the iommu\ntables.\n\nDavid Hildenbrand pointed out that there is a race in that the\nfunction checks early on that there is not already an entry in the\nstt->iommu_tables list with the same LIOBN, but an entry with the\nsame LIOBN could get added between then and when the new entry is\nadded to the list.\n\nThis fixes both problems.  To simplify things, we now call\nanon_inode_getfd() before placing the new entry in the list.  The\ncheck for an existing entry is done while holding the kvm->lock\nmutex, immediately before adding the new entry to the list.\n\n[paulus@ozlabs.org - folded in that part of edd03602d972 (\"KVM:\n PPC: Book3S HV: Protect updates to spapr_tce_tables list\", 2017-08-28)\n which restructured the code that 47c5310a8dbe modified, to avoid\n a build failure caused by the absence of put_unused_fd().\n Also removed the locked memory accounting, since it doesn't exist\n in this version, and adjusted the commit message.]\n\nFixes: 54738c097163 (\"KVM: PPC: Accelerate H_PUT_TCE by implementing it in real mode\")\nReported-by: Nixiaoming <nixiaoming@huawei.com>\nReported-by: David Hildenbrand <david@redhat.com>\nSigned-off-by: Paul Mackerras <paulus@ozlabs.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-4.4/commits/9b9ce7484a5f7099435ee2827acd1020edacedef"},{"sha":"8923bf76c1ea47b16b2d6ccb9e09cdd913ffa06d","author":{"name":"Tahsin Erdogan","email":"f575aabfcf931cdd93bfc82db2c7bb41f58ee7dd@google.com"},"message":"tracing: Fix trace_pipe behavior for instance traces\n\ncommit 75df6e688ccd517e339a7c422ef7ad73045b18a2 upstream.\n\nWhen reading data from trace_pipe, tracing_wait_pipe() performs a\ncheck to see if tracing has been turned off after some data was read.\nCurrently, this check always looks at global trace state, but it\nshould be checking the trace instance where trace_pipe is located at.\n\nBecause of this bug, cat instances/i1/trace_pipe in the following\nscript will immediately exit instead of waiting for data:\n\ncd /sys/kernel/debug/tracing\necho 0 > tracing_on\nmkdir -p instances/i1\necho 1 > instances/i1/tracing_on\necho 1 > instances/i1/events/sched/sched_process_exec/enable\ncat instances/i1/trace_pipe\n\nLink: http://lkml.kernel.org/r/20170917102348.1615-1-tahsin@google.com\n\nFixes: 10246fa35d4f (\"tracing: give easy way to clear trace buffer\")\nSigned-off-by: Tahsin Erdogan <tahsin@google.com>\nSigned-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-4.4/commits/8923bf76c1ea47b16b2d6ccb9e09cdd913ffa06d"},{"sha":"58061248504a4ab93f802e648daad063857dcac6","author":{"name":"Bo Yan","email":"edd93ff839b8df3dc1ed20dab6d5b707bc8ef164@nvidia.com"},"message":"tracing: Erase irqsoff trace with empty write\n\ncommit 8dd33bcb7050dd6f8c1432732f930932c9d3a33e upstream.\n\nOne convenient way to erase trace is \"echo > trace\". However, this\nis currently broken if the current tracer is irqsoff tracer. This\nis because irqsoff tracer use max_buffer as the default trace\nbuffer.\n\nSet the max_buffer as the one to be cleared when it's the trace\nbuffer currently in use.\n\nLink: http://lkml.kernel.org/r/1505754215-29411-1-git-send-email-byan@nvidia.com\n\nCc: <mingo@redhat.com>\nFixes: 4acd4d00f (\"tracing: give easy way to clear trace buffer\")\nSigned-off-by: Bo Yan <byan@nvidia.com>\nSigned-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-4.4/commits/58061248504a4ab93f802e648daad063857dcac6"},{"sha":"fec4cd33779f9edd7ab2d0d5ad7228f55f3f6887","author":{"name":"Xin Long","email":"0c651f6709819e543c4ca1708bc1021b57131127@gmail.com"},"message":"scsi: scsi_transport_iscsi: fix the issue that iscsi_if_rx doesn't parse nlmsg properly\n\ncommit c88f0e6b06f4092995688211a631bb436125d77b upstream.\n\nChunYu found a kernel crash by syzkaller:\n\n[  651.617875] kasan: CONFIG_KASAN_INLINE enabled\n[  651.618217] kasan: GPF could be caused by NULL-ptr deref or user memory access\n[  651.618731] general protection fault: 0000 [#1] SMP KASAN\n[  651.621543] CPU: 1 PID: 9539 Comm: scsi Not tainted 4.11.0.cov #32\n[  651.621938] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011\n[  651.622309] task: ffff880117780000 task.stack: ffff8800a3188000\n[  651.622762] RIP: 0010:skb_release_data+0x26c/0x590\n[...]\n[  651.627260] Call Trace:\n[  651.629156]  skb_release_all+0x4f/0x60\n[  651.629450]  consume_skb+0x1a5/0x600\n[  651.630705]  netlink_unicast+0x505/0x720\n[  651.632345]  netlink_sendmsg+0xab2/0xe70\n[  651.633704]  sock_sendmsg+0xcf/0x110\n[  651.633942]  ___sys_sendmsg+0x833/0x980\n[  651.637117]  __sys_sendmsg+0xf3/0x240\n[  651.638820]  SyS_sendmsg+0x32/0x50\n[  651.639048]  entry_SYSCALL_64_fastpath+0x1f/0xc2\n\nIt's caused by skb_shared_info at the end of sk_buff was overwritten by\nISCSI_KEVENT_IF_ERROR when parsing nlmsg info from skb in iscsi_if_rx.\n\nDuring the loop if skb->len == nlh->nlmsg_len and both are sizeof(*nlh),\nev = nlmsg_data(nlh) will acutally get skb_shinfo(SKB) instead and set a\nnew value to skb_shinfo(SKB)->nr_frags by ev->type.\n\nThis patch is to fix it by checking nlh->nlmsg_len properly there to\navoid over accessing sk_buff.\n\nReported-by: ChunYu Wang <chunwang@redhat.com>\nSigned-off-by: Xin Long <lucien.xin@gmail.com>\nAcked-by: Chris Leech <cleech@redhat.com>\nSigned-off-by: Martin K. Petersen <martin.petersen@oracle.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-4.4/commits/fec4cd33779f9edd7ab2d0d5ad7228f55f3f6887"},{"sha":"2d9db72fb50e72aafaac2b99f4fcf1013497d8da","author":{"name":"LEROY Christophe","email":"039dabc4895565112aed26d4ec2b65f486237723@c-s.fr"},"message":"crypto: talitos - fix sha224\n\ncommit afd62fa26343be6445479e75de9f07092a061459 upstream.\n\nKernel crypto tests report the following error at startup\n\n[    2.752626] alg: hash: Test 4 failed for sha224-talitos\n[    2.757907] 00000000: 30 e2 86 e2 e7 8a dd 0d d7 eb 9f d5 83 fe f1 b0\n00000010: 2d 5a 6c a5 f9 55 ea fd 0e 72 05 22\n\nThis patch fixes it\n\nSigned-off-by: Christophe Leroy <christophe.leroy@c-s.fr>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-4.4/commits/2d9db72fb50e72aafaac2b99f4fcf1013497d8da"},{"sha":"50f17a4b9141111a50d9eb127389fa69b2085d7c","author":{"name":"Eric Biggers","email":"0106d512ed1cb672be29d4b167a07ead51709fba@google.com"},"message":"KEYS: fix writing past end of user-supplied buffer in keyring_read()\n\ncommit e645016abc803dafc75e4b8f6e4118f088900ffb upstream.\n\nUserspace can call keyctl_read() on a keyring to get the list of IDs of\nkeys in the keyring.  But if the user-supplied buffer is too small, the\nkernel would write the full list anyway --- which will corrupt whatever\nuserspace memory happened to be past the end of the buffer.  Fix it by\nonly filling the space that is available.\n\nFixes: b2a4df200d57 (\"KEYS: Expand the capacity of a keyring\")\nSigned-off-by: Eric Biggers <ebiggers@google.com>\nSigned-off-by: David Howells <dhowells@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-4.4/commits/50f17a4b9141111a50d9eb127389fa69b2085d7c"},{"sha":"e3b663ba2ddd8f30ba92d4e6898637bb526dba70","author":{"name":"Eric Biggers","email":"0106d512ed1cb672be29d4b167a07ead51709fba@google.com"},"message":"KEYS: prevent creating a different user's keyrings\n\ncommit 237bbd29f7a049d310d907f4b2716a7feef9abf3 upstream.\n\nIt was possible for an unprivileged user to create the user and user\nsession keyrings for another user.  For example:\n\n    sudo -u '#3000' sh -c 'keyctl add keyring _uid.4000 \"\" @u\n                           keyctl add keyring _uid_ses.4000 \"\" @u\n                           sleep 15' &\n    sleep 1\n    sudo -u '#4000' keyctl describe @u\n    sudo -u '#4000' keyctl describe @us\n\nThis is problematic because these \"fake\" keyrings won't have the right\npermissions.  In particular, the user who created them first will own\nthem and will have full access to them via the possessor permissions,\nwhich can be used to compromise the security of a user's keys:\n\n    -4: alswrv-----v------------  3000     0 keyring: _uid.4000\n    -5: alswrv-----v------------  3000     0 keyring: _uid_ses.4000\n\nFix it by marking user and user session keyrings with a flag\nKEY_FLAG_UID_KEYRING.  Then, when searching for a user or user session\nkeyring by name, skip all keyrings that don't have the flag set.\n\nFixes: 69664cf16af4 (\"keys: don't generate user and user session keyrings unless they're accessed\")\nSigned-off-by: Eric Biggers <ebiggers@google.com>\nSigned-off-by: David Howells <dhowells@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-4.4/commits/e3b663ba2ddd8f30ba92d4e6898637bb526dba70"},{"sha":"6ea8051f42d965e3197ef31d4f54f75525b9439c","author":{"name":"Eric Biggers","email":"0106d512ed1cb672be29d4b167a07ead51709fba@google.com"},"message":"KEYS: prevent KEYCTL_READ on negative key\n\ncommit 37863c43b2c6464f252862bf2e9768264e961678 upstream.\n\nBecause keyctl_read_key() looks up the key with no permissions\nrequested, it may find a negatively instantiated key.  If the key is\nalso possessed, we went ahead and called ->read() on the key.  But the\nkey payload will actually contain the ->reject_error rather than the\nnormal payload.  Thus, the kernel oopses trying to read the\nuser_key_payload from memory address (int)-ENOKEY = 0x00000000ffffff82.\n\nFortunately the payload data is stored inline, so it shouldn't be\npossible to abuse this as an arbitrary memory read primitive...\n\nReproducer:\n    keyctl new_session\n    keyctl request2 user desc '' @s\n    keyctl read $(keyctl show | awk '/user: desc/ {print $1}')\n\nIt causes a crash like the following:\n     BUG: unable to handle kernel paging request at 00000000ffffff92\n     IP: user_read+0x33/0xa0\n     PGD 36a54067 P4D 36a54067 PUD 0\n     Oops: 0000 [#1] SMP\n     CPU: 0 PID: 211 Comm: keyctl Not tainted 4.14.0-rc1 #337\n     Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-20170228_101828-anatol 04/01/2014\n     task: ffff90aa3b74c3c0 task.stack: ffff9878c0478000\n     RIP: 0010:user_read+0x33/0xa0\n     RSP: 0018:ffff9878c047bee8 EFLAGS: 00010246\n     RAX: 0000000000000001 RBX: ffff90aa3d7da340 RCX: 0000000000000017\n     RDX: 0000000000000000 RSI: 00000000ffffff82 RDI: ffff90aa3d7da340\n     RBP: ffff9878c047bf00 R08: 00000024f95da94f R09: 0000000000000000\n     R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000\n     R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n     FS:  00007f58ece69740(0000) GS:ffff90aa3e200000(0000) knlGS:0000000000000000\n     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n     CR2: 00000000ffffff92 CR3: 0000000036adc001 CR4: 00000000003606f0\n     Call Trace:\n      keyctl_read_key+0xac/0xe0\n      SyS_keyctl+0x99/0x120\n      entry_SYSCALL_64_fastpath+0x1f/0xbe\n     RIP: 0033:0x7f58ec787bb9\n     RSP: 002b:00007ffc8d401678 EFLAGS: 00000206 ORIG_RAX: 00000000000000fa\n     RAX: ffffffffffffffda RBX: 00007ffc8d402800 RCX: 00007f58ec787bb9\n     RDX: 0000000000000000 RSI: 00000000174a63ac RDI: 000000000000000b\n     RBP: 0000000000000004 R08: 00007ffc8d402809 R09: 0000000000000020\n     R10: 0000000000000000 R11: 0000000000000206 R12: 00007ffc8d402800\n     R13: 00007ffc8d4016e0 R14: 0000000000000000 R15: 0000000000000000\n     Code: e5 41 55 49 89 f5 41 54 49 89 d4 53 48 89 fb e8 a4 b4 ad ff 85 c0 74 09 80 3d b9 4c 96 00 00 74 43 48 8b b3 20 01 00 00 4d 85 ed <0f> b7 5e 10 74 29 4d 85 e4 74 24 4c 39 e3 4c 89 e2 4c 89 ef 48\n     RIP: user_read+0x33/0xa0 RSP: ffff9878c047bee8\n     CR2: 00000000ffffff92\n\nFixes: 61ea0c0ba904 (\"KEYS: Skip key state checks when checking for possession\")\nSigned-off-by: Eric Biggers <ebiggers@google.com>\nSigned-off-by: David Howells <dhowells@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-4.4/commits/6ea8051f42d965e3197ef31d4f54f75525b9439c"},{"sha":"b93becabbaf4c0e3963ebd62e2e094fc68deec08","author":{"name":"Tyrel Datwyler","email":"239574f6f50677ab121db12378c1c57839ade2b5@linux.vnet.ibm.com"},"message":"powerpc/pseries: Fix parent_dn reference leak in add_dt_node()\n\ncommit b537ca6fede69a281dc524983e5e633d79a10a08 upstream.\n\nA reference to the parent device node is held by add_dt_node() for the\nnode to be added. If the call to dlpar_configure_connector() fails\nadd_dt_node() returns ENOENT and that reference is not freed.\n\nAdd a call to of_node_put(parent_dn) prior to bailing out after a\nfailed dlpar_configure_connector() call.\n\nFixes: 8d5ff320766f (\"powerpc/pseries: Make dlpar_configure_connector parent node aware\")\nSigned-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-4.4/commits/b93becabbaf4c0e3963ebd62e2e094fc68deec08"},{"sha":"b3c1243ba1bc4ab4c632078412381750f94bb649","author":{"name":"Steve French","email":"dadf70b8465ad9f3c1689b7cee29b8d58c371d4b@gmail.com"},"message":"SMB: Validate negotiate (to protect against downgrade) even if signing off\n\ncommit 0603c96f3af50e2f9299fa410c224ab1d465e0f9 upstream.\n\nAs long as signing is supported (ie not a guest user connection) and\nconnection is SMB3 or SMB3.02, then validate negotiate (protect\nagainst man in the middle downgrade attacks).  We had been doing this\nonly when signing was required, not when signing was just enabled,\nbut this more closely matches recommended SMB3 behavior and is\nbetter security.  Suggested by Metze.\n\nSigned-off-by: Steve French <smfrench@gmail.com>\nReviewed-by: Jeremy Allison <jra@samba.org>\nAcked-by: Stefan Metzmacher <metze@samba.org>\nReviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-4.4/commits/b3c1243ba1bc4ab4c632078412381750f94bb649"},{"sha":"64304f5ae2f37d54072b208d53fb692ef941d168","author":{"name":"Steve French","email":"dadf70b8465ad9f3c1689b7cee29b8d58c371d4b@gmail.com"},"message":"SMB3: Don't ignore O_SYNC/O_DSYNC and O_DIRECT flags\n\ncommit 1013e760d10e614dc10b5624ce9fc41563ba2e65 upstream.\n\nSigned-off-by: Steve French <smfrench@gmail.com>\nReviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>\nReviewed-by: Pavel Shilovsky <pshilov@microsoft.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-4.4/commits/64304f5ae2f37d54072b208d53fb692ef941d168"},{"sha":"9f119f5cc0480e7d1eaa4e16ecbcddcdd5e8db6f","author":{"name":"Andreas Gruenbacher","email":"08b2cb48e36cff32923bf4d42059e4e98f599fa4@redhat.com"},"message":"vfs: Return -ENXIO for negative SEEK_HOLE / SEEK_DATA offsets\n\ncommit fc46820b27a2d9a46f7e90c9ceb4a64a1bc5fab8 upstream.\n\nIn generic_file_llseek_size, return -ENXIO for negative offsets as well\nas offsets beyond EOF.  This affects filesystems which don't implement\nSEEK_HOLE / SEEK_DATA internally, possibly because they don't support\nholes.\n\nFixes xfstest generic/448.\n\nSigned-off-by: Andreas Gruenbacher <agruenba@redhat.com>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-4.4/commits/9f119f5cc0480e7d1eaa4e16ecbcddcdd5e8db6f"},{"sha":"65e3664fc6087d2941e940e38beb39920e9ae032","author":{"name":"Vladis Dronov","email":"41435c47c64e54f8ec26bbc1be6d7972ea4d40bd@redhat.com"},"message":"nl80211: check for the required netlink attributes presence\n\ncommit e785fa0a164aa11001cba931367c7f94ffaff888 upstream.\n\nnl80211_set_rekey_data() does not check if the required attributes\nNL80211_REKEY_DATA_{REPLAY_CTR,KEK,KCK} are present when processing\nNL80211_CMD_SET_REKEY_OFFLOAD request. This request can be issued by\nusers with CAP_NET_ADMIN privilege and may result in NULL dereference\nand a system crash. Add a check for the required attributes presence.\nThis patch is based on the patch by bo Zhang.\n\nThis fixes CVE-2017-12153.\n\nReferences: https://bugzilla.redhat.com/show_bug.cgi?id=1491046\nFixes: e5497d766ad (\"cfg80211/nl80211: support GTK rekey offload\")\nReported-by: bo Zhang <zhangbo5891001@gmail.com>\nSigned-off-by: Vladis Dronov <vdronov@redhat.com>\nSigned-off-by: Johannes Berg <johannes.berg@intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-4.4/commits/65e3664fc6087d2941e940e38beb39920e9ae032"},{"sha":"d9100405a20a71dd620843e0380e38fc50731108","author":{"name":"Christoph Hellwig","email":"ed9f47d6dfaca04b245b5f2816a0d3e9462a0b83@lst.de"},"message":"bsg-lib: don't free job in bsg_prepare_job\n\ncommit f507b54dccfd8000c517d740bc45f20c74532d18 upstream.\n\nThe job structure is allocated as part of the request, so we should not\nfree it in the error path of bsg_prepare_job.\n\nSigned-off-by: Christoph Hellwig <hch@lst.de>\nReviewed-by: Ming Lei <ming.lei@redhat.com>\nSigned-off-by: Jens Axboe <axboe@kernel.dk>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-4.4/commits/d9100405a20a71dd620843e0380e38fc50731108"},{"sha":"6528968794bc6b4091a7603ae863472c1ef7c393","author":{"name":"Marc Zyngier","email":"3404add73d8af5dc5183acdd46985971473febc7@arm.com"},"message":"arm64: Make sure SPsel is always set\n\ncommit 5371513fb338fb9989c569dc071326d369d6ade8 upstream.\n\nWhen the kernel is entered at EL2 on an ARMv8.0 system, we construct\nthe EL1 pstate and make sure this uses the the EL1 stack pointer\n(we perform an exception return to EL1h).\n\nBut if the kernel is either entered at EL1 or stays at EL2 (because\nwe're on a VHE-capable system), we fail to set SPsel, and use whatever\nstack selection the higher exception level has choosen for us.\n\nLet's not take any chance, and make sure that SPsel is set to one\nbefore we decide the mode we're going to run in.\n\nAcked-by: Mark Rutland <mark.rutland@arm.com>\nSigned-off-by: Marc Zyngier <marc.zyngier@arm.com>\nSigned-off-by: Will Deacon <will.deacon@arm.com>\nSigned-off-by: Catalin Marinas <catalin.marinas@arm.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-4.4/commits/6528968794bc6b4091a7603ae863472c1ef7c393"},{"sha":"6ad74630c016ef823f2720671ee4db641d35fd2c","author":{"name":"Jim Mattson","email":"e5a765aabab19368c7df8b27c5612e935d2ed847@google.com"},"message":"kvm: nVMX: Don't allow L2 to access the hardware CR8\n\ncommit 51aa68e7d57e3217192d88ce90fd5b8ef29ec94f upstream.\n\nIf L1 does not specify the \"use TPR shadow\" VM-execution control in\nvmcs12, then L0 must specify the \"CR8-load exiting\" and \"CR8-store\nexiting\" VM-execution controls in vmcs02. Failure to do so will give\nthe L2 VM unrestricted read/write access to the hardware CR8.\n\nThis fixes CVE-2017-12154.\n\nSigned-off-by: Jim Mattson <jmattson@google.com>\nReviewed-by: David Hildenbrand <david@redhat.com>\nSigned-off-by: Paolo Bonzini <pbonzini@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-4.4/commits/6ad74630c016ef823f2720671ee4db641d35fd2c"},{"sha":"0544aab81d35a0ec852eb63a5e6bfa6eac132848","author":{"name":"Nicolai Stange","email":"527d1bd4a586426c3b05fde0aa37487d5d0f2ca1@suse.de"},"message":"PCI: Fix race condition with driver_override\n\ncommit 9561475db680f7144d2223a409dd3d7e322aca03 upstream.\n\nThe driver_override implementation is susceptible to a race condition when\ndifferent threads are reading vs. storing a different driver override.  Add\nlocking to avoid the race condition.\n\nThis is in close analogy to commit 6265539776a0 (\"driver core: platform:\nfix race condition with driver_override\") from Adrian Salido.\n\nFixes: 782a985d7af2 (\"PCI: Introduce new device binding path using pci_dev.driver_override\")\nSigned-off-by: Nicolai Stange <nstange@suse.de>\nSigned-off-by: Bjorn Helgaas <bhelgaas@google.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-4.4/commits/0544aab81d35a0ec852eb63a5e6bfa6eac132848"}]}
{"actor":{"display_login":"akhilnarang"}}