02 Jun, 2016
40 commits
-
commit 107e15fc1f8d6ef69eac5f175971252f76e82f0d upstream.
Unlike Intel Medfield and Tangier platforms DNV uses PCI BAR0 for IO compatible
resources and BAR1 for MMIO. We need latter in a way to support DMA. Introduce
an additional field in the internal structure and pass PCI BAR based on device
ID.Reported-by: "Lai, Poey Seng"
Fixes: 6ede6dcd87aa ("serial: 8250_mid: add support for DMA engine handling from UART MMIO")
Reviewed-by: Heikki Krogerus
Signed-off-by: Andy Shevchenko
Signed-off-by: Greg Kroah-Hartman -
commit 6f210c18c1c0f016772c8cd51ae12a02bfb9e7ef upstream.
Since commit 21947ba654a6 ("serial: 8250_pci: replace switch-case by
formula"), the 8250 driver crashes in the byt_set_termios() function
with a divide error. This is caused by the fact that a baud rate of 0 (B0)
is not handled properly. Fix it by falling back to B9600 in this case.Signed-off-by: David Müller
Fixes: 21947ba654a6 ("serial: 8250_pci: replace switch-case by formula")
Suggested-by: Andy Shevchenko
Reviewed-by: Andy Shevchenko
Signed-off-by: Greg Kroah-Hartman -
commit 0f40fbbcc34e093255a2b2d70b6b0fb48c3f39aa upstream.
OpenSSH expects the (non-blocking) read() of pty master to return
EAGAIN only if it has received all of the slave-side output after
it has received SIGCHLD. This used to work on pre-3.12 kernels.This fix effectively forces non-blocking read() and poll() to
block for parallel i/o to complete for all ttys. It also unwinds
these changes:1) f8747d4a466ab2cafe56112c51b3379f9fdb7a12
tty: Fix pty master read() after slave closes2) 52bce7f8d4fc633c9a9d0646eef58ba6ae9a3b73
pty, n_tty: Simplify input processing on final close3) 1a48632ffed61352a7810ce089dc5a8bcd505a60
pty: Fix input race when closingInspired by analysis and patch from Marc Aurele La France
Reported-by: Volth
Reported-by: Marc Aurele La France
BugLink: https://bugzilla.mindrot.org/show_bug.cgi?id=52
BugLink: https://bugzilla.mindrot.org/show_bug.cgi?id=2492
Signed-off-by: Brian Bloniarz
Reviewed-by: Peter Hurley
Signed-off-by: Greg Kroah-Hartman -
commit 5be605ac9af979265d7b64c160ad9928088a78be upstream.
Commit 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when
hardware handshake is enabled") actually allowed to enable hardware
handshaking.
Before, the CRTSCTS flags was silently ignored.As the DMA controller can't drive RTS (as explain in the commit message).
Ensure that hardware flow control stays disabled when DMA is used and FIFOs
are not available.Signed-off-by: Alexandre Belloni
Acked-by: Nicolas Ferre
Fixes: 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when hardware handshake is enabled")
Signed-off-by: Greg Kroah-Hartman -
commit d175feca89a1c162f60f4e3560ca7bc9437c65eb upstream.
Dmitry reported, that the current cleanup code in n_gsm can trigger a
warning:
WARNING: CPU: 2 PID: 24238 at drivers/tty/n_gsm.c:2048 gsm_cleanup_mux+0x166/0x6b0()
...
Call Trace:
...
[] warn_slowpath_null+0x29/0x30 kernel/panic.c:490
[] gsm_cleanup_mux+0x166/0x6b0 drivers/tty/n_gsm.c:2048
[] gsmld_open+0x5b7/0x7a0 drivers/tty/n_gsm.c:2386
[] tty_ldisc_open.isra.2+0x78/0xd0 drivers/tty/tty_ldisc.c:447
[] tty_set_ldisc+0x1ca/0xa70 drivers/tty/tty_ldisc.c:567
[< inline >] tiocsetd drivers/tty/tty_io.c:2650
[] tty_ioctl+0xb2a/0x2140 drivers/tty/tty_io.c:2883
...But this is a legal path when open fails to find a space in the
gsm_mux array and tries to clean up. So make it a standard test
instead of a warning.Reported-by: "Dmitry Vyukov"
Cc: Alan Cox
Link: http://lkml.kernel.org/r/CACT4Y+bHQbAB68VFi7Romcs-Z9ZW3kQRvcq+BvHH1oa5NcAdLA@mail.gmail.com
Fixes: 5a640967 ("tty/n_gsm.c: fix a memory leak in gsmld_open()")
Signed-off-by: Jiri Slaby
Signed-off-by: Greg Kroah-Hartman -
commit 6798df4c5fe0a7e6d2065cf79649a794e5ba7114 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 3e795de763.
Before that we used to return -ENODEV.So fix the return value to be -ENODEV in that case again.
Fixes: 3e795de763 ("VT binding: Add binding/unbinding support for the VT console")
Signed-off-by: Jiri Slaby
Reported-by: "Dan Carpenter"
Signed-off-by: Greg Kroah-Hartman -
commit 702f926067d2a4b28c10a3c41a1172dd62d9e735 upstream.
b4ff8389ed14 is incomplete: relies on nr_legacy_irqs() to get the number
of legacy interrupts when actually nr_legacy_irqs() returns 0 after
probe_8259A(). Use NR_IRQS_LEGACY instead.Signed-off-by: Stefano Stabellini
Signed-off-by: Greg Kroah-Hartman -
commit 316314cae15fb0e3869b76b468f59a0c83ac3d4e upstream.
This ensures that the guest doesn't see XSAVE extensions
(e.g. xgetbv1 or xsavec) that the host lacks.Cc: stable@vger.kernel.org
Reviewed-by: Radim Krčmář
[4.5 does have CPUID_D_1_EAX, but earlier kernels don't, so use
the numeric value. This is consistent with other occurrences
of cpuid_mask in arch/x86/kvm/cpuid.c - Paolo]
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman -
commit b45bacd2d048f405c7760e5cc9b60dd67708734f upstream.
Writing CP0_Compare clears the timer interrupt pending bit
(CP0_Cause.TI), but this wasn't being done atomically. If a timer
interrupt raced with the write of the guest CP0_Compare, the timer
interrupt could end up being pending even though the new CP0_Compare is
nowhere near CP0_Count.We were already updating the hrtimer expiry with
kvm_mips_update_hrtimer(), which used both kvm_mips_freeze_hrtimer() and
kvm_mips_resume_hrtimer(). Close the race window by expanding out
kvm_mips_update_hrtimer(), and clearing CP0_Cause.TI and setting
CP0_Compare between the freeze and resume. Since the pending timer
interrupt should not be cleared when CP0_Compare is written via the KVM
user API, an ack argument is added to distinguish the source of the
write.Fixes: e30492bbe95a ("MIPS: KVM: Rewrite count/compare timer emulation")
Signed-off-by: James Hogan
Cc: Paolo Bonzini
Cc: "Radim KrÄmář"
Cc: Ralf Baechle
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman -
commit 4355c44f063d3de4f072d796604c7f4ba4085cc3 upstream.
There's a particularly narrow and subtle race condition when the
software emulated guest timer is frozen which can allow a guest timer
interrupt to be missed.This happens due to the hrtimer expiry being inexact, so very
occasionally the freeze time will be after the moment when the emulated
CP0_Count transitions to the same value as CP0_Compare (so an IRQ should
be generated), but before the moment when the hrtimer is due to expire
(so no IRQ is generated). The IRQ won't be generated when the timer is
resumed either, since the resume CP0_Count will already match CP0_Compare.With VZ guests in particular this is far more likely to happen, since
the soft timer may be frozen frequently in order to restore the timer
state to the hardware guest timer. This happens after 5-10 hours of
guest soak testing, resulting in an overflow in guest kernel timekeeping
calculations, hanging the guest. A more focussed test case to
intentionally hit the race (with the help of a new hypcall to cause the
timer state to migrated between hardware & software) hits the condition
fairly reliably within around 30 seconds.Instead of relying purely on the inexact hrtimer expiry to determine
whether an IRQ should be generated, read the guest CP0_Compare and
directly check whether the freeze time is before or after it. Only if
CP0_Count is on or after CP0_Compare do we check the hrtimer expiry to
determine whether the last IRQ has already been generated (which will
have pushed back the expiry by one timer period).Fixes: e30492bbe95a ("MIPS: KVM: Rewrite count/compare timer emulation")
Signed-off-by: James Hogan
Cc: Paolo Bonzini
Cc: "Radim KrÄmář"
Cc: Ralf Baechle
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman -
commit f24632475d4ffed5626abbfab7ef30a128dd1474 upstream.
Commit d28bc9dd25ce reversed the order of two lines which initialize cr0,
allowing the current (old) cr0 value to mess up vcpu initialization.
This was observed in the checks for cr0 X86_CR0_WP bit in the context of
kvm_mmu_reset_context(). Besides, setting vcpu->arch.cr0 after vmx_set_cr0()
is completely redundant. Change the order back to ensure proper vcpu
initialization.The combination of booting with ovmf firmware when guest vcpus > 1 and kvm's
ept=N option being set results in a VM-entry failure. This patch fixes that.Fixes: d28bc9dd25ce ("KVM: x86: INIT and reset sequences are different")
Signed-off-by: Bruce Rogers
Signed-off-by: Radim Krčmář
Signed-off-by: Greg Kroah-Hartman -
commit 9842df62004f366b9fed2423e24df10542ee0dc5 upstream.
MSR 0x2f8 accessed the 124th Variable Range MTRR ever since MTRR support
was introduced by 9ba075a664df ("KVM: MTRR support").0x2f8 became harmful when 910a6aae4e2e ("KVM: MTRR: exactly define the
size of variable MTRRs") shrinked the array of VR MTRRs from 256 to 8,
which made access to index 124 out of bounds. The surrounding code only
WARNs in this situation, thus the guest gained a limited read/write
access to struct kvm_arch_vcpu.0x2f8 is not a valid VR MTRR MSR, because KVM has/advertises only 16 VR
MTRR MSRs, 0x200-0x20f. Every VR MTRR is set up using two MSRs, 0x2f8
was treated as a PHYSBASE and 0x2f9 would be its PHYSMASK, but 0x2f9 was
not implemented in KVM, therefore 0x2f8 could never do anything useful
and getting rid of it is safe.This fixes CVE-2016-3713.
Fixes: 910a6aae4e2e ("KVM: MTRR: exactly define the size of variable MTRRs")
Reported-by: David Matlack
Signed-off-by: Andy Honig
Signed-off-by: Radim Krčmář
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman -
commit d375278d666760e195693b57415ba0a125cadd55 upstream.
DMA is optional with this driver. If it was not enabled the devpriv->dma
pointer will be NULL.Fix the possible NULL pointer dereference when trying to disable the DMA
channels in das1800_ai_cancel() and tidy up the comments to fix the
checkpatch.pl issues:
WARNING: line over 80 charactersIt's probably harmless in das1800_ai_setup_dma() because the 'desc' pointer
will not be used if DMA is disabled but fix it there also.Fixes: 99dfc3357e98 ("staging: comedi: das1800: remove depends on ISA_DMA_API limitation")
Signed-off-by: H Hartley Sweeten
Reviewed-by: Ian Abbott
Signed-off-by: Greg Kroah-Hartman -
commit 5096c4d3bfa75bdd23c78f799aabd08598afb48f upstream.
The argument of dev_err() in usb_gadget_map_request() should be dev
instead of &gadget->dev.Fixes: 7ace8fc ("usb: gadget: udc: core: Fix argument of dma_map_single for IOMMU")
Signed-off-by: Yoshihiro Shimoda
Signed-off-by: Greg Kroah-Hartman -
commit 6fb650d43da3e7054984dc548eaa88765a94d49f upstream.
When a USB driver is bound to an interface (either through probing or
by claiming it) or is unbound from an interface, the USB core always
disables Link Power Management during the transition and then
re-enables it afterward. The reason is because the driver might want
to prevent hub-initiated link power transitions, in which case the HCD
would have to recalculate the various LPM parameters. This
recalculation takes place when LPM is re-enabled and the new
parameters are sent to the device and its parent hub.However, if the driver does not want to prevent hub-initiated link
power transitions then none of this work is necessary. The parameters
don't need to be recalculated, and LPM doesn't need to be disabled and
re-enabled.It turns out that disabling and enabling LPM can be time-consuming,
enough so that it interferes with user programs that want to claim and
release interfaces rapidly via usbfs. Since the usbfs kernel driver
doesn't set the disable_hub_initiated_lpm flag, we can speed things up
and get the user programs to work by leaving LPM alone whenever the
flag isn't set.And while we're improving the way disable_hub_initiated_lpm gets used,
let's also fix its kerneldoc.Signed-off-by: Alan Stern
Tested-by: Matthew Giassa
CC: Mathias Nyman
Signed-off-by: Greg Kroah-Hartman -
commit cdc77c82a8286b1181b81b6e5ef60c8e83ded7bc upstream.
The current implemenentation restart the sent pattern for each entry in
the sg list. The receiving end expects a continuous pattern, and test
will fail unless scatterilst entries happen to be aligned with the
patternFix this by calculating the pattern byte based on total sent size
instead of just the current sg entry.Signed-off-by: Mathias Nyman
Fixes: 8b5249019352 ("[PATCH] USB: usbtest: scatterlist OUT data pattern testing")
Acked-by: Felipe Balbi
Acked-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
commit f78bbcae86e676fad9e6c6bb6cd9d9868ba23696 upstream.
When binding the function to usb_configuration, check whether the thread
is running before starting another one. Without that, when function
instance is added to multiple configurations, fsg_bing starts multiple
threads with all but the latest one being forgotten by the driver. This
leads to obvious thread leaks, possible lockups when trying to halt the
machine and possible more issues.This fixes issues with legacy/multi¹ gadget as well as configfs gadgets
when mass_storage function is added to multiple configurations.This change also simplifies API since the legacy gadgets no longer need
to worry about starting the thread by themselves (which was where bug
in legacy/multi was in the first place).N.B., this patch doesn’t address adding single mass_storage function
instance to a single configuration twice. Thankfully, there’s no
legitimate reason for such setup plus, if I’m not mistaken, configfs
gadget doesn’t even allow it to be expressed.¹ I have no example failure though. Conclusion that legacy/multi has
a bug is based purely on me reading the code.Acked-by: Alan Stern
Signed-off-by: Michal Nazarewicz
Tested-by: Ivaylo Dimitrov
Cc: Alan Stern
Signed-off-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman -
commit 332a5b446b7916d272c2a659a3b20909ce34d2c1 upstream.
In the current implementation functionfs generates a EFAULT for async read
operations if the read buffer size is larger than the URB data size. Since
a application does not necessarily know how much data the host side is
going to send it typically supplies a buffer larger than the actual data,
which will then result in a EFAULT error.This behaviour was introduced while refactoring the code to use iov_iter
interface in commit c993c39b8639 ("gadget/function/f_fs.c: use put iov_iter
into io_data"). The original code took the minimum over the URB size and
the user buffer size and then attempted to copy that many bytes using
copy_to_user(). If copy_to_user() could not copy all data a EFAULT error
was generated. Restore the original behaviour by only generating a EFAULT
error when the number of bytes copied is not the size of the URB and the
target buffer has not been fully filled.Commit 342f39a6c8d3 ("usb: gadget: f_fs: fix check in read operation")
already fixed the same problem for the synchronous read path.Fixes: c993c39b8639 ("gadget/function/f_fs.c: use put iov_iter into io_data")
Acked-by: Michal Nazarewicz
Signed-off-by: Lars-Peter Clausen
Signed-off-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman -
commit 74d2a91aec97ab832790c9398d320413ad185321 upstream.
Add even more ZTE device ids.
Signed-off-by: lei liu
[johan: rebase and replace commit message ]
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman -
commit f0d09463c59c2d764a6c6d492cbe6d2c77f27153 upstream.
More ZTE device ids.
Signed-off-by: lei liu
[properly sort them - gregkh]
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman -
commit 444f94e9e625f6ec6bbe2cb232a6451c637f35a3 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
[johan: sort current entries and trim trailing whitespace ]
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman -
commit c8d62957d450cc1a22ce3242908709fe367ddc8e 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: f9c99bb8b3a1 ("USB: usb-serial: replace shutdown with disconnect,
release")
Signed-off-by: Johan Hovold
Acked-by: Greg Kroah-Hartman
Signed-off-by: Greg Kroah-Hartman -
commit c5c0c55598cefc826d6cfb0a417eeaee3631715c upstream.
Private data, URBs and buffers allocated for Epic devices during
attach were never released on errors (e.g. missing endpoints).Fixes: 6e8cf7751f9f ("USB: add EPIC support to the io_edgeport driver")
Signed-off-by: Johan Hovold
Acked-by: Greg Kroah-Hartman
Signed-off-by: Greg Kroah-Hartman -
commit 028c49f5e02a257c94129cd815f7c8485f51d4ef 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: f7a33e608d9a ("USB: serial: add quatech2 usb to serial driver")
Signed-off-by: Johan Hovold
Acked-by: Greg Kroah-Hartman
Signed-off-by: Greg Kroah-Hartman -
commit 35be1a71d70775e7bd7e45fa6d2897342ff4c9d2 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: f9c99bb8b3a1 ("USB: usb-serial: replace shutdown with disconnect,
release")
Signed-off-by: Johan Hovold
Acked-by: Greg Kroah-Hartman
Signed-off-by: Greg Kroah-Hartman -
commit 9e45284984096314994777f27e1446dfbfd2f0d7 upstream.
The interface read and event URBs are submitted in attach, but were
never explicitly unlinked by the driver. Instead the URBs would have
been killed by usb-serial core on disconnect.In case of a late probe error (e.g. due to failed minor allocation),
disconnect is never called and we could end up with active URBs for an
unbound interface. This in turn could lead to deallocated memory being
dereferenced in the completion callbacks.Fixes: ee467a1f2066 ("USB: serial: add Moxa UPORT 12XX/14XX/16XX
driver")
Signed-off-by: Johan Hovold
Acked-by: Greg Kroah-Hartman
Signed-off-by: Greg Kroah-Hartman -
commit bc46b45a421a64a0895dd41a34d3d2086e1ac7f6 upstream.
Ensure that mei_cl_read_start is called under the device lock
also in the bus layer. The function updates global ctrl_wr_list
which should be locked.Signed-off-by: Alexander Usyskin
Signed-off-by: Tomas Winkler
Signed-off-by: Greg Kroah-Hartman -
commit 9d04ee11db7bf0d848266cbfd7db336097a0e239 upstream.
When a message is received and amthif client is not in reading state
the message is ignored and left dangling in the queue. This may happen
after one of the amthif host connections is closed w/o completing the
reading. Another client will pick up a wrong message on next read
attempt which will lead to link reset.
To prevent this the driver has to properly discard the message when
amthif client is not in reading state.Signed-off-by: Alexander Usyskin
Signed-off-by: Tomas Winkler
Signed-off-by: Greg Kroah-Hartman -
commit 6a8d648c8d1824117a9e9edb948ed1611fb013c0 upstream.
In the case when disconnection is initiated from the FW
the driver is flushing items from the write control list while
iterating over it:mei_irq_write_handler()
list_for_each_entry_safe(ctrl_wr_list)
Signed-off-by: Tomas Winkler
Signed-off-by: Greg Kroah-Hartman -
commit c7c999cb18da88a881e10e07f0724ad0bfaff770 upstream.
hci_vhci driver creates a hci device object dynamically upon each
HCI_VENDOR_PKT write. Although it checks the already created object
and returns an error, it's still racy and may build multiple hci_dev
objects concurrently when parallel writes are performed, as the device
tracks only a single hci_dev object.This patch introduces a mutex to protect against the concurrent device
creations.Signed-off-by: Takashi Iwai
Signed-off-by: Marcel Holtmann
Signed-off-by: Greg Kroah-Hartman -
commit 13407376b255325fa817798800117a839f3aa055 upstream.
The write handler allocates skbs and queues them into data->readq.
Read side should read them, if there is any. If there is none, skbs
should be dropped by hdev->flush. But this happens only if the device
is HCI_UP, i.e. hdev->power_on work was triggered already. When it was
not, skbs stay allocated in the queue when /dev/vhci is closed. So
purge the queue in ->release.Program to reproduce:
#include
#include
#include
#include#include
#include
#includeint main()
{
char buf[] = { 0xff, 0 };
struct iovec iov = {
.iov_base = buf,
.iov_len = sizeof(buf),
};
int fd;while (1) {
fd = open("/dev/vhci", O_RDWR);
if (fd < 0)
err(1, "open");usleep(50);
if (writev(fd, &iov, 1) < 0)
err(1, "writev");usleep(50);
close(fd);
}return 0;
}Result:
kmemleak: 4609 new suspected memory leaks
unreferenced object 0xffff88059f4d5440 (size 232):
comm "vhci", pid 1084, jiffies 4294912542 (age 37569.296s)
hex dump (first 32 bytes):
20 f0 23 87 05 88 ff ff 20 f0 23 87 05 88 ff ff .#..... .#.....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
...
[] __alloc_skb+0x0/0x5a0
[] vhci_create_device+0x5c/0x580 [hci_vhci]
[] vhci_write+0x306/0x4c8 [hci_vhci]Fixes: 23424c0d31 (Bluetooth: Add support creating virtual AMP controllers)
Signed-off-by: Jiri Slaby
Signed-off-by: Marcel Holtmann
Signed-off-by: Greg Kroah-Hartman -
commit 373a32c848ae3a1c03618517cce85f9211a6facf upstream.
Both vhci_get_user and vhci_release race with open_timeout work. They
both contain cancel_delayed_work_sync, but do not test whether the
work actually created hdev or not. Since the work can be in progress
and _sync will wait for finishing it, we can have data->hdev allocated
when cancel_delayed_work_sync returns. But the call sites do 'if
(data->hdev)' *before* cancel_delayed_work_sync.As a result:
* vhci_get_user allocates a second hdev and puts it into
data->hdev. The former is leaked.
* vhci_release does not release data->hdev properly as it thinks there
is none.Fix both cases by moving the actual test *after* the call to
cancel_delayed_work_sync.This can be hit by this program:
#include
#include
#include
#include
#include
#include#include
#includeint main(int argc, char **argv)
{
int fd;srand(time(NULL));
while (1) {
const int delta = (rand() % 200 - 100) * 100;fd = open("/dev/vhci", O_RDWR);
if (fd < 0)
err(1, "open");usleep(1000000 + delta);
close(fd);
}return 0;
}And the result is:
BUG: KASAN: use-after-free in skb_queue_tail+0x13e/0x150 at addr ffff88006b0c1228
Read of size 8 by task kworker/u13:1/32068
=============================================================================
BUG kmalloc-192 (Tainted: G E ): kasan: bad access detected
-----------------------------------------------------------------------------Disabling lock debugging due to kernel taint
INFO: Allocated in vhci_open+0x50/0x330 [hci_vhci] age=260 cpu=3 pid=32040
...
kmem_cache_alloc_trace+0x150/0x190
vhci_open+0x50/0x330 [hci_vhci]
misc_open+0x35b/0x4e0
chrdev_open+0x23b/0x510
...
INFO: Freed in vhci_release+0xa4/0xd0 [hci_vhci] age=9 cpu=2 pid=32040
...
__slab_free+0x204/0x310
vhci_release+0xa4/0xd0 [hci_vhci]
...
INFO: Slab 0xffffea0001ac3000 objects=16 used=13 fp=0xffff88006b0c1e00 flags=0x5fffff80004080
INFO: Object 0xffff88006b0c1200 @offset=4608 fp=0xffff88006b0c0600
Bytes b4 ffff88006b0c11f0: 09 df 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................
Object ffff88006b0c1200: 00 06 0c 6b 00 88 ff ff 00 00 00 00 00 00 00 00 ...k............
Object ffff88006b0c1210: 10 12 0c 6b 00 88 ff ff 10 12 0c 6b 00 88 ff ff ...k.......k....
Object ffff88006b0c1220: c0 46 c2 6b 00 88 ff ff c0 46 c2 6b 00 88 ff ff .F.k.....F.k....
Object ffff88006b0c1230: 01 00 00 00 01 00 00 00 e0 ff ff ff 0f 00 00 00 ................
Object ffff88006b0c1240: 40 12 0c 6b 00 88 ff ff 40 12 0c 6b 00 88 ff ff @..k....@..k....
Object ffff88006b0c1250: 50 0d 6e a0 ff ff ff ff 00 02 00 00 00 00 ad de P.n.............
Object ffff88006b0c1260: 00 00 00 00 00 00 00 00 ab 62 02 00 01 00 00 00 .........b......
Object ffff88006b0c1270: 90 b9 19 81 ff ff ff ff 38 12 0c 6b 00 88 ff ff ........8..k....
Object ffff88006b0c1280: 03 00 20 00 ff ff ff ff ff ff ff ff 00 00 00 00 .. .............
Object ffff88006b0c1290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Object ffff88006b0c12a0: 00 00 00 00 00 00 00 00 00 80 cd 3d 00 88 ff ff ...........=....
Object ffff88006b0c12b0: 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 . ..............
Redzone ffff88006b0c12c0: bb bb bb bb bb bb bb bb ........
Padding ffff88006b0c13f8: 00 00 00 00 00 00 00 00 ........
CPU: 3 PID: 32068 Comm: kworker/u13:1 Tainted: G B E 4.4.6-0-default #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.1-0-g4adadbd-20151112_172657-sheep25 04/01/2014
Workqueue: hci0 hci_cmd_work [bluetooth]
00000000ffffffff ffffffff81926cfa ffff88006be37c68 ffff88006bc27180
ffff88006b0c1200 ffff88006b0c1234 ffffffff81577993 ffffffff82489320
ffff88006bc24240 0000000000000046 ffff88006a100000 000000026e51eb80
Call Trace:
...
[] ? skb_queue_tail+0x13e/0x150
[] ? vhci_send_frame+0xac/0x100 [hci_vhci]
[] ? hci_send_frame+0x188/0x320 [bluetooth]
[] ? hci_cmd_work+0x115/0x310 [bluetooth]
[] ? process_one_work+0x815/0x1340
[] ? worker_thread+0xe5/0x11f0
[] ? process_one_work+0x1340/0x1340
[] ? kthread+0x1c8/0x230
...
Memory state around the buggy address:
ffff88006b0c1100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88006b0c1180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88006b0c1200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88006b0c1280: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
ffff88006b0c1300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fcFixes: 23424c0d31 (Bluetooth: Add support creating virtual AMP controllers)
Signed-off-by: Jiri Slaby
Signed-off-by: Marcel Holtmann
Cc: Dmitry Vyukov
Signed-off-by: Greg Kroah-Hartman -
commit 822969369482166050c5b2f7013501505e025c39 upstream.
The CMD19/CMD14 bus width test has been found to be unreliable in
some cases. It is not essential, so simply remove it.Signed-off-by: Adrian Hunter
Signed-off-by: Ulf Hansson
Signed-off-by: Greg Kroah-Hartman -
commit 32ecd320db39bcb007679ed42f283740641b81ea 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
Signed-off-by: Adrian Hunter
Signed-off-by: Ulf Hansson
Signed-off-by: Greg Kroah-Hartman -
commit ff8651237f39cea60dc89b2d9f25d9ede3fc82c0 upstream.
Some BIOSes unconditionally send an ACPI notification to RBTN when the
system is resuming from suspend. This makes dell-rbtn send an input
event to userspace as if a function key was pressed. Prevent this by
ignoring all the notifications received while the device is suspended.Link: https://bugzilla.kernel.org/show_bug.cgi?id=106031
Signed-off-by: Gabriele Mazzotta
Tested-by: Alex Hung
Reviewed-by: Pali Rohár
Signed-off-by: Darren Hart
Signed-off-by: Greg Kroah-Hartman -
commit 30c9bb0d7603e7b3f4d6a0ea231e1cddae020c32 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 <<<>>>) 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: 741d81280ad2 (ACPI: Add facility to remove all _OSI strings)
Tested-by: Lukas Wunner
Tested-by: Chen Yu
Signed-off-by: Lv Zheng
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit 265984b36ce82fec67957d452dd2b22e010611e4 upstream.
The CMD19/CMD14 bus width test has been found to be unreliable in
some cases. It is not essential, so simply remove it.Signed-off-by: Adrian Hunter
Signed-off-by: Ulf Hansson
Signed-off-by: Greg Kroah-Hartman -
commit 1c447116d017a98c90f8f71c8c5a611e0aa42178 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: Adrian Hunter
Signed-off-by: Ulf Hansson
Signed-off-by: Greg Kroah-Hartman -
commit bb208f144cf3f59d8f89a09a80efd04389718907 upstream.
As described in 'can: m_can: tag current CAN FD controllers as non-ISO'
(6cfda7fbebe) it is possible to define fixed configuration options by
setting the according bit in 'ctrlmode' and clear it in 'ctrlmode_supported'.
This leads to the incovenience that the fixed configuration bits can not be
passed by netlink even when they have the correct values (e.g. non-ISO, FD).This patch fixes that issue and not only allows fixed set bit values to be set
again but now requires(!) to provide these fixed values at configuration time.
A valid CAN FD configuration consists of a nominal/arbitration bittiming, a
data bittiming and a control mode with CAN_CTRLMODE_FD set - which is now
enforced by a new can_validate() function. This fix additionally removed the
inconsistency that was prohibiting the support of 'CANFD-only' controller
drivers, like the RCar CAN FD.For this reason a new helper can_set_static_ctrlmode() has been introduced to
provide a proper interface to handle static enabled CAN controller options.Reported-by: Ramesh Shanmugasundaram
Signed-off-by: Oliver Hartkopp
Reviewed-by: Ramesh Shanmugasundaram
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Greg Kroah-Hartman -
commit 7c9b973061b03af62734f613f6abec46c0dd4a88 upstream.
The GICv3 driver wrongly assumes that it runs on the non-secure
side of a secure-enabled system, while it could be on a system
with a single security state, or a GICv3 with GICD_CTLR.DS set.Either way, it is important to configure this properly, or
interrupts will simply not be delivered on this HW.Reported-by: Peter Maydell
Tested-by: Peter Maydell
Signed-off-by: Marc Zyngier
Signed-off-by: Greg Kroah-Hartman
