- 19 Oct, 2018 40 commits
-
-
Yuan-Chi Pang authored
BugLink: https://bugs.launchpad.net/bugs/1798770 [ Upstream commit 1f631c32 ] IEEE 802.11-2016 14.10.8.3 HWMP sequence numbering says: If it is a target mesh STA, it shall update its own HWMP SN to maximum (current HWMP SN, target HWMP SN in the PREQ element) + 1 immediately before it generates a PREP element in response to a PREQ element. Signed-off-by:
Yuan-Chi Pang <fu3mo6goo@gmail.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Sasha Levin <alexander.levin@microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Michael Hennerich authored
BugLink: https://bugs.launchpad.net/bugs/1798770 [ Upstream commit 6537886c ] This fixes: [BUG] gpio: gpio-adp5588: A possible sleep-in-atomic-context bug in adp5588_gpio_write() [BUG] gpio: gpio-adp5588: A possible sleep-in-atomic-context bug in adp5588_gpio_direction_input() Reported-by:
Jia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by:
Michael Hennerich <michael.hennerich@analog.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Danek Duvall authored
BugLink: https://bugs.launchpad.net/bugs/1798770 [ Upstream commit d7c863a2 ] The mac80211_hwsim driver intends to say that it supports up to four STBC receive streams, but instead it ends up saying something undefined. The IEEE80211_VHT_CAP_RXSTBC_X macros aren't independent bits that can be ORed together, but values. In this case, _4 is the appropriate one to use. Signed-off-by:
Danek Duvall <duvall@comfychair.org> Signed-off-by:
-
Danek Duvall authored
BugLink: https://bugs.launchpad.net/bugs/1798770 [ Upstream commit 67d1ba8a ] The mod mask for VHT capabilities intends to say that you can override the number of STBC receive streams, and it does, but only by accident. The IEEE80211_VHT_CAP_RXSTBC_X aren't bits to be set, but values (albeit left-shifted). ORing the bits together gets the right answer, but we should use the _MASK macro here instead. Signed-off-by:
-
Paul Mackerras authored
BugLink: https://bugs.launchpad.net/bugs/1798770 [ Upstream commit 46dec40f ] This fixes a bug which causes guest virtual addresses to get translated to guest real addresses incorrectly when the guest is using the HPT MMU and has more than 256GB of RAM, or more specifically has a HPT larger than 2GB. This has showed up in testing as a failure of the host to emulate doorbell instructions correctly on POWER9 for HPT guests with more than 256GB of RAM. The bug is that the HPTE index in kvmppc_mmu_book3s_64_hv_xlate() is stored as an int, and in forming the HPTE address, the index gets shifted left 4 bits as an int before being signed-extended to 64 bits. The simple fix is to make the variable a long int, matching the return type of kvmppc_hv_find_lock_hpte(), which is what calculates the index. Fixes: 697d3899 ("KVM: PPC: Implement MMIO emulation support for Book3S HV guests") Signed-off-by:
Paul Mackerras <paulus@ozlabs.org> Signed-off-by:
-
Sakari Ailus authored
BugLink: https://bugs.launchpad.net/bugs/1798770 commit ad608fbc upstream. The event subscriptions are added to the subscribed event list while holding a spinlock, but that lock is subsequently released while still accessing the subscription object. This makes it possible to unsubscribe the event --- and freeing the subscription object's memory --- while the subscription object is simultaneously accessed. Prevent this by adding a mutex to serialise the event subscription and unsubscription. This also gives a guarantee to the callback ops that the add op has returned before the del op is called. This change also results in making the elems field less special: subscriptions are only added to the event list once they are fully initialised. Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by:
Hans Verkuil <hans.verkuil@cisco.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: stable@vger.kernel.org # for 4.14 and up Fixes: c3b5b024 ("V4L/DVB: V4L: Events: Add backend") Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Marc Zyngier authored
BugLink: https://bugs.launchpad.net/bugs/1798770 commit 2a3f9345 upstream. Not all execution modes are valid for a guest, and some of them depend on what the HW actually supports. Let's verify that what userspace provides is compatible with both the VM settings and the HW capabilities. Cc: <stable@vger.kernel.org> Fixes: 0d854a60 ("arm64: KVM: enable initialization of a 32bit vcpu") Reviewed-by:
Christoffer Dall <christoffer.dall@arm.com> Reviewed-by:
Mark Rutland <mark.rutland@arm.com> Reviewed-by:
Dave Martin <Dave.Martin@arm.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Suzuki K Poulose authored
BugLink: https://bugs.launchpad.net/bugs/1798770 commit 042446a3 upstream. Add cpu_hwcap bit for keeping track of the support for 32bit EL0. Tested-by:
Yury Norov <ynorov@caviumnetworks.com> Signed-off-by:
Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by:
-
Mika Westerberg authored
BugLink: https://bugs.launchpad.net/bugs/1798770 [ Upstream commit 7fd6d98b ] Commit 7ae81952cda ("i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI BAR") made it possible for AML code to access SMBus I/O ports by installing custom SystemIO OpRegion handler and blocking i80i driver access upon first AML read/write to this OpRegion. However, while ThinkPad T560 does have SystemIO OpRegion declared under the SMBus device, it does not access any of the SMBus registers: Device (SMBU) { ... OperationRegion (SMBP, PCI_Config, 0x50, 0x04) Field (SMBP, DWordAcc, NoLock, Preserve) { , 5, TCOB, 11, Offset (0x04) } Name (TCBV, 0x00) Method (TCBS, 0, NotSerialized) { If ((TCBV == 0x00)) { TCBV = (\_SB.PCI0.SMBU.TCOB << 0x05) } Return (TCBV) /* \_SB_.PCI0.SMBU.TCBV */ } OperationRegion (TCBA, SystemIO, TCBS (), 0x10) Field (TCBA, ByteAcc, NoLock, Preserve) { Offset (0x04), , 9, CPSC, 1 } } Problem with the current approach is that it blocks all I/O port access and because this system has touchpad connected to the SMBus controller after first AML access (happens during suspend/resume cycle) the touchpad fails to work anymore. Fix this so that we allow ACPI AML I/O port access if it does not touch the region reserved for the SMBus. Fixes: 7ae81952cda ("i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI BAR") Link: https://bugzilla.kernel.org/show_bug.cgi?id=200737Reported-by:
Yussuf Khalil <dev@pp3345.net> Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by:
Jean Delvare <jdelvare@suse.de> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1798770 [ Upstream commit f196dec6 ] The adt7475_read_word() function was meant to return negative error codes on failure. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Tokunori Ikegami <ikegami@allied-telesis.co.jp> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Lothar Felten authored
BugLink: https://bugs.launchpad.net/bugs/1798770 [ Upstream commit 3ad86700 ] fix the sysfs shunt resistor read access: return the shunt resistor value, not the calibration register contents. update email address Signed-off-by:
Lothar Felten <lothar.felten@gmail.com> Signed-off-by:
-
Bo Chen authored
BugLink: https://bugs.launchpad.net/bugs/1798770 [ Upstream commit ee400a3f ] In 'e1000_set_ringparam()', the tx_ring and rx_ring are updated with new value and the old tx/rx rings are freed only when the device is up. There are resource leaks on old tx/rx rings when the device is not up. This bug is reported by COD, a tool for testing kernel module binaries I am building. This patch fixes the bug by always calling 'kfree()' on old tx/rx rings in 'e1000_set_ringparam()'. Signed-off-by:
Bo Chen <chenbo@pdx.edu> Reviewed-by:
Alexander Duyck <alexander.h.duyck@intel.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Bo Chen authored
BugLink: https://bugs.launchpad.net/bugs/1798770 [ Upstream commit cf1acec0 ] When the device is not up, the call to 'e1000_up()' from the error handling path of 'e1000_set_ringparam()' causes a kernel oops with a null-pointer dereference. The null-pointer dereference is triggered in function 'e1000_alloc_rx_buffers()' at line 'buffer_info = &rx_ring->buffer_info[i]'. This bug was reported by COD, a tool for testing kernel module binaries I am building. This bug was also detected by KFI from Dr. Kai Cong. This patch fixes the bug by checking on 'netif_running()' before calling 'e1000_up()' in 'e1000_set_ringparam()'. Signed-off-by:
-
Huazhong Tan authored
BugLink: https://bugs.launchpad.net/bugs/1798770 [ Upstream commit 3ed614dc ] When enable the config item "CONFIG_ARM64_64K_PAGES", the size of PAGE_SIZE is 65536(64K). But the type of length and page_offset are u16, they will overflow. So change them to u32. Fixes: 6fe6611f ("net: add Hisilicon Network Subsystem hnae framework support") Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
Salil Mehta <salil.mehta@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Anson Huang authored
BugLink: https://bugs.launchpad.net/bugs/1798770 [ Upstream commit 152395fd ] When thermal zone is in passive mode, disabling its mode from sysfs is NOT taking effect at all, it is still polling the temperature of the disabled thermal zone and handling all thermal trips, it makes user confused. The disabling operation should disable the thermal zone behavior completely, for both active and passive mode, this patch clears the passive_delay when thermal zone is disabled and restores it when it is enabled. Signed-off-by:
Anson Huang <Anson.Huang@nxp.com> Signed-off-by:
Eduardo Valentin <edubezval@gmail.com> Signed-off-by:
-
Theodore Ts'o authored
BugLink: https://bugs.launchpad.net/bugs/1798770 commit 8cdb5240 upstream. When expanding the extra isize space, we must never move the system.data xattr out of the inode body. For performance reasons, it doesn't make any sense, and the inline data implementation assumes that system.data xattr is never in the external xattr block. This addresses CVE-2018-10880 https://bugzilla.kernel.org/show_bug.cgi?id=200005Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by:
Zubin Mithra <zsm@chromium.org> Signed-off-by:
-
Dave Martin authored
BugLink: https://bugs.launchpad.net/bugs/1798770 commit d26c25a9 upstream. We currently allow userspace to access the core register file in about any possible way, including straddling multiple registers and doing unaligned accesses. This is not the expected use of the ABI, and nobody is actually using it that way. Let's tighten it by explicitly checking the size and alignment for each field of the register file. Cc: <stable@vger.kernel.org> Fixes: 2f4a07c5 ("arm64: KVM: guest one-reg interface") Reviewed-by:
-
Uwe Kleine-König authored
BugLink: https://bugs.launchpad.net/bugs/1798770 commit 7e620984 upstream. Back in 2015 when irda was dropped from the driver imx1 was broken. This change reintroduces the support for the third interrupt of the UART. Fixes: afe9cbb1 ("serial: imx: drop support for IRDA") Cc: stable <stable@vger.kernel.org> Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by:
Leonard Crestez <leonard.crestez@nxp.com> Signed-off-by:
-
Vincent Pelletier authored
BugLink: https://bugs.launchpad.net/bugs/1798770 commit 8c39e269 upstream. Signed-off-by:
Vincent Pelletier <plr.vincent@gmail.com> Reviewed-by:
Mike Christie <mchristi@redhat.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> [plr.vincent@gmail.com: hunk context change for 4.4 and 4.9, no code change] Signed-off-by:
-
Bart Van Assche authored
BugLink: https://bugs.launchpad.net/bugs/1798770 commit ee92efe4 upstream. Use different loop variables for the inner and outer loop. This avoids that an infinite loop occurs if there are more RDMA channels than target->req_ring_size. Fixes: d92c0da7 ("IB/srp: Add multichannel support") Cc: <stable@vger.kernel.org> Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Aaron Ma authored
BugLink: https://bugs.launchpad.net/bugs/1798770 commit 91a97507 upstream. Adding 2 new touchpad IDs to support middle button support. Cc: stable@vger.kernel.org Signed-off-by:
Aaron Ma <aaron.ma@canonical.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Alan Stern authored
BugLink: https://bugs.launchpad.net/bugs/1798770 commit c183813f upstream. usb_driver_claim_interface() disables and re-enables Link Power Management, but it shouldn't do either one, for the reasons listed below. This patch removes the two LPM-related function calls from the routine. The reason for disabling LPM in the analogous function usb_probe_interface() is so that drivers won't have to deal with unwanted LPM transitions in their probe routine. But usb_driver_claim_interface() doesn't call the driver's probe routine (or any other callbacks), so that reason doesn't apply here. Furthermore, no driver other than usbfs will ever call usb_driver_claim_interface() unless it is already bound to another interface in the same device, which means disabling LPM here would be redundant. usbfs doesn't interact with LPM at all. Lastly, the error return from usb_unlocked_disable_lpm() isn't handled properly; the code doesn't clean up its earlier actions before returning. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Fixes: 8306095f ("USB: Disable USB 3.0 LPM in critical sections.") CC: <stable@vger.kernel.org> Signed-off-by:
-
Sebastian Andrzej Siewior authored
BugLink: https://bugs.launchpad.net/bugs/1798770 commit e871db8d upstream. This reverts commit 6e22e3af. The bug the patch describes to, has been already fixed in commit 2df69484 ("USB: cdc-wdm: don't enable interrupts in USB-giveback") so need to this, revert it. Fixes: 6e22e3af ("usb: cdc-wdm: Fix a sleep-in-atomic-context bug in service_outstanding_interrupt()") Cc: stable <stable@vger.kernel.org> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Oliver Neukum authored
BugLink: https://bugs.launchpad.net/bugs/1798770 commit 81e0403b upstream. If we filter flags before they reach the core we need to generate our own warnings. Signed-off-by:
Oliver Neukum <oneukum@suse.com> Fixes: 0cb54a3e ("USB: debugging code shouldn't alter control flow") Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Oliver Neukum authored
BugLink: https://bugs.launchpad.net/bugs/1798770 commit 7a68d9fb upstream. Requesting a ZERO_PACKET or not is sensible only for output. In the input direction the device decides. Likewise accepting short packets makes sense only for input. This allows operation with panic_on_warn without opening up a local DOS. Signed-off-by:
-
ming_qian authored
BugLink: https://bugs.launchpad.net/bugs/1798770 commit f620d1d7 upstream. media: uvcvideo: Support UVC 1.5 video probe & commit controls The length of UVC 1.5 video control is 48, and it is 34 for UVC 1.1. Change it to 48 for UVC 1.5 device, and the UVC 1.5 device can be recognized. More changes to the driver are needed for full UVC 1.5 compatibility. However, at least the UVC 1.5 Realtek RTS5847/RTS5852 cameras have been reported to work well. [laurent.pinchart@ideasonboard.com: Factor out code to helper function, update size checks] Cc: stable@vger.kernel.org Signed-off-by:
ming_qian <ming_qian@realsil.com.cn> Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by:
Ana Guerrero Lopez <ana.guerrero@collabora.com> Signed-off-by:
-
Stefan Bader authored
This reverts commit b1b1d467 to be replaced by the upstream stable variant. BugLink: https://bugs.launchpad.net/bugs/1798770Signed-off-by:
-
Alexey Dobriyan authored
BugLink: https://bugs.launchpad.net/bugs/1798770 commit e5d9998f upstream. /* * cpu_partial determined the maximum number of objects * kept in the per cpu partial lists of a processor. */ Can't be negative. Link: http://lkml.kernel.org/r/20180305200730.15812-15-adobriyan@gmail.comSigned-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Acked-by:
Christoph Lameter <cl@linux.com> Cc: Pekka Enberg <penberg@kernel.org> Cc: David Rientjes <rientjes@google.com> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
zhong jiang <zhongjiang@huawei.com> Signed-off-by:
-
Alan Stern authored
BugLink: https://bugs.launchpad.net/bugs/1798770 commit c9a4cb20 upstream. usb_find_alt_setting() takes a pointer to a struct usb_host_config as an argument; it searches for an interface with specified interface and alternate setting numbers in that config. However, it crashes if the usb_host_config pointer argument is NULL. Since this is a general-purpose routine, available for use in many places, we want to to be more robust. This patch makes it return NULL whenever the config argument is NULL. Signed-off-by:
-
Alan Stern authored
BugLink: https://bugs.launchpad.net/bugs/1798770 commit bd729f9d upstream. The syzbot fuzzing project found a use-after-free bug in the USB core. The bug was caused by usbfs not unbinding from an interface when the USB device file was closed, which led another process to attempt the unbind later on, after the private data structure had been deallocated. The reason usbfs did not unbind the interface at the appropriate time was because it thought the interface had never been claimed in the first place. This was caused by the fact that usb_driver_claim_interface() does not clean up properly when device_bind_driver() returns an error. Although the error code gets passed back to the caller, the iface->dev.driver pointer remains set and iface->condition remains equal to USB_INTERFACE_BOUND. This patch adds proper error handling to usb_driver_claim_interface(). Signed-off-by:
-
Geert Uytterhoeven authored
BugLink: https://bugs.launchpad.net/bugs/1798770 commit 8dbbaa47 upstream. When interrupted, wait_event_interruptible_timeout() returns -ERESTARTSYS, and the SPI transfer in progress will fail, as expected: m25p80 spi0.0: SPI transfer failed: -512 spi_master spi0: failed to transfer one message from queue However, as the underlying DMA transfers may not have completed, all subsequent SPI transfers may start to fail: spi_master spi0: receive timeout qspi_transfer_out_in() returned -110 m25p80 spi0.0: SPI transfer failed: -110 spi_master spi0: failed to transfer one message from queue Fix this by calling dmaengine_terminate_all() not only for timeouts, but also for errors. This can be reproduced on r8a7991/koelsch, using "hd /dev/mtd0" followed by CTRL-C. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by:
-
Geert Uytterhoeven authored
BugLink: https://bugs.launchpad.net/bugs/1798770 commit c1ca59c2 upstream. If the SPI queue is running during system suspend, the system may lock up. Fix this by stopping/restarting the queue during system suspend/resume, by calling spi_master_suspend()/spi_master_resume() from the PM callbacks. In-kernel users will receive an -ESHUTDOWN error while system suspend/resume is in progress. Based on a patch for sh-msiof by Gaku Inami. Signed-off-by:
-
Hiromitsu Yamasaki authored
BugLink: https://bugs.launchpad.net/bugs/1798770 commit 31a5fae4 upstream. This patch changes writing to the SISTR register according to the H/W user's manual. The TDREQ bit and RDREQ bits of SISTR are read-only, and must be written their initial values of zero. Signed-off-by:
Hiromitsu Yamasaki <hiromitsu.yamasaki.ym@renesas.com> [geert: reword] Signed-off-by:
-
Gaku Inami authored
BugLink: https://bugs.launchpad.net/bugs/1798770 commit ffa69d6a upstream. If the SPI queue is running during system suspend, the system may lock up. Fix this by stopping/restarting the queue during system suspend/resume by calling spi_master_suspend()/spi_master_resume() from the PM callbacks. In-kernel users will receive an -ESHUTDOWN error while system suspend/resume is in progress. Signed-off-by:
Gaku Inami <gaku.inami.xw@bp.renesas.com> Signed-off-by:
-
Marcel Ziswiler authored
BugLink: https://bugs.launchpad.net/bugs/1798770 commit 7001cab1 upstream. Depending on the SPI instance one may get an interrupt storm upon requesting resp. interrupt unless the clock is explicitly enabled beforehand. This has been observed trying to bring up instance 4 on T20. Signed-off-by:
Marcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by:
-
Christophe Leroy authored
BugLink: https://bugs.launchpad.net/bugs/1798770 commit be28c1e3 upstream. kgdb expects poll function to return immediately and returning NO_POLL_CHAR when no character is available. Fixes: f5316b4a ("kgdb,8250,pl011: Return immediately from console poll") Cc: Jason Wessel <jason.wessel@windriver.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by:
-
Andy Whitcroft authored
BugLink: https://bugs.launchpad.net/bugs/1798770 commit 65eea8ed upstream. The final field of a floppy_struct is the field "name", which is a pointer to a string in kernel memory. The kernel pointer should not be copied to user memory. The FDGETPRM ioctl copies a floppy_struct to user memory, including this "name" field. This pointer cannot be used by the user and it will leak a kernel address to user-space, which will reveal the location of kernel code and data and undermine KASLR protection. Model this code after the compat ioctl which copies the returned data to a previously cleared temporary structure on the stack (excluding the name pointer) and copy out to userspace from there. As we already have an inparam union with an appropriate member and that memory is already cleared even for read only calls make use of that as a temporary store. Based on an initial patch by Brian Belleville. CVE-2018-7755 Signed-off-by:
Andy Whitcroft <apw@canonical.com> Broke up long line. Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Kevin Hilman authored
BugLink: https://bugs.launchpad.net/bugs/1798770 [ Upstream commit 949bdcc8 ] Fix the DT node addresses to match the reg property addresses, which were verified to match the TRM: http://www.ti.com/lit/pdf/sprui30 Cc: Roger Quadros <rogerq@ti.com> Signed-off-by:
Kevin Hilman <khilman@baylibre.com> Acked-by:
Roger Quadros <rogerq@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
J. Bruce Fields authored
BugLink: https://bugs.launchpad.net/bugs/1798770 [ Upstream commit 5b7b15ae ] We're encoding a single op in the reply but leaving the number of ops zero, so the reply makes no sense. Somewhat academic as this isn't a case any real client will hit, though in theory perhaps that could change in a future protocol extension. Reviewed-by:
Jeff Layton <jlayton@kernel.org> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Jessica Yu authored
BugLink: https://bugs.launchpad.net/bugs/1798770 [ Upstream commit 9f2d1e68 ] Livepatch modules are special in that we preserve their entire symbol tables in order to be able to apply relocations after module load. The unwanted side effect of this is that undefined (SHN_UNDEF) symbols of livepatch modules are accessible via the kallsyms api and this can confuse symbol resolution in livepatch (klp_find_object_symbol()) and cause subtle bugs in livepatch. Have the module kallsyms api skip over SHN_UNDEF symbols. These symbols are usually not available for normal modules anyway as we cut down their symbol tables to just the core (non-undefined) symbols, so this should really just affect livepatch modules. Note that this patch doesn't affect the display of undefined symbols in /proc/kallsyms. Reported-by:
Josh Poimboeuf <jpoimboe@redhat.com> Tested-by:
Jessica Yu <jeyu@kernel.org> Signed-off-by:
-
