- Jan 12, 2018
-
-
- Jan 11, 2018
-
-
Mohammed Javid authored
Accessing of incorrect structure pointer is causing memory out of bound access, fixed issue by accessing the correct structure pointer. Bug: 63851638 Change-Id: I3c2f5f7a97cac854093ef670184d06db4231f5e1 Acked-by:
Ashok Vuyyuru <avuyyuru@qti.qualcomm.com> Signed-off-by:
Mohammed Javid <mjavid@codeaurora.org> Signed-off-by:
Siqi Lin <siqilin@google.com>
-
Dennis Cagle authored
Add conditional check when sending VIDIOC_MSM_FLASH_CFG in 32-bit process. Change-Id: I73bcce85a212495ce94e6265947c11a6bc0e4040 CRs-Fixed: 2092793 Bug: 64836865 Git-repo: https://source.codeaurora.org/quic/la/kernel/msm-3.10 Git-commit: b153beb7af263b04ff6f79286eacba977e2f10eb Signed-off-by:
Tanvi Aggarwal <tanvia@codeaurora.org> Signed-off-by:
Dennis Cagle <d-cagle@codeaurora.org>
-
Aditya Bavanari authored
Set freed pointers to NULL to avoid double free in msm_compr_playback_open and msm_compr_playback_free functions of the compress driver. CRs-Fixed: 2142216 Bug: 68664502 Change-Id: Ifd011dd85dd9f610c7b69dd460f73d26e006cd66 Signed-off-by:Aditya Bavanari <abavanar@codeaurora.org>
-
Marissa Wall authored
[ Upstream commit c27927e3 ] Updates to tp_reserve can race with reads of the field in packet_set_ring. Avoid this by holding the socket lock during updates in setsockopt PACKET_RESERVE. This bug was discovered by syzkaller. Fixes: 8913336a ("packet: add PACKET_RESERVE sockopt") Bug: 68806121 Change-Id: Ifbceac3542a1b7f25290c3e21008fa76c59fe391 Reported-by:
Andrey Konovalov <andreyknvl@google.com> Signed-off-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Marissa Wall <marissaw@google.com>
-
Mohit Aggarwal authored
Currently, while de-initializing clients, there is a possibility of using already freed memory. The patch adds proper protection to fix the issue. CRs-Fixed: 2068569 Bug: 68870904 Change-Id: I4b397a82e03fa2f1c84cfa8ca912cdb6a51ba08b Signed-off-by:Mohit Aggarwal <maggarwa@codeaurora.org>
-
Johan Hovold authored
commit 299d7572 Make sure to reset the USB-console port pointer when console setup fails in order to avoid having the struct usb_serial be prematurely freed by the console code when the device is later disconnected. Bug: 69050921 Change-Id: I46e86fddd10611a30e7f4ab62ba07dc6eccc0312 Fixes: 73e487fd ("[PATCH] USB console: fix disconnection issues") Cc: stable <stable@vger.kernel.org> # 2.6.18 Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Johan Hovold <johan@kernel.org>
-
Takashi Iwai authored
commit 124751d5 upstream. USB-audio driver may leave a stray URB for the mixer interrupt when it exits by some error during probe. This leads to a use-after-free error as spotted by syzkaller like: ================================================================== BUG: KASAN: use-after-free in snd_usb_mixer_interrupt+0x604/0x6f0 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:16 dump_stack+0x292/0x395 lib/dump_stack.c:52 print_address_description+0x78/0x280 mm/kasan/report.c:252 kasan_report_error mm/kasan/report.c:351 kasan_report+0x23d/0x350 mm/kasan/report.c:409 __asan_report_load8_noabort+0x19/0x20 mm/kasan/report.c:430 snd_usb_mixer_interrupt+0x604/0x6f0 sound/usb/mixer.c:2490 __usb_hcd_giveback_urb+0x2e0/0x650 drivers/usb/core/hcd.c:1779 .... Allocated by task 1484: save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59 save_stack+0x43/0xd0 mm/kasan/kasan.c:447 set_track mm/kasan/kasan.c:459 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551 kmem_cache_alloc_trace+0x11e/0x2d0 mm/slub.c:2772 kmalloc ./include/linux/slab.h:493 kzalloc ./include/linux/slab.h:666 snd_usb_create_mixer+0x145/0x1010 sound/usb/mixer.c:2540 create_standard_mixer_quirk+0x58/0x80 sound/usb/quirks.c:516 snd_usb_create_quirk+0x92/0x100 sound/usb/quirks.c:560 create_composite_quirk+0x1c4/0x3e0 sound/usb/quirks.c:59 snd_usb_create_quirk+0x92/0x100 sound/usb/quirks.c:560 usb_audio_probe+0x1040/0x2c10 sound/usb/card.c:618 .... Freed by task 1484: save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59 save_stack+0x43/0xd0 mm/kasan/kasan.c:447 set_track mm/kasan/kasan.c:459 kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:524 slab_free_hook mm/slub.c:1390 slab_free_freelist_hook mm/slub.c:1412 slab_free mm/slub.c:2988 kfree+0xf6/0x2f0 mm/slub.c:3919 snd_usb_mixer_free+0x11a/0x160 sound/usb/mixer.c:2244 snd_usb_mixer_dev_free+0x36/0x50 sound/usb/mixer.c:2250 __snd_device_free+0x1ff/0x380 sound/core/device.c:91 snd_device_free_all+0x8f/0xe0 sound/core/device.c:244 snd_card_do_free sound/core/init.c:461 release_card_device+0x47/0x170 sound/core/init.c:181 device_release+0x13f/0x210 drivers/base/core.c:814 .... Actually such a URB is killed properly at disconnection when the device gets probed successfully, and what we need is to apply it for the error-path, too. In this patch, we apply snd_usb_mixer_disconnect() at releasing. Also introduce a new flag, disconnected, to struct usb_mixer_interface for not performing the disconnection procedure twice. Bug: 69051382 Change-Id: Ibe5b1f714cd304cfefcd736d0bcfc168c54f8a48 Reported-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit bfc81a8b When a USB-audio device receives a maliciously adjusted or corrupted buffer descriptor, the USB-audio driver may access an out-of-bounce value at its parser. This was detected by syzkaller, something like: BUG: KASAN: slab-out-of-bounds in usb_audio_probe+0x27b2/0x2ab0 Read of size 1 at addr ffff88006b83a9e8 by task kworker/0:1/24 CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc1-42251-gebb2c2437d80 #224 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:16 dump_stack+0x292/0x395 lib/dump_stack.c:52 print_address_description+0x78/0x280 mm/kasan/report.c:252 kasan_report_error mm/kasan/report.c:351 kasan_report+0x22f/0x340 mm/kasan/report.c:409 __asan_report_load1_noabort+0x19/0x20 mm/kasan/report.c:427 snd_usb_create_streams sound/usb/card.c:248 usb_audio_probe+0x27b2/0x2ab0 sound/usb/card.c:605 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361 really_probe drivers/base/dd.c:413 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523 device_add+0xd0b/0x1660 drivers/base/core.c:1835 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266 really_probe drivers/base/dd.c:413 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523 device_add+0xd0b/0x1660 drivers/base/core.c:1835 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457 hub_port_connect drivers/usb/core/hub.c:4903 hub_port_connect_change drivers/usb/core/hub.c:5009 port_event drivers/usb/core/hub.c:5115 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119 worker_thread+0x221/0x1850 kernel/workqueue.c:2253 kthread+0x3a1/0x470 kernel/kthread.c:231 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431 This patch adds the checks of out-of-bounce accesses at appropriate places and bails out when it goes out of the given buffer. Bug: 69051731 Change-Id: If4bed53e824123f7dc2df2cf0ec9ce98560cf259 Reported-by:
-
Greg Kroah-Hartman authored
commit bd7a3fe7 Andrey Konovalov reported a possible out-of-bounds problem for a USB interface association descriptor. He writes: It seems there's no proper size check of a USB_DT_INTERFACE_ASSOCIATION descriptor. It's only checked that the size is >= 2 in usb_parse_configuration(), so find_iad() might do out-of-bounds access to intf_assoc->bInterfaceCount. And he's right, we don't check for crazy descriptors of this type very well, so resolve this problem. Yet another issue found by syzkaller... Bug: 69052055 Change-Id: I2cc3b5a66d16abd0fc567d69457fc90a45eb12d8 Reported-by:
-
Jaejoong Kim authored
commit f043bfc9 The hid descriptor identifies the length and type of subordinate descriptors for a device. If the received hid descriptor is smaller than the size of the struct hid_descriptor, it is possible to cause out-of-bounds. In addition, if bNumDescriptors of the hid descriptor have an incorrect value, this can also cause out-of-bounds while approaching hdesc->desc[n]. So check the size of hid descriptor and bNumDescriptors. BUG: KASAN: slab-out-of-bounds in usbhid_parse+0x9b1/0xa20 Read of size 1 at addr ffff88006c5f8edf by task kworker/1:2/1261 CPU: 1 PID: 1261 Comm: kworker/1:2 Not tainted 4.14.0-rc1-42251-gebb2c2437d80 #169 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:16 dump_stack+0x292/0x395 lib/dump_stack.c:52 print_address_description+0x78/0x280 mm/kasan/report.c:252 kasan_report_error mm/kasan/report.c:351 kasan_report+0x22f/0x340 mm/kasan/report.c:409 __asan_report_load1_noabort+0x19/0x20 mm/kasan/report.c:427 usbhid_parse+0x9b1/0xa20 drivers/hid/usbhid/hid-core.c:1004 hid_add_device+0x16b/0xb30 drivers/hid/hid-core.c:2944 usbhid_probe+0xc28/0x1100 drivers/hid/usbhid/hid-core.c:1369 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361 really_probe drivers/base/dd.c:413 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523 device_add+0xd0b/0x1660 drivers/base/core.c:1835 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266 really_probe drivers/base/dd.c:413 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523 device_add+0xd0b/0x1660 drivers/base/core.c:1835 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457 hub_port_connect drivers/usb/core/hub.c:4903 hub_port_connect_change drivers/usb/core/hub.c:5009 port_event drivers/usb/core/hub.c:5115 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119 worker_thread+0x221/0x1850 kernel/workqueue.c:2253 kthread+0x3a1/0x470 kernel/kthread.c:231 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431 Bug: 69052348 Change-Id: I4239036291a1722baa83274fc730060527231db9 Cc: stable@vger.kernel.org Reported-by:
Jaejoong Kim <climbbb.kim@gmail.com> Tested-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Jiri Kosina <jkosina@suse.cz>
-
Alan Stern authored
commit 1c0edc36 Andrey used the syzkaller fuzzer to find an out-of-bounds memory access in usb_get_bos_descriptor(). The code wasn't checking that the next usb_dev_cap_header structure could fit into the remaining buffer space. This patch fixes the error and also reduces the bNumDeviceCaps field in the header to match the actual number of capabilities found, in cases where there are fewer than expected. Bug: 69052675 Change-Id: Ica990541695ce5ba46ca8d2bd01e8230dcf5dcd4 Reported-by:
-
Willem de Bruijn authored
[ Upstream commit 008ba2a1 ] Packet socket bind operations must hold the po->bind_lock. This keeps po->running consistent with whether the socket is actually on a ptype list to receive packets. fanout_add unbinds a socket and its packet_rcv/tpacket_rcv call, then binds the fanout object to receive through packet_rcv_fanout. Make it hold the po->bind_lock when testing po->running and rebinding. Else, it can race with other rebind operations, such as that in packet_set_ring from packet_rcv to tpacket_rcv. Concurrent updates can result in a socket being added to a fanout group twice, causing use-after-free KASAN bug reports, among others. Reported independently by both trinity and syzkaller. Verified that the syzkaller reproducer passes after this patch. Bug: 69160446 Fixes: dc99f600 ("packet: Add fanout support.") Change-Id: I6817d1f12654dd682a962cfd4645006a7315360d Reported-by:
nixioaming <nixiaoming@huawei.com> Signed-off-by:
-
Marissa Wall authored
[ Upstream commit 4971613c ] Once a socket has po->fanout set, it remains a member of the group until it is destroyed. The prot_hook must be constant and identical across sockets in the group. If fanout_add races with packet_do_bind between the test of po->fanout and taking the lock, the bind call may make type or dev inconsistent with that of the fanout group. Hold po->bind_lock when testing po->fanout to avoid this race. I had to introduce artificial delay (local_bh_enable) to actually observe the race. Bug: 69160446 Fixes: dc99f600 ("packet: Add fanout support.") Change-Id: I899f9b6bcbd1d4b033388ef22c472857574bfc30 Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Maulik Shah authored
There can be use after free with multiple ioctl calls. Add mutex lock when updating userspace power. Bug: 70235107 Change-Id: Ieae08d05478a462b19cf7f91b64267177eaebe84 Signed-off-by:
Maulik Shah <mkshah@codeaurora.org> Signed-off-by:
Mahesh Sivasubramanian <msivasub@codeaurora.org>
-
Sean Callanan authored
msm-core.c implements an ioctl which does not properly copy its argument into kernel memory. This means that its argument is treated as a kernel-space pointer, so passing something like 0x1 causes a panic. This fix ensures that all accesses to the ioctl's argument are properly copied out of user memory, eliminating the panic. Bug: 70237702 Change-Id: I17f6c0c4675e64e121c166b0a062e83a4c5c9757 Signed-off-by:
Archana Sathyakumar <asathyak@codeaurora.org> Signed-off-by:
Sean Callanan <spyffe@google.com> (am from https://source.codeaurora.org/quic/la/kernel/msm-3.10/commit/?id=51ce6aec73d80e1f1fcc9c7fa71e9c2fcbdbc0fd)
-
- Jan 09, 2018
-
-
Sreelakshmi Gownipalli authored
Unserialized access to diag_dbgfs_dci_data_index can lead to heap overflow. Add mutex protection while updating the diag_dbgfs_dci_data_index. Bug: 70237704 Change-Id: Iee9d0447494e3576e6293afcd4d7611bc429aa8a Signed-off-by:Sreelakshmi Gownipalli <sgownipa@codeaurora.org>
-
- Jan 04, 2018
-
-
Daniel Rosenberg authored
The default_normal option causes mounts with the gid set to AID_SDCARD_RW to have user specific gids, as in the normal case. Signed-off-by:Daniel Rosenberg <drosen@google.com> Change-Id: I9619b8ac55f41415df943484dc8db1ea986cef6f Bug: 64672411
-
Daniel Rosenberg authored
fsnotify_open is not called within dentry_open, so we need to call it ourselves. Change-Id: Ia7f323b3d615e6ca5574e114e8a5d7973fb4c119 Signed-off-by:
-
- Dec 06, 2017
-
-
Daniel Rosenberg authored
The SNDRV_RAWMIDI_STREAM_{OUTPUT,INPUT} ioctls may reallocate runtime->buffer while other kernel threads are accessing it. If the underlying krealloc() call frees the original buffer, then this can turn into a use-after-free. Most of these accesses happen while the thread is holding runtime->lock, and can be fixed by just holding the same lock while replacing runtime->buffer, however we can't hold this spinlock while snd_rawmidi_kernel_{read1,write1} are copying to/from userspace. We need to add and acquire a new mutex to prevent this from happening concurrently with reallocation. We hold this mutex during the entire reallocation process, to also prevent multiple concurrent reallocations leading to a double-free. Signed-off-by: -
kunleiz authored
Add size check to ensure cal data bytes size fits inside the cal date when copying to user space buffer. CRs-Fixed: 2110256 Bug: 65172622 Change-Id: I511999984684a9db4aaf1cf2c65eb1495c36980f Signed-off-by:
kunleiz <kunleiz@codeaurora.org> Signed-off-by:
-
Chenbo Feng authored
When multiple threads is trying to tag/delete the same socket at the same time, there is a chance the tag_ref_entry of the target socket to be null before the uid_tag_data entry is freed. It is caused by the ctrl_cmd_tag function where it doesn't correctly grab the spinlocks when tagging a socket. Signed-off-by:Chenbo Feng <fengc@google.com> Bug: 65853158 Change-Id: I5d89885918054cf835370a52bff2d693362ac5f0
-
Trishansh Bhardwaj authored
Check validity of command before processing. Bug: 67713103 Change-Id: Icc5c57eac999b7c40fbb9505b2b88745167adc66 Signed-off-by:Trishansh Bhardwaj <tbhardwa@codeaurora.org>
-
Takashi Iwai authored
There is a potential race window opened at creating and deleting a port via ioctl, as spotted by fuzzing. snd_seq_create_port() creates a port object and returns its pointer, but it doesn't take the refcount, thus it can be deleted immediately by another thread. Meanwhile, snd_seq_ioctl_create_port() still calls the function snd_seq_system_client_ev_port_start() with the created port object that is being deleted, and this triggers use-after-free like: BUG: KASAN: use-after-free in snd_seq_ioctl_create_port+0x504/0x630 [snd_seq] at addr ffff8801f2241cb1 ============================================================================= BUG kmalloc-512 (Tainted: G B ): kasan: bad access detected ----------------------------------------------------------------------------- INFO: Allocated in snd_seq_create_port+0x94/0x9b0 [snd_seq] age=1 cpu=3 pid=4511 ___slab_alloc+0x425/0x460 __slab_alloc+0x20/0x40 kmem_cache_alloc_trace+0x150/0x190 snd_seq_create_port+0x94/0x9b0 [snd_seq] snd_seq_ioctl_create_port+0xd1/0x630 [snd_seq] snd_seq_do_ioctl+0x11c/0x190 [snd_seq] snd_seq_ioctl+0x40/0x80 [snd_seq] do_vfs_ioctl+0x54b/0xda0 SyS_ioctl+0x79/0x90 entry_SYSCALL_64_fastpath+0x16/0x75 INFO: Freed in port_delete+0x136/0x1a0 [snd_seq] age=1 cpu=2 pid=4717 __slab_free+0x204/0x310 kfree+0x15f/0x180 port_delete+0x136/0x1a0 [snd_seq] snd_seq_delete_port+0x235/0x350 [snd_seq] snd_seq_ioctl_delete_port+0xc8/0x180 [snd_seq] snd_seq_do_ioctl+0x11c/0x190 [snd_seq] snd_seq_ioctl+0x40/0x80 [snd_seq] do_vfs_ioctl+0x54b/0xda0 SyS_ioctl+0x79/0x90 entry_SYSCALL_64_fastpath+0x16/0x75 Call Trace: [<ffffffff81b03781>] dump_stack+0x63/0x82 [<ffffffff81531b3b>] print_trailer+0xfb/0x160 [<ffffffff81536db4>] object_err+0x34/0x40 [<ffffffff815392d3>] kasan_report.part.2+0x223/0x520 [<ffffffffa07aadf4>] ? snd_seq_ioctl_create_port+0x504/0x630 [snd_seq] [<ffffffff815395fe>] __asan_report_load1_noabort+0x2e/0x30 [<ffffffffa07aadf4>] snd_seq_ioctl_create_port+0x504/0x630 [snd_seq] [<ffffffffa07aa8f0>] ? snd_seq_ioctl_delete_port+0x180/0x180 [snd_seq] [<ffffffff8136be50>] ? taskstats_exit+0xbc0/0xbc0 [<ffffffffa07abc5c>] snd_seq_do_ioctl+0x11c/0x190 [snd_seq] [<ffffffffa07abd10>] snd_seq_ioctl+0x40/0x80 [snd_seq] [<ffffffff8136d433>] ? acct_account_cputime+0x63/0x80 [<ffffffff815b515b>] do_vfs_ioctl+0x54b/0xda0 ..... We may fix this in a few different ways, and in this patch, it's fixed simply by taking the refcount properly at snd_seq_create_port() and letting the caller unref the object after use. Also, there is another potential use-after-free by sprintf() call in snd_seq_create_port(), and this is moved inside the lock. This fix covers CVE-2017-15265. Reported-and-tested-by:
Michael23 Yu <ycqzsy@gmail.com> Suggested-by:
Linus Torvalds <torvalds@linux-foundation.org> Cc: <stable@vger.kernel.org> Signed-off-by:
Connor O'Brien <connoro@google.com> Bug: 67900971 Change-Id: Id29492065ff11927db7c0c1f50288f07a52e9823
-
Mohammed Javid authored
Added to code changes to ref_cnt variable will decrement only when add_ref_hdr variable is true. Bug: 68992478 Change-Id: I0bcc3909669f4843c43135e5f047ac28fa62bb63 Acked-by:
-
Steve Pfetsch authored
Remove unused Synaptics DSX touch screen driver files as these are not used in any of the latest targets. Bug: 68992479 Change-Id: I0cc19825691c92fee1c5b71ff7e9e7a6253f6afe Signed-off-by:
Shantanu Jain <shjain@codeaurora.org> Signed-off-by:
Steve Pfetsch <spfetsch@google.com> (am from: https://source.codeaurora.org/quic/la/kernel/msm-3.18/commit/?id=e83ebd2098009b0d336ffab11e00f739902bd5d9)
-
Paul Lawrence authored
Based on upstream change 06ebb06d One more instance when the caller requests 0 bytes instead of running off and dereferencing potentially invalid iovecs. Signed-off-by:
Paul Lawrence <paullawrence@google.com> Bug: 36279469 Change-Id: Ib8d529e17c07c77357ab70bd6a2d7e305d6b27f0
-
- Nov 30, 2017
-
-
Patrick Tjin authored
January 2018.1 Bug: 68996174 Change-Id: Id5f6cfaa3027ae601f774218dd79b1dff90b6077
-
- Nov 07, 2017
-
-
Patrick Tjin authored
January 2017.1 Bug: 68996174 Change-Id: Iccdc88be6cea832954e016a5d0b805bf107bd699 Signed-off-by:Patrick Tjin <pattjin@google.com>
-
- Nov 06, 2017
-
-
Greg Hackmann authored
Bug: 68266545 Change-Id: Ibdb1fd768b748002b90bfc165612c12c8311f8a2
-
Greg Hackmann authored
Bug: 68266545 Change-Id: I6005a6e944494257bfc2243fde2f7a09c3fd76c6
-
Marc Zyngier authored
We now trap accesses to CNTVCT_EL0 when the counter is broken enough to require the kernel to mediate the access. But it turns out that some existing userspace (such as OpenMPI) do probe for the counter frequency, leading to an UNDEF exception as CNTVCT_EL0 and CNTFRQ_EL0 share the same control bit. The fix is to handle the exception the same way we do for CNTVCT_EL0. Bug: 68266545 Fixes: a86bd139 ("arm64: arch_timer: Enable CNTVCT_EL0 trap if workaround is enabled") Reported-by:
Hanjun Guo <guohanjun@huawei.com> Tested-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> (cherry picked from commit 9842119a) Change-Id: Ie5a9a93fcca238d6097ecacd6df0e540be90220b
-
Marc Zyngier authored
Since people seem to make a point in breaking the userspace visible counter, we have no choice but to trap the access. Add the required handler. Bug: 68266545 Acked-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
-
Herbert Xu authored
commit 4f0414e5 upstream. We need to load the TX SG list in sendmsg(2) after waiting for incoming data, not before. Bug: 64386293 Change-Id: Ibb0b7969ee1df314b49462ecd65ce381118d915d Cc: stable@vger.kernel.org Reported-by:
Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Tested-by:
Andrey Ryabinin <aryabinin@virtuozzo.com> Signed-off-by:
Willy Tarreau <w@1wt.eu> Signed-off-by:
-
Ecco Park authored
The configs for this is used for Bluez. So, there is no reason to keep this that causes the Security Vulnerability. Bug: 63527053 Change-Id: Ia25a8268412ce58c6a162953af3602634b219669 Signed-off-by:Ecco Park <eccopark@google.com>
-
tharun kumar authored
validate user buffers before accessing in kernel driver. Bug: 67713083 Change-Id: I7997d069d0549de03f1467c63bdb81b20fcf3d6c Acked-by:
Chenna Kesava Raju <chennak@qti.qualcomm.com> Signed-off-by:
Tharun Kumar Merugu <mtharu@codeaurora.org>
-
Steve Pfetsch authored
Bug: 62800865 Change-Id: I386b9bfbf5463527bf20dacc5da6574ad8d613a0 Signed-off-by: -
Marissa Wall authored
The 'move_paghes()' system call was introduced long long ago with the same permission checks as for sending a signal (except using CAP_SYS_NICE instead of CAP_SYS_KILL for the overriding capability). That turns out to not be a great choice - while the system call really only moves physical page allocations around (and you need other capabilities to do a lot of it), you can check the return value to map out some the virtual address choices and defeat ASLR of a binary that still shares your uid. So change the access checks to the more common 'ptrace_may_access()' model instead. This tightens the access checks for the uid, and also effectively changes the CAP_SYS_NICE check to CAP_SYS_PTRACE, but it's unlikely that anybody really _uses_ this legacy system call any more (we hav ebetter NUMA placement models these days), so I expect nobody to notice. Famous last words. Reported-by:
Otto Ebeling <otto.ebeling@iki.fi> Acked-by:
Eric W. Biederman <ebiederm@xmission.com> Cc: Willy Tarreau <w@1wt.eu> Cc: stable@kernel.org Bug: 65468230 Signed-off-by:
-
Viktor Slavkovic authored
A lock-unlock is missing in ASHMEM_SET_SIZE ioctl which can result in a race condition when mmap is called. After the !asma->file check, before setting asma->size, asma->file can be set in mmap. That would result in having different asma->size than the mapped memory size. Combined with ASHMEM_UNPIN ioctl and shrinker invocation, this can result in memory corruption. Bug: 66954097 Signed-off-by:Viktor Slavkovic <viktors@google.com> Change-Id: Ia52312a75ade30bc94be6b94420f17f34e0c1f86
-
Karthikeyan Mani authored
Remove read permission for debugfs reg dump node for group and users to not allow reading of wcd9xxx registers. CRs-fixed: 2113240 Bug: 62464339 Change-Id: I73a22e140446828e694fdc95fde7ac4e051c9548 Signed-off-by:Karthikeyan Mani <kmani@codeaurora.org>
-
