<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/char, branch v3.0.31</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/drivers/char?h=v3.0.31</id>
<link rel='self' href='https://git.amat.us/linux/atom/drivers/char?h=v3.0.31'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2011-10-03T18:40:58Z</updated>
<entry>
<title>TPM: Zero buffer after copying to userspace</title>
<updated>2011-10-03T18:40:58Z</updated>
<author>
<name>Peter Huewe</name>
<email>huewe.external.infineon@googlemail.com</email>
</author>
<published>2011-09-15T17:47:42Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=1d43a87614596faf4b9cae2d0c894aa67a7c5121'/>
<id>urn:sha1:1d43a87614596faf4b9cae2d0c894aa67a7c5121</id>
<content type='text'>
commit 3321c07ae5068568cd61ac9f4ba749006a7185c9 upstream.

Since the buffer might contain security related data it might be a good idea to
zero the buffer after we have copied it to userspace.

This got assigned CVE-2011-1162.

Signed-off-by: Rajiv Andrade &lt;srajiv@linux.vnet.ibm.com&gt;
Signed-off-by: James Morris &lt;jmorris@namei.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>TPM: Call tpm_transmit with correct size</title>
<updated>2011-10-03T18:40:58Z</updated>
<author>
<name>Peter Huewe</name>
<email>huewe.external.infineon@googlemail.com</email>
</author>
<published>2011-09-15T17:37:43Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=108885cc2856128a266423d45f617e65961048f7'/>
<id>urn:sha1:108885cc2856128a266423d45f617e65961048f7</id>
<content type='text'>
commit 6b07d30aca7e52f2881b8c8c20c8a2cd28e8b3d3 upstream.

This patch changes the call of tpm_transmit by supplying the size of the
userspace buffer instead of TPM_BUFSIZE.

This got assigned CVE-2011-1161.

[The first hunk didn't make sense given one could expect
 way less data than TPM_BUFSIZE, so added tpm_transmit boundary
 check over bufsiz instead
 The last parameter of tpm_transmit() reflects the amount
 of data expected from the device, and not the buffer size
 being supplied to it. It isn't ideal to parse it directly,
 so we just set it to the maximum the input buffer can handle
 and let the userspace API to do such job.]

Signed-off-by: Rajiv Andrade &lt;srajiv@linux.vnet.ibm.com&gt;
Signed-off-by: James Morris &lt;jmorris@namei.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>net: Compute protocol sequence numbers and fragment IDs using MD5.</title>
<updated>2011-08-16T01:31:35Z</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2011-08-04T03:50:44Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=e997d47bff5a467262ef224b4cf8cbba2d3eceea'/>
<id>urn:sha1:e997d47bff5a467262ef224b4cf8cbba2d3eceea</id>
<content type='text'>
Computers have become a lot faster since we compromised on the
partial MD4 hash which we use currently for performance reasons.

MD5 is a much safer choice, and is inline with both RFC1948 and
other ISS generators (OpenBSD, Solaris, etc.)

Furthermore, only having 24-bits of the sequence number be truly
unpredictable is a very serious limitation.  So the periodic
regeneration and 8-bit counter have been removed.  We compute and
use a full 32-bit sequence number.

For ipv6, DCCP was found to use a 32-bit truncated initial sequence
number (it needs 43-bits) and that is fixed here as well.

Reported-by: Dan Kaminsky &lt;dan@doxpara.com&gt;
Tested-by: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
</entry>
<entry>
<title>agp/intel: Fix typo in G4x_GMCH_SIZE_VT_2M</title>
<updated>2011-07-13T06:44:27Z</updated>
<author>
<name>Chris Wilson</name>
<email>chris@chris-wilson.co.uk</email>
</author>
<published>2011-07-12T22:38:18Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=780d7cc44524cd396a34757127f51ecb8ccaf2da'/>
<id>urn:sha1:780d7cc44524cd396a34757127f51ecb8ccaf2da</id>
<content type='text'>
Konstantin Belousov found an error in the define of G4x_GMCH_SIZE_VT_2M
relative to the GMCH specs, and confirmed that indeed one of his users
with a Q45 reports 0xb not 0xc for a 2/2MiB GATT.

Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Konstantin Belousov &lt;kostikbel@gmail.com&gt;
Cc: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Acked-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
</entry>
<entry>
<title>drivers/char/hpet.c: fix periodic-emulation for delayed interrupts</title>
<updated>2011-06-16T03:04:02Z</updated>
<author>
<name>Nils Carlson</name>
<email>nils.carlson@ericsson.com</email>
</author>
<published>2011-06-15T22:08:54Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=273ef9509b7903e50f36aaf9f1d5dc9087fca506'/>
<id>urn:sha1:273ef9509b7903e50f36aaf9f1d5dc9087fca506</id>
<content type='text'>
When interrupts are delayed due to interrupt masking or due to other
interrupts being serviced the HPET periodic-emuation would fail.  This
happened because given an interval t and a time for the current interrupt
m we would compute the next time as t + m.  This works until we are
delayed for &gt; t, in which case we would be writing a new value which is in
fact in the past.

This can be solved by computing the next time instead as (k * t) + m where
k is large enough to be in the future.  The exact computation of k is
described in a comment to the code.

More detail:

Assuming an interval of 5 between each expected interrupt we have a normal
case of

t0: interrupt, read t0 from comparator, set next interrupt t0 + 5
t5: interrupt, read t5 from comparator, set next interrupt t5 + 5
t10: interrupt, read t10 from comparator, set next interrupt t10 + 5
...

So, what happens when the interrupt is serviced too late?

t0: interrupt, read t0 from comparator, set next interrupt t0 + 5
t11: delayed interrupt serviced, read t5 from comparator, set next
interrupt t5 + 5, which is in the past!
... counter loops ...
t10: Much much later, get the next interrupt.

This can happen either because we have interrupts masked for too long
(some stupid driver goes on a printk rampage) or just because we are
pushing the limits of the interval (too small a period), or both most
probably.

My solution is to read the main counter as well and set the next interrupt
to occur at the right interval, for example:

t0: interrupt, read t0 from comparator, set next interrupt t0 + 5
t11: delayed interrupt serviced, read t5 from comparator, set next
interrupt t15 as t10 has been missed.
t15: back on track.

Signed-off-by: Nils Carlson &lt;nils.carlson@ericsson.com&gt;
Cc: John Stultz &lt;john.stultz@linaro.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Clemens Ladisch &lt;clemens@ladisch.de&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>virtio console: don't manually set or finalize VIRTIO_CONSOLE_F_MULTIPORT.</title>
<updated>2011-05-30T01:44:13Z</updated>
<author>
<name>Rusty Russell</name>
<email>rusty@rustcorp.com.au</email>
</author>
<published>2011-05-30T17:14:13Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=177dbd95637a52b9118aca757d5856ec3995d3e7'/>
<id>urn:sha1:177dbd95637a52b9118aca757d5856ec3995d3e7</id>
<content type='text'>
That's already been done by the virtio infrastructure before the probe
function is called.

Reported-by: alexey.kardashevskiy@au1.ibm.com
Acked-by: Amit Shah &lt;amit.shah@redhat.com&gt;
Tested-by: Amit Shah &lt;amit.shah@redhat.com&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
</content>
</entry>
<entry>
<title>drivers/char/ppdev.c: put gotten port value</title>
<updated>2011-05-27T00:12:37Z</updated>
<author>
<name>Julia Lawall</name>
<email>julia@diku.dk</email>
</author>
<published>2011-05-26T23:25:59Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=d98808a253f209465ed9f415c565f4c294a213b8'/>
<id>urn:sha1:d98808a253f209465ed9f415c565f4c294a213b8</id>
<content type='text'>
parport_find_number() calls parport_get_port() on its result, so there
should be a corresponding call to parport_put_port() before dropping the
reference.  Similar code is found in the function register_device() in the
same file.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

  // &lt;smpl&gt;
  @exists@
  local idexpression struct parport * x;
  expression ra,rr;
  statement S1,S2;
  @@

  x = parport_find_number(...)
  ... when != x = rr
      when any
      when != parport_put_port(x,...)
      when != if (...) { ... parport_put_port(x,...) ...}
  (
  if(&lt;+...x...+&gt;) S1 else S2
  |
  if(...) { ... when != x = ra
       when forall
       when != parport_put_port(x,...)
  *return...;
  }
  )
  // &lt;/smpl&gt;

Signed-off-by: Julia Lawall &lt;julia@diku.dk&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>drivers/char/mspec.c: use {k,v}zalloc to allocate memory</title>
<updated>2011-05-27T00:12:37Z</updated>
<author>
<name>Rakib Mullick</name>
<email>rakib.mullick@gmail.com</email>
</author>
<published>2011-05-26T23:25:56Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=658c74cf3c98b1c9bc21e26731052db66251dfd8'/>
<id>urn:sha1:658c74cf3c98b1c9bc21e26731052db66251dfd8</id>
<content type='text'>
Let memory allocator initialize the allocated memory as null, thus remove
the use of memset.

Signed-off-by: Rakib Mullick &lt;rakib.mullick@gmail.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>ipmi: convert to seq_file interface</title>
<updated>2011-05-27T00:12:37Z</updated>
<author>
<name>Alexey Dobriyan</name>
<email>adobriyan@gmail.com</email>
</author>
<published>2011-05-26T23:25:55Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=074127367a503de0168e2ca5d0b36a6f761f026a'/>
<id>urn:sha1:074127367a503de0168e2ca5d0b36a6f761f026a</id>
<content type='text'>
The -&gt;read_proc interface is going away, convert to seq_file.

Signed-off-by: Alexey Dobriyan &lt;adobriyan@gmail.com&gt;
Cc:Corey Minyard &lt;minyard@acm.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>i8k: Integrate with the hwmon subsystem</title>
<updated>2011-05-25T18:43:33Z</updated>
<author>
<name>Jean Delvare</name>
<email>khali@linux-fr.org</email>
</author>
<published>2011-05-25T18:43:33Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=949a9d70020defd7c241607ab3ed037ea88f551c'/>
<id>urn:sha1:949a9d70020defd7c241607ab3ed037ea88f551c</id>
<content type='text'>
Let i8k create an hwmon class device so that libsensors will expose
the CPU temperature and fan speeds to monitoring applications.

Signed-off-by: Jean Delvare &lt;khali@linux-fr.org&gt;
Acked-by: Guenter Roeck &lt;guenter.roeck@ericsson.com&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Ingo Molnar &lt;mingo@redhat.com&gt;
Cc: "H. Peter Anvin" &lt;hpa@zytor.com&gt;
Cc: Massimo Dal Zotto &lt;dz@debian.org&gt;
</content>
</entry>
</feed>
