<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git, branch v3.0.80</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v3.0.80</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v3.0.80'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2013-05-24T18:09:48+00:00</updated>
<entry>
<title>Linux 3.0.80</title>
<updated>2013-05-24T18:09:48+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2013-05-24T18:09:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f9429439e89dd9e7440de0334f3eefcd3a37adf4'/>
<id>urn:sha1:f9429439e89dd9e7440de0334f3eefcd3a37adf4</id>
<content type='text'>
</content>
</entry>
<entry>
<title>media: mantis: fix silly crash case</title>
<updated>2013-05-24T18:09:24+00:00</updated>
<author>
<name>Alan Cox</name>
<email>alan@linux.intel.com</email>
</author>
<published>2012-08-09T15:33:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e51c0ea1c933d98e3f0ea5bf0a8a3149475cf0a1'/>
<id>urn:sha1:e51c0ea1c933d98e3f0ea5bf0a8a3149475cf0a1</id>
<content type='text'>
commit e1d45ae10aea8e8a403e5d96bf5902ee670007ff upstream.

If we set mantis-&gt;fe to NULL on an error its not a good idea to then try
passing NULL to the unregister paths and oopsing really.

Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=16473

Signed-off-by: Alan Cox &lt;alan@linux.intel.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@redhat.com&gt;
Cc: Bjørn Mork &lt;bjorn@mork.no&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>hwmon: fix error return code in abituguru_probe()</title>
<updated>2013-05-24T18:09:24+00:00</updated>
<author>
<name>Wei Yongjun</name>
<email>yongjun_wei@trendmicro.com.cn</email>
</author>
<published>2013-05-13T06:01:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=38180ec039a7589112633b85b2cfab72a76ec9c0'/>
<id>urn:sha1:38180ec039a7589112633b85b2cfab72a76ec9c0</id>
<content type='text'>
commit ecacb0b17c08fae89f65468727f0e4b8e91da4e1 upstream.

Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.

Signed-off-by: Wei Yongjun &lt;yongjun_wei@trendmicro.com.cn&gt;
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>btrfs: don't stop searching after encountering the wrong item</title>
<updated>2013-05-24T18:09:24+00:00</updated>
<author>
<name>Gabriel de Perthuis</name>
<email>g2p.code@gmail.com</email>
</author>
<published>2013-05-06T17:40:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3f9831881378bae530028b35a7a06c811441162d'/>
<id>urn:sha1:3f9831881378bae530028b35a7a06c811441162d</id>
<content type='text'>
commit 03b71c6ca6286625d8f1ed44aabab9b5bf5dac10 upstream.

The search ioctl skips items that are too large for a result buffer, but
inline items of a certain size occuring before any search result is
found would trigger an overflow and stop the search entirely.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=57641

Signed-off-by: Gabriel de Perthuis &lt;g2p.code+btrfs@gmail.com&gt;
Signed-off-by: Josef Bacik &lt;jbacik@fusionio.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Linux 3.0.79</title>
<updated>2013-05-19T17:05:47+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2013-05-19T17:05:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ae101a35196a14a8388b7db5f7ddd0b3cfdc5f99'/>
<id>urn:sha1:ae101a35196a14a8388b7db5f7ddd0b3cfdc5f99</id>
<content type='text'>
</content>
</entry>
<entry>
<title>usermodehelper: check subprocess_info-&gt;path != NULL</title>
<updated>2013-05-19T17:04:50+00:00</updated>
<author>
<name>Oleg Nesterov</name>
<email>oleg@redhat.com</email>
</author>
<published>2013-05-16T15:43:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=49432a001824f973ccf8214c7ef9e8e72c974987'/>
<id>urn:sha1:49432a001824f973ccf8214c7ef9e8e72c974987</id>
<content type='text'>
commit 264b83c07a84223f0efd0d1db9ccc66d6f88288f upstream.

argv_split(empty_or_all_spaces) happily succeeds, it simply returns
argc == 0 and argv[0] == NULL. Change call_usermodehelper_exec() to
check sub_info-&gt;path != NULL to avoid the crash.

This is the minimal fix, todo:

 - perhaps we should change argv_split() to return NULL or change the
   callers.

 - kill or justify -&gt;path[0] check

 - narrow the scope of helper_lock()

Signed-off-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
Acked-By: Lucas De Marchi &lt;lucas.demarchi@intel.com&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>drm/radeon: check incoming cliprects pointer</title>
<updated>2013-05-19T17:04:50+00:00</updated>
<author>
<name>Kees Cook</name>
<email>keescook@chromium.org</email>
</author>
<published>2013-05-13T05:00:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ac087d8e21d7722266d913d766b5c8b87772cbb4'/>
<id>urn:sha1:ac087d8e21d7722266d913d766b5c8b87772cbb4</id>
<content type='text'>
commit fefaedcfb82d2e57c2320acf60604ab03b750cc0 upstream.

The "boxes" parameter points into userspace memory. It should be verified
like any other operation against user memory.

Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ipmi: ipmi_devintf: compat_ioctl method fails to take ipmi_mutex</title>
<updated>2013-05-19T17:04:49+00:00</updated>
<author>
<name>Benjamin LaHaise</name>
<email>bcrl@kvack.org</email>
</author>
<published>2013-05-16T19:04:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=486684458640fe1e74937b2e0eef41444515caf0'/>
<id>urn:sha1:486684458640fe1e74937b2e0eef41444515caf0</id>
<content type='text'>
commit 6368087e851e697679af059b4247aca33a69cef3 upstream.

When a 32 bit version of ipmitool is used on a 64 bit kernel, the
ipmi_devintf code fails to correctly acquire ipmi_mutex.  This results in
incomplete data being retrieved in some cases, or other possible failures.
Add a wrapper around compat_ipmi_ioctl() to take ipmi_mutex to fix this.

Signed-off-by: Benjamin LaHaise &lt;bcrl@kvack.org&gt;
Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&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>drivers/char/ipmi: memcpy, need additional 2 bytes to avoid memory overflow</title>
<updated>2013-05-19T17:04:49+00:00</updated>
<author>
<name>Chen Gang</name>
<email>gang.chen@asianux.com</email>
</author>
<published>2013-05-16T19:04:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c9e43f309c0a5ecb9467ea826c238fc0febb1e30'/>
<id>urn:sha1:c9e43f309c0a5ecb9467ea826c238fc0febb1e30</id>
<content type='text'>
commit a5f2b3d6a738e7d4180012fe7b541172f8c8dcea upstream.

When calling memcpy, read_data and write_data need additional 2 bytes.

  write_data:
    for checking:  "if (size &gt; IPMI_MAX_MSG_LENGTH)"
    for operating: "memcpy(bt-&gt;write_data + 3, data + 1, size - 1)"

  read_data:
    for checking:  "if (msg_len &lt; 3 || msg_len &gt; IPMI_MAX_MSG_LENGTH)"
    for operating: "memcpy(data + 2, bt-&gt;read_data + 4, msg_len - 2)"

Signed-off-by: Chen Gang &lt;gang.chen@asianux.com&gt;
Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&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>ACPI / EC: Restart transaction even when the IBF flag set</title>
<updated>2013-05-19T17:04:48+00:00</updated>
<author>
<name>Lan Tianyu</name>
<email>tianyu.lan@intel.com</email>
</author>
<published>2013-05-06T03:23:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9e5124c57d380d616aef157c0f9e05ef0c80d1ca'/>
<id>urn:sha1:9e5124c57d380d616aef157c0f9e05ef0c80d1ca</id>
<content type='text'>
commit 28fe5c825f8e15744d04c7c1b8df197950923ecd upstream.

The EC driver works abnormally with IBF flag always set.
IBF means "The host has written a byte of data to the command
or data port, but the embedded controller has not yet read it".
If IBF is set in the EC status and not cleared, this will cause
all subsequent EC requests to fail with a timeout error.

Change the EC driver so that it doesn't refuse to restart a
transaction if IBF is set in the status.  Also increase the
number of transaction restarts to 5, as it turns out that 2
is not sufficient in some cases.

This bug happens on several different machines (Asus V1S,
Dell Latitude E6530, Samsung R719, Acer Aspire 5930G,
Sony Vaio SR19VN and others).

[rjw: Changelog]
References: https://bugzilla.kernel.org/show_bug.cgi?id=14733
References: https://bugzilla.kernel.org/show_bug.cgi?id=15560
References: https://bugzilla.kernel.org/show_bug.cgi?id=15946
References: https://bugzilla.kernel.org/show_bug.cgi?id=42945
References: https://bugzilla.kernel.org/show_bug.cgi?id=48221
Signed-off-by: Lan Tianyu &lt;tianyu.lan@intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
