{"push_id":2534123737,"size":47,"distinct_size":47,"ref":"refs/heads/tw80","head":"5c3670c3a00b86080e7a0b883ecb350e7b1a05e6","before":"95e8908bb43624dd25c04f8a1960147801c82f6e","commits":[{"sha":"de3a60fb7486516b9f2adce567bef10c894563af","author":{"name":"Eric Biggers","email":"6f6115196800bbe9712b3f04c7e40093bb382fc5@google.com"},"message":"ext4: prevent right-shifting extents beyond EXT_MAX_BLOCKS\n\ncommit 349fa7d6e1935f49bf4161c4900711b2989180a9 upstream.\n\nDuring the \"insert range\" fallocate operation, extents starting at the\nrange offset are shifted \"right\" (to a higher file offset) by the range\nlength.  But, as shown by syzbot, it's not validated that this doesn't\ncause extents to be shifted beyond EXT_MAX_BLOCKS.  In that case\n->ee_block can wrap around, corrupting the extent tree.\n\nFix it by returning an error if the space between the end of the last\nextent and EXT4_MAX_BLOCKS is smaller than the range being inserted.\n\nThis bug can be reproduced by running the following commands when the\ncurrent directory is on an ext4 filesystem with a 4k block size:\n\n        fallocate -l 8192 file\n        fallocate --keep-size -o 0xfffffffe000 -l 4096 -n file\n        fallocate --insert-range -l 8192 file\n\nThen after unmounting the filesystem, e2fsck reports corruption.\n\nReported-by: syzbot+06c885be0edcdaeab40c@syzkaller.appspotmail.com\nFixes: 331573febb6a (\"ext4: Add support FALLOC_FL_INSERT_RANGE for fallocate\")\nCc: stable@vger.kernel.org # v4.2+\nSigned-off-by: Eric Biggers <ebiggers@google.com>\nSigned-off-by: Theodore Ts'o <tytso@mit.edu>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/exynos-linux-stable/greatlte/commits/de3a60fb7486516b9f2adce567bef10c894563af"},{"sha":"47757f587b676902a6b4a9f4023eb02b71fbf281","author":{"name":"Theodore Ts'o","email":"4ed386e0495d3e109932df055831d9ec2f824927@mit.edu"},"message":"ext4: set h_journal if there is a failure starting a reserved handle\n\ncommit b2569260d55228b617bd82aba6d0db2faeeb4116 upstream.\n\nIf ext4 tries to start a reserved handle via\njbd2_journal_start_reserved(), and the journal has been aborted, this\ncan result in a NULL pointer dereference.  This is because the fields\nh_journal and h_transaction in the handle structure share the same\nmemory, via a union, so jbd2_journal_start_reserved() will clear\nh_journal before calling start_this_handle().  If this function fails\ndue to an aborted handle, h_journal will still be NULL, and the call\nto jbd2_journal_free_reserved() will pass a NULL journal to\nsub_reserve_credits().\n\nThis can be reproduced by running \"kvm-xfstests -c dioread_nolock\ngeneric/475\".\n\nCc: stable@kernel.org # 3.11\nFixes: 8f7d89f36829b (\"jbd2: transaction reservation support\")\nSigned-off-by: Theodore Ts'o <tytso@mit.edu>\nReviewed-by: Andreas Dilger <adilger@dilger.ca>\nReviewed-by: Jan Kara <jack@suse.cz>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/exynos-linux-stable/greatlte/commits/47757f587b676902a6b4a9f4023eb02b71fbf281"},{"sha":"ea057aed06d8f13d931652bc4faa604ac0c50aa2","author":{"name":"Theodore Ts'o","email":"4ed386e0495d3e109932df055831d9ec2f824927@mit.edu"},"message":"ext4: add validity checks for bitmap block numbers\n\ncommit 7dac4a1726a9c64a517d595c40e95e2d0d135f6f upstream.\n\nAn privileged attacker can cause a crash by mounting a crafted ext4\nimage which triggers a out-of-bounds read in the function\next4_valid_block_bitmap() in fs/ext4/balloc.c.\n\nThis issue has been assigned CVE-2018-1093.\n\nBugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199181\nBugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1560782\nReported-by: Wen Xu <wen.xu@gatech.edu>\nSigned-off-by: Theodore Ts'o <tytso@mit.edu>\nCc: stable@vger.kernel.org\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/exynos-linux-stable/greatlte/commits/ea057aed06d8f13d931652bc4faa604ac0c50aa2"},{"sha":"629433b4f9bad7da26a30e84e6eeb59e3ef41a16","author":{"name":"Lukas Czerner","email":"6c9141d0e2318b390a8a6bf8ecd9f819d16f05b4@redhat.com"},"message":"ext4: fix bitmap position validation\n\ncommit 22be37acce25d66ecf6403fc8f44df9c5ded2372 upstream.\n\nCurrently in ext4_valid_block_bitmap() we expect the bitmap to be\npositioned anywhere between 0 and s_blocksize clusters, but that's\nwrong because the bitmap can be placed anywhere in the block group. This\ncauses false positives when validating bitmaps on perfectly valid file\nsystem layouts. Fix it by checking whether the bitmap is within the group\nboundary.\n\nThe problem can be reproduced using the following\n\nmkfs -t ext3 -E stride=256 /dev/vdb1\nmount /dev/vdb1 /mnt/test\ncd /mnt/test\nwget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.16.3.tar.xz\ntar xf linux-4.16.3.tar.xz\n\nThis will result in the warnings in the logs\n\nEXT4-fs error (device vdb1): ext4_validate_block_bitmap:399: comm tar: bg 84: block 2774529: invalid block bitmap\n\n[ Changed slightly for clarity and to not drop a overflow test -- TYT ]\n\nSigned-off-by: Lukas Czerner <lczerner@redhat.com>\nSigned-off-by: Theodore Ts'o <tytso@mit.edu>\nReported-by: Ilya Dryomov <idryomov@gmail.com>\nFixes: 7dac4a1726a9 (\"ext4: add validity checks for bitmap block numbers\")\nCc: stable@vger.kernel.org\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/exynos-linux-stable/greatlte/commits/629433b4f9bad7da26a30e84e6eeb59e3ef41a16"},{"sha":"50d26a47c13e6d7c96b6e250593ec2d1f4123258","author":{"name":"Shuah Khan","email":"c62751f8c6ce7eb0639cab80a821801931863a4b@osg.samsung.com"},"message":"usbip: usbip_host: fix to hold parent lock for device_attach() calls\n\ncommit 4bfb141bc01312a817d36627cc47c93f801c216d upstream.\n\nusbip_host calls device_attach() without holding dev->parent lock.\nFix it.\n\nSigned-off-by: Shuah Khan <shuahkh@osg.samsung.com>\nCc: stable <stable@vger.kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/exynos-linux-stable/greatlte/commits/50d26a47c13e6d7c96b6e250593ec2d1f4123258"},{"sha":"c4e4036903ac3c6cd9cba06cd0dffb9a9aa4b069","author":{"name":"Shuah Khan","email":"c62751f8c6ce7eb0639cab80a821801931863a4b@osg.samsung.com"},"message":"usbip: vhci_hcd: Fix usb device and sockfd leaks\n\ncommit 9020a7efe537856eb3e826ebebdf38a5d07a7857 upstream.\n\nvhci_hcd fails to do reset to put usb device and sockfd in the\nmodule remove/stop paths. Fix the leak.\n\nSigned-off-by: Shuah Khan <shuahkh@osg.samsung.com>\nCc: stable <stable@vger.kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/exynos-linux-stable/greatlte/commits/c4e4036903ac3c6cd9cba06cd0dffb9a9aa4b069"},{"sha":"0964d65e05ea80a6464629b20a16e49373f14a44","author":{"name":"Collin May","email":"016e57c89e3285b6cfaea483202c72c7a834aab4@collinswebsite.com"},"message":"USB: serial: simple: add libtransistor console\n\ncommit fe710508b6ba9d28730f3021fed70e7043433b2e upstream.\n\nAdd simple driver for libtransistor USB console.\nThis device is implemented in software:\nhttps://github.com/reswitched/libtransistor/blob/development/lib/usb_serial.c\n\nSigned-off-by: Collin May <collin@collinswebsite.com>\nCc: stable <stable@vger.kernel.org>\nSigned-off-by: Johan Hovold <johan@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/exynos-linux-stable/greatlte/commits/0964d65e05ea80a6464629b20a16e49373f14a44"},{"sha":"8713dc52928d8b0df4ac21396ab794917b7b7d4b","author":{"name":"Vasyl Vavrychuk","email":"6b6ff1aeeddbf0f5c49ad097ffaf33464ac3d2e9@gmail.com"},"message":"USB: serial: ftdi_sio: use jtag quirk for Arrow USB Blaster\n\ncommit 470b5d6f0cf4674be2d1ec94e54283a1770b6a1a upstream.\n\nArrow USB Blaster integrated on MAX1000 board uses the same vendor ID\n(0x0403) and product ID (0x6010) as the \"original\" FTDI device.\n\nThis patch avoids picking up by ftdi_sio of the first interface of this\nUSB device. After that this device can be used by Arrow user-space JTAG\ndriver.\n\nSigned-off-by: Vasyl Vavrychuk <vvavrychuk@gmail.com>\nCc: stable <stable@vger.kernel.org>\nSigned-off-by: Johan Hovold <johan@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/exynos-linux-stable/greatlte/commits/8713dc52928d8b0df4ac21396ab794917b7b7d4b"},{"sha":"d6ccb61e3d86174bf182913bad26fe6e1ede3659","author":{"name":"Kyle Roeschley","email":"ca3201b7961668836d79bcab60556c323784a58a@ni.com"},"message":"USB: serial: cp210x: add ID for NI USB serial console\n\ncommit 1e23aace21515a8f7615a1de016c0ea8d4e0cc6e upstream.\n\nAdded the USB VID and PID for the USB serial console on some National\nInstruments devices.\n\nSigned-off-by: Kyle Roeschley <kyle.roeschley@ni.com>\nCc: stable <stable@vger.kernel.org>\nSigned-off-by: Johan Hovold <johan@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/exynos-linux-stable/greatlte/commits/d6ccb61e3d86174bf182913bad26fe6e1ede3659"},{"sha":"46aba9fa5b7c79631b6a8e5dbb86d9db7882f9be","author":{"name":"Kamil Lulko","email":"5764a707aac3f90197a15da763f29d49e2436636@intel.com"},"message":"usb: core: Add quirk for HP v222w 16GB Mini\n\ncommit 3180dabe08e3653bf0a838553905d88f3773f29c upstream.\n\nAdd DELAY_INIT quirk to fix the following problem with HP\nv222w 16GB Mini:\n\nusb 1-3: unable to read config index 0 descriptor/start: -110\nusb 1-3: can't read configurations, error -110\nusb 1-3: can't set config #1, error -110\n\nSigned-off-by: Kamil Lulko <kamilx.lulko@intel.com>\nSigned-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>\nCc: stable <stable@vger.kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/exynos-linux-stable/greatlte/commits/46aba9fa5b7c79631b6a8e5dbb86d9db7882f9be"},{"sha":"d2a2cc40f2413643bc0a15fe102365a3c466bb82","author":{"name":"Ravi Chandra Sadineni","email":"068c0dca42d898d893968d7098b20075cb89039f@chromium.org"},"message":"USB: Increment wakeup count on remote wakeup.\n\ncommit 83a62c51ba7b3c0bf45150c4eac7aefc6c785e94 upstream.\n\nOn chromebooks we depend on wakeup count to identify the wakeup source.\nBut currently USB devices do not increment the wakeup count when they\ntrigger the remote wake. This patch addresses the same.\n\nResume condition is reported differently on USB 2.0 and USB 3.0 devices.\n\nOn USB 2.0 devices, a wake capable device, if wake enabled, drives\nresume signal to indicate a remote wake (USB 2.0 spec section 7.1.7.7).\nThe upstream facing port then sets C_PORT_SUSPEND bit and reports a\nport change event (USB 2.0 spec section 11.24.2.7.2.3). Thus if a port\nhas resumed before driving the resume signal from the host and\nC_PORT_SUSPEND is set, then the device attached to the given port might\nbe the reason for the last system wakeup. Increment the wakeup count for\nthe same.\n\nOn USB 3.0 devices, a function may signal that it wants to exit from device\nsuspend by sending a Function Wake Device Notification to the host (USB3.0\nspec section 8.5.6.4) Thus on receiving the Function Wake, increment the\nwakeup count.\n\nSigned-off-by: Ravi Chandra Sadineni <ravisadineni@chromium.org>\nAcked-by: Alan Stern <stern@rowland.harvard.edu>\nCc: stable <stable@vger.kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/exynos-linux-stable/greatlte/commits/d2a2cc40f2413643bc0a15fe102365a3c466bb82"},{"sha":"311a886f34311e575f7f911ebdbcbba9f05a498e","author":{"name":"Takashi Iwai","email":"4596b3305151c7ee743192a95d394341e3d3b644@suse.de"},"message":"ALSA: usb-audio: Skip broken EU on Dell dock USB-audio\n\ncommit 1d8d6428d1da642ddd75b0be2d1bb1123ff8e017 upstream.\n\nThe Dell Dock USB-audio device with 0bda:4014 is behaving notoriously\nbad, and we have already applied some workaround to avoid the firmware\nhiccup.  Yet we still need to skip one thing, the Extension Unit at ID\n4, which doesn't react correctly to the mixer ctl access.\n\nBugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1090658\nCc: <stable@vger.kernel.org>\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/exynos-linux-stable/greatlte/commits/311a886f34311e575f7f911ebdbcbba9f05a498e"},{"sha":"a4fc9c518e70c6e1c9c897a99b028795235d83ca","author":{"name":"Michael S. Tsirkin","email":"255103e50249e3d658441816e0597170ebfc16ef@redhat.com"},"message":"virtio: add ability to iterate over vqs\n\ncommit 24a7e4d20783c0514850f24a5c41ede46ab058f0 upstream.\n\nFor cleanup it's helpful to be able to simply scan all vqs and discard\nall data. Add an iterator to do that.\n\nCc: stable@vger.kernel.org\nSigned-off-by: Michael S. Tsirkin <mst@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/exynos-linux-stable/greatlte/commits/a4fc9c518e70c6e1c9c897a99b028795235d83ca"},{"sha":"dd807a784fd36f4136516d5858efb6473dda422c","author":{"name":"Michael S. Tsirkin","email":"255103e50249e3d658441816e0597170ebfc16ef@redhat.com"},"message":"virtio_console: free buffers after reset\n\ncommit a7a69ec0d8e4a58be7db88d33cbfa2912807bb2b upstream.\n\nConsole driver is out of spec. The spec says:\n\tA driver MUST NOT decrement the available idx on a live\n\tvirtqueue (ie. there is no way to “unexpose” buffers).\nand it does exactly that by trying to detach unused buffers\nwithout doing a device reset first.\n\nDefer detaching the buffers until device unplug.\n\nOf course this means we might get an interrupt for\na vq without an attached port now. Handle that by\ndiscarding the consumed buffer.\n\nReported-by: Tiwei Bie <tiwei.bie@intel.com>\nFixes: b3258ff1d6 (\"virtio: Decrement avail idx on buffer detach\")\nCc: stable@vger.kernel.org\nSigned-off-by: Michael S. Tsirkin <mst@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/exynos-linux-stable/greatlte/commits/dd807a784fd36f4136516d5858efb6473dda422c"},{"sha":"7aa90727fda6943274224bc8dde19d346b60ee3f","author":{"name":"Gerd Hoffmann","email":"cad73e70082427fddc9be3baaf34e698dffd21c0@redhat.com"},"message":"drm/virtio: fix vq wait_event condition\n\ncommit d02d270014f70dcab0117776b81a37b6fca745ae upstream.\n\nWait until we have enough space in the virt queue to actually queue up\nour request.  Avoids the guest spinning in case we have a non-zero\namount of free entries but not enough for the request.\n\nCc: stable@vger.kernel.org\nReported-by: Alain Magloire <amagloire@blackberry.com>\nSigned-off-by: Gerd Hoffmann <kraxel@redhat.com>\nReviewed-by: Dave Airlie <airlied@redhat.com>\nLink: http://patchwork.freedesktop.org/patch/msgid/20180403095904.11152-1-kraxel@redhat.com\nSigned-off-by: Sean Paul <seanpaul@chromium.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/exynos-linux-stable/greatlte/commits/7aa90727fda6943274224bc8dde19d346b60ee3f"},{"sha":"ed7d4b0c4aaa64190be153f3813540e263a201a2","author":{"name":"Tetsuo Handa","email":"3d00b54ad717112934d0b63b7ac2975b44022a61@I-love.SAKURA.ne.jp"},"message":"tty: Don't call panic() at tty_ldisc_init()\n\ncommit 903f9db10f18f735e62ba447147b6c434b6af003 upstream.\n\nsyzbot is reporting kernel panic [1] triggered by memory allocation failure\nat tty_ldisc_get() from tty_ldisc_init(). But since both tty_ldisc_get()\nand caller of tty_ldisc_init() can cleanly handle errors, tty_ldisc_init()\ndoes not need to call panic() when tty_ldisc_get() failed.\n\n[1] https://syzkaller.appspot.com/bug?id=883431818e036ae6a9981156a64b821110f39187\n\nSigned-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>\nReported-by: syzbot <syzkaller@googlegroups.com>\nCc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nCc: Jiri Slaby <jslaby@suse.com>\nCc: stable <stable@vger.kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/exynos-linux-stable/greatlte/commits/ed7d4b0c4aaa64190be153f3813540e263a201a2"},{"sha":"9c389e2be2741da9cba7c572c3e2ab47ed445cce","author":{"name":"Tony Lindgren","email":"1001e8702733cced254345e193c88aaa47a4f5de@atomide.com"},"message":"tty: n_gsm: Fix long delays with control frame timeouts in ADM mode\n\ncommit e9ec22547986dd32c5c70da78107ce35dbff1344 upstream.\n\nCommit ea3d8465ab9b (\"tty: n_gsm: Allow ADM response in addition to UA for\ncontrol dlci\") added support for DLCI to stay in Asynchronous Disconnected\nMode (ADM). But we still get long delays waiting for commands to other\nDLCI to complete:\n\n--> 5) C: SABM(P)\nQ>  0) C: UIH(F)\nQ>  0) C: UIH(F)\nQ>  0) C: UIH(F)\n...\n\nThis happens because gsm_control_send() sets cretries timer to T2 that is\nby default set to 34. This will cause resend for T2 times for the control\nframe. In ADM mode, we will never get a response so the control frame, so\nretries are just delaying all the commands.\n\nLet's fix the issue by setting DLCI_MODE_ADM flag after detecting the ADM\nmode for the control DLCI. Then we can use that in gsm_control_send() to\nset retries to 1. This means the control frame will be sent once allowing\nthe other end at an opportunity to switch from ADM to ABM mode.\n\nNote that retries will be decremented in gsm_control_retransmit() so\nwe don't want to set it to 0 here.\n\nFixes: ea3d8465ab9b (\"tty: n_gsm: Allow ADM response in addition to UA for control dlci\")\nCc: linux-serial@vger.kernel.org\nCc: Alan Cox <alan@llwyncelyn.cymru>\nCc: Dan Williams <dcbw@redhat.com>\nCc: Jiri Prchal <jiri.prchal@aksignal.cz>\nCc: Jiri Slaby <jslaby@suse.cz>\nCc: Marcel Partap <mpartap@gmx.net>\nCc: Merlijn Wajer <merlijn@wizzup.org>\nCc: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>\nCc: Michael Scott <michael.scott@linaro.org>\nCc: Pavel Machek <pavel@ucw.cz>\nCc: Peter Hurley <peter@hurleysoftware.com>\nCc: Russ Gorby <russ.gorby@intel.com>\nCc: Sascha Hauer <s.hauer@pengutronix.de>\nCc: Sebastian Reichel <sre@kernel.org>\nSigned-off-by: Tony Lindgren <tony@atomide.com>\nCc: stable <stable@vger.kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/exynos-linux-stable/greatlte/commits/9c389e2be2741da9cba7c572c3e2ab47ed445cce"},{"sha":"c37a5d3c70cc07f77a5805e69ab46841f7c1c839","author":{"name":"Tony Lindgren","email":"1001e8702733cced254345e193c88aaa47a4f5de@atomide.com"},"message":"tty: n_gsm: Fix DLCI handling for ADM mode if debug & 2 is not set\n\ncommit b2d89ad9c9682e795ed6eeb9ed455789ad6cedf1 upstream.\n\nAt least on droid 4 with control channel in ADM mode, there is no response\nto Modem Status Command (MSC). Currently gsmtty_modem_update() expects to\nhave data in dlci->modem_rx unless debug & 2 is set. This means that on\ndroid 4, things only work if debug & 2 is set.\n\nLet's fix the issue by ignoring empty dlci->modem_rx for ADM mode. In\nthe AMD mode, CMD_MSC will never respond and gsm_process_modem() won't\nget called to set dlci->modem_rx.\n\nAnd according to ts_127010v140000p.pdf, MSC is only relevant if basic\noption is chosen, so let's test for that too.\n\nFixes: ea3d8465ab9b (\"tty: n_gsm: Allow ADM response in addition to UA for control dlci\")\nCc: linux-serial@vger.kernel.org\nCc: Alan Cox <alan@llwyncelyn.cymru>\nCc: Dan Williams <dcbw@redhat.com>\nCc: Jiri Prchal <jiri.prchal@aksignal.cz>\nCc: Jiri Slaby <jslaby@suse.cz>\nCc: Marcel Partap <mpartap@gmx.net>\nCc: Merlijn Wajer <merlijn@wizzup.org>\nCc: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>\nCc: Michael Scott <michael.scott@linaro.org>\nCc: Pavel Machek <pavel@ucw.cz>\nCc: Peter Hurley <peter@hurleysoftware.com>\nCc: Russ Gorby <russ.gorby@intel.com>\nCc: Sascha Hauer <s.hauer@pengutronix.de>\nCc: Sebastian Reichel <sre@kernel.org>\nSigned-off-by: Tony Lindgren <tony@atomide.com>\nCc: stable <stable@vger.kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/exynos-linux-stable/greatlte/commits/c37a5d3c70cc07f77a5805e69ab46841f7c1c839"},{"sha":"7717f4f8de215aaad8dca8cd2575f30ad282a082","author":{"name":"Tetsuo Handa","email":"3d00b54ad717112934d0b63b7ac2975b44022a61@I-love.SAKURA.ne.jp"},"message":"tty: Use __GFP_NOFAIL for tty_ldisc_get()\n\ncommit bcdd0ca8cb8730573afebcaae4138f8f4c8eaa20 upstream.\n\nsyzbot is reporting crashes triggered by memory allocation fault injection\nat tty_ldisc_get() [1]. As an attempt to handle OOM in a graceful way, we\nhave tried commit 5362544bebe85071 (\"tty: don't panic on OOM in\ntty_set_ldisc()\"). But we reverted that attempt by commit a8983d01f9b7d600\n(\"Revert \"tty: don't panic on OOM in tty_set_ldisc()\"\") due to reproducible\ncrash. We should spend resource for finding and fixing race condition bugs\nrather than complicate error paths for 2 * sizeof(void *) bytes allocation\nfailure.\n\n[1] https://syzkaller.appspot.com/bug?id=489d33fa386453859ead58ff5171d43772b13aa3\n\nSigned-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>\nReported-by: syzbot <syzbot+40b7287c2dc987c48c81@syzkaller.appspotmail.com>\nCc: Michal Hocko <mhocko@suse.com>\nCc: Vegard Nossum <vegard.nossum@gmail.com>\nCc: Dmitry Vyukov <dvyukov@google.com>\nCc: Jiri Slaby <jslaby@suse.com>\nCc: Peter Hurley <peter@hurleysoftware.com>\nCc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nCc: stable <stable@vger.kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/exynos-linux-stable/greatlte/commits/7717f4f8de215aaad8dca8cd2575f30ad282a082"},{"sha":"0f3234318b2817683433d6cc9d1c9d98d9770aa3","author":{"name":"Takashi Iwai","email":"4596b3305151c7ee743192a95d394341e3d3b644@suse.de"},"message":"ALSA: opl3: Hardening for potential Spectre v1\n\ncommit 7f054a5bee0987f1e2d4e59daea462421c76f2cb upstream.\n\nAs recently Smatch suggested, one place in OPL3 driver may expand the\narray directly from the user-space value with speculation:\n  sound/drivers/opl3/opl3_synth.c:476 snd_opl3_set_voice() warn: potential spectre issue 'snd_opl3_regmap'\n\nThis patch puts array_index_nospec() for hardening against it.\n\nBugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2\nReported-by: Dan Carpenter <dan.carpenter@oracle.com>\nCc: <stable@vger.kernel.org>\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/exynos-linux-stable/greatlte/commits/0f3234318b2817683433d6cc9d1c9d98d9770aa3"}]}
{"actor":{"display_login":"farovitus"}}