- 15 Jun, 2016 24 commits
-
-
Jiri Slaby authored
commit 6798df4c upstream. When csw->con_startup() fails in do_register_con_driver, we return no error (i.e. 0). This was changed back in 2006 by commit 3e795de7. Before that we used to return -ENODEV. So fix the return value to be -ENODEV in that case again. Fixes: 3e795de7 ("VT binding: Add binding/unbinding support for the VT console") Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Reported-by:
"Dan Carpenter" <dan.carpenter@oracle.com> Signed-off-by:
-
Schemmel Hans-Christoph authored
commit 444f94e9 upstream. Added support for Gemalto's Cinterion PH8 and AHxx products with 2 RmNet Interfaces and products with 1 RmNet + 1 USB Audio interface. In addition some minor renaming and formatting. Signed-off-by:
Hans-Christoph Schemmel <hans-christoph.schemmel@gemalto.com> [johan: sort current entries and trim trailing whitespace ] Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Johan Hovold authored
commit c8d62957 upstream. URBs and buffers allocated in attach for Epic devices would never be deallocated in case of a later probe error (e.g. failure to allocate minor numbers) as disconnect is then never called. Fix by moving deallocation to release and making sure that the URBs are first unlinked. Fixes: f9c99bb8 ("USB: usb-serial: replace shutdown with disconnect, release") Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Johan Hovold authored
commit c5c0c555 upstream. Private data, URBs and buffers allocated for Epic devices during attach were never released on errors (e.g. missing endpoints). Fixes: 6e8cf775 ("USB: add EPIC support to the io_edgeport driver") Signed-off-by:
-
Johan Hovold authored
commit 028c49f5 upstream. The interface read URB is submitted in attach, but was only unlinked by the driver at disconnect. In case of a late probe error (e.g. due to failed minor allocation), disconnect is never called and we would end up with active URBs for an unbound interface. This in turn could lead to deallocated memory being dereferenced in the completion callback. Fixes: f7a33e60 ("USB: serial: add quatech2 usb to serial driver") Signed-off-by:
-
Johan Hovold authored
commit 35be1a71 upstream. The interface instat and indat URBs were submitted in attach, but never unlinked in release before deallocating the corresponding transfer buffers. In the case of a late probe error (e.g. due to failed minor allocation), disconnect would not have been called before release, causing the buffers to be freed while the URBs are still in use. We'd also end up with active URBs for an unbound interface. Fixes: f9c99bb8 ("USB: usb-serial: replace shutdown with disconnect, release") Signed-off-by:
-
Vladis Dronov authored
commit d5468d7a upstream. Commit 588afcc1 ("[media] usbvision fix overflow of interfaces array")' should be reverted, because: * "!dev->actconfig->interface[ifnum]" won't catch a case where the value is not NULL but some garbage. This way the system may crash later with GPF. * "(ifnum >= USB_MAXINTERFACES)" does not cover all the error conditions. "ifnum" should be compared to "dev->actconfig-> desc.bNumInterfaces", i.e. compared to the number of "struct usb_interface" kzalloc()-ed, not to USB_MAXINTERFACES. * There is a "struct usb_device" leak in this error path, as there is usb_get_dev(), but no usb_put_dev() on this path. * There is a bug of the same type several lines below with number of endpoints. The code is accessing hard-coded second endpoint ("interface->endpoint[1].desc") which may not exist. It would be great to handle this in the same patch too. * All the concerns above are resolved by already-accepted commit fa52bd50 ("[media] usbvision: fix crash on detecting device with invalid configuration") * Mailing list message: http://www.spinics.net/lists/linux-media/msg94832.htmlSigned-off-by:
Vladis Dronov <vdronov@redhat.com> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by:
-
Matt Gumbel authored
commit 32ecd320 upstream. 008GE0 Toshiba mmc in some Intel Baytrail tablets responds to MMC_SEND_EXT_CSD in 450-600ms. This patch will... () Increase the long read time quirk timeout from 300ms to 600ms. Original author of that quirk says 300ms was only a guess and that the number may need to be raised in the future. () Add this specific MMC to the quirk Signed-off-by:
Matt Gumbel <matthew.k.gumbel@intel.com> Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Lv Zheng authored
commit 30c9bb0d upstream. The order of the _OSI related functionalities is as follows: acpi_blacklisted() acpi_dmi_osi_linux() acpi_osi_setup() acpi_osi_setup() acpi_update_interfaces() if "!*" <<<<<<<<<<<<<<<<<<<<<<<< parse_args() __setup("acpi_osi=") acpi_osi_setup_linux() acpi_update_interfaces() if "!*" <<<<<<<<<<<<<<<<<<<<<<<< acpi_early_init() acpi_initialize_subsystem() acpi_ut_initialize_interfaces() ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ acpi_bus_init() acpi_os_initialize1() acpi_install_interface_handler(acpi_osi_handler) acpi_osi_setup_late() acpi_update_interfaces() for "!" >>>>>>>>>>>>>>>>>>>>>>>> acpi_osi_handler() Since acpi_osi_setup_linux() can override acpi_dmi_osi_linux(), the command line setting can override the DMI detection. That's why acpi_blacklisted() is put before __setup("acpi_osi="). Then we can notice the following wrong invocation order. There are acpi_update_interfaces() (marked by <<<<) calls invoked before acpi_ut_initialize_interfaces() (marked by ^^^^). This makes it impossible to use acpi_osi=!* correctly from OSI DMI table or from the command line. The use of acpi_osi=!* is meant to disable both ACPICA (acpi_gbl_supported_interfaces) and Linux specific strings (osi_setup_entries) while the ACPICA part should have stopped working because of the order issue. This patch fixes this issue by moving acpi_update_interfaces() to where it is invoked for acpi_osi=! (marked by >>>>) as this is ensured to be invoked after acpi_ut_initialize_interfaces() (marked by ^^^^). Linux specific strings are still handled in the original place in order to make the following command line working: acpi_osi=!* acpi_osi="Module Device". Note that since acpi_osi=!* is meant to further disable linux specific string comparing to the acpi_osi=!, there is no such use case in our bug fixing work and hence there is no one using acpi_osi=!* either from the command line or from the DMI quirks, this issue is just a theoretical issue. Fixes: 741d8128 (ACPI: Add facility to remove all _OSI strings) Tested-by:
Lukas Wunner <lukas@wunner.de> Tested-by:
Chen Yu <yu.c.chen@intel.com> Signed-off-by:
Lv Zheng <lv.zheng@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Adrian Hunter authored
commit 1c447116 upstream. Some eMMCs set the partition switch timeout too low. Now typically eMMCs are considered a critical component (e.g. because they store the root file system) and consequently are expected to be reliable. Thus we can neglect the use case where eMMCs can't switch reliably and we might want a lower timeout to facilitate speedy recovery. Although we could employ a quirk for the cards that are affected (if we could identify them all), as described above, there is little benefit to having a low timeout, so instead simply set a minimum timeout. The minimum is set to 300ms somewhat arbitrarily - the examples that have been seen had a timeout of 10ms but were sometimes taking 60-70ms. Signed-off-by:
-
Steven Rostedt (Red Hat) authored
commit 59643d15 upstream. If the size passed to ring_buffer_resize() is greater than MAX_LONG - BUF_PAGE_SIZE then the DIV_ROUND_UP() will return zero. Here's the details: # echo 18014398509481980 > /sys/kernel/debug/tracing/buffer_size_kb tracing_entries_write() processes this and converts kb to bytes. 18014398509481980 << 10 = 18446744073709547520 and this is passed to ring_buffer_resize() as unsigned long size. size = DIV_ROUND_UP(size, BUF_PAGE_SIZE); Where DIV_ROUND_UP(a, b) is (a + b - 1)/b BUF_PAGE_SIZE is 4080 and here 18446744073709547520 + 4080 - 1 = 18446744073709551599 where 18446744073709551599 is still smaller than 2^64 2^64 - 18446744073709551599 = 17 But now 18446744073709551599 / 4080 = 4521260802379792 and size = size * 4080 = 18446744073709551360 This is checked to make sure its still greater than 2 * 4080, which it is. Then we convert to the number of buffer pages needed. nr_page = DIV_ROUND_UP(size, BUF_PAGE_SIZE) but this time size is 18446744073709551360 and 2^64 - (18446744073709551360 + 4080 - 1) = -3823 Thus it overflows and the resulting number is less than 4080, which makes 3823 / 4080 = 0 an nr_pages is set to this. As we already checked against the minimum that nr_pages may be, this causes the logic to fail as well, and we crash the kernel. There's no reason to have the two DIV_ROUND_UP() (that's just result of historical code changes), clean up the code and fix this bug. Fixes: 83f40318 ("ring-buffer: Make removal of ring buffer pages atomic") Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Steven Rostedt (Red Hat) authored
commit 9b94a8fb upstream. The size variable to change the ring buffer in ftrace is a long. The nr_pages used to update the ring buffer based on the size is int. On 64 bit machines this can cause an overflow problem. For example, the following will cause the ring buffer to crash: # cd /sys/kernel/debug/tracing # echo 10 > buffer_size_kb # echo 8556384240 > buffer_size_kb Then you get the warning of: WARNING: CPU: 1 PID: 318 at kernel/trace/ring_buffer.c:1527 rb_update_pages+0x22f/0x260 Which is: RB_WARN_ON(cpu_buffer, nr_removed); Note each ring buffer page holds 4080 bytes. This is because: 1) 10 causes the ring buffer to have 3 pages. (10kb requires 3 * 4080 pages to hold) 2) (2^31 / 2^10 + 1) * 4080 = 8556384240 The value written into buffer_size_kb is shifted by 10 and then passed to ring_buffer_resize(). 8556384240 * 2^10 = 8761737461760 3) The size passed to ring_buffer_resize() is then divided by BUF_PAGE_SIZE which is 4080. 8761737461760 / 4080 = 2147484672 4) nr_pages is subtracted from the current nr_pages (3) and we get: 2147484669. This value is saved in a signed integer nr_pages_to_update 5) 2147484669 is greater than 2^31 but smaller than 2^32, a signed int turns into the value of -2147482627 6) As the value is a negative number, in update_pages_handler() it is negated and passed to rb_remove_pages() and 2147482627 pages will be removed, which is much larger than 3 and it causes the warning because not all the pages asked to be removed were removed. Link: https://bugzilla.kernel.org/show_bug.cgi?id=118001 Fixes: 7a8e76a3 ("tracing: unified trace buffer") Reported-by:
Hao Qin <QEver.cn@gmail.com> Signed-off-by:
-
Stefan Metzmacher authored
commit cfda35d9 upstream. See [MS-NLMP] 3.2.5.1.2 Server Receives an AUTHENTICATE_MESSAGE from the Client: ... Set NullSession to FALSE If (AUTHENTICATE_MESSAGE.UserNameLen == 0 AND AUTHENTICATE_MESSAGE.NtChallengeResponse.Length == 0 AND (AUTHENTICATE_MESSAGE.LmChallengeResponse == Z(1) OR AUTHENTICATE_MESSAGE.LmChallengeResponse.Length == 0)) -- Special case: client requested anonymous authentication Set NullSession to TRUE ... Only server which map unknown users to guest will allow access using a non-null NTChallengeResponse. For Samba it's the "map to guest = bad user" option. BUG: https://bugzilla.samba.org/show_bug.cgi?id=11913Signed-off-by:
Stefan Metzmacher <metze@samba.org> Signed-off-by:
Steve French <smfrench@gmail.com> Signed-off-by:
-
Steve French authored
commit 897fba11 upstream. Wrong return code was being returned on SMB3 rmdir of non-empty directory. For SMB3 (unlike for cifs), we attempt to delete a directory by set of delete on close flag on the open. Windows clients set this flag via a set info (SET_FILE_DISPOSITION to set this flag) which properly checks if the directory is empty. With this patch on smb3 mounts we correctly return "DIRECTORY NOT EMPTY" on attempts to remove a non-empty directory. Signed-off-by:
Steve French <steve.french@primarydata.com> Acked-by:
Sachin Prabhu <sprabhu@redhat.com> Signed-off-by:
-
Vineet Gupta authored
commit a6416f57 upstream. ARCompact and ARCv2 only have ASL, while binutils used to support LSL as a alias mnemonic. Newer binutils (upstream) don't want to do that so replace it. Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
-
Daniel Bristot de Oliveira authored
commit c14022bf upstream. The device which identifies itself as a "USB Keykoard" (no typo) with VID:PID 1a2c:0027 does not seem to be handling the reports initialization very well. This results in a "usb_submit_urb(ctrl) failed: -1" message from the kernel when connected, and a delay before its initialization. It can also cause the hang the system. This patch adds the quirk for this device, which causes the delay to disappear. It is named as "USB Keykoard2" because the "USB Keykoard" already exists. Signed-off-by:
Daniel Bristot de Oliveira <bristot@redhat.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Cc: Oliver Neukum <oliver@neukum.org> Signed-off-by:
-
Cyan Ogilvie authored
commit d3059673 upstream. The wiimote motion plus gyros use two scales to report fast and slow rotation - below 440 deg/s uses 8192/440 units / deg/s, and above uses 8192/2000 units / deg/s. Previously this driver attempted to linearize the two by scaling the fast rate by 18 and the slow by 9, but this results in a scale of 8192*9/440 = ~167.564 for slow and 8192*18/2000 = 73.728 for fast. Correct the fast motion scale factor so that both report ~167.564 units / deg/s Signed-off-by:
Cyan Ogilvie <cyan.ogilvie@gmail.com> Reviewed-by:
David Herrmann <dh.herrmann@gmail.com> Signed-off-by:
-
Sean Young authored
commit 6e5e9a06 upstream. This device supports force feedback and has two ports. Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Николай Кудрявцев authored
commit 9a1d78a3 upstream. Acer Aspire Switch 12 keyboard Chicony's controller reports too big usage index on the 1st interface. The patch fixes the report. The work based on solution from drivers/hid/hid-holtek-mouse.c Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=101721Signed-off-by:
Nicholas Kudriavtsev <nkudriavtsev@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.com> Signed-off-by:
-
Slava Bacherikov authored
commit f9a82c20 upstream. Microsoft Wireless Comfort Keyboard has vendor specific My Favorites 1-5 keys. Linux already supports this buttons on other MS keyboards by MS_ERGONOMY quirk. So apply MS_ERGONOMY quirk to USB PID 0x00e3 (Microsoft Wireless Optical Desktop Receiver 3.0A). After this My Favorites 1..5 keys will be reported as KEY_F14..KEY_F15 events. Signed-off-by:
Slava Bacherikov <slava@bacher09.org> Signed-off-by:
-
Donavan Lance authored
commit c6956eb7 upstream. Adds support for Microsoft Type Cover 3 with 0x07e2 product ID. Signed-off-by:
Donavan Lance <shvr@fedoraproject.org> Signed-off-by:
-
Alistair Leslie-Hughes authored
commit c847a89a upstream. Adds support for the Micrsift Digital 4K, Media 600 and Media 3000 V1 Keyboards, which have the same quirks as the already existing hardware MS_NE4K. Fixes https://bugzilla.kernel.org/show_bug.cgi?id=52841 [jkosina@suse.cz: rephrase changelog] Signed-off-by:
Alistair Leslie-Hughes <leslie_alistair@hotmail.com> Signed-off-by:
-
Stephen Just authored
commit 0439de75 upstream. Adding support for the Microsoft Surface 3 (non-pro) Type Cover. The existing definitions and quirks are actually for the Surface Pro 3 type covers. I've renamed the old constants to reflect that they belong to the Surface Pro 3, and added a new constant and matching code for the Surface 3. Signed-off-by:
Stephen Just <stephenjust@gmail.com> Signed-off-by:
-
Raimund Roth authored
commit 18eec2cd upstream. Adding support for the Microsoft Surface Pro Power Cover. Signed-off-by:
Raimund Roth <raimundmroth@gmail.com> Signed-off-by:
-
- 31 May, 2016 3 commits
-
-
Nazar Mokrynskyi authored
commit 567a44ec upstream. Needed for v2 of the device firmware, otherwise kernel will stuck for few seconds and throw "usb_submit_urb(ctrl) failed: -1" early on system boot. Signed-off-by:
Nazar Mokrynskyi <nazar@mokrynskyi.com> Reviewed-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
-
Trent Lloyd authored
commit 282bf1fe upstream. These devices feature multiple interfaces/endpoints: a legacy BIOS/boot interface (endpoint 0x81), as well as 2 corsair-specific keyboard interfaces (endpoint 0x82, 0x83 IN/0x03 OUT) and an RGB LED control interface (endpoint 0x84 IN/0x04 OUT) Because the extra 3 interfaces are not of subclass USB_INTERFACE_SUBCLASS_BOOT, HID_QUIRK_NOGET is not automatically set on them and a 10s timeout per-endpoint (30s per device) occurs initialising reports on boot. We configure HID_QUIRK_NO_INIT_REPORTS for these devices. Additionally the left-side G1-G18 macro keys on the K95RGB generate output on the un-opened 0x82/0x83 endpoints which causes the keyboard to stop responding waiting for this event to be collected. We enable HID_QUIRK_ALWAYS_POLL to prevent this situation from occurring. Signed-off-by:
Trent Lloyd <trent@lloyd.id.au> Tested-by:
SUGNIAUX Wilfried <wsu@ppharm2k20.net> Signed-off-by:
-
Jason Gunthorpe authored
commit e6bd18f5 upstream. The drivers/infiniband stack uses write() as a replacement for bi-directional ioctl(). This is not safe. There are ways to trigger write calls that result in the return structure that is normally written to user space being shunted off to user specified kernel memory instead. For the immediate repair, detect and deny suspicious accesses to the write API. For long term, update the user space libraries and the kernel API to something that doesn't present the same security vulnerabilities (likely a structured ioctl() interface). The impacted uAPI interfaces are generally only available if hardware from drivers/infiniband is installed in the system. [js] backport to 3.12: hfi1 is not there yet (exclude), ipath is still there (include) Reported-by:
Jann Horn <jann@thejh.net> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> [ Expanded check to all known write() entry points ] Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
- 25 May, 2016 1 commit
-
-
Benjamin Coddington authored
commit ce85cfbe upstream. If a READDIR reply comes back without any page data, avoid a NULL pointer dereference in xdr_copy_to_scratch(). BUG: unable to handle kernel NULL pointer dereference at 0000000000000001 IP: [<ffffffff813a378d>] memcpy+0xd/0x110 ... Call Trace: ? xdr_inline_decode+0x7a/0xb0 [sunrpc] nfs3_decode_dirent+0x73/0x320 [nfsv3] nfs_readdir_page_filler+0xd5/0x4e0 [nfs] ? nfs3_rpc_wrapper.constprop.9+0x42/0xc0 [nfsv3] nfs_readdir_xdr_to_array+0x1fa/0x330 [nfs] ? mem_cgroup_commit_charge+0xac/0x160 ? nfs_readdir_xdr_to_array+0x330/0x330 [nfs] nfs_readdir_filler+0x22/0x90 [nfs] do_read_cache_page+0x7e/0x1a0 read_cache_page+0x1c/0x20 nfs_readdir+0x18e/0x660 [nfs] ? nfs3_xdr_dec_getattr3res+0x80/0x80 [nfsv3] iterate_dir+0x97/0x130 SyS_getdents+0x94/0x120 ? fillonedir+0xd0/0xd0 system_call_fastpath+0x12/0x17 Signed-off-by:
Benjamin Coddington <bcodding@redhat.com> Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Cc: Neil Brown <nfbrown@suse.com> Signed-off-by:
-
- 19 May, 2016 11 commits
-
-
Jiri Slaby authored
-
Antonio Alecrim Jr authored
commit eb8948a0 upstream. Signed-off-by:
Antonio Alecrim Jr <antonio.alecrim@gmail.com> Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
Kirill Tkhai authored
commit f7b8a47d upstream. sched_move_task() is the only interface to change sched_task_group: cpu_cgrp_subsys methods and autogroup_move_group() use it. Everything is synchronized by task_rq_lock(), so cpu_cgroup_attach() is ordered with other users of sched_move_task(). This means we do no need RCU here: if we've dereferenced a tg here, the .attach method hasn't been called for it yet. Thus, we should pass "true" to task_css_check() to silence lockdep warnings. Fixes: eeb61e53 ("sched: Fix race between task_group and sched_task_group") Reported-by:
Oleg Nesterov <oleg@redhat.com> Reported-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
Kirill Tkhai <ktkhai@parallels.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: http://lkml.kernel.org/r/1414473874.8574.2.camel@tkhaiSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
David Howells authored
commit 23c8a812 upstream. This fixes CVE-2016-0758. In the ASN.1 decoder, when the length field of an ASN.1 value is extracted, it isn't validated against the remaining amount of data before being added to the cursor. With a sufficiently large size indicated, the check: datalen - dp < 2 may then fail due to integer overflow. Fix this by checking the length indicated against the amount of remaining data in both places a definite length is determined. Whilst we're at it, make the following changes: (1) Check the maximum size of extended length does not exceed the capacity of the variable it's being stored in (len) rather than the type that variable is assumed to be (size_t). (2) Compare the EOC tag to the symbolic constant ASN1_EOC rather than the integer 0. (3) To reduce confusion, move the initialisation of len outside of: for (len = 0; n > 0; n--) { since it doesn't have anything to do with the loop counter n. Signed-off-by:
Mimi Zohar <zohar@linux.vnet.ibm.com> Acked-by:
David Woodhouse <David.Woodhouse@intel.com> Acked-by:
Peter Jones <pjones@redhat.com> Signed-off-by:
-
David Howells authored
commit 0d62e9dd upstream. If the ASN.1 decoder is asked to parse a sequence of objects, non-optional matches get skipped if there's no more data to be had rather than a data-overrun error being reported. This is due to the code segment that decides whether to skip optional matches (ie. matches that could get ignored because an element is marked OPTIONAL in the grammar) due to a lack of data also skips non-optional elements if the data pointer has reached the end of the buffer. This can be tested with the data decoder for the new RSA akcipher algorithm that takes three non-optional integers. Currently, it skips the last integer if there is insufficient data. Without the fix, #defining DEBUG in asn1_decoder.c will show something like: next_op: pc=0/13 dp=0/270 C=0 J=0 - match? 30 30 00 - TAG: 30 266 CONS next_op: pc=2/13 dp=4/270 C=1 J=0 - match? 02 02 00 - TAG: 02 257 - LEAF: 257 next_op: pc=5/13 dp=265/270 C=1 J=0 - match? 02 02 00 - TAG: 02 3 - LEAF: 3 next_op: pc=8/13 dp=270/270 C=1 J=0 next_op: pc=11/13 dp=270/270 C=1 J=0 - end cons t=4 dp=270 l=270/270 The next_op line for pc=8/13 should be followed by a match line. This is not exploitable for X.509 certificates by means of shortening the message and fixing up the ASN.1 CONS tags because: (1) The relevant records being built up are cleared before use. (2) If the message is shortened sufficiently to remove the public key, the ASN.1 parse of the RSA key will fail quickly due to a lack of data. (3) Extracted signature data is either turned into MPIs (which cope with a 0 length) or is simpler integers specifying algoritms and suchlike (which can validly be 0); and (4) The AKID and SKID extensions are optional and their removal is handled without risking passing a NULL to asymmetric_key_generate_id(). (5) If the certificate is truncated sufficiently to remove the subject, issuer or serialNumber then the ASN.1 decoder will fail with a 'Cons stack underflow' return. This is not exploitable for PKCS#7 messages by means of removal of elements from such a message from the tail end of a sequence: (1) Any shortened X.509 certs embedded in the PKCS#7 message are survivable as detailed above. (2) The message digest content isn't used if it shows a NULL pointer, similarly, the authattrs aren't used if that shows a NULL pointer. (3) A missing signature results in a NULL MPI - which the MPI routines deal with. (4) If data is NULL, it is expected that the message has detached content and that is handled appropriately. (5) If the serialNumber is excised, the unconditional action associated with it will pick up the containing SEQUENCE instead, so no NULL pointer will be seen here. If both the issuer and the serialNumber are excised, the ASN.1 decode will fail with an 'Unexpected tag' return. In either case, there's no way to get to asymmetric_key_generate_id() with a NULL pointer. (6) Other fields are decoded to simple integers. Shortening the message to omit an algorithm ID field will cause checks on this to fail early in the verification process. This can also be tested by snipping objects off of the end of the ASN.1 stream such that mandatory tags are removed - or even from the end of internal SEQUENCEs. If any mandatory tag is missing, the error EBADMSG *should* be produced. Without this patch ERANGE or ENOPKG might be produced or the parse may apparently succeed, perhaps with ENOKEY or EKEYREJECTED being produced later, depending on what gets snipped. Just snipping off the final BIT_STRING or OCTET_STRING from either sample should be a start since both are mandatory and neither will cause an EBADMSG without the patches Reported-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Kangjie Lu authored
[ Upstream commit 79e48650 ] Stack object "dte_facilities" is allocated in x25_rx_call_request(), which is supposed to be initialized in x25_negotiate_facilities. However, 5 fields (8 bytes in total) are not initialized. This object is then copied to userland via copy_to_user, thus infoleak occurs. Signed-off-by:
Kangjie Lu <kjlu@gatech.edu> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Nikolay Aleksandrov authored
[ Upstream commit 31ca0458 ] get_bridge_ifindices() is used from the old "deviceless" bridge ioctl calls which aren't called with rtnl held. The comment above says that it is called with rtnl but that is not really the case. Here's a sample output from a test ASSERT_RTNL() which I put in get_bridge_ifindices and executed "brctl show": [ 957.422726] RTNL: assertion failed at net/bridge//br_ioctl.c (30) [ 957.422925] CPU: 0 PID: 1862 Comm: brctl Tainted: G W O 4.6.0-rc4+ #157 [ 957.423009] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.8.1-20150318_183358- 04/01/2014 [ 957.423009] 0000000000000000 ffff880058adfdf0 ffffffff8138dec5 0000000000000400 [ 957.423009] ffffffff81ce8380 ffff880058adfe58 ffffffffa05ead32 0000000000000001 [ 957.423009] 00007ffec1a444b0 0000000000000400 ffff880053c19130 0000000000008940 [ 957.423009] Call Trace: [ 957.423009] [<ffffffff8138dec5>] dump_stack+0x85/0xc0 [ 957.423009] [<ffffffffa05ead32>] br_ioctl_deviceless_stub+0x212/0x2e0 [bridge] [ 957.423009] [<ffffffff81515beb>] sock_ioctl+0x22b/0x290 [ 957.423009] [<ffffffff8126ba75>] do_vfs_ioctl+0x95/0x700 [ 957.423009] [<ffffffff8126c159>] SyS_ioctl+0x79/0x90 [ 957.423009] [<ffffffff8163a4c0>] entry_SYSCALL_64_fastpath+0x23/0xc1 Since it only reads bridge ifindices, we can use rcu to safely walk the net device list. Also remove the wrong rtnl comment above. Signed-off-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by:
-
Ian Campbell authored
[ Upstream commit dedc58e0 ] The peer may be expecting a reply having sent a request and then done a shutdown(SHUT_WR), so tearing down the whole socket at this point seems wrong and breaks for me with a client which does a SHUT_WR. Looking at other socket family's stream_recvmsg callbacks doing a shutdown here does not seem to be the norm and removing it does not seem to have had any adverse effects that I can see. I'm using Stefan's RFC virtio transport patches, I'm unsure of the impact on the vmci transport. Signed-off-by:
Ian Campbell <ian.campbell@docker.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Stefan Hajnoczi <stefanha@redhat.com> Cc: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com> Cc: Andy King <acking@vmware.com> Cc: Dmitry Torokhov <dtor@vmware.com> Cc: Jorgen Hansen <jhansen@vmware.com> Cc: Adit Ranadive <aditr@vmware.com> Cc: netdev@vger.kernel.org Signed-off-by:
-
Kangjie Lu authored
[ Upstream commit 5f8e4474 ] The stack object “map” has a total size of 32 bytes. Its last 4 bytes are padding generated by compiler. These padding bytes are not initialized and sent out via “nla_put”. Signed-off-by:
-
Kangjie Lu authored
[ Upstream commit b8670c09 ] The stack object “info” has a total size of 12 bytes. Its last byte is padding which is not initialized and leaked via “put_cmsg”. Signed-off-by:
-
Neil Horman authored
[ Upstream commit 6071bd1a ] This was recently reported to me, and reproduced on the latest net kernel, when attempting to run netperf from a host that had a netem qdisc attached to the egress interface: [ 788.073771] ---------------------[ cut here ]--------------------------- [ 788.096716] WARNING: at net/core/dev.c:2253 skb_warn_bad_offload+0xcd/0xda() [ 788.129521] bnx2: caps=(0x00000001801949b3, 0x0000000000000000) len=2962 data_len=0 gso_size=1448 gso_type=1 ip_summed=3 [ 788.182150] Modules linked in: sch_netem kvm_amd kvm crc32_pclmul ipmi_ssif ghash_clmulni_intel sp5100_tco amd64_edac_mod aesni_intel lrw gf128mul glue_helper ablk_helper edac_mce_amd cryptd pcspkr sg edac_core hpilo ipmi_si i2c_piix4 k10temp fam15h_power hpwdt ipmi_msghandler shpchp acpi_power_meter pcc_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c sd_mod crc_t10dif crct10dif_generic mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit drm_kms_helper ahci ata_generic pata_acpi ttm libahci crct10dif_pclmul pata_atiixp tg3 libata crct10dif_common drm crc32c_intel ptp serio_raw bnx2 r8169 hpsa pps_core i2c_core mii dm_mirror dm_region_hash dm_log dm_mod [ 788.465294] CPU: 16 PID: 0 Comm: swapper/16 Tainted: G W ------------ 3.10.0-327.el7.x86_64 #1 [ 788.511521] Hardware name: HP ProLiant DL385p Gen8, BIOS A28 12/17/2012 [ 788.542260] ffff880437c036b8 f7afc56532a53db9 ffff880437c03670 ffffffff816351f1 [ 788.576332] ffff880437c036a8 ffffffff8107b200 ffff880633e74200 ffff880231674000 [ 788.611943] 0000000000000001 0000000000000003 0000000000000000 ffff880437c03710 [ 788.647241] Call Trace: [ 788.658817] <IRQ> [<ffffffff816351f1>] dump_stack+0x19/0x1b [ 788.686193] [<ffffffff8107b200>] warn_slowpath_common+0x70/0xb0 [ 788.713803] [<ffffffff8107b29c>] warn_slowpath_fmt+0x5c/0x80 [ 788.741314] [<ffffffff812f92f3>] ? ___ratelimit+0x93/0x100 [ 788.767018] [<ffffffff81637f49>] skb_warn_bad_offload+0xcd/0xda [ 788.796117] [<ffffffff8152950c>] skb_checksum_help+0x17c/0x190 [ 788.823392] [<ffffffffa01463a1>] netem_enqueue+0x741/0x7c0 [sch_netem] [ 788.854487] [<ffffffff8152cb58>] dev_queue_xmit+0x2a8/0x570 [ 788.880870] [<ffffffff8156ae1d>] ip_finish_output+0x53d/0x7d0 ... The problem occurs because netem is not prepared to handle GSO packets (as it uses skb_checksum_help in its enqueue path, which cannot manipulate these frames). The solution I think is to simply segment the skb in a simmilar fashion to the way we do in __dev_queue_xmit (via validate_xmit_skb), with some minor changes. When we decide to corrupt an skb, if the frame is GSO, we segment it, corrupt the first segment, and enqueue the remaining ones. tested successfully by myself on the latest net kernel, to which this applies [js] backport to 3.12: no qdisc_qstats_drop yet, update directly. Also use qdisc_tree_decrease_qlen instead of qdisc_tree_reduce_backlog. Signed-off-by:
Neil Horman <nhorman@tuxdriver.com> CC: Jamal Hadi Salim <jhs@mojatatu.com> CC: "David S. Miller" <davem@davemloft.net> CC: netem@lists.linux-foundation.org CC: eric.dumazet@gmail.com CC: stephen@networkplumber.org Acked-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
- 18 May, 2016 1 commit
-
-
Eric Dumazet authored
[ Upstream commit fc96256c ] When multiple skb are TX-completed in a row, we might incorrectly keep a timestamp of a prior skb and cause extra work. Fixes: ec693d47 ("net/mlx4_en: Add HW timestamping (TS) support") Signed-off-by:
Eran Ben Elisha <eranbe@mellanox.com> Signed-off-by:
-
