In the API, the driver inserts 0 after the SSID name, to mark the
end of the ssid, but if the SSID name is 32 characters which is
the max SSID length possible, the driver puts 0 at the 33rd
place of memory which is not the part of the SSID name, which
results in OOB write, or off-by-one write condition.
Fix is to remove the addition of 0 after ssid, as in every
case the driver prints the ssid, taking the ssid length
as the input, and in that case insertion of 0 will not serve
any purpose.
Change-Id: I1d58026ec9f48fe9d00bd2f50783c65899588978
CRs-Fixed: 2598900
(cherry picked from commit ad65dc9f8a5731d4138ba61f2731f0db3b68bc82)
Link layer stats are not supported as required by CTS, so don't report
support for them.
Undefining WLAN_FEATURE_LINK_LAYER_STATS at build level causes various
build errors, because the flag is not checked properly in all cases or
fall-back implementations are missing. Therefore, instead of disabling
the feature, just hide it from the system instead.
Test: run cts -m CtsStatsdHostTestCases -t android.cts.statsd.atom.HostAtomTests#testWifiActivityInfo
Change-Id: I9d053ff8bdee1352645c3b8f75bfb284f4f0ca05
Link layer stats triggers firmware timeout.
02-17 21:28:32.793 390 390 E WifiHAL : wifi_get_link_stats: requestResponse Error:-7
02-17 21:28:32.805 567 1525 E WifiVendorHal: getWifiLinkLayerStats(l.937) failed {.code = ERROR_UNKNOWN, .description = , timed out}
They weren't queried before pie, so deal without them.
Unfortunately I didn't find a way to teach wifi HAL not to query this so
the log still gets spammed with
02-19 11:31:10.316 393 393 E WifiHAL : wifi_get_link_stats: requestResponse Error:-3
02-19 11:31:10.320 568 1615 E WifiVendorHal: getWifiLinkLayerStats(l.937) failed {.code = ERROR_NOT_SUPPORTED, .description = }
every few seconds. But at least it doesn't hang the device anymore.
Change-Id: Ia00d19b7384605c6ee6b7b68d441a4616e9816a6
(cherry picked from commit
LineageOS/android_kernel_cyanogen_msm8974@7b01570045)
When host sends assoc response to supplicant, it
allocates a buffer of fixed size and copies a variable
length of assoc response IEs to this fixed sized buffer.
There is a possibility of OOB write to the allocated buffer
if the assoc response IEs length is greater than the
allocated buffer size.
To avoid above issue validate the assoc response IEs length
with the allocated buffer size before data copy to the buffer.
Change-Id: Ib12385e9ff04e5172ae8b505faf959e426fda439
CRs-Fixed: 2616226
(cherry picked from commit 9bb1a72f6ebdf5d2b1a466aec732aa9c5bc37c4d)
In function rrm_fill_beacon_ies, the total IE length is
calculated as sum of length field of the IE and 2 (element id 1
byte and IE length field 1 byte). The total IE length is defined
of type uint16_t and will overflow if the *(pBcnIes + 1)=0xfe.
Validate the len against total IE length to avoid overflow.
Change-Id: If8f86952ce43c5923906fc6ef18705f1785c5d88
CRs-Fixed: 2617004
(cherry picked from commit 949b1745b9e1ddd8f81960723643cdf10e5f1963)
Currently, for while loop BcnNumIes is checked against 0
which may cause OOB read for len = *(pBcnIes + 1).
Fix is to check BcnNumIes against size of header i.e 2 instead
of 0 to avoid 00B read.
Change-Id: Id167410da790e449d36853d8505142e1b218e9b8
CRs-Fixed: 2635666
(cherry picked from commit 7957db59a545ac43b260401546f4bc72470783df)
When host sends ft assoc response to supplicant, it
allocates a buffer of fixed size and copies a variable
length of assoc response IEs to this fixed sized buffer.
There is a possibility of OOB write to the allocated buffer
if the assoc response IEs length is greater than the
allocated buffer size.
To avoid above issue validate the assoc response IEs length
with the allocated buffer size before data copy to the buffer.
Change-Id: Ife9c2071a8cc4a2918b9f349f4024478f94b2d78
CRs-Fixed: 2616225
(cherry picked from commit c7ea2364eb458e2706b7bae3ed3e70fba7fa56e6)
lim_is_assoc_req_for_drop() uses pHashTable which can be accessed
by peDeleteSession simulataneously. This can lead to crash as
memory for pHashTable can be deleted.
Fix this by protecting usage of pHashTable with a lock.
Change-Id: Iaef7a26d9f3e1ccb76807c9dcf140a6f3de34d8e
CRs-Fixed: 2771345
(cherry picked from commit 0c398c2bd44fd1370eca2b1aa01a80f4675fea13)
*ported from kernel 3.18
With the wiphy::features flag being used up this patch adds a
new field wiphy::ext_features. Considering extensibility this
new field is declared as a byte array. This extensible flag is
exposed to user-space by NL80211_ATTR_EXT_FEATURES.
Cc: Avinash Patil <patila@marvell.com>
Signed-off-by: Gautam (Gautam Kumar) Shukla <gautams@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Git-commit: d75bb06b61cb69ee6223d791d3bb230e68623b20
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git
CRs-Fixed: 1098230
Change-Id: Ice288928b17340a571c1acca719325fbf1020072
rpm-regulator-ldoa27 is defined in msm8226-regulator already
Signed-off-by: Francescodario Cuzzocrea <bosconovic@gmail.com>
Change-Id: I64b33b9e0d38da45a5989b5fc36ec4c12dc8fc2b
commit 0b0509508beff65c1d50541861bc0d4973487dc5 upstream.
When allocating space in the target buffer for the security context,
make sure the extra_buffers_size doesn't overflow. This can only
happen if the given size is invalid, but an overflow can turn it
into a valid size. Fail the transaction if an overflow is detected.
Bug: 130571081
Change-Id: Ibaec652d2073491cc426a4a24004a848348316bf
Signed-off-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[haggertk: Backport to 3.4. Omitted return_error_{line,param}]
CVE-2019-2181
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
In case the target node requests a security context, the
extra_buffers_size is increased with the size of the security context.
But, that size is not available for use by regular scatter-gather
buffers; make sure the ending of that buffer is marked correctly.
Bug: 136210786
Acked-by: Todd Kjos <tkjos@google.com>
Fixes: ec74136ded79 ("binder: create node flag to request sender's security context")
Signed-off-by: Martijn Coenen <maco@android.com>
Cc: stable@vger.kernel.org # 5.1+
Link: https://lore.kernel.org/r/20190709110923.220736-1-maco@android.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit a56587065094fd96eb4c2b5ad65571daad32156d)
Change-Id: Icb499a8843814532631de6c12d9709e7540967bf
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
To allow servers to verify client identity, allow a node
flag to be set that causes the sender's security context
to be delivered with the transaction. The BR_TRANSACTION
command is extended in BR_TRANSACTION_SEC_CTX to
contain a pointer to the security context string.
Bug: 25646100
Change-Id: I0ec053072d6337576680067e07f90dd054b1ecfb
Signed-off-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
To have the kernel pre-create 16 loop devices, which will save boot time
as soon as we start having more than 8 APEXes.
Bug: 119022885
Change-Id: I81fcd421fa3ce69c3f1ae150f7aca3cb64320385
Signed-off-by: Martijn Coenen <maco@android.com>
Commit ff86bf0c65f1 ("alarmtimer: Rate limit periodic intervals") sets a
minimum bound on the alarm timer interval. This minimum bound shouldn't
be applied if the interval is 0. Otherwise, one-shot timers will be
converted into periodic ones.
Fixes: ff86bf0c65f1 ("alarmtimer: Rate limit periodic intervals")
Change-Id: I3dd6cb7b5caec3d39b956489448c19d3cda41e5c
Reported-by: Ben Fennema <fennema@google.com>
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Cc: stable@vger.kernel.org
Cc: John Stultz <john.stultz@linaro.org>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
commit ff86bf0c65f14346bf2440534f9ba5ac232c39a0 upstream.
The alarmtimer code has another source of potentially rearming itself too
fast. Interval timers with a very samll interval have a similar CPU hog
effect as the previously fixed overflow issue.
The reason is that alarmtimers do not implement the normal protection
against this kind of problem which the other posix timer use:
timer expires -> queue signal -> deliver signal -> rearm timer
This scheme brings the rearming under scheduler control and prevents
permanently firing timers which hog the CPU.
Bringing this scheme to the alarm timer code is a major overhaul because it
lacks all the necessary mechanisms completely.
So for a quick fix limit the interval to one jiffie. This is not
problematic in practice as alarmtimers are usually backed by an RTC for
suspend which have 1 second resolution. It could be therefor argued that
the resolution of this clock should be set to 1 second in general, but
that's outside the scope of this fix.
Change-Id: Iad8d71a3136cf397b75a541720ebbfbc4152dd31
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Kostya Serebryany <kcc@google.com>
Cc: syzkaller <syzkaller@googlegroups.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Dmitry Vyukov <dvyukov@google.com>
Link: http://lkml.kernel.org/r/20170530211655.896767100@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
hrtimer_init_on_stack() needs a matching call to
destroy_hrtimer_on_stack(), so both need to be exported.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit c08376ac97cb202ec65320f3d90d5c4c5e2adb0b)
[astrachan: Fixes i386-allmodconfig build failure in vsoc.ko noticed
by 01.org kbuild-all project building kernel/msm]
Bug: 70214720
Change-Id: If4d5c466255019322ea21ef38ee5b1b382cce969
Signed-off-by: Alistair Strachan <astrachan@google.com>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
commit 48d0c9becc7f3c66874c100c126459a9da0fdced upstream.
The POSIX specification defines that relative CLOCK_REALTIME timers are not
affected by clock modifications. Those timers have to use CLOCK_MONOTONIC
to ensure POSIX compliance.
The introduction of the additional HRTIMER_MODE_PINNED mode broke this
requirement for pinned timers.
There is no user space visible impact because user space timers are not
using pinned mode, but for consistency reasons this needs to be fixed.
Check whether the mode has the HRTIMER_MODE_REL bit set instead of
comparing with HRTIMER_MODE_ABS.
Change-Id: Ib186c3983c6f66fb4000d85fd5ec09b702a033ab
Signed-off-by: Anna-Maria Gleixner <anna-maria@linutronix.de>
Cc: Christoph Hellwig <hch@lst.de>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: keescook@chromium.org
Fixes: 597d027573 ("timers: Framework for identifying pinned timers")
Link: http://lkml.kernel.org/r/20171221104205.7269-7-anna-maria@linutronix.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Mike Galbraith <efault@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
commit d5421ea43d30701e03cadc56a38854c36a8b4433 upstream.
The hrtimer interrupt code contains a hang detection and mitigation
mechanism, which prevents that a long delayed hrtimer interrupt causes a
continous retriggering of interrupts which prevent the system from making
progress. If a hang is detected then the timer hardware is programmed with
a certain delay into the future and a flag is set in the hrtimer cpu base
which prevents newly enqueued timers from reprogramming the timer hardware
prior to the chosen delay. The subsequent hrtimer interrupt after the delay
clears the flag and resumes normal operation.
If such a hang happens in the last hrtimer interrupt before a CPU is
unplugged then the hang_detected flag is set and stays that way when the
CPU is plugged in again. At that point the timer hardware is not armed and
it cannot be armed because the hang_detected flag is still active, so
nothing clears that flag. As a consequence the CPU does not receive hrtimer
interrupts and no timers expire on that CPU which results in RCU stalls and
other malfunctions.
Clear the flag along with some other less critical members of the hrtimer
cpu base to ensure starting from a clean state when a CPU is plugged in.
Thanks to Paul, Sebastian and Anna-Maria for their help to get down to the
root cause of that hard to reproduce heisenbug. Once understood it's
trivial and certainly justifies a brown paperbag.
Fixes: 41d2e49493 ("hrtimer: Tune hrtimer_interrupt hang logic")
Change-Id: I707de358bcc70a980dc4bd581c159a30e01cce41
Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sebastian Sewior <bigeasy@linutronix.de>
Cc: Anna-Maria Gleixner <anna-maria@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1801261447590.2067@nanos
[bigeasy: backport to v3.18, drop ->next_timer it was introduced later]
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
[ Upstream commit f7bcb70ebae0dcdb5a2d859b09e4465784d99029 ]
It was noted that the 32bit implementation of ktime_divns()
was doing unsigned division and didn't properly handle
negative values.
And when a ktime helper was changed to utilize
ktime_divns, it caused a regression on some IR blasters.
See the following bugzilla for details:
https://bugzilla.redhat.com/show_bug.cgi?id=1200353
This patch fixes the problem in ktime_divns by checking
and preserving the sign bit, and then reapplying it if
appropriate after the division, it also changes the return
type to a s64 to make it more obvious this is expected.
Nicolas also pointed out that negative dividers would
cause infinite loops on 32bit systems, negative dividers
is unlikely for users of this function, but out of caution
this patch adds checks for negative dividers for both
32-bit (BUG_ON) and 64-bit(WARN_ON) versions to make sure
no such use cases creep in.
[ tglx: Hand an u64 to do_div() to avoid the compiler warning ]
Fixes: 166afb64511e 'ktime: Sanitize ktime_to_us/ms conversion'
Change-Id: I8af36d5e6bd3a3f049f564dd3b65cc1b3e929561
Reported-and-tested-by: Trevor Cordes <trevor@tecnopolis.ca>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Josh Boyer <jwboyer@redhat.com>
Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/1431118043-23452-1-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
[ Upstream commit 8b618628b2bf83512fc8df5e8672619d65adfdfb ]
At least on ARM, do_div() is optimized to turn constant divisors into
an inline multiplication by the reciprocal value at compile time.
However this optimization is missed entirely whenever ktime_divns() is
used and the slow out-of-line division code is used all the time.
Let ktime_divns() use do_div() inline whenever the divisor is constant
and small enough. This will make things like ktime_to_us() and
ktime_to_ms() much faster.
Change-Id: I6a672b10d6d6b373b327f9548135ededfd1e1835
Cc: Arnd Bergmann <arnd.bergmann@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Nicolas Pitre <nico@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
With the plain nanoseconds based ktime_t we can simply use
ktime_divns() instead of going through loops and hoops of
timespec/timeval conversion.
Change-Id: Ib33ea80bc3fdd26fcada1072b1f8ffc26081c0ba
Reported-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
commit 54ffccbf053b5b6ca4f6e45094b942fab92a25fc upstream.
tiocspgrp() takes two tty_struct pointers: One to the tty that userspace
passed to ioctl() (`tty`) and one to the TTY being changed (`real_tty`).
These pointers are different when ioctl() is called with a master fd.
To properly lock real_tty->pgrp, we must take real_tty->ctrl_lock.
This bug makes it possible for racing ioctl(TIOCSPGRP, ...) calls on
both sides of a PTY pair to corrupt the refcount of `struct pid`,
leading to use-after-free errors.
Fixes: 47f86834bb ("redo locking of tty->pgrp")
CC: stable@kernel.org
Signed-off-by: Jann Horn <jannh@google.com>
Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Change-Id: Ib41dbafa06012374b219c7236968733373189ffd
CVE-2020-29661
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
sdfat version 2.4.5 introduced wbc_to_write_flags() as a compat
function for legacy kernels. Unfortunately, as the legacy
__sdfat_submit_bio_write() path was adapted to take advantage of
wbc_to_write_flags(), it used the return value direcly as the
rw paramater to submit_bio(), and the default return value is 0
(READ). This becomes a problem later when write paths assert that
bio_data_dir() is WRITE (i.e., write bit of bio->bi_rw is set).
Pass a bitwise-or of WRITE and the return value of wbc_to_write_flags()
to submit_bio() on this legacy path. This logically unifies the
approach with the newer path here and directly with the legacy path of
__sdfat_submit_bio_write2() in mpage.c.
Fixes: afd489c6a8c8 ("fs: sdfat: Update to version 2.4.5")
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: Ic7b937a467e9e116c3390c6ac0e009a59229b93c
Abhishek Ambure
Karsten Tausche
Stefan Assmann
Ashish Kumar Dhanotiya
Pragaspathi Thilagaraj
sheenam monga
Gautam Kumar Shukla
prototype74
Todd Kjos
Martijn Coenen
Todd Kjos
Greg Hackmann
Thomas Gleixner
Guenter Roeck
Anna-Maria Gleixner
John Stultz
Nicolas Pitre
Andrea
Jann Horn
Sharath Chandra Vurukala
Jason Yan
Kevin F. Haggerty
matteo0026