* [01/20] eCryptfs: Sanitize write counts of /dev/ecryptfs
2012-02-01 21:00 [00/20] 2.6.32.56-longterm review Greg KH
@ 2012-02-01 20:14 ` Greg KH
2012-02-01 20:14 ` [02/20] ecryptfs: Improve metadata read failure logging Greg KH
` (18 subsequent siblings)
19 siblings, 0 replies; 30+ messages in thread
From: Greg KH @ 2012-02-01 20:14 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: torvalds, akpm, alan, Tyler Hicks, Sasha Levin
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Tyler Hicks <tyhicks@canonical.com>
commit db10e556518eb9d21ee92ff944530d84349684f4 upstream.
A malicious count value specified when writing to /dev/ecryptfs may
result in a a very large kernel memory allocation.
This patch peeks at the specified packet payload size, adds that to the
size of the packet headers and compares the result with the write count
value. The resulting maximum memory allocation size is approximately 532
bytes.
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Reported-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ecryptfs/miscdev.c | 56 +++++++++++++++++++++++++++++++++-----------------
1 file changed, 38 insertions(+), 18 deletions(-)
--- a/fs/ecryptfs/miscdev.c
+++ b/fs/ecryptfs/miscdev.c
@@ -408,11 +408,47 @@ ecryptfs_miscdev_write(struct file *file
ssize_t sz = 0;
char *data;
uid_t euid = current_euid();
+ unsigned char packet_size_peek[3];
int rc;
- if (count == 0)
+ if (count == 0) {
goto out;
+ } else if (count == (1 + 4)) {
+ /* Likely a harmless MSG_HELO or MSG_QUIT - no packet length */
+ goto memdup;
+ } else if (count < (1 + 4 + 1)
+ || count > (1 + 4 + 2 + sizeof(struct ecryptfs_message) + 4
+ + ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES)) {
+ printk(KERN_WARNING "%s: Acceptable packet size range is "
+ "[%d-%lu], but amount of data written is [%zu].",
+ __func__, (1 + 4 + 1),
+ (1 + 4 + 2 + sizeof(struct ecryptfs_message) + 4
+ + ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES), count);
+ return -EINVAL;
+ }
+
+ if (copy_from_user(packet_size_peek, (buf + 1 + 4),
+ sizeof(packet_size_peek))) {
+ printk(KERN_WARNING "%s: Error while inspecting packet size\n",
+ __func__);
+ return -EFAULT;
+ }
+ rc = ecryptfs_parse_packet_length(packet_size_peek, &packet_size,
+ &packet_size_length);
+ if (rc) {
+ printk(KERN_WARNING "%s: Error parsing packet length; "
+ "rc = [%d]\n", __func__, rc);
+ return rc;
+ }
+
+ if ((1 + 4 + packet_size_length + packet_size) != count) {
+ printk(KERN_WARNING "%s: Invalid packet size [%zu]\n", __func__,
+ packet_size);
+ return -EINVAL;
+ }
+
+memdup:
data = memdup_user(buf, count);
if (IS_ERR(data)) {
printk(KERN_ERR "%s: memdup_user returned error [%ld]\n",
@@ -434,23 +470,7 @@ ecryptfs_miscdev_write(struct file *file
}
memcpy(&counter_nbo, &data[i], 4);
seq = be32_to_cpu(counter_nbo);
- i += 4;
- rc = ecryptfs_parse_packet_length(&data[i], &packet_size,
- &packet_size_length);
- if (rc) {
- printk(KERN_WARNING "%s: Error parsing packet length; "
- "rc = [%d]\n", __func__, rc);
- goto out_free;
- }
- i += packet_size_length;
- if ((1 + 4 + packet_size_length + packet_size) != count) {
- printk(KERN_WARNING "%s: (1 + packet_size_length([%zd])"
- " + packet_size([%zd]))([%zd]) != "
- "count([%zd]). Invalid packet format.\n",
- __func__, packet_size_length, packet_size,
- (1 + packet_size_length + packet_size), count);
- goto out_free;
- }
+ i += 4 + packet_size_length;
rc = ecryptfs_miscdev_response(&data[i], packet_size,
euid, current_user_ns(),
task_pid(current), seq);
^ permalink raw reply [flat|nested] 30+ messages in thread* [02/20] ecryptfs: Improve metadata read failure logging
2012-02-01 21:00 [00/20] 2.6.32.56-longterm review Greg KH
2012-02-01 20:14 ` [01/20] eCryptfs: Sanitize write counts of /dev/ecryptfs Greg KH
@ 2012-02-01 20:14 ` Greg KH
2012-02-01 20:14 ` [03/20] eCryptfs: Make truncate path killable Greg KH
` (17 subsequent siblings)
19 siblings, 0 replies; 30+ messages in thread
From: Greg KH @ 2012-02-01 20:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Tim Gardner, Kees Cook, Tyler Hicks
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Tim Gardner <tim.gardner@canonical.com>
commit 30373dc0c87ffef68d5628e77d56ffb1fa22e1ee upstream.
Print inode on metadata read failure. The only real
way of dealing with metadata read failures is to delete
the underlying file system file. Having the inode
allows one to 'find . -inum INODE`.
[tyhicks@canonical.com: Removed some minor not-for-stable parts]
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ecryptfs/crypto.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/fs/ecryptfs/crypto.c
+++ b/fs/ecryptfs/crypto.c
@@ -1609,7 +1609,8 @@ int ecryptfs_read_metadata(struct dentry
rc = ecryptfs_read_xattr_region(page_virt, ecryptfs_inode);
if (rc) {
printk(KERN_DEBUG "Valid eCryptfs headers not found in "
- "file header region or xattr region\n");
+ "file header region or xattr region, inode %lu\n",
+ ecryptfs_inode->i_ino);
rc = -EINVAL;
goto out;
}
@@ -1618,7 +1619,8 @@ int ecryptfs_read_metadata(struct dentry
ECRYPTFS_DONT_VALIDATE_HEADER_SIZE);
if (rc) {
printk(KERN_DEBUG "Valid eCryptfs headers not found in "
- "file xattr region either\n");
+ "file xattr region either, inode %lu\n",
+ ecryptfs_inode->i_ino);
rc = -EINVAL;
}
if (crypt_stat->mount_crypt_stat->flags
@@ -1629,7 +1631,8 @@ int ecryptfs_read_metadata(struct dentry
"crypto metadata only in the extended attribute "
"region, but eCryptfs was mounted without "
"xattr support enabled. eCryptfs will not treat "
- "this like an encrypted file.\n");
+ "this like an encrypted file, inode %lu\n",
+ ecryptfs_inode->i_ino);
rc = -EINVAL;
}
}
^ permalink raw reply [flat|nested] 30+ messages in thread* [03/20] eCryptfs: Make truncate path killable
2012-02-01 21:00 [00/20] 2.6.32.56-longterm review Greg KH
2012-02-01 20:14 ` [01/20] eCryptfs: Sanitize write counts of /dev/ecryptfs Greg KH
2012-02-01 20:14 ` [02/20] ecryptfs: Improve metadata read failure logging Greg KH
@ 2012-02-01 20:14 ` Greg KH
2012-02-01 20:14 ` [04/20] drm: Fix authentication kernel crash Greg KH
` (16 subsequent siblings)
19 siblings, 0 replies; 30+ messages in thread
From: Greg KH @ 2012-02-01 20:14 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: torvalds, akpm, alan, Tyler Hicks
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Tyler Hicks <tyhicks@canonical.com>
commit 5e6f0d769017cc49207ef56996e42363ec26c1f0 upstream.
ecryptfs_write() handles the truncation of eCryptfs inodes. It grabs a
page, zeroes out the appropriate portions, and then encrypts the page
before writing it to the lower filesystem. It was unkillable and due to
the lack of sparse file support could result in tying up a large portion
of system resources, while encrypting pages of zeros, with no way for
the truncate operation to be stopped from userspace.
This patch adds the ability for ecryptfs_write() to detect a pending
fatal signal and return as gracefully as possible. The intent is to
leave the lower file in a useable state, while still allowing a user to
break out of the encryption loop. If a pending fatal signal is detected,
the eCryptfs inode size is updated to reflect the modified inode size
and then -EINTR is returned.
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ecryptfs/read_write.c | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
--- a/fs/ecryptfs/read_write.c
+++ b/fs/ecryptfs/read_write.c
@@ -136,6 +136,11 @@ int ecryptfs_write(struct file *ecryptfs
size_t num_bytes = (PAGE_CACHE_SIZE - start_offset_in_page);
size_t total_remaining_bytes = ((offset + size) - pos);
+ if (fatal_signal_pending(current)) {
+ rc = -EINTR;
+ break;
+ }
+
if (num_bytes > total_remaining_bytes)
num_bytes = total_remaining_bytes;
if (pos < offset) {
@@ -197,15 +202,19 @@ int ecryptfs_write(struct file *ecryptfs
}
pos += num_bytes;
}
- if ((offset + size) > ecryptfs_file_size) {
- i_size_write(ecryptfs_inode, (offset + size));
+ if (pos > ecryptfs_file_size) {
+ i_size_write(ecryptfs_inode, pos);
if (crypt_stat->flags & ECRYPTFS_ENCRYPTED) {
- rc = ecryptfs_write_inode_size_to_metadata(
+ int rc2;
+
+ rc2 = ecryptfs_write_inode_size_to_metadata(
ecryptfs_inode);
- if (rc) {
+ if (rc2) {
printk(KERN_ERR "Problem with "
"ecryptfs_write_inode_size_to_metadata; "
- "rc = [%d]\n", rc);
+ "rc = [%d]\n", rc2);
+ if (!rc)
+ rc = rc2;
goto out;
}
}
^ permalink raw reply [flat|nested] 30+ messages in thread* [04/20] drm: Fix authentication kernel crash
2012-02-01 21:00 [00/20] 2.6.32.56-longterm review Greg KH
` (2 preceding siblings ...)
2012-02-01 20:14 ` [03/20] eCryptfs: Make truncate path killable Greg KH
@ 2012-02-01 20:14 ` Greg KH
2012-02-01 20:14 ` Greg KH
` (15 subsequent siblings)
19 siblings, 0 replies; 30+ messages in thread
From: Greg KH @ 2012-02-01 20:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Thomas Hellstrom, Daniel Vetter,
Dave Airlie
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Hellstrom <thellstrom@vmware.com>
commit 598781d71119827b454fd75d46f84755bca6f0c6 upstream.
If the master tries to authenticate a client using drm_authmagic and
that client has already closed its drm file descriptor,
either wilfully or because it was terminated, the
call to drm_authmagic will dereference a stale pointer into kmalloc'ed memory
and corrupt it.
Typically this results in a hard system hang.
This patch fixes that problem by removing any authentication tokens
(struct drm_magic_entry) open for a file descriptor when that file
descriptor is closed.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/drm_auth.c | 6 +++++-
drivers/gpu/drm/drm_fops.c | 5 +++++
include/drm/drmP.h | 1 +
3 files changed, 11 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -102,7 +102,7 @@ static int drm_add_magic(struct drm_mast
* Searches and unlinks the entry in drm_device::magiclist with the magic
* number hash key, while holding the drm_device::struct_mutex lock.
*/
-static int drm_remove_magic(struct drm_master *master, drm_magic_t magic)
+int drm_remove_magic(struct drm_master *master, drm_magic_t magic)
{
struct drm_magic_entry *pt;
struct drm_hash_item *hash;
@@ -137,6 +137,8 @@ static int drm_remove_magic(struct drm_m
* If there is a magic number in drm_file::magic then use it, otherwise
* searches an unique non-zero magic number and add it associating it with \p
* file_priv.
+ * This ioctl needs protection by the drm_global_mutex, which protects
+ * struct drm_file::magic and struct drm_magic_entry::priv.
*/
int drm_getmagic(struct drm_device *dev, void *data, struct drm_file *file_priv)
{
@@ -174,6 +176,8 @@ int drm_getmagic(struct drm_device *dev,
* \return zero if authentication successed, or a negative number otherwise.
*
* Checks if \p file_priv is associated with the magic number passed in \arg.
+ * This ioctl needs protection by the drm_global_mutex, which protects
+ * struct drm_file::magic and struct drm_magic_entry::priv.
*/
int drm_authmagic(struct drm_device *dev, void *data,
struct drm_file *file_priv)
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -449,6 +449,11 @@ int drm_release(struct inode *inode, str
(long)old_encode_dev(file_priv->minor->device),
dev->open_count);
+ /* Release any auth tokens that might point to this file_priv,
+ (do that under the drm_global_mutex) */
+ if (file_priv->magic)
+ (void) drm_remove_magic(file_priv->master, file_priv->magic);
+
/* if the master has gone away we can't do anything with the lock */
if (file_priv->minor->master)
drm_master_release(dev, filp);
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1221,6 +1221,7 @@ extern int drm_getmagic(struct drm_devic
struct drm_file *file_priv);
extern int drm_authmagic(struct drm_device *dev, void *data,
struct drm_file *file_priv);
+extern int drm_remove_magic(struct drm_master *master, drm_magic_t magic);
/* Cache management (drm_cache.c) */
void drm_clflush_pages(struct page *pages[], unsigned long num_pages);
^ permalink raw reply [flat|nested] 30+ messages in thread* [05/20] crypto: sha512 - make it work, undo percpu message schedule
2012-02-01 21:00 [00/20] 2.6.32.56-longterm review Greg KH
@ 2012-02-01 20:14 ` Greg KH
2012-02-01 20:14 ` [02/20] ecryptfs: Improve metadata read failure logging Greg KH
` (18 subsequent siblings)
19 siblings, 0 replies; 30+ messages in thread
From: Greg KH @ 2012-02-01 20:14 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: torvalds, akpm, alan, Alexey Dobriyan, Herbert Xu
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Alexey Dobriyan <adobriyan@gmail.com>
commit 84e31fdb7c797a7303e0cc295cb9bc8b73fb872d upstream.
commit f9e2bca6c22d75a289a349f869701214d63b5060
aka "crypto: sha512 - Move message schedule W[80] to static percpu area"
created global message schedule area.
If sha512_update will ever be entered twice, hash will be silently
calculated incorrectly.
Probably the easiest way to notice incorrect hashes being calculated is
to run 2 ping floods over AH with hmac(sha512):
#!/usr/sbin/setkey -f
flush;
spdflush;
add IP1 IP2 ah 25 -A hmac-sha512 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000025;
add IP2 IP1 ah 52 -A hmac-sha512 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000052;
spdadd IP1 IP2 any -P out ipsec ah/transport//require;
spdadd IP2 IP1 any -P in ipsec ah/transport//require;
XfrmInStateProtoError will start ticking with -EBADMSG being returned
from ah_input(). This never happens with, say, hmac(sha1).
With patch applied (on BOTH sides), XfrmInStateProtoError does not tick
with multiple bidirectional ping flood streams like it doesn't tick
with SHA-1.
After this patch sha512_transform() will start using ~750 bytes of stack on x86_64.
This is OK for simple loads, for something more heavy, stack reduction will be done
separatedly.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
crypto/sha512_generic.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
--- a/crypto/sha512_generic.c
+++ b/crypto/sha512_generic.c
@@ -21,8 +21,6 @@
#include <linux/percpu.h>
#include <asm/byteorder.h>
-static DEFINE_PER_CPU(u64[80], msg_schedule);
-
static inline u64 Ch(u64 x, u64 y, u64 z)
{
return z ^ (x & (y ^ z));
@@ -89,7 +87,7 @@ sha512_transform(u64 *state, const u8 *i
u64 a, b, c, d, e, f, g, h, t1, t2;
int i;
- u64 *W = get_cpu_var(msg_schedule);
+ u64 W[80];
/* load the input */
for (i = 0; i < 16; i++)
@@ -128,8 +126,6 @@ sha512_transform(u64 *state, const u8 *i
/* erase our data */
a = b = c = d = e = f = g = h = t1 = t2 = 0;
- memset(W, 0, sizeof(__get_cpu_var(msg_schedule)));
- put_cpu_var(msg_schedule);
}
static int
^ permalink raw reply [flat|nested] 30+ messages in thread* [05/20] crypto: sha512 - make it work, undo percpu message schedule
@ 2012-02-01 20:14 ` Greg KH
0 siblings, 0 replies; 30+ messages in thread
From: Greg KH @ 2012-02-01 20:14 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: torvalds, akpm, alan, Alexey Dobriyan, Herbert Xu
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Alexey Dobriyan <adobriyan@gmail.com>
commit 84e31fdb7c797a7303e0cc295cb9bc8b73fb872d upstream.
commit f9e2bca6c22d75a289a349f869701214d63b5060
aka "crypto: sha512 - Move message schedule W[80] to static percpu area"
created global message schedule area.
If sha512_update will ever be entered twice, hash will be silently
calculated incorrectly.
Probably the easiest way to notice incorrect hashes being calculated is
to run 2 ping floods over AH with hmac(sha512):
#!/usr/sbin/setkey -f
flush;
spdflush;
add IP1 IP2 ah 25 -A hmac-sha512 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000025;
add IP2 IP1 ah 52 -A hmac-sha512 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000052;
spdadd IP1 IP2 any -P out ipsec ah/transport//require;
spdadd IP2 IP1 any -P in ipsec ah/transport//require;
XfrmInStateProtoError will start ticking with -EBADMSG being returned
from ah_input(). This never happens with, say, hmac(sha1).
With patch applied (on BOTH sides), XfrmInStateProtoError does not tick
with multiple bidirectional ping flood streams like it doesn't tick
with SHA-1.
After this patch sha512_transform() will start using ~750 bytes of stack on x86_64.
This is OK for simple loads, for something more heavy, stack reduction will be done
separatedly.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
crypto/sha512_generic.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
--- a/crypto/sha512_generic.c
+++ b/crypto/sha512_generic.c
@@ -21,8 +21,6 @@
#include <linux/percpu.h>
#include <asm/byteorder.h>
-static DEFINE_PER_CPU(u64[80], msg_schedule);
-
static inline u64 Ch(u64 x, u64 y, u64 z)
{
return z ^ (x & (y ^ z));
@@ -89,7 +87,7 @@ sha512_transform(u64 *state, const u8 *i
u64 a, b, c, d, e, f, g, h, t1, t2;
int i;
- u64 *W = get_cpu_var(msg_schedule);
+ u64 W[80];
/* load the input */
for (i = 0; i < 16; i++)
@@ -128,8 +126,6 @@ sha512_transform(u64 *state, const u8 *i
/* erase our data */
a = b = c = d = e = f = g = h = t1 = t2 = 0;
- memset(W, 0, sizeof(__get_cpu_var(msg_schedule)));
- put_cpu_var(msg_schedule);
}
static int
^ permalink raw reply [flat|nested] 30+ messages in thread
* [06/20] crypto: sha512 - reduce stack usage to safe number
2012-02-01 21:00 [00/20] 2.6.32.56-longterm review Greg KH
@ 2012-02-01 20:14 ` Greg KH
2012-02-01 20:14 ` [02/20] ecryptfs: Improve metadata read failure logging Greg KH
` (18 subsequent siblings)
19 siblings, 0 replies; 30+ messages in thread
From: Greg KH @ 2012-02-01 20:14 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: torvalds, akpm, alan, Alexey Dobriyan, Herbert Xu
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Alexey Dobriyan <adobriyan@gmail.com>
commit 51fc6dc8f948047364f7d42a4ed89b416c6cc0a3 upstream.
For rounds 16--79, W[i] only depends on W[i - 2], W[i - 7], W[i - 15] and W[i - 16].
Consequently, keeping all W[80] array on stack is unnecessary,
only 16 values are really needed.
Using W[16] instead of W[80] greatly reduces stack usage
(~750 bytes to ~340 bytes on x86_64).
Line by line explanation:
* BLEND_OP
array is "circular" now, all indexes have to be modulo 16.
Round number is positive, so remainder operation should be
without surprises.
* initial full message scheduling is trimmed to first 16 values which
come from data block, the rest is calculated before it's needed.
* original loop body is unrolled version of new SHA512_0_15 and
SHA512_16_79 macros, unrolling was done to not do explicit variable
renaming. Otherwise it's the very same code after preprocessing.
See sha1_transform() code which does the same trick.
Patch survives in-tree crypto test and original bugreport test
(ping flood with hmac(sha512).
See FIPS 180-2 for SHA-512 definition
http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
crypto/sha512_generic.c | 58 ++++++++++++++++++++++++++++--------------------
1 file changed, 34 insertions(+), 24 deletions(-)
--- a/crypto/sha512_generic.c
+++ b/crypto/sha512_generic.c
@@ -78,7 +78,7 @@ static inline void LOAD_OP(int I, u64 *W
static inline void BLEND_OP(int I, u64 *W)
{
- W[I] = s1(W[I-2]) + W[I-7] + s0(W[I-15]) + W[I-16];
+ W[I % 16] += s1(W[(I-2) % 16]) + W[(I-7) % 16] + s0(W[(I-15) % 16]);
}
static void
@@ -87,38 +87,48 @@ sha512_transform(u64 *state, const u8 *i
u64 a, b, c, d, e, f, g, h, t1, t2;
int i;
- u64 W[80];
+ u64 W[16];
/* load the input */
for (i = 0; i < 16; i++)
LOAD_OP(i, W, input);
- for (i = 16; i < 80; i++) {
- BLEND_OP(i, W);
- }
-
/* load the state into our registers */
a=state[0]; b=state[1]; c=state[2]; d=state[3];
e=state[4]; f=state[5]; g=state[6]; h=state[7];
- /* now iterate */
- for (i=0; i<80; i+=8) {
- t1 = h + e1(e) + Ch(e,f,g) + sha512_K[i ] + W[i ];
- t2 = e0(a) + Maj(a,b,c); d+=t1; h=t1+t2;
- t1 = g + e1(d) + Ch(d,e,f) + sha512_K[i+1] + W[i+1];
- t2 = e0(h) + Maj(h,a,b); c+=t1; g=t1+t2;
- t1 = f + e1(c) + Ch(c,d,e) + sha512_K[i+2] + W[i+2];
- t2 = e0(g) + Maj(g,h,a); b+=t1; f=t1+t2;
- t1 = e + e1(b) + Ch(b,c,d) + sha512_K[i+3] + W[i+3];
- t2 = e0(f) + Maj(f,g,h); a+=t1; e=t1+t2;
- t1 = d + e1(a) + Ch(a,b,c) + sha512_K[i+4] + W[i+4];
- t2 = e0(e) + Maj(e,f,g); h+=t1; d=t1+t2;
- t1 = c + e1(h) + Ch(h,a,b) + sha512_K[i+5] + W[i+5];
- t2 = e0(d) + Maj(d,e,f); g+=t1; c=t1+t2;
- t1 = b + e1(g) + Ch(g,h,a) + sha512_K[i+6] + W[i+6];
- t2 = e0(c) + Maj(c,d,e); f+=t1; b=t1+t2;
- t1 = a + e1(f) + Ch(f,g,h) + sha512_K[i+7] + W[i+7];
- t2 = e0(b) + Maj(b,c,d); e+=t1; a=t1+t2;
+#define SHA512_0_15(i, a, b, c, d, e, f, g, h) \
+ t1 = h + e1(e) + Ch(e, f, g) + sha512_K[i] + W[i]; \
+ t2 = e0(a) + Maj(a, b, c); \
+ d += t1; \
+ h = t1 + t2
+
+#define SHA512_16_79(i, a, b, c, d, e, f, g, h) \
+ BLEND_OP(i, W); \
+ t1 = h + e1(e) + Ch(e, f, g) + sha512_K[i] + W[(i)%16]; \
+ t2 = e0(a) + Maj(a, b, c); \
+ d += t1; \
+ h = t1 + t2
+
+ for (i = 0; i < 16; i += 8) {
+ SHA512_0_15(i, a, b, c, d, e, f, g, h);
+ SHA512_0_15(i + 1, h, a, b, c, d, e, f, g);
+ SHA512_0_15(i + 2, g, h, a, b, c, d, e, f);
+ SHA512_0_15(i + 3, f, g, h, a, b, c, d, e);
+ SHA512_0_15(i + 4, e, f, g, h, a, b, c, d);
+ SHA512_0_15(i + 5, d, e, f, g, h, a, b, c);
+ SHA512_0_15(i + 6, c, d, e, f, g, h, a, b);
+ SHA512_0_15(i + 7, b, c, d, e, f, g, h, a);
+ }
+ for (i = 16; i < 80; i += 8) {
+ SHA512_16_79(i, a, b, c, d, e, f, g, h);
+ SHA512_16_79(i + 1, h, a, b, c, d, e, f, g);
+ SHA512_16_79(i + 2, g, h, a, b, c, d, e, f);
+ SHA512_16_79(i + 3, f, g, h, a, b, c, d, e);
+ SHA512_16_79(i + 4, e, f, g, h, a, b, c, d);
+ SHA512_16_79(i + 5, d, e, f, g, h, a, b, c);
+ SHA512_16_79(i + 6, c, d, e, f, g, h, a, b);
+ SHA512_16_79(i + 7, b, c, d, e, f, g, h, a);
}
state[0] += a; state[1] += b; state[2] += c; state[3] += d;
^ permalink raw reply [flat|nested] 30+ messages in thread* [06/20] crypto: sha512 - reduce stack usage to safe number
@ 2012-02-01 20:14 ` Greg KH
0 siblings, 0 replies; 30+ messages in thread
From: Greg KH @ 2012-02-01 20:14 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: torvalds, akpm, alan, Alexey Dobriyan, Herbert Xu
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Alexey Dobriyan <adobriyan@gmail.com>
commit 51fc6dc8f948047364f7d42a4ed89b416c6cc0a3 upstream.
For rounds 16--79, W[i] only depends on W[i - 2], W[i - 7], W[i - 15] and W[i - 16].
Consequently, keeping all W[80] array on stack is unnecessary,
only 16 values are really needed.
Using W[16] instead of W[80] greatly reduces stack usage
(~750 bytes to ~340 bytes on x86_64).
Line by line explanation:
* BLEND_OP
array is "circular" now, all indexes have to be modulo 16.
Round number is positive, so remainder operation should be
without surprises.
* initial full message scheduling is trimmed to first 16 values which
come from data block, the rest is calculated before it's needed.
* original loop body is unrolled version of new SHA512_0_15 and
SHA512_16_79 macros, unrolling was done to not do explicit variable
renaming. Otherwise it's the very same code after preprocessing.
See sha1_transform() code which does the same trick.
Patch survives in-tree crypto test and original bugreport test
(ping flood with hmac(sha512).
See FIPS 180-2 for SHA-512 definition
http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
crypto/sha512_generic.c | 58 ++++++++++++++++++++++++++++--------------------
1 file changed, 34 insertions(+), 24 deletions(-)
--- a/crypto/sha512_generic.c
+++ b/crypto/sha512_generic.c
@@ -78,7 +78,7 @@ static inline void LOAD_OP(int I, u64 *W
static inline void BLEND_OP(int I, u64 *W)
{
- W[I] = s1(W[I-2]) + W[I-7] + s0(W[I-15]) + W[I-16];
+ W[I % 16] += s1(W[(I-2) % 16]) + W[(I-7) % 16] + s0(W[(I-15) % 16]);
}
static void
@@ -87,38 +87,48 @@ sha512_transform(u64 *state, const u8 *i
u64 a, b, c, d, e, f, g, h, t1, t2;
int i;
- u64 W[80];
+ u64 W[16];
/* load the input */
for (i = 0; i < 16; i++)
LOAD_OP(i, W, input);
- for (i = 16; i < 80; i++) {
- BLEND_OP(i, W);
- }
-
/* load the state into our registers */
a=state[0]; b=state[1]; c=state[2]; d=state[3];
e=state[4]; f=state[5]; g=state[6]; h=state[7];
- /* now iterate */
- for (i=0; i<80; i+=8) {
- t1 = h + e1(e) + Ch(e,f,g) + sha512_K[i ] + W[i ];
- t2 = e0(a) + Maj(a,b,c); d+=t1; h=t1+t2;
- t1 = g + e1(d) + Ch(d,e,f) + sha512_K[i+1] + W[i+1];
- t2 = e0(h) + Maj(h,a,b); c+=t1; g=t1+t2;
- t1 = f + e1(c) + Ch(c,d,e) + sha512_K[i+2] + W[i+2];
- t2 = e0(g) + Maj(g,h,a); b+=t1; f=t1+t2;
- t1 = e + e1(b) + Ch(b,c,d) + sha512_K[i+3] + W[i+3];
- t2 = e0(f) + Maj(f,g,h); a+=t1; e=t1+t2;
- t1 = d + e1(a) + Ch(a,b,c) + sha512_K[i+4] + W[i+4];
- t2 = e0(e) + Maj(e,f,g); h+=t1; d=t1+t2;
- t1 = c + e1(h) + Ch(h,a,b) + sha512_K[i+5] + W[i+5];
- t2 = e0(d) + Maj(d,e,f); g+=t1; c=t1+t2;
- t1 = b + e1(g) + Ch(g,h,a) + sha512_K[i+6] + W[i+6];
- t2 = e0(c) + Maj(c,d,e); f+=t1; b=t1+t2;
- t1 = a + e1(f) + Ch(f,g,h) + sha512_K[i+7] + W[i+7];
- t2 = e0(b) + Maj(b,c,d); e+=t1; a=t1+t2;
+#define SHA512_0_15(i, a, b, c, d, e, f, g, h) \
+ t1 = h + e1(e) + Ch(e, f, g) + sha512_K[i] + W[i]; \
+ t2 = e0(a) + Maj(a, b, c); \
+ d += t1; \
+ h = t1 + t2
+
+#define SHA512_16_79(i, a, b, c, d, e, f, g, h) \
+ BLEND_OP(i, W); \
+ t1 = h + e1(e) + Ch(e, f, g) + sha512_K[i] + W[(i)%16]; \
+ t2 = e0(a) + Maj(a, b, c); \
+ d += t1; \
+ h = t1 + t2
+
+ for (i = 0; i < 16; i += 8) {
+ SHA512_0_15(i, a, b, c, d, e, f, g, h);
+ SHA512_0_15(i + 1, h, a, b, c, d, e, f, g);
+ SHA512_0_15(i + 2, g, h, a, b, c, d, e, f);
+ SHA512_0_15(i + 3, f, g, h, a, b, c, d, e);
+ SHA512_0_15(i + 4, e, f, g, h, a, b, c, d);
+ SHA512_0_15(i + 5, d, e, f, g, h, a, b, c);
+ SHA512_0_15(i + 6, c, d, e, f, g, h, a, b);
+ SHA512_0_15(i + 7, b, c, d, e, f, g, h, a);
+ }
+ for (i = 16; i < 80; i += 8) {
+ SHA512_16_79(i, a, b, c, d, e, f, g, h);
+ SHA512_16_79(i + 1, h, a, b, c, d, e, f, g);
+ SHA512_16_79(i + 2, g, h, a, b, c, d, e, f);
+ SHA512_16_79(i + 3, f, g, h, a, b, c, d, e);
+ SHA512_16_79(i + 4, e, f, g, h, a, b, c, d);
+ SHA512_16_79(i + 5, d, e, f, g, h, a, b, c);
+ SHA512_16_79(i + 6, c, d, e, f, g, h, a, b);
+ SHA512_16_79(i + 7, b, c, d, e, f, g, h, a);
}
state[0] += a; state[1] += b; state[2] += c; state[3] += d;
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [06/20] crypto: sha512 - reduce stack usage to safe number
2012-02-01 20:14 ` Greg KH
(?)
@ 2012-02-01 23:42 ` Alexey Dobriyan
2012-02-01 23:52 ` Greg KH
-1 siblings, 1 reply; 30+ messages in thread
From: Alexey Dobriyan @ 2012-02-01 23:42 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel, stable, torvalds, akpm, alan, Herbert Xu
On Wed, Feb 01, 2012 at 12:14:08PM -0800, Greg KH wrote:
> @@ -87,38 +87,48 @@ sha512_transform(u64 *state, const u8 *i
> u64 a, b, c, d, e, f, g, h, t1, t2;
>
> int i;
> - u64 W[80];
> + u64 W[16];
This needs 3rd companion patch which does stack reduction even on i386.
Patch which removes excessive loop unrolling and thus fixes the problem
has been posted. Maybe there is some other way to maintain low stack
space on i386 but I haven't found it.
http://marc.info/?l=linux-netdev&m=132768692525017&w=4
If you apply only 2, original bug will be fixed, but on at least i386
stack usage could go in 900-byte region.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [06/20] crypto: sha512 - reduce stack usage to safe number
2012-02-01 23:42 ` Alexey Dobriyan
@ 2012-02-01 23:52 ` Greg KH
0 siblings, 0 replies; 30+ messages in thread
From: Greg KH @ 2012-02-01 23:52 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: linux-kernel, stable, torvalds, akpm, alan, Herbert Xu
On Thu, Feb 02, 2012 at 02:42:08AM +0300, Alexey Dobriyan wrote:
> On Wed, Feb 01, 2012 at 12:14:08PM -0800, Greg KH wrote:
> > @@ -87,38 +87,48 @@ sha512_transform(u64 *state, const u8 *i
> > u64 a, b, c, d, e, f, g, h, t1, t2;
> >
> > int i;
> > - u64 W[80];
> > + u64 W[16];
>
> This needs 3rd companion patch which does stack reduction even on i386.
> Patch which removes excessive loop unrolling and thus fixes the problem
> has been posted. Maybe there is some other way to maintain low stack
> space on i386 but I haven't found it.
>
> http://marc.info/?l=linux-netdev&m=132768692525017&w=4
>
> If you apply only 2, original bug will be fixed, but on at least i386
> stack usage could go in 900-byte region.
But this patch isn't in Linus's tree yet, right?
So, should I just drop this one for now (well both of them) or just wait
for the above referenced patch to hit Linus's tree and handle it then?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [06/20] crypto: sha512 - reduce stack usage to safe number
@ 2012-02-01 23:52 ` Greg KH
0 siblings, 0 replies; 30+ messages in thread
From: Greg KH @ 2012-02-01 23:52 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: linux-kernel, stable, torvalds, akpm, alan, Herbert Xu
On Thu, Feb 02, 2012 at 02:42:08AM +0300, Alexey Dobriyan wrote:
> On Wed, Feb 01, 2012 at 12:14:08PM -0800, Greg KH wrote:
> > @@ -87,38 +87,48 @@ sha512_transform(u64 *state, const u8 *i
> > u64 a, b, c, d, e, f, g, h, t1, t2;
> >
> > int i;
> > - u64 W[80];
> > + u64 W[16];
>
> This needs 3rd companion patch which does stack reduction even on i386.
> Patch which removes excessive loop unrolling and thus fixes the problem
> has been posted. Maybe there is some other way to maintain low stack
> space on i386 but I haven't found it.
>
> http://marc.info/?l=linux-netdev&m=132768692525017&w=4
>
> If you apply only 2, original bug will be fixed, but on at least i386
> stack usage could go in 900-byte region.
But this patch isn't in Linus's tree yet, right?
So, should I just drop this one for now (well both of them) or just wait
for the above referenced patch to hit Linus's tree and handle it then?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [06/20] crypto: sha512 - reduce stack usage to safe number
2012-02-01 23:52 ` Greg KH
@ 2012-02-02 0:04 ` Herbert Xu
-1 siblings, 0 replies; 30+ messages in thread
From: Herbert Xu @ 2012-02-02 0:04 UTC (permalink / raw)
To: Greg KH; +Cc: Alexey Dobriyan, linux-kernel, stable, torvalds, akpm, alan
On Wed, Feb 01, 2012 at 03:52:04PM -0800, Greg KH wrote:
>
> But this patch isn't in Linus's tree yet, right?
>
> So, should I just drop this one for now (well both of them) or just wait
> for the above referenced patch to hit Linus's tree and handle it then?
We're still working on the i386 issue. However, I'd say that
you should take these two patches now since the problem they
fix is far worse than the potential stack issue on i386.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [06/20] crypto: sha512 - reduce stack usage to safe number
@ 2012-02-02 0:04 ` Herbert Xu
0 siblings, 0 replies; 30+ messages in thread
From: Herbert Xu @ 2012-02-02 0:04 UTC (permalink / raw)
To: Greg KH; +Cc: Alexey Dobriyan, linux-kernel, stable, torvalds, akpm, alan
On Wed, Feb 01, 2012 at 03:52:04PM -0800, Greg KH wrote:
>
> But this patch isn't in Linus's tree yet, right?
>
> So, should I just drop this one for now (well both of them) or just wait
> for the above referenced patch to hit Linus's tree and handle it then?
We're still working on the i386 issue. However, I'd say that
you should take these two patches now since the problem they
fix is far worse than the potential stack issue on i386.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [06/20] crypto: sha512 - reduce stack usage to safe number
2012-02-02 0:04 ` Herbert Xu
@ 2012-02-02 0:09 ` Greg KH
-1 siblings, 0 replies; 30+ messages in thread
From: Greg KH @ 2012-02-02 0:09 UTC (permalink / raw)
To: Herbert Xu; +Cc: Alexey Dobriyan, linux-kernel, stable, torvalds, akpm, alan
On Thu, Feb 02, 2012 at 11:04:51AM +1100, Herbert Xu wrote:
> On Wed, Feb 01, 2012 at 03:52:04PM -0800, Greg KH wrote:
> >
> > But this patch isn't in Linus's tree yet, right?
> >
> > So, should I just drop this one for now (well both of them) or just wait
> > for the above referenced patch to hit Linus's tree and handle it then?
>
> We're still working on the i386 issue. However, I'd say that
> you should take these two patches now since the problem they
> fix is far worse than the potential stack issue on i386.
Ok, thanks for letting me know, I'll leave these patches in.
greg k-h
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [06/20] crypto: sha512 - reduce stack usage to safe number
@ 2012-02-02 0:09 ` Greg KH
0 siblings, 0 replies; 30+ messages in thread
From: Greg KH @ 2012-02-02 0:09 UTC (permalink / raw)
To: Herbert Xu; +Cc: Alexey Dobriyan, linux-kernel, stable, torvalds, akpm, alan
On Thu, Feb 02, 2012 at 11:04:51AM +1100, Herbert Xu wrote:
> On Wed, Feb 01, 2012 at 03:52:04PM -0800, Greg KH wrote:
> >
> > But this patch isn't in Linus's tree yet, right?
> >
> > So, should I just drop this one for now (well both of them) or just wait
> > for the above referenced patch to hit Linus's tree and handle it then?
>
> We're still working on the i386 issue. However, I'd say that
> you should take these two patches now since the problem they
> fix is far worse than the potential stack issue on i386.
Ok, thanks for letting me know, I'll leave these patches in.
greg k-h
^ permalink raw reply [flat|nested] 30+ messages in thread
* [07/20] Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"
2012-02-01 21:00 [00/20] 2.6.32.56-longterm review Greg KH
` (5 preceding siblings ...)
2012-02-01 20:14 ` Greg KH
@ 2012-02-01 20:14 ` Greg KH
2012-02-01 20:14 ` [08/20] block: fail SCSI passthrough ioctls on partition devices Greg KH
` (12 subsequent siblings)
19 siblings, 0 replies; 30+ messages in thread
From: Greg KH @ 2012-02-01 20:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Ulf Hansson, Linus Walleij, Per Forlin,
Russell King, Greg KH, Herton Ronaldo Krzesinski
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
This reverts commit c8cdf3f97d34d906e0519d5cbc2ab3f81269d0b4, applied on
linux 2.6.32.53 stable release, as it can introduce the following build
error while building 2.6.32.y on armel:
linux-2.6.32/drivers/mmc/host/mmci.c: In function 'mmci_cmd_irq':
linux-2.6.32/drivers/mmc/host/mmci.c:237: error: implicit declaration of function 'dma_inprogress'
linux-2.6.32/drivers/mmc/host/mmci.c:238: error: implicit declaration of function 'mmci_dma_data_error'
Aparently the commit was wrongly pushed into 2.6.32, since it depends on
commit c8ebae37 ("ARM: mmci: add dmaengine-based DMA support"), not
present on 2.6.32.
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/host/mmci.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -232,12 +232,8 @@ mmci_cmd_irq(struct mmci_host *host, str
}
if (!cmd->data || cmd->error) {
- if (host->data) {
- /* Terminate the DMA transfer */
- if (dma_inprogress(host))
- mmci_dma_data_error(host);
+ if (host->data)
mmci_stop_data(host);
- }
mmci_request_end(host, cmd->mrq);
} else if (!(cmd->data->flags & MMC_DATA_READ)) {
mmci_start_data(host, cmd->data);
^ permalink raw reply [flat|nested] 30+ messages in thread* [08/20] block: fail SCSI passthrough ioctls on partition devices
2012-02-01 21:00 [00/20] 2.6.32.56-longterm review Greg KH
` (6 preceding siblings ...)
2012-02-01 20:14 ` [07/20] Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma" Greg KH
@ 2012-02-01 20:14 ` Greg KH
2012-02-01 20:14 ` [09/20] dm: do not forward ioctls from logical volumes to the underlying device Greg KH
` (11 subsequent siblings)
19 siblings, 0 replies; 30+ messages in thread
From: Greg KH @ 2012-02-01 20:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Paolo Bonzini, Petr Matousek, linux-scsi,
Jens Axboe, James Bottomley, Ben Hutchings
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Paolo Bonzini <pbonzini@redhat.com>
commit 0bfc96cb77224736dfa35c3c555d37b3646ef35e upstream.
[ Changes with respect to 3.3: return -ENOTTY from scsi_verify_blk_ioctl
and -ENOIOCTLCMD from sd_compat_ioctl. ]
Linux allows executing the SG_IO ioctl on a partition or LVM volume, and
will pass the command to the underlying block device. This is
well-known, but it is also a large security problem when (via Unix
permissions, ACLs, SELinux or a combination thereof) a program or user
needs to be granted access only to part of the disk.
This patch lets partitions forward a small set of harmless ioctls;
others are logged with printk so that we can see which ioctls are
actually sent. In my tests only CDROM_GET_CAPABILITY actually occurred.
Of course it was being sent to a (partition on a) hard disk, so it would
have failed with ENOTTY and the patch isn't changing anything in
practice. Still, I'm treating it specially to avoid spamming the logs.
In principle, this restriction should include programs running with
CAP_SYS_RAWIO. If for example I let a program access /dev/sda2 and
/dev/sdb, it still should not be able to read/write outside the
boundaries of /dev/sda2 independent of the capabilities. However, for
now programs with CAP_SYS_RAWIO will still be allowed to send the
ioctls. Their actions will still be logged.
This patch does not affect the non-libata IDE driver. That driver
however already tests for bd != bd->bd_contains before issuing some
ioctl; it could be restricted further to forbid these ioctls even for
programs running with CAP_SYS_ADMIN/CAP_SYS_RAWIO.
Cc: linux-scsi@vger.kernel.org
Cc: Jens Axboe <axboe@kernel.dk>
Cc: James Bottomley <JBottomley@parallels.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
[ Make it also print the command name when warning - Linus ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[bwh: Backport to 2.6.32 - ENOIOCTLCMD does not get converted to
ENOTTY, so we must return ENOTTY directly]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
block/scsi_ioctl.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
drivers/scsi/sd.c | 11 +++++++++--
include/linux/blkdev.h | 1 +
3 files changed, 55 insertions(+), 2 deletions(-)
--- a/block/scsi_ioctl.c
+++ b/block/scsi_ioctl.c
@@ -24,6 +24,7 @@
#include <linux/capability.h>
#include <linux/completion.h>
#include <linux/cdrom.h>
+#include <linux/ratelimit.h>
#include <linux/slab.h>
#include <linux/times.h>
#include <asm/uaccess.h>
@@ -689,9 +690,53 @@ int scsi_cmd_ioctl(struct request_queue
}
EXPORT_SYMBOL(scsi_cmd_ioctl);
+int scsi_verify_blk_ioctl(struct block_device *bd, unsigned int cmd)
+{
+ if (bd && bd == bd->bd_contains)
+ return 0;
+
+ /* Actually none of these is particularly useful on a partition,
+ * but they are safe.
+ */
+ switch (cmd) {
+ case SCSI_IOCTL_GET_IDLUN:
+ case SCSI_IOCTL_GET_BUS_NUMBER:
+ case SCSI_IOCTL_GET_PCI:
+ case SCSI_IOCTL_PROBE_HOST:
+ case SG_GET_VERSION_NUM:
+ case SG_SET_TIMEOUT:
+ case SG_GET_TIMEOUT:
+ case SG_GET_RESERVED_SIZE:
+ case SG_SET_RESERVED_SIZE:
+ case SG_EMULATED_HOST:
+ return 0;
+ case CDROM_GET_CAPABILITY:
+ /* Keep this until we remove the printk below. udev sends it
+ * and we do not want to spam dmesg about it. CD-ROMs do
+ * not have partitions, so we get here only for disks.
+ */
+ return -ENOTTY;
+ default:
+ break;
+ }
+
+ /* In particular, rule out all resets and host-specific ioctls. */
+ printk_ratelimited(KERN_WARNING
+ "%s: sending ioctl %x to a partition!\n", current->comm, cmd);
+
+ return capable(CAP_SYS_RAWIO) ? 0 : -ENOTTY;
+}
+EXPORT_SYMBOL(scsi_verify_blk_ioctl);
+
int scsi_cmd_blk_ioctl(struct block_device *bd, fmode_t mode,
unsigned int cmd, void __user *arg)
{
+ int ret;
+
+ ret = scsi_verify_blk_ioctl(bd, cmd);
+ if (ret < 0)
+ return ret;
+
return scsi_cmd_ioctl(bd->bd_disk->queue, bd->bd_disk, mode, cmd, arg);
}
EXPORT_SYMBOL(scsi_cmd_blk_ioctl);
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -817,6 +817,10 @@ static int sd_ioctl(struct block_device
SCSI_LOG_IOCTL(1, printk("sd_ioctl: disk=%s, cmd=0x%x\n",
disk->disk_name, cmd));
+ error = scsi_verify_blk_ioctl(bdev, cmd);
+ if (error < 0)
+ return error;
+
/*
* If we are in the middle of error recovery, don't let anyone
* else try and use this device. Also, if error recovery fails, it
@@ -996,6 +1000,11 @@ static int sd_compat_ioctl(struct block_
unsigned int cmd, unsigned long arg)
{
struct scsi_device *sdev = scsi_disk(bdev->bd_disk)->device;
+ int ret;
+
+ ret = scsi_verify_blk_ioctl(bdev, cmd);
+ if (ret < 0)
+ return -ENOIOCTLCMD;
/*
* If we are in the middle of error recovery, don't let anyone
@@ -1007,8 +1016,6 @@ static int sd_compat_ioctl(struct block_
return -ENODEV;
if (sdev->host->hostt->compat_ioctl) {
- int ret;
-
ret = sdev->host->hostt->compat_ioctl(sdev, cmd, (void __user *)arg);
return ret;
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -777,6 +777,7 @@ extern void blk_plug_device(struct reque
extern void blk_plug_device_unlocked(struct request_queue *);
extern int blk_remove_plug(struct request_queue *);
extern void blk_recount_segments(struct request_queue *, struct bio *);
+extern int scsi_verify_blk_ioctl(struct block_device *, unsigned int);
extern int scsi_cmd_blk_ioctl(struct block_device *, fmode_t,
unsigned int, void __user *);
extern int scsi_cmd_ioctl(struct request_queue *, struct gendisk *, fmode_t,
^ permalink raw reply [flat|nested] 30+ messages in thread* [09/20] dm: do not forward ioctls from logical volumes to the underlying device
2012-02-01 21:00 [00/20] 2.6.32.56-longterm review Greg KH
` (7 preceding siblings ...)
2012-02-01 20:14 ` [08/20] block: fail SCSI passthrough ioctls on partition devices Greg KH
@ 2012-02-01 20:14 ` Greg KH
2012-02-01 20:14 ` [10/20] USB: ftdi_sio: fix TIOCSSERIAL baud_base handling Greg KH
` (10 subsequent siblings)
19 siblings, 0 replies; 30+ messages in thread
From: Greg KH @ 2012-02-01 20:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Paolo Bonzini, Petr Matousek, linux-scsi,
Jens Axboe, James Bottomley, Alasdair G Kergon, dm-devel,
Ben Hutchings
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Paolo Bonzini <pbonzini@redhat.com>
commit ec8013beddd717d1740cfefb1a9b900deef85462 upstream.
A logical volume can map to just part of underlying physical volume.
In this case, it must be treated like a partition.
Based on a patch from Alasdair G Kergon.
Cc: Alasdair G Kergon <agk@redhat.com>
Cc: dm-devel@redhat.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[bwh: Backport to 2.6.32 - drop change to drivers/md/dm-flakey.c]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-linear.c | 12 +++++++++++-
drivers/md/dm-mpath.c | 6 ++++++
2 files changed, 17 insertions(+), 1 deletion(-)
--- a/drivers/md/dm-linear.c
+++ b/drivers/md/dm-linear.c
@@ -116,7 +116,17 @@ static int linear_ioctl(struct dm_target
unsigned long arg)
{
struct linear_c *lc = (struct linear_c *) ti->private;
- return __blkdev_driver_ioctl(lc->dev->bdev, lc->dev->mode, cmd, arg);
+ struct dm_dev *dev = lc->dev;
+ int r = 0;
+
+ /*
+ * Only pass ioctls through if the device sizes match exactly.
+ */
+ if (lc->start ||
+ ti->len != i_size_read(dev->bdev->bd_inode) >> SECTOR_SHIFT)
+ r = scsi_verify_blk_ioctl(NULL, cmd);
+
+ return r ? : __blkdev_driver_ioctl(dev->bdev, dev->mode, cmd, arg);
}
static int linear_merge(struct dm_target *ti, struct bvec_merge_data *bvm,
--- a/drivers/md/dm-mpath.c
+++ b/drivers/md/dm-mpath.c
@@ -1464,6 +1464,12 @@ static int multipath_ioctl(struct dm_tar
spin_unlock_irqrestore(&m->lock, flags);
+ /*
+ * Only pass ioctls through if the device sizes match exactly.
+ */
+ if (!r && ti->len != i_size_read(bdev->bd_inode) >> SECTOR_SHIFT)
+ r = scsi_verify_blk_ioctl(NULL, cmd);
+
return r ? : __blkdev_driver_ioctl(bdev, mode, cmd, arg);
}
^ permalink raw reply [flat|nested] 30+ messages in thread* [10/20] USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
2012-02-01 21:00 [00/20] 2.6.32.56-longterm review Greg KH
` (8 preceding siblings ...)
2012-02-01 20:14 ` [09/20] dm: do not forward ioctls from logical volumes to the underlying device Greg KH
@ 2012-02-01 20:14 ` Greg KH
2012-02-01 20:14 ` [11/20] USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3 Greg KH
` (9 subsequent siblings)
19 siblings, 0 replies; 30+ messages in thread
From: Greg KH @ 2012-02-01 20:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Torbjörn Lofterud, Johan Hovold
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1085 bytes --]
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <jhovold@gmail.com>
commit eb833a9e0972f60beb4ab8104ad7ef6bf30f02fc upstream.
Return EINVAL if new baud_base does not match the current one.
The baud_base is device specific and can not be changed. This restores
the old (pre-2005) behaviour which was changed due to a
misunderstanding regarding this fact (see
https://lkml.org/lkml/2005/1/20/84).
Reported-by: Torbjörn Lofterud <torbjorn@pi.nxs.se>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/ftdi_sio.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1351,8 +1351,7 @@ static int set_serial_info(struct tty_st
goto check_and_exit;
}
- if ((new_serial.baud_base != priv->baud_base) &&
- (new_serial.baud_base < 9600)) {
+ if (new_serial.baud_base != priv->baud_base) {
unlock_kernel();
return -EINVAL;
}
^ permalink raw reply [flat|nested] 30+ messages in thread* [11/20] USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
2012-02-01 21:00 [00/20] 2.6.32.56-longterm review Greg KH
` (9 preceding siblings ...)
2012-02-01 20:14 ` [10/20] USB: ftdi_sio: fix TIOCSSERIAL baud_base handling Greg KH
@ 2012-02-01 20:14 ` Greg KH
2012-02-01 20:14 ` [12/20] USB: serial: ftdi additional IDs Greg KH
` (8 subsequent siblings)
19 siblings, 0 replies; 30+ messages in thread
From: Greg KH @ 2012-02-01 20:14 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: torvalds, akpm, alan, Peter Korsgaard
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Peter Korsgaard <jacmet@sunsite.dk>
commit 55f13aeae0346f0c89bfface91ad9a97653dc433 upstream.
Port A for JTAG, port B for serial.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/ftdi_sio.c | 2 ++
drivers/usb/serial/ftdi_sio_ids.h | 7 +++++++
2 files changed, 9 insertions(+)
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -806,6 +806,8 @@ static struct usb_device_id id_table_com
{ USB_DEVICE(BAYER_VID, BAYER_CONTOUR_CABLE_PID) },
{ USB_DEVICE(FTDI_VID, MARVELL_OPENRD_PID),
.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
+ { USB_DEVICE(FTDI_VID, TI_XDS100V2_PID),
+ .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
{ USB_DEVICE(FTDI_VID, HAMEG_HO820_PID) },
{ USB_DEVICE(FTDI_VID, HAMEG_HO720_PID) },
{ USB_DEVICE(FTDI_VID, HAMEG_HO730_PID) },
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -38,6 +38,13 @@
/* www.candapter.com Ewert Energy Systems CANdapter device */
#define FTDI_CANDAPTER_PID 0x9F80 /* Product Id */
+/*
+ * Texas Instruments XDS100v2 JTAG / BeagleBone A3
+ * http://processors.wiki.ti.com/index.php/XDS100
+ * http://beagleboard.org/bone
+ */
+#define TI_XDS100V2_PID 0xa6d0
+
#define FTDI_NXTCAM_PID 0xABB8 /* NXTCam for Mindstorms NXT */
/* US Interface Navigator (http://www.usinterface.com/) */
^ permalink raw reply [flat|nested] 30+ messages in thread* [12/20] USB: serial: ftdi additional IDs
2012-02-01 21:00 [00/20] 2.6.32.56-longterm review Greg KH
` (10 preceding siblings ...)
2012-02-01 20:14 ` [11/20] USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3 Greg KH
@ 2012-02-01 20:14 ` Greg KH
2012-02-01 20:14 ` [13/20] USB: ftdi_sio: Add more identifiers Greg KH
` (7 subsequent siblings)
19 siblings, 0 replies; 30+ messages in thread
From: Greg KH @ 2012-02-01 20:14 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: torvalds, akpm, alan, Peter Naulls
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Peter Naulls <peter@chocky.org>
commit fc216ec363f4d174932df90bbf35c77d0540e561 upstream.
I tested this against 2.6.39 in the Ubuntu kernel, however I see the IDs
are not in latest 3.2 git.
This adds IDs for the FTDI controller in the Rainforest Automation
Zigbee dongle.
Signed-off-by: Peter Naulls <peter@chocky.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/ftdi_sio.c | 1 +
drivers/usb/serial/ftdi_sio_ids.h | 6 ++++++
2 files changed, 7 insertions(+)
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -844,6 +844,7 @@ static struct usb_device_id id_table_com
.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
{ USB_DEVICE(ST_VID, ST_STMCLT1030_PID),
.driver_info = (kernel_ulong_t)&ftdi_stmclite_quirk },
+ { USB_DEVICE(FTDI_VID, FTDI_RF_R106) },
{ }, /* Optional parameter entry */
{ } /* Terminating entry */
};
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -1180,3 +1180,9 @@
*/
/* TagTracer MIFARE*/
#define FTDI_ZEITCONTROL_TAGTRACE_MIFARE_PID 0xF7C0
+
+/*
+ * Rainforest Automation
+ */
+/* ZigBee controller */
+#define FTDI_RF_R106 0x8A28
^ permalink raw reply [flat|nested] 30+ messages in thread* [13/20] USB: ftdi_sio: Add more identifiers
2012-02-01 21:00 [00/20] 2.6.32.56-longterm review Greg KH
` (11 preceding siblings ...)
2012-02-01 20:14 ` [12/20] USB: serial: ftdi additional IDs Greg KH
@ 2012-02-01 20:14 ` Greg KH
2012-02-01 20:14 ` [14/20] USB: cdc-wdm: updating desc->length must be protected by spin_lock Greg KH
` (6 subsequent siblings)
19 siblings, 0 replies; 30+ messages in thread
From: Greg KH @ 2012-02-01 20:14 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: torvalds, akpm, alan, Alan Cox
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Alan Cox <alan@linux.intel.com>
commit 2353f806c97020d4c7709f15eebb49b591f7306d upstream.
0x04d8, 0x000a: Hornby Elite
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/ftdi_sio.c | 1 +
drivers/usb/serial/ftdi_sio_ids.h | 6 ++++++
2 files changed, 7 insertions(+)
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -798,6 +798,7 @@ static struct usb_device_id id_table_com
.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
{ USB_DEVICE(ADI_VID, ADI_GNICEPLUS_PID),
.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
+ { USB_DEVICE(HORNBY_VID, HORNBY_ELITE_PID) },
{ USB_DEVICE(JETI_VID, JETI_SPC1201_PID) },
{ USB_DEVICE(MARVELL_VID, MARVELL_SHEEVAPLUG_PID),
.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -531,6 +531,12 @@
#define ADI_GNICEPLUS_PID 0xF001
/*
+ * Hornby Elite
+ */
+#define HORNBY_VID 0x04D8
+#define HORNBY_ELITE_PID 0x000A
+
+/*
* RATOC REX-USB60F
*/
#define RATOC_VENDOR_ID 0x0584
^ permalink raw reply [flat|nested] 30+ messages in thread* [14/20] USB: cdc-wdm: updating desc->length must be protected by spin_lock
2012-02-01 21:00 [00/20] 2.6.32.56-longterm review Greg KH
` (12 preceding siblings ...)
2012-02-01 20:14 ` [13/20] USB: ftdi_sio: Add more identifiers Greg KH
@ 2012-02-01 20:14 ` Greg KH
2012-02-01 20:14 ` [15/20] usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method Greg KH
` (5 subsequent siblings)
19 siblings, 0 replies; 30+ messages in thread
From: Greg KH @ 2012-02-01 20:14 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: torvalds, akpm, alan, Bjørn Mork, Oliver Neukum
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 881 bytes --]
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Bjørn Mork <bjorn@mork.no>
commit c428b70c1e115c5649707a602742e34130d19428 upstream.
wdm_in_callback() will also touch this field, so we cannot change it without locking
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Acked-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/class/cdc-wdm.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/usb/class/cdc-wdm.c
+++ b/drivers/usb/class/cdc-wdm.c
@@ -458,7 +458,9 @@ retry:
for (i = 0; i < desc->length - cntr; i++)
desc->ubuf[i] = desc->ubuf[i + cntr];
+ spin_lock_irq(&desc->iuspin);
desc->length -= cntr;
+ spin_unlock_irq(&desc->iuspin);
/* in case we had outstanding data */
if (!desc->length)
clear_bit(WDM_READ, &desc->flags);
^ permalink raw reply [flat|nested] 30+ messages in thread* [15/20] usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
2012-02-01 21:00 [00/20] 2.6.32.56-longterm review Greg KH
` (13 preceding siblings ...)
2012-02-01 20:14 ` [14/20] USB: cdc-wdm: updating desc->length must be protected by spin_lock Greg KH
@ 2012-02-01 20:14 ` Greg KH
2012-02-01 20:14 ` [16/20] USB: usbsevseg: fix max length Greg KH
` (4 subsequent siblings)
19 siblings, 0 replies; 30+ messages in thread
From: Greg KH @ 2012-02-01 20:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: torvalds, akpm, alan, Eric W. Biederman, Wolfgang Frisch
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: "Eric W. Biederman" <ebiederm@xmission.com>
commit 6d443d8499e4e59ffb949759cdded32730f8d2f6 upstream.
Calling edge_remove_sysfs_attrs from edge_disconnect is too late
as the device has already been removed from sysfs.
Do the simple and obvious thing and make edge_remove_sysfs_attrs
the port_remove method.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Reported-by: Wolfgang Frisch <wfpub@roembden.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/io_ti.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
--- a/drivers/usb/serial/io_ti.c
+++ b/drivers/usb/serial/io_ti.c
@@ -2664,15 +2664,7 @@ cleanup:
static void edge_disconnect(struct usb_serial *serial)
{
- int i;
- struct edgeport_port *edge_port;
-
dbg("%s", __func__);
-
- for (i = 0; i < serial->num_ports; ++i) {
- edge_port = usb_get_serial_port_data(serial->port[i]);
- edge_remove_sysfs_attrs(edge_port->port);
- }
}
static void edge_release(struct usb_serial *serial)
@@ -2927,6 +2919,7 @@ static struct usb_serial_driver edgeport
.disconnect = edge_disconnect,
.release = edge_release,
.port_probe = edge_create_sysfs_attrs,
+ .port_remove = edge_remove_sysfs_attrs,
.ioctl = edge_ioctl,
.set_termios = edge_set_termios,
.tiocmget = edge_tiocmget,
@@ -2957,6 +2950,7 @@ static struct usb_serial_driver edgeport
.disconnect = edge_disconnect,
.release = edge_release,
.port_probe = edge_create_sysfs_attrs,
+ .port_remove = edge_remove_sysfs_attrs,
.ioctl = edge_ioctl,
.set_termios = edge_set_termios,
.tiocmget = edge_tiocmget,
^ permalink raw reply [flat|nested] 30+ messages in thread* [16/20] USB: usbsevseg: fix max length
2012-02-01 21:00 [00/20] 2.6.32.56-longterm review Greg KH
` (14 preceding siblings ...)
2012-02-01 20:14 ` [15/20] usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method Greg KH
@ 2012-02-01 20:14 ` Greg KH
2012-02-01 20:14 ` [17/20] hwmon: (f71805f) Fix clamping of temperature limits Greg KH
` (3 subsequent siblings)
19 siblings, 0 replies; 30+ messages in thread
From: Greg KH @ 2012-02-01 20:14 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: torvalds, akpm, alan, Harrison Metzger, Stuart Pook
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Harrison Metzger <harrisonmetz@gmail.com>
commit 1097ccebe630170080c41df0edcf88e0626e9c75 upstream.
This changes the max length for the usb seven segment delcom device to 8
from 6. Delcom has both 6 and 8 variants and having 8 works fine with
devices which are only 6.
Signed-off-by: Harrison Metzger <harrisonmetz@gmail.com>
Signed-off-by: Stuart Pook <stuart@acm.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/misc/usbsevseg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/misc/usbsevseg.c
+++ b/drivers/usb/misc/usbsevseg.c
@@ -24,7 +24,7 @@
#define VENDOR_ID 0x0fc5
#define PRODUCT_ID 0x1227
-#define MAXLEN 6
+#define MAXLEN 8
/* table of devices that work with this driver */
static struct usb_device_id id_table[] = {
^ permalink raw reply [flat|nested] 30+ messages in thread* [17/20] hwmon: (f71805f) Fix clamping of temperature limits
2012-02-01 21:00 [00/20] 2.6.32.56-longterm review Greg KH
` (15 preceding siblings ...)
2012-02-01 20:14 ` [16/20] USB: usbsevseg: fix max length Greg KH
@ 2012-02-01 20:14 ` Greg KH
2012-02-01 20:14 ` [18/20] hwmon: (sht15) fix bad error code Greg KH
` (2 subsequent siblings)
19 siblings, 0 replies; 30+ messages in thread
From: Greg KH @ 2012-02-01 20:14 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: torvalds, akpm, alan, Jean Delvare, Guenter Roeck
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Jean Delvare <khali@linux-fr.org>
commit 86b2bbfdbd1fcc4a3aa62ccd3f245c40c5ad5b85 upstream.
Properly clamp temperature limits set by the user. Without this fix,
attempts to write temperature limits above the maximum supported by
the chip (255 degrees Celsius) would arbitrarily and unexpectedly
result in the limit being set to 0 degree Celsius.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hwmon/f71805f.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/drivers/hwmon/f71805f.c
+++ b/drivers/hwmon/f71805f.c
@@ -281,11 +281,11 @@ static inline long temp_from_reg(u8 reg)
static inline u8 temp_to_reg(long val)
{
- if (val < 0)
- val = 0;
- else if (val > 1000 * 0xff)
- val = 0xff;
- return ((val + 500) / 1000);
+ if (val <= 0)
+ return 0;
+ if (val >= 1000 * 0xff)
+ return 0xff;
+ return (val + 500) / 1000;
}
/*
^ permalink raw reply [flat|nested] 30+ messages in thread* [18/20] hwmon: (sht15) fix bad error code
2012-02-01 21:00 [00/20] 2.6.32.56-longterm review Greg KH
` (16 preceding siblings ...)
2012-02-01 20:14 ` [17/20] hwmon: (f71805f) Fix clamping of temperature limits Greg KH
@ 2012-02-01 20:14 ` Greg KH
2012-02-01 20:14 ` [19/20] USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19 Greg KH
2012-02-01 20:14 ` [20/20] USB: cp210x: do not map baud rates to B0 Greg KH
19 siblings, 0 replies; 30+ messages in thread
From: Greg KH @ 2012-02-01 20:14 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: torvalds, akpm, alan, Vivien Didelot, Guenter Roeck
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
commit 6edf3c30af01854c416f8654d3d5d2652470afd4 upstream.
When no platform data was supplied, returned error code was 0.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hwmon/sht15.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/hwmon/sht15.c
+++ b/drivers/hwmon/sht15.c
@@ -515,7 +515,7 @@ static int sht15_invalidate_voltage(stru
static int __devinit sht15_probe(struct platform_device *pdev)
{
- int ret = 0;
+ int ret;
struct sht15_data *data = kzalloc(sizeof(*data), GFP_KERNEL);
if (!data) {
@@ -532,6 +532,7 @@ static int __devinit sht15_probe(struct
init_waitqueue_head(&data->wait_queue);
if (pdev->dev.platform_data == NULL) {
+ ret = -EINVAL;
dev_err(&pdev->dev, "no platform data supplied");
goto err_free_data;
}
^ permalink raw reply [flat|nested] 30+ messages in thread* [19/20] USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19
2012-02-01 21:00 [00/20] 2.6.32.56-longterm review Greg KH
` (17 preceding siblings ...)
2012-02-01 20:14 ` [18/20] hwmon: (sht15) fix bad error code Greg KH
@ 2012-02-01 20:14 ` Greg KH
2012-02-01 20:14 ` [20/20] USB: cp210x: do not map baud rates to B0 Greg KH
19 siblings, 0 replies; 30+ messages in thread
From: Greg KH @ 2012-02-01 20:14 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: torvalds, akpm, alan, Renato Caldas
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Renato Caldas <rmsc@fe.up.pt>
commit 791b7d7cf69de11275e4dccec2f538eec02cbff6 upstream.
This device is a Oscilloscope/Logic Analizer/Pattern Generator/TDR,
using a Silabs CP2103 USB to UART Bridge.
Signed-off-by: Renato Caldas <rmsc@fe.up.pt>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/cp210x.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -140,6 +140,7 @@ static struct usb_device_id id_table []
{ USB_DEVICE(0x1843, 0x0200) }, /* Vaisala USB Instrument Cable */
{ USB_DEVICE(0x18EF, 0xE00F) }, /* ELV USB-I2C-Interface */
{ USB_DEVICE(0x1BE3, 0x07A6) }, /* WAGO 750-923 USB Service Cable */
+ { USB_DEVICE(0x3195, 0xF190) }, /* Link Instruments MSO-19 */
{ USB_DEVICE(0x413C, 0x9500) }, /* DW700 GPS USB interface */
{ } /* Terminating Entry */
};
^ permalink raw reply [flat|nested] 30+ messages in thread* [20/20] USB: cp210x: do not map baud rates to B0
2012-02-01 21:00 [00/20] 2.6.32.56-longterm review Greg KH
` (18 preceding siblings ...)
2012-02-01 20:14 ` [19/20] USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19 Greg KH
@ 2012-02-01 20:14 ` Greg KH
19 siblings, 0 replies; 30+ messages in thread
From: Greg KH @ 2012-02-01 20:14 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: torvalds, akpm, alan, Johan Hovold, Preston Fick
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <jhovold@gmail.com>
commit be125d9c8d59560e7cc2d6e2b65c8fd233498ab7 upstream.
We do not implement B0 hangup yet so map low baudrates to 300bps.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Cc: Preston Fick <preston.fick@silabs.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/cp210x.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -361,8 +361,8 @@ static inline int cp210x_set_config_sing
* Quantises the baud rate as per AN205 Table 1
*/
static unsigned int cp210x_quantise_baudrate(unsigned int baud) {
- if (baud <= 56) baud = 0;
- else if (baud <= 300) baud = 300;
+ if (baud <= 300)
+ baud = 300;
else if (baud <= 600) baud = 600;
else if (baud <= 1200) baud = 1200;
else if (baud <= 1800) baud = 1800;
^ permalink raw reply [flat|nested] 30+ messages in thread