Yue Cao claims that current host rate limiting of challenge ACKS
(RFC 5961) could leak enough information to allow a patient attacker
to hijack TCP sessions. He will soon provide details in an academic
paper.
This patch increases the default limit from 100 to 1000, and adds
some randomization so that the attacker can no longer hijack
sessions without spending a considerable amount of probes.
Based on initial analysis and patch from Linus.
Note that we also have per socket rate limiting, so it is tempting
to remove the host limit in the future.
v2: randomize the count of challenge acks per second, not the period.
Fixes: 282f23c6ee ("tcp: implement RFC 5961 3.2")
Reported-by: Yue Cao <ycao009@ucr.edu>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Change-Id: I1bf93d033e788c37899837f0c9e930bc4e20aa4c
Git-repo: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git
Git-commit: 75ff39ccc1bd5d3c455b6822ab09e533c551f758
[d-cagle@codeaurora.org: Resolve trivial merge conflict]
Signed-off-by: Dennis Cagle <d-cagle@codeaurora.org>
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.
Change-Id: I13b15885df9dc0c17a3e1670ae9606bf3ce4ba05
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Acked-by: David Woodhouse <David.Woodhouse@intel.com>
Acked-by: Peter Jones <pjones@redhat.com>
Git-repo: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git
Git-commit: 23c8a812dc3c621009e4f0e5342aa4e2ede1ceaa
Signed-off-by: Dennis Cagle <d-cagle@codeaurora.org>
This is required to allow tasks to freely move between cgroups associated
with the tune controller.
Change-Id: I1f39b957462034586edc2fdc0a35488b314e9c8c
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
The schedtune controller will mimic the cpusets controller configuration
for now. For that we need to make 4 groups in addition to the root
group present by default.
Change-Id: I082f1e4e4ebf863e623cf66ee127eac70a3e2716
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
To support task performance boosting, the usage of a single knob has the
advantage to be a simple solution, both from the implementation and the
usability standpoint. However, on a real system it can be difficult to
identify a single value for the knob which fits the needs of multiple
different tasks. For example, some kernel threads and/or user-space
background services should be better managed the "standard" way while we
still want to be able to boost the performance of specific workloads.
In order to improve the flexibility of the task boosting mechanism this
patch is the first of a small series which extends the previous
implementation to introduce a "per task group" support.
This first patch introduces just the basic CGroups support, a new
"schedtune" CGroups controller is added which allows to configure
different boost value for different groups of tasks.
To keep the implementation simple but still effective for a boosting
strategy, the new controller:
1. allows only a two layer hierarchy
2. supports only a limited number of boost groups
A two layer hierarchy allows to place each task either:
a) in the root control group
thus being subject to a system-wide boosting value
b) in a child of the root group
thus being subject to the specific boost value defined by that
"boost group"
The limited number of "boost groups" supported is mainly motivated by
the observation that in a real system it could be useful to have only
few classes of tasks which deserve different treatment.
For example, background vs foreground or interactive vs low-priority.
As an additional benefit, a limited number of boost groups allows also
to have a simpler implementation especially for the code required to
compute the boost value for CPUs which have runnable tasks belonging to
different boost groups.
Change-Id: I1304e33a8440bfdad9c8bcf8129ff390216f2e32
cc: Tejun Heo <tj@kernel.org>
cc: Li Zefan <lizefan@huawei.com>
cc: Johannes Weiner <hannes@cmpxchg.org>
cc: Ingo Molnar <mingo@redhat.com>
cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Git-commit: 13001f47c9
Git-repo: https://android.googlesource.com/kernel/common
Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>
Add a module parameter "fg_restart" to restart the fuel gauge
without loading the battery profile. This will be useful in
geting a fresh SOC estimate whenever required.
Change-Id: I0c054ad523a0eab72f777d010807bb3a55f63f7e
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Currently, FG_GEN3 driver loads the battery profile if it finds
out the profile loaded earlier doesn't match with the available
profile. This will be done when the profile integrity bit is
set already. Make this force profile loading as a configurable
parameter through a device tree property.
While at it, add a module parameter to dump the profile contents
conditionally. This will be helpful in debugging.
Change-Id: Ibaff55aa5434ee283e6d597485d193e9e52bb74e
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
msoc-full is not used to determine when the battery is full. The charger
will wakeup the device when it has terminated charging indicating that
the battery is full. Disable the msoc-full IRQ as a wakeup source.
The msoc-delta IRQ is used to wakeup the device when the SOC changes
therefore having the bsoc-delta IRQ as a wakeup source is unnecessary.
Disable the bsoc-delta IRQ as a wakeup source.
Change-Id: Iab7087ce3d6727abc852d3a84590cfa570ec584d
Signed-off-by: Nicholas Troast <ntroast@codeaurora.org>
Currently, delta SOC threshold is written as a 8 bit value but
the encoding is in 11 bits. This will cause the delta SOC
threshold programmed to a lower value causing interrupts to fire
quickly. Change the numerator of delta SOC SRAM parameter so that
the delta SOC threshold will be set correctly. Maximum possible
threshold will be 12.45% (1/2048 * 255).
Change-Id: Ia908c917d71939b9d72b16ddca3400a692540bf3
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Configure CC_CV threshold voltage to 4.34V for both itech and
ascent battery profiles that will be used by GEN3 fuel gauge
on pmicobalt.
CRs-Fixed: 1068593
Change-Id: I7df3d343afa62ffdbf6f5db8c7fc7d94e2f0e3a0
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Based on the battery profile parameters, Vbatt greater than float
voltage and full voltage thresholds needs to be configured. Add
support for the same. Since this needs the battery profile
parameters to be read in advance before the hardware is
initialized, shuffle the code to get battery profile early.
CRs-Fixed: 1068593
Change-Id: If5df62d933cc653a276967b3d16c080c6d4ecb2e
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
