<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/char, branch v4.14.217</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.217</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.217'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2020-11-18T17:28:00+00:00</updated>
<entry>
<title>random32: make prandom_u32() output unpredictable</title>
<updated>2020-11-18T17:28:00+00:00</updated>
<author>
<name>George Spelvin</name>
<email>lkml@sdf.org</email>
</author>
<published>2020-08-09T06:57:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a16f026330fee92e434267dc35c21bceaa7fd573'/>
<id>urn:sha1:a16f026330fee92e434267dc35c21bceaa7fd573</id>
<content type='text'>
commit c51f8f88d705e06bd696d7510aff22b33eb8e638 upstream.

Non-cryptographic PRNGs may have great statistical properties, but
are usually trivially predictable to someone who knows the algorithm,
given a small sample of their output.  An LFSR like prandom_u32() is
particularly simple, even if the sample is widely scattered bits.

It turns out the network stack uses prandom_u32() for some things like
random port numbers which it would prefer are *not* trivially predictable.
Predictability led to a practical DNS spoofing attack.  Oops.

This patch replaces the LFSR with a homebrew cryptographic PRNG based
on the SipHash round function, which is in turn seeded with 128 bits
of strong random key.  (The authors of SipHash have *not* been consulted
about this abuse of their algorithm.)  Speed is prioritized over security;
attacks are rare, while performance is always wanted.

Replacing all callers of prandom_u32() is the quick fix.
Whether to reinstate a weaker PRNG for uses which can tolerate it
is an open question.

Commit f227e3ec3b5c ("random32: update the net random state on interrupt
and activity") was an earlier attempt at a solution.  This patch replaces
it.

Reported-by: Amit Klein &lt;aksecurity@gmail.com&gt;
Cc: Willy Tarreau &lt;w@1wt.eu&gt;
Cc: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: "Jason A. Donenfeld" &lt;Jason@zx2c4.com&gt;
Cc: Andy Lutomirski &lt;luto@kernel.org&gt;
Cc: Kees Cook &lt;keescook@chromium.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: tytso@mit.edu
Cc: Florian Westphal &lt;fw@strlen.de&gt;
Cc: Marc Plumb &lt;lkml.mplumb@gmail.com&gt;
Fixes: f227e3ec3b5c ("random32: update the net random state on interrupt and activity")
Signed-off-by: George Spelvin &lt;lkml@sdf.org&gt;
Link: https://lore.kernel.org/netdev/20200808152628.GA27941@SDF.ORG/
[ willy: partial reversal of f227e3ec3b5c; moved SIPROUND definitions
  to prandom.h for later use; merged George's prandom_seed() proposal;
  inlined siprand_u32(); replaced the net_rand_state[] array with 4
  members to fix a build issue; cosmetic cleanups to make checkpatch
  happy; fixed RANDOM32_SELFTEST build ]
[wt: backported to 4.14 -- various context adjustments; timer API change]
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drivers: char: tlclk.c: Avoid data race between init and interrupt handler</title>
<updated>2020-10-01T11:12:42+00:00</updated>
<author>
<name>Madhuparna Bhowmik</name>
<email>madhuparnabhowmik10@gmail.com</email>
</author>
<published>2020-04-17T15:34:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=418b8afbecf6707599cadadddf12c1b7b6a4e0a3'/>
<id>urn:sha1:418b8afbecf6707599cadadddf12c1b7b6a4e0a3</id>
<content type='text'>
[ Upstream commit 44b8fb6eaa7c3fb770bf1e37619cdb3902cca1fc ]

After registering character device the file operation callbacks can be
called. The open callback registers interrupt handler.
Therefore interrupt handler can execute in parallel with rest of the init
function. To avoid such data race initialize telclk_interrupt variable
and struct alarm_events before registering character device.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Madhuparna Bhowmik &lt;madhuparnabhowmik10@gmail.com&gt;
Link: https://lore.kernel.org/r/20200417153451.1551-1-madhuparnabhowmik10@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>tpm: ibmvtpm: Wait for buffer to be set before proceeding</title>
<updated>2020-10-01T11:12:37+00:00</updated>
<author>
<name>Stefan Berger</name>
<email>stefanb@linux.ibm.com</email>
</author>
<published>2020-03-12T15:53:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=80090ac63e908e9932a0d8f8a8fe0812daf97a8a'/>
<id>urn:sha1:80090ac63e908e9932a0d8f8a8fe0812daf97a8a</id>
<content type='text'>
[ Upstream commit d8d74ea3c00214aee1e1826ca18e77944812b9b4 ]

Synchronize with the results from the CRQs before continuing with
the initialization. This avoids trying to send TPM commands while
the rtce buffer has not been allocated, yet.

This patch fixes an existing race condition that may occurr if the
hypervisor does not quickly respond to the VTPM_GET_RTCE_BUFFER_SIZE
request sent during initialization and therefore the ibmvtpm-&gt;rtce_buf
has not been allocated at the time the first TPM command is sent.

Fixes: 132f76294744 ("drivers/char/tpm: Add new device driver to support IBM vTPM")
Signed-off-by: Stefan Berger &lt;stefanb@linux.ibm.com&gt;
Acked-by: Nayna Jain &lt;nayna@linux.ibm.com&gt;
Tested-by: Nayna Jain &lt;nayna@linux.ibm.com&gt;
Reviewed-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>tpm: Unify the mismatching TPM space buffer sizes</title>
<updated>2020-09-03T09:22:34+00:00</updated>
<author>
<name>Jarkko Sakkinen</name>
<email>jarkko.sakkinen@linux.intel.com</email>
</author>
<published>2020-08-31T18:58:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0a221a7442cc3a0da05cf97603ada6dcd6f33beb'/>
<id>urn:sha1:0a221a7442cc3a0da05cf97603ada6dcd6f33beb</id>
<content type='text'>
[ Upstream commit 6c4e79d99e6f42b79040f1a33cd4018f5425030b ]

The size of the buffers for storing context's and sessions can vary from
arch to arch as PAGE_SIZE can be anything between 4 kB and 256 kB (the
maximum for PPC64). Define a fixed buffer size set to 16 kB. This should be
enough for most use with three handles (that is how many we allow at the
moment). Parametrize the buffer size while doing this, so that it is easier
to revisit this later on if required.

Cc: stable@vger.kernel.org
Reported-by: Stefan Berger &lt;stefanb@linux.ibm.com&gt;
Fixes: 745b361e989a ("tpm: infrastructure for TPM spaces")
Reviewed-by: Jerry Snitselaar &lt;jsnitsel@redhat.com&gt;
Tested-by: Stefan Berger &lt;stefanb@linux.ibm.com&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>agp/intel: Fix a memory leak on module initialisation failure</title>
<updated>2020-08-21T07:48:06+00:00</updated>
<author>
<name>Qiushi Wu</name>
<email>wu000273@umn.edu</email>
</author>
<published>2020-05-22T08:34:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b3ad6a3db008e4565d97da15c00ef25ee4b5b59a'/>
<id>urn:sha1:b3ad6a3db008e4565d97da15c00ef25ee4b5b59a</id>
<content type='text'>
[ Upstream commit b975abbd382fe442713a4c233549abb90e57c22b ]

In intel_gtt_setup_scratch_page(), pointer "page" is not released if
pci_dma_mapping_error() return an error, leading to a memory leak on
module initialisation failure.  Simply fix this issue by freeing "page"
before return.

Fixes: 0e87d2b06cb46 ("intel-gtt: initialize our own scratch page")
Signed-off-by: Qiushi Wu &lt;wu000273@umn.edu&gt;
Reviewed-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20200522083451.7448-1-chris@chris-wilson.co.uk
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>random32: update the net random state on interrupt and activity</title>
<updated>2020-08-07T07:38:41+00:00</updated>
<author>
<name>Willy Tarreau</name>
<email>w@1wt.eu</email>
</author>
<published>2020-07-10T13:23:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=583bcbc024f6bf8daa266f4f71b99e9d6e78c40b'/>
<id>urn:sha1:583bcbc024f6bf8daa266f4f71b99e9d6e78c40b</id>
<content type='text'>
commit f227e3ec3b5cad859ad15666874405e8c1bbc1d4 upstream.

This modifies the first 32 bits out of the 128 bits of a random CPU's
net_rand_state on interrupt or CPU activity to complicate remote
observations that could lead to guessing the network RNG's internal
state.

Note that depending on some network devices' interrupt rate moderation
or binding, this re-seeding might happen on every packet or even almost
never.

In addition, with NOHZ some CPUs might not even get timer interrupts,
leaving their local state rarely updated, while they are running
networked processes making use of the random state.  For this reason, we
also perform this update in update_process_times() in order to at least
update the state when there is user or system activity, since it's the
only case we care about.

Reported-by: Amit Klein &lt;aksecurity@gmail.com&gt;
Suggested-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: "Jason A. Donenfeld" &lt;Jason@zx2c4.com&gt;
Cc: Andy Lutomirski &lt;luto@kernel.org&gt;
Cc: Kees Cook &lt;keescook@chromium.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>virtio: virtio_console: add missing MODULE_DEVICE_TABLE() for rproc serial</title>
<updated>2020-07-22T07:22:27+00:00</updated>
<author>
<name>Alexander Lobakin</name>
<email>alobakin@pm.me</email>
</author>
<published>2020-06-23T11:09:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=57fb09c5bc3cefef8045670956af8082bb4f81a9'/>
<id>urn:sha1:57fb09c5bc3cefef8045670956af8082bb4f81a9</id>
<content type='text'>
commit 897c44f0bae574c5fb318c759b060bebf9dd6013 upstream.

rproc_serial_id_table lacks an exposure to module devicetable, so
when remoteproc firmware requests VIRTIO_ID_RPROC_SERIAL, no uevent
is generated and no module autoloading occurs.
Add missing MODULE_DEVICE_TABLE() annotation and move the existing
one for VIRTIO_ID_CONSOLE right to the table itself.

Fixes: 1b6370463e88 ("virtio_console: Add support for remoteproc serial")
Cc: &lt;stable@vger.kernel.org&gt; # v3.8+
Signed-off-by: Alexander Lobakin &lt;alobakin@pm.me&gt;
Reviewed-by: Amit Shah &lt;amit@kernel.org&gt;
Link: https://lore.kernel.org/r/x7C_CbeJtoGMy258nwAXASYz3xgFMFpyzmUvOyZzRnQrgWCREBjaqBOpAUS7ol4NnZYvSVwmTsCG0Ohyfvta-ygw6HMHcoeKK0C3QFiAO_Q=@pm.me
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>tpm_tis: extra chip-&gt;ops check on error path in tpm_tis_core_init</title>
<updated>2020-07-22T07:22:21+00:00</updated>
<author>
<name>Vasily Averin</name>
<email>vvs@virtuozzo.com</email>
</author>
<published>2020-06-13T14:18:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f09eb6fa26287c4ad4baf0cbf16715624b5a8b76'/>
<id>urn:sha1:f09eb6fa26287c4ad4baf0cbf16715624b5a8b76</id>
<content type='text'>
[ Upstream commit ccf6fb858e17a8f8a914a1c6444d277cfedfeae6 ]

Found by smatch:
drivers/char/tpm/tpm_tis_core.c:1088 tpm_tis_core_init() warn:
 variable dereferenced before check 'chip-&gt;ops' (see line 979)

'chip-&gt;ops' is assigned in the beginning of function
in tpmm_chip_alloc-&gt;tpm_chip_alloc
and is used before first possible goto to error path.

Signed-off-by: Vasily Averin &lt;vvs@virtuozzo.com&gt;
Reviewed-by: Jerry Snitselaar &lt;jsnitsel@redhat.com&gt;
Reviewed-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>agp/intel: Reinforce the barrier after GTT updates</title>
<updated>2020-06-20T08:25:06+00:00</updated>
<author>
<name>Chris Wilson</name>
<email>chris@chris-wilson.co.uk</email>
</author>
<published>2020-04-10T08:35:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1fa0bfc8fe5570ab7569d9a9dddad874fc7a4346'/>
<id>urn:sha1:1fa0bfc8fe5570ab7569d9a9dddad874fc7a4346</id>
<content type='text'>
commit f30d3ced9fafa03e4855508929b5b6334907f45e upstream.

After changing the timing between GTT updates and execution on the GPU,
we started seeing sporadic failures on Ironlake. These were narrowed
down to being an insufficiently strong enough barrier/delay after
updating the GTT and scheduling execution on the GPU. By forcing the
uncached read, and adding the missing barrier for the singular
insert_page (relocation paths), the sporadic failures go away.

Fixes: 983d308cb8f6 ("agp/intel: Serialise after GTT updates")
Fixes: 3497971a71d8 ("agp/intel: Flush chipset writes after updating a single PTE")
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Acked-by: Andi Shyti &lt;andi.shyti@intel.com&gt;
Cc: stable@vger.kernel.org # v4.0+
Link: https://patchwork.freedesktop.org/patch/msgid/20200410083535.25464-1-chris@chris-wilson.co.uk
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ipmi: Fix NULL pointer dereference in ssif_probe</title>
<updated>2020-05-20T06:17:08+00:00</updated>
<author>
<name>Gustavo A. R. Silva</name>
<email>gustavo@embeddedor.com</email>
</author>
<published>2018-08-31T15:00:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7c492a0a1202fdf36bc76062246523f1b537e5db'/>
<id>urn:sha1:7c492a0a1202fdf36bc76062246523f1b537e5db</id>
<content type='text'>
[ Upstream commit a8627cda7cfffe1792c199660c2b4f03ba2bd97b ]

There is a potential execution path in which function ssif_info_find()
returns NULL, hence there is a NULL pointer dereference when accessing
pointer *addr_info*

Fix this by null checking *addr_info* before dereferencing it.

Addresses-Coverity-ID: 1473145 ("Explicit null dereferenced")
Fixes: e333054a91d1 ("ipmi: Fix I2C client removal in the SSIF driver")
Signed-off-by: Gustavo A. R. Silva &lt;gustavo@embeddedor.com&gt;
Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
