{"push_id":813257386,"size":54,"distinct_size":54,"ref":"refs/heads/5.1","head":"177d0853a14b9ebee30935a400b9b6802c6e5027","before":"3da99e4fdf55c3ca9a55b0b72f5a436964bcba2e","commits":[{"sha":"57a87af89dfe7d1857e31a4175d1fcf585261906","author":{"email":"8a741aa8cbd77ebc4a56ddb528ce9fd15d42f034@xmission.com","name":"Eric W. Biederman"},"message":"unshare: Unsharing a thread does not require unsharing a vm\n\ncommit 12c641ab8270f787dfcce08b5f20ce8b65008096 upstream.\n\nIn the logic in the initial commit of unshare made creating a new\nthread group for a process, contingent upon creating a new memory\naddress space for that process.  That is wrong.  Two separate\nprocesses in different thread groups can share a memory address space\nand clone allows creation of such proceses.\n\nThis is significant because it was observed that mm_users > 1 does not\nmean that a process is multi-threaded, as reading /proc/PID/maps\ntemporarily increments mm_users, which allows other processes to\n(accidentally) interfere with unshare() calls.\n\nCorrect the check in check_unshare_flags() to test for\n!thread_group_empty() for CLONE_THREAD, CLONE_SIGHAND, and CLONE_VM.\nFor sighand->count > 1 for CLONE_SIGHAND and CLONE_VM.\nFor !current_is_single_threaded instead of mm_users > 1 for CLONE_VM.\n\nBy using the correct checks in unshare this removes the possibility of\nan accidental denial of service attack.\n\nAdditionally using the correct checks in unshare ensures that only an\nexplicit unshare(CLONE_VM) can possibly trigger the slow path of\ncurrent_is_single_threaded().  As an explict unshare(CLONE_VM) is\npointless it is not expected there are many applications that make\nthat call.\n\nFixes: b2e0d98705e60e45bbb3c0032c48824ad7ae0704 userns: Implement unshare of the user namespace\nReported-by: Ricky Zhou <rickyz@chromium.org>\nReported-by: Kees Cook <keescook@chromium.org>\nReviewed-by: Kees Cook <keescook@chromium.org>\nSigned-off-by: \"Eric W. Biederman\" <ebiederm@xmission.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Radium-Devices/Radium_yu/commits/57a87af89dfe7d1857e31a4175d1fcf585261906"},{"sha":"3f86d653967f635dd378be7ec51635d8e6e934a3","author":{"email":"424ebdc21fc3d0b1d4ce3d72fe6f41801cd0ae69@schischi.me","name":"Adrien Schildknecht"},"message":"rtlwifi: rtl8192cu: Add new device ID\n\ncommit 1642d09fb9b128e8e538b2a4179962a34f38dff9 upstream.\n\nThe v2 of NetGear WNA1000M uses a different idProduct: USB ID 0846:9043\n\nSigned-off-by: Adrien Schildknecht <adrien+dev@schischi.me>\nAcked-by: Larry Finger <Larry.Finger@lwfinger.net>\nSigned-off-by: Kalle Valo <kvalo@codeaurora.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Radium-Devices/Radium_yu/commits/3f86d653967f635dd378be7ec51635d8e6e934a3"},{"sha":"fd7e6b02e5d36b61730cff14227f553e3339c2b4","author":{"email":"efca98801f3398ebd7eeff805a2c18e6c49e84d4@suse.de","name":"Jean Delvare"},"message":"tg3: Fix temperature reporting\n\ncommit d3d11fe08ccc9bff174fc958722b5661f0932486 upstream.\n\nThe temperature registers appear to report values in degrees Celsius\nwhile the hwmon API mandates values to be exposed in millidegrees\nCelsius. Do the conversion so that the values reported by \"sensors\"\nare correct.\n\nFixes: aed93e0bf493 (\"tg3: Add hwmon support for temperature\")\nSigned-off-by: Jean Delvare <jdelvare@suse.de>\nCc: Prashant Sreedharan <prashant@broadcom.com>\nCc: Michael Chan <mchan@broadcom.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Radium-Devices/Radium_yu/commits/fd7e6b02e5d36b61730cff14227f553e3339c2b4"},{"sha":"f0bd6dc5050177f2431465597452676de2ed622b","author":{"email":"b1c1d8736f20db3fb6c1c66bb1455ed43909f0d8@bobcopeland.com","name":"Bob Copeland"},"message":"mac80211: enable assoc check for mesh interfaces\n\ncommit 3633ebebab2bbe88124388b7620442315c968e8f upstream.\n\nWe already set a station to be associated when peering completes, both\nin user space and in the kernel.  Thus we should always have an\nassociated sta before sending data frames to that station.\n\nFailure to check assoc state can cause crashes in the lower-level driver\ndue to transmitting unicast data frames before driver sta structures\n(e.g. ampdu state in ath9k) are initialized.  This occurred when\nforwarding in the presence of fixed mesh paths: frames were transmitted\nto stations with whom we hadn't yet completed peering.\n\nReported-by: Alexis Green <agreen@cococorp.com>\nTested-by: Jesse Jones <jjones@cococorp.com>\nSigned-off-by: Bob Copeland <me@bobcopeland.com>\nSigned-off-by: Johannes Berg <johannes.berg@intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Radium-Devices/Radium_yu/commits/f0bd6dc5050177f2431465597452676de2ed622b"},{"sha":"e9bd256993210ec168944f33ecbe17b1c8ca9eb3","author":{"email":"fbe788dcd509b324901fbdfe505a4d610d560569@google.com","name":"Jeff Vander Stoep"},"message":"arm64: kconfig: Move LIST_POISON to a safe value\n\ncommit bf0c4e04732479f650ff59d1ee82de761c0071f0 upstream.\n\nMove the poison pointer offset to 0xdead000000000000, a\nrecognized value that is not mappable by user-space exploits.\n\nAcked-by: Catalin Marinas <catalin.marinas@arm.com>\nSigned-off-by: Thierry Strudel <tstrudel@google.com>\nSigned-off-by: Jeff Vander Stoep <jeffv@google.com>\nSigned-off-by: Will Deacon <will.deacon@arm.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Radium-Devices/Radium_yu/commits/e9bd256993210ec168944f33ecbe17b1c8ca9eb3"},{"sha":"abd97bb39352e90d7a11fdcfd88bd1cfcf7983df","author":{"email":"b913f13ef92ac157955c954ccaaff7be065faba4@arm.com","name":"Will Deacon"},"message":"arm64: compat: fix vfp save/restore across signal handlers in big-endian\n\ncommit bdec97a855ef1e239f130f7a11584721c9a1bf04 upstream.\n\nWhen saving/restoring the VFP registers from a compat (AArch32)\nsignal frame, we rely on the compat registers forming a prefix of the\nnative register file and therefore make use of copy_{to,from}_user to\ntransfer between the native fpsimd_state and the compat_vfp_sigframe.\n\nUnfortunately, this doesn't work so well in a big-endian environment.\nOur fpsimd save/restore code operates directly on 128-bit quantities\n(Q registers) whereas the compat_vfp_sigframe represents the registers\nas an array of 64-bit (D) registers. The architecture packs the compat D\nregisters into the Q registers, with the least significant bytes holding\nthe lower register. Consequently, we need to swap the 64-bit halves when\nconverting between these two representations on a big-endian machine.\n\nThis patch replaces the __copy_{to,from}_user invocations in our\ncompat VFP signal handling code with explicit __put_user loops that\noperate on 64-bit values and swap them accordingly.\n\nReviewed-by: Catalin Marinas <catalin.marinas@arm.com>\nSigned-off-by: Will Deacon <will.deacon@arm.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Radium-Devices/Radium_yu/commits/abd97bb39352e90d7a11fdcfd88bd1cfcf7983df"},{"sha":"90cede3343eed6b16a84370910e562a7c92da556","author":{"email":"b913f13ef92ac157955c954ccaaff7be065faba4@arm.com","name":"Will Deacon"},"message":"arm64: head.S: initialise mdcr_el2 in el2_setup\n\ncommit d10bcd473301888f957ec4b6b12aa3621be78d59 upstream.\n\nWhen entering the kernel at EL2, we fail to initialise the MDCR_EL2\nregister which controls debug access and PMU capabilities at EL1.\n\nThis patch ensures that the register is initialised so that all traps\nare disabled and all the PMU counters are available to the host. When a\nguest is scheduled, KVM takes care to configure trapping appropriately.\n\nAcked-by: Marc Zyngier <marc.zyngier@arm.com>\nSigned-off-by: Will Deacon <will.deacon@arm.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Radium-Devices/Radium_yu/commits/90cede3343eed6b16a84370910e562a7c92da556"},{"sha":"cfdbe75dbf0383dc75a517a9ad6845a1a2d95dfb","author":{"email":"4596b3305151c7ee743192a95d394341e3d3b644@suse.de","name":"Takashi Iwai"},"message":"ALSA: hda - Enable headphone jack detect on old Fujitsu laptops\n\ncommit bb148bdeb0ab16fc0ae8009799471e4d7180073b upstream.\n\nAccording to the bug report, FSC Amilo laptops with ALC880 can detect\nthe headphone jack but currently the driver disables it.  It's partly\nintentionally, as non-working jack detect was reported in the past.\nLet's enable now.\n\nBugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=102501\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Radium-Devices/Radium_yu/commits/cfdbe75dbf0383dc75a517a9ad6845a1a2d95dfb"},{"sha":"da9b2022c6a5fd627e23aaab02b9dbc05bf135e3","author":{"email":"4596b3305151c7ee743192a95d394341e3d3b644@suse.de","name":"Takashi Iwai"},"message":"ALSA: hda - Use ALC880_FIXUP_FUJITSU for FSC Amilo M1437\n\ncommit a161574e200ae63a5042120e0d8c36830e81bde3 upstream.\n\nIt turned out that the machine has a bass speaker, so take a correct\nfixup entry.\n\nBugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=102501\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Radium-Devices/Radium_yu/commits/da9b2022c6a5fd627e23aaab02b9dbc05bf135e3"},{"sha":"5ad254571c9851d28721731d5d015ad220761c59","author":{"email":"864f124608374e06e4da1fa5d2e47ed839b95411@ellerman.id.au","name":"Michael Ellerman"},"message":"powerpc/mm: Fix pte_pagesize_index() crash on 4K w/64K hash\n\ncommit 74b5037baa2011a2799e2c43adde7d171b072f9e upstream.\n\nThe powerpc kernel can be built to have either a 4K PAGE_SIZE or a 64K\nPAGE_SIZE.\n\nHowever when built with a 4K PAGE_SIZE there is an additional config\noption which can be enabled, PPC_HAS_HASH_64K, which means the kernel\nalso knows how to hash a 64K page even though the base PAGE_SIZE is 4K.\n\nThis is used in one obscure configuration, to support 64K pages for SPU\nlocal store on the Cell processor when the rest of the kernel is using\n4K pages.\n\nIn this configuration, pte_pagesize_index() is defined to just pass\nthrough its arguments to get_slice_psize(). However pte_pagesize_index()\nis called for both user and kernel addresses, whereas get_slice_psize()\nonly knows how to handle user addresses.\n\nThis has been broken forever, however until recently it happened to\nwork. That was because in get_slice_psize() the large kernel address\nwould cause the right shift of the slice mask to return zero.\n\nHowever in commit 7aa0727f3302 (\"powerpc/mm: Increase the slice range to\n64TB\"), the get_slice_psize() code was changed so that instead of a\nright shift we do an array lookup based on the address. When passed a\nkernel address this means we index way off the end of the slice array\nand return random junk.\n\nThat is only fatal if we happen to hit something non-zero, but when we\ndo return a non-zero value we confuse the MMU code and eventually cause\na check stop.\n\nThis fix is ugly, but simple. When we're called for a kernel address we\nreturn 4K, which is always correct in this configuration, otherwise we\nuse the slice mask.\n\nFixes: 7aa0727f3302 (\"powerpc/mm: Increase the slice range to 64TB\")\nReported-by: Cyril Bur <cyrilbur@gmail.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>\nReviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Radium-Devices/Radium_yu/commits/5ad254571c9851d28721731d5d015ad220761c59"},{"sha":"bbb0ef214a94c94b6bd4842aadef1b61392e0ac3","author":{"email":"9e65be74847981e55b2564b6266c57d86d3bac05@redhat.com","name":"Thomas Huth"},"message":"powerpc/rtas: Introduce rtas_get_sensor_fast() for IRQ handlers\n\ncommit 1c2cb594441d02815d304cccec9742ff5c707495 upstream.\n\nThe EPOW interrupt handler uses rtas_get_sensor(), which in turn\nuses rtas_busy_delay() to wait for RTAS becoming ready in case it\nis necessary. But rtas_busy_delay() is annotated with might_sleep()\nand thus may not be used by interrupts handlers like the EPOW handler!\nThis leads to the following BUG when CONFIG_DEBUG_ATOMIC_SLEEP is\nenabled:\n\n BUG: sleeping function called from invalid context at arch/powerpc/kernel/rtas.c:496\n in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/1\n CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.2.0-rc2-thuth #6\n Call Trace:\n [c00000007ffe7b90] [c000000000807670] dump_stack+0xa0/0xdc (unreliable)\n [c00000007ffe7bc0] [c0000000000e1f14] ___might_sleep+0x134/0x180\n [c00000007ffe7c20] [c00000000002aec0] rtas_busy_delay+0x30/0xd0\n [c00000007ffe7c50] [c00000000002bde4] rtas_get_sensor+0x74/0xe0\n [c00000007ffe7ce0] [c000000000083264] ras_epow_interrupt+0x44/0x450\n [c00000007ffe7d90] [c000000000120260] handle_irq_event_percpu+0xa0/0x300\n [c00000007ffe7e70] [c000000000120524] handle_irq_event+0x64/0xc0\n [c00000007ffe7eb0] [c000000000124dbc] handle_fasteoi_irq+0xec/0x260\n [c00000007ffe7ef0] [c00000000011f4f0] generic_handle_irq+0x50/0x80\n [c00000007ffe7f20] [c000000000010f3c] __do_irq+0x8c/0x200\n [c00000007ffe7f90] [c0000000000236cc] call_do_irq+0x14/0x24\n [c00000007e6f39e0] [c000000000011144] do_IRQ+0x94/0x110\n [c00000007e6f3a30] [c000000000002594] hardware_interrupt_common+0x114/0x180\n\nFix this issue by introducing a new rtas_get_sensor_fast() function\nthat does not use rtas_busy_delay() - and thus can only be used for\nsensors that do not cause a BUSY condition - known as \"fast\" sensors.\n\nThe EPOW sensor is defined to be \"fast\" in sPAPR - mpe.\n\nFixes: 587f83e8dd50 (\"powerpc/pseries: Use rtas_get_sensor in RAS code\")\nSigned-off-by: Thomas Huth <thuth@redhat.com>\nReviewed-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Radium-Devices/Radium_yu/commits/bbb0ef214a94c94b6bd4842aadef1b61392e0ac3"},{"sha":"69b191dda144d77194cc647dbe4f8c14cf0694b6","author":{"email":"d794857f3a261131b0913d7b7c8d46da4e1882e5@neverware.com","name":"Jeffery Miller"},"message":"Add radeon suspend/resume quirk for HP Compaq dc5750.\n\ncommit 09bfda10e6efd7b65bcc29237bee1765ed779657 upstream.\n\nWith the radeon driver loaded the HP Compaq dc5750\nSmall Form Factor machine fails to resume from suspend.\nAdding a quirk similar to other devices avoids\nthe problem and the system resumes properly.\n\nSigned-off-by: Jeffery Miller <jmiller@neverware.com>\nSigned-off-by: Alex Deucher <alexander.deucher@amd.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Radium-Devices/Radium_yu/commits/69b191dda144d77194cc647dbe4f8c14cf0694b6"},{"sha":"a9aa2fa8104e26766421dffcc61dcae10d78d9e9","author":{"email":"3c5fb063765d3c2eb5938ad9ebec439bc976721a@gmail.com","name":"Minfei Huang"},"message":"x86/mm: Initialize pmd_idx in page_table_range_init_count()\n\ncommit 9962eea9e55f797f05f20ba6448929cab2a9f018 upstream.\n\nThe variable pmd_idx is not initialized for the first iteration of the\nfor loop.\n\nAssign the proper value which indexes the start address.\n\nFixes: 719272c45b82 'x86, mm: only call early_ioremap_page_table_range_init() once'\nSigned-off-by: Minfei Huang <mnfhuang@gmail.com>\nCc: tony.luck@intel.com\nCc: wangnan0@huawei.com\nCc: david.vrabel@citrix.com\nReviewed-by: yinghai@kernel.org\nLink: http://lkml.kernel.org/r/1436703522-29552-1-git-send-email-mhuang@redhat.com\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Radium-Devices/Radium_yu/commits/a9aa2fa8104e26766421dffcc61dcae10d78d9e9"},{"sha":"36a4d237fcf761178995c76a82dc572601afc30d","author":{"email":"aa743a0aaec8f7d7a1f01442503957f4d7a2d634@hardeman.nu","name":"David Härdeman"},"message":"rc-core: fix remove uevent generation\n\ncommit a66b0c41ad277ae62a3ae6ac430a71882f899557 upstream.\n\nThe input_dev is already gone when the rc device is being unregistered\nso checking for its presence only means that no remove uevent will be\ngenerated.\n\nSigned-off-by: David Härdeman <david@hardeman.nu>\nSigned-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Radium-Devices/Radium_yu/commits/36a4d237fcf761178995c76a82dc572601afc30d"},{"sha":"93d9586bf3ba94edb0d0741af30d1e893aa8892b","author":{"email":"1c00aa603bb92d594c03cff60ecf8e63b2a5bcb1@suse.com","name":"NeilBrown"},"message":"NFSv4: don't set SETATTR for O_RDONLY|O_EXCL\n\ncommit efcbc04e16dfa95fef76309f89710dd1d99a5453 upstream.\n\nIt is unusual to combine the open flags O_RDONLY and O_EXCL, but\nit appears that libre-office does just that.\n\n[pid  3250] stat(\"/home/USER/.config\", {st_mode=S_IFDIR|0700, st_size=8192, ...}) = 0\n[pid  3250] open(\"/home/USER/.config/libreoffice/4-suse/user/extensions/buildid\", O_RDONLY|O_EXCL <unfinished ...>\n\nNFSv4 takes O_EXCL as a sign that a setattr command should be sent,\nprobably to reset the timestamps.\n\nWhen it was an O_RDONLY open, the SETATTR command does not\nidentify any actual attributes to change.\nIf no delegation was provided to the open, the SETATTR uses the\nall-zeros stateid and the request is accepted (at least by the\nLinux NFS server - no harm, no foul).\n\nIf a read-delegation was provided, this is used in the SETATTR\nrequest, and a Netapp filer will justifiably claim\nNFS4ERR_BAD_STATEID, which the Linux client takes as a sign\nto retry - indefinitely.\n\nSo only treat O_EXCL specially if O_CREAT was also given.\n\nSigned-off-by: NeilBrown <neilb@suse.com>\nSigned-off-by: Trond Myklebust <trond.myklebust@primarydata.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Radium-Devices/Radium_yu/commits/93d9586bf3ba94edb0d0741af30d1e893aa8892b"},{"sha":"0ad89d6f68d2f0aa6d6530d54df0e033c0d3f376","author":{"email":"cc958843532c615cbd4920e868f78c7985331a5a@primarydata.com","name":"Trond Myklebust"},"message":"NFS: nfs_set_pgio_error sometimes misses errors\n\ncommit e9ae58aeee8842a50f7e199d602a5ccb2e41a95f upstream.\n\nWe should ensure that we always set the pgio_header's error field\nif a READ or WRITE RPC call returns an error. The current code depends\non 'hdr->good_bytes' always being initialised to a large value, which\nis not always done correctly by callers.\nWhen this happens, applications may end up missing important errors.\n\nSigned-off-by: Trond Myklebust <trond.myklebust@primarydata.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Radium-Devices/Radium_yu/commits/0ad89d6f68d2f0aa6d6530d54df0e033c0d3f376"},{"sha":"0757b6d100c38ae139e47b0af48b7c8d435a4dcb","author":{"email":"5b1e7895819cf7d6bc77091b09bbfd6d330a4e74@gmx.de","name":"Helge Deller"},"message":"parisc: Filter out spurious interrupts in PA-RISC irq handler\n\ncommit b1b4e435e4ef7de77f07bf2a42c8380b960c2d44 upstream.\n\nWhen detecting a serial port on newer PA-RISC machines (with iosapic) we have a\nlong way to go to find the right IRQ line, registering it, then registering the\nserial port and the irq handler for the serial port. During this phase spurious\ninterrupts for the serial port may happen which then crashes the kernel because\nthe action handler might not have been set up yet.\n\nSo, basically it's a race condition between the serial port hardware and the\nCPU which sets up the necessary fields in the irq sructs. The main reason for\nthis race is, that we unmask the serial port irqs too early without having set\nup everything properly before (which isn't easily possible because we need the\nIRQ number to register the serial ports).\n\nThis patch is a work-around for this problem. It adds checks to the CPU irq\nhandler to verify if the IRQ action field has been initialized already. If not,\nwe just skip this interrupt (which isn't critical for a serial port at bootup).\nThe real fix would probably involve rewriting all PA-RISC specific IRQ code\n(for CPU, IOSAPIC, GSC and EISA) to use IRQ domains with proper parenting of\nthe irq chips and proper irq enabling along this line.\n\nThis bug has been in the PA-RISC port since the beginning, but the crashes\nhappened very rarely with currently used hardware.  But on the latest machine\nwhich I bought (a C8000 workstation), which uses the fastest CPUs (4 x PA8900,\n1GHz) and which has the largest possible L1 cache size (64MB each), the kernel\ncrashed at every boot because of this race. So, without this patch the machine\nwould currently be unuseable.\n\nFor the record, here is the flow logic:\n1. serial_init_chip() in 8250_gsc.c calls iosapic_serial_irq().\n2. iosapic_serial_irq() calls txn_alloc_irq() to find the irq.\n3. iosapic_serial_irq() calls cpu_claim_irq() to register the CPU irq\n4. cpu_claim_irq() unmasks the CPU irq (which it shouldn't!)\n5. serial_init_chip() then registers the 8250 port.\nProblems:\n- In step 4 the CPU irq shouldn't have been registered yet, but after step 5\n- If serial irq happens between 4 and 5 have finished, the kernel will crash\n\nSigned-off-by: Helge Deller <deller@gmx.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Radium-Devices/Radium_yu/commits/0757b6d100c38ae139e47b0af48b7c8d435a4dcb"},{"sha":"f9b13de78be5a6d54659add81112efe1ae88bd7d","author":{"email":"4228565148a107be15d6e56720228e001b496879@samsung.com","name":"Jaewon Kim"},"message":"vmscan: fix increasing nr_isolated incurred by putback unevictable pages\n\ncommit c54839a722a02818677bcabe57e957f0ce4f841d upstream.\n\nreclaim_clean_pages_from_list() assumes that shrink_page_list() returns\nnumber of pages removed from the candidate list.  But shrink_page_list()\nputs back mlocked pages without passing it to caller and without\ncounting as nr_reclaimed.  This increases nr_isolated.\n\nTo fix this, this patch changes shrink_page_list() to pass unevictable\npages back to caller.  Caller will take care those pages.\n\nMinchan said:\n\nIt fixes two issues.\n\n1. With unevictable page, cma_alloc will be successful.\n\nExactly speaking, cma_alloc of current kernel will fail due to\nunevictable pages.\n\n2. fix leaking of NR_ISOLATED counter of vmstat\n\nWith it, too_many_isolated works.  Otherwise, it could make hang until\nthe process get SIGKILL.\n\nSigned-off-by: Jaewon Kim <jaewon31.kim@samsung.com>\nAcked-by: Minchan Kim <minchan@kernel.org>\nCc: Mel Gorman <mgorman@techsingularity.net>\nAcked-by: Vlastimil Babka <vbabka@suse.cz>\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>","distinct":true,"url":"https://api.github.com/repos/Radium-Devices/Radium_yu/commits/f9b13de78be5a6d54659add81112efe1ae88bd7d"},{"sha":"9493e26814dd7ef332bfc00f51f27f1e5cf7b93e","author":{"email":"1ff1d5ceb421971f93e6626b02a9591b29d7600e@thejh.net","name":"Jann Horn"},"message":"fs: if a coredump already exists, unlink and recreate with O_EXCL\n\ncommit fbb1816942c04429e85dbf4c1a080accc534299e upstream.\n\nIt was possible for an attacking user to trick root (or another user) into\nwriting his coredumps into an attacker-readable, pre-existing file using\nrename() or link(), causing the disclosure of secret data from the victim\nprocess' virtual memory.  Depending on the configuration, it was also\npossible to trick root into overwriting system files with coredumps.  Fix\nthat issue by never writing coredumps into existing files.\n\nRequirements for the attack:\n - The attack only applies if the victim's process has a nonzero\n   RLIMIT_CORE and is dumpable.\n - The attacker can trick the victim into coredumping into an\n   attacker-writable directory D, either because the core_pattern is\n   relative and the victim's cwd is attacker-writable or because an\n   absolute core_pattern pointing to a world-writable directory is used.\n - The attacker has one of these:\n  A: on a system with protected_hardlinks=0:\n     execute access to a folder containing a victim-owned,\n     attacker-readable file on the same partition as D, and the\n     victim-owned file will be deleted before the main part of the attack\n     takes place. (In practice, there are lots of files that fulfill\n     this condition, e.g. entries in Debian's /var/lib/dpkg/info/.)\n     This does not apply to most Linux systems because most distros set\n     protected_hardlinks=1.\n  B: on a system with protected_hardlinks=1:\n     execute access to a folder containing a victim-owned,\n     attacker-readable and attacker-writable file on the same partition\n     as D, and the victim-owned file will be deleted before the main part\n     of the attack takes place.\n     (This seems to be uncommon.)\n  C: on any system, independent of protected_hardlinks:\n     write access to a non-sticky folder containing a victim-owned,\n     attacker-readable file on the same partition as D\n     (This seems to be uncommon.)\n\nThe basic idea is that the attacker moves the victim-owned file to where\nhe expects the victim process to dump its core.  The victim process dumps\nits core into the existing file, and the attacker reads the coredump from\nit.\n\nIf the attacker can't move the file because he does not have write access\nto the containing directory, he can instead link the file to a directory\nhe controls, then wait for the original link to the file to be deleted\n(because the kernel checks that the link count of the corefile is 1).\n\nA less reliable variant that requires D to be non-sticky works with link()\nand does not require deletion of the original link: link() the file into\nD, but then unlink() it directly before the kernel performs the link count\ncheck.\n\nOn systems with protected_hardlinks=0, this variant allows an attacker to\nnot only gain information from coredumps, but also clobber existing,\nvictim-writable files with coredumps.  (This could theoretically lead to a\nprivilege escalation.)\n\nSigned-off-by: Jann Horn <jann@thejh.net>\nCc: Kees Cook <keescook@chromium.org>\nCc: Al Viro <viro@zeniv.linux.org.uk>\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>","distinct":true,"url":"https://api.github.com/repos/Radium-Devices/Radium_yu/commits/9493e26814dd7ef332bfc00f51f27f1e5cf7b93e"},{"sha":"60d5da65c3f11f56af3c9307de0248a3c9c17d52","author":{"email":"1c00aa603bb92d594c03cff60ecf8e63b2a5bcb1@suse.com","name":"NeilBrown"},"message":"md/raid10: always set reshape_safe when initializing reshape_position.\n\ncommit 299b0685e31c9f3dcc2d58ee3beca761a40b44b3 upstream.\n\n'reshape_position' tracks where in the reshape we have reached.\n'reshape_safe' tracks where in the reshape we have safely recorded\nin the metadata.\n\nThese are compared to determine when to update the metadata.\nSo it is important that reshape_safe is initialised properly.\nCurrently it isn't.  When starting a reshape from the beginning\nit usually has the correct value by luck.  But when reducing the\nnumber of devices in a RAID10, it has the wrong value and this leads\nto the metadata not being updated correctly.\nThis can lead to corruption if the reshape is not allowed to complete.\n\nThis patch is suitable for any -stable kernel which supports RAID10\nreshape, which is 3.5 and later.\n\nFixes: 3ea7daa5d7fd (\"md/raid10: add reshape support\")\nSigned-off-by: NeilBrown <neilb@suse.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Radium-Devices/Radium_yu/commits/60d5da65c3f11f56af3c9307de0248a3c9c17d52"}]}