2.6.35.14 longterm review
Subsystems (24)
cover 2.6.35.14 longterm review
This is the start of the longterm review cycle for the 2.6.35.14 release. There are a large number of patches in this series, which will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it.
I'm posting the patches in 100 patch chunks to not overload the mailing list. The next chunk will come tomorrow.
The full quilt queue can be found atgit://git.kernel.org/pub/scm/linux/kernel/git/longterm/longterm-queue-2.6.35
Responses should be made within 48 hours.
-Andi
PATCH 1/98 kbuild: Disable -Wunused-but-set-variable for gcc 4.6.0
2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Dave Jones <[email protected]>
[ upstream commit af0e5d565d2fffcd97d1e2d89669d627cc04e8b8 ]
Disable the new -Wunused-but-set-variable that was added in gcc 4.6.0 It produces more false positives than useful warnings.
This can still be enabled using W=1
Makefile +3 -0
@@ -546,6 +546,9 @@ ifndef CONFIG_CC_STACKPROTECTOR KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector) endif +# This warning generated too much noise in a regular build. +KBUILD_CFLAGS += $(call cc-option, -Wno-unused-but-set-variable) + ifdef CONFIG_FRAME_POINTER KBUILD_CFLAGS += -fno-omit-frame-pointer -fno-optimize-sibling-calls else
PATCH 2/98 kbuild: Fix passing -Wno-* options to gcc 4.4+
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Michal Marek <[email protected]>
[ upstream commit 8417da6f2128008c431c7d130af6cd3d9079922e ]
Starting with 4.4, gcc will happily accept -Wno-<anything> in the cc-option test and complain later when compiling a file that has some other warning. This rather unexpected behavior is intentional as per
http://gcc.gnu.org/PR28322, so work around it by testing for support of the opposite option (without the no-). Introduce a new Makefile function cc-disable-warning that does this and update two uses of cc-option in the toplevel Makefile.
Documentation/kbuild/makefiles.txt +12 -0
@@ -502,6 +502,18 @@ more details, with real examples. gcc >= 3.00. For gcc < 3.00, -malign-functions=4 is used. Note: cc-option-align uses KBUILD_CFLAGS for $(CC) options + cc-disable-warning + cc-disable-warning checks if gcc supports a given warning and returns + the commandline switch to disable it. This special function is needed, + because gcc 4.4 and later accept any unknown -Wno-* option and only + warn about it if there is another warning in the source file. + + Example: + KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable) + + In the above example, -Wno-unused-but-set-variable will be added to + KBUILD_CFLAGS only if gcc really accepts it. + cc-version cc-version returns a numerical version of the $(CC) compiler version. The format is <major><minor> where both are two digits. So for example
Makefile +2 -2
@@ -547,7 +547,7 @@ KBUILD_CFLAGS += $(call cc-option, -fno- endif # This warning generated too much noise in a regular build. -KBUILD_CFLAGS += $(call cc-option, -Wno-unused-but-set-variable) +KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable) ifdef CONFIG_FRAME_POINTER KBUILD_CFLAGS += -fno-omit-frame-pointer -fno-optimize-sibling-calls
@@ -577,7 +577,7 @@ CHECKFLAGS += $(NOSTDINC_FLAGS) KBUILD_CFLAGS += $(call cc-option,-Wdeclaration-after-statement,) # disable pointer signed / unsigned warnings in gcc 4.0 -KBUILD_CFLAGS += $(call cc-option,-Wno-pointer-sign,) +KBUILD_CFLAGS += $(call cc-disable-warning, pointer-sign) # disable invalid "can't wrap" optimizations for signed / pointers KBUILD_CFLAGS += $(call cc-option,-fno-strict-overflow)
scripts/Kbuild.include +5 -0
@@ -118,6 +118,11 @@ cc-option-yn = $(call try-run,\ cc-option-align = $(subst -functions=0,,\ $(call cc-option,-falign-functions=0,-malign-functions=0)) +# cc-disable-warning +# Usage: cflags-y += $(call cc-disable-warning,unused-but-set-variable) +cc-disable-warning = $(call try-run,\ + $(CC) $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) -W$(strip $(1)) -c -xc /dev/null -o "$$TMP",-Wno-$(strip $(1))) + # cc-version # Usage gcc-ver := $(call cc-version) cc-version = $(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-version.sh $(CC))
PATCH 3/98 Add Andi Kleen as 2.6.35 longterm maintainer
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Andi Kleen <[email protected]>
People complained about me not being in the MAINTAINERS file. So fix that.
MAINTAINERS +6 -0
@@ -3444,6 +3444,12 @@ F: drivers/lguest/ F: include/linux/lguest*.h F: arch/x86/include/asm/lguest*.h +LINUX 2.6.35 LONGTERM: +M: Andi Kleen <[email protected]> +L: [email protected] +S: Maintained +F: * + LINUX FOR IBM pSERIES (RS/6000) M: Paul Mackerras <[email protected]> W: http://www.ibm.com/linux/ltc/projects/ppc
PATCH 4/98 Remove the old V4L1 v4lgrab.c file
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Mauro Carvalho Chehab <[email protected]>
[ upstream commit 55fe25b418640fad04190103274841b2c907bacd ]
This example file uses the old V4L1 API. It also doesn't use libv4l. So, it is completely obsolete. A good example already exists at v4l-utils (v4l2grab.c):
http://git.linuxtv.org/v4l-utils.git
[AK: included in 2.6.35 because v4lgrab doesn't build without the host's linux/videodev.h]
Documentation/Makefile +1 -1
@@ -1,3 +1,3 @@ obj-m := DocBook/ accounting/ auxdisplay/ connector/ \ filesystems/ filesystems/configfs/ ia64/ laptops/ networking/ \ - pcmcia/ spi/ timers/ video4linux/ vm/ watchdog/src/ + pcmcia/ spi/ timers/ vm/ watchdog/src/
Documentation/video4linux/Makefile deleted +0 -8
@@ -1,8 +0,0 @@ -# kbuild trick to avoid linker error. Can be omitted if a module is built. -obj- := dummy.o - -# List of programs to build -hostprogs-y := v4lgrab - -# Tell kbuild to always build the programs -always := $(hostprogs-y)
Documentation/video4linux/v4lgrab.c deleted +0 -201
201 lines not on this page · raw message
PATCH 5/98 agp: fix arbitrary kernel memory writes
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Vasiliy Kulikov <[email protected]>
[ upstream commit 194b3da873fd334ef183806db751473512af29ce ]
pg_start is copied from userspace on AGPIOC_BIND and AGPIOC_UNBIND ioctl cmds of agp_ioctl() and passed to agpioc_bind_wrap(). As said in the comment, (pg_start + mem->page_count) may wrap in case of AGPIOC_BIND, and it is not checked at all in case of AGPIOC_UNBIND. As a result, user with sufficient privileges (usually "video" group) may generate either local DoS or privilege escalation.
drivers/char/agp/generic.c +8 -3
@@ -1122,8 +1122,8 @@ int agp_generic_insert_memory(struct agpreturn -EINVAL ; } -/* AK: could wrap */ -if ((pg_start + mem->page_count) > num_entries) +if (((pg_start + mem->page_count) > num_entries) || + ((pg_start + mem->page_count) < pg_start))return -EINVAL ; j = pg_start;
@@ -1157,7 +1157,7 @@ int agp_generic_remove_memory(struct agp {size_t i;struct agp_bridge_data *bridge; -int mask_type; +int mask_type, num_entries; bridge = mem->bridge;if (!bridge)
@@ -1169,6 +1169,11 @@ int agp_generic_remove_memory(struct agpif (type != mem->type)return -EINVAL ; + num_entries =agp_num_entries (); +if (((pg_start + mem->page_count) > num_entries) || + ((pg_start + mem->page_count) < pg_start)) +return -EINVAL ; + mask_type = bridge->driver->agp_type_to_mask_type (bridge, type);if (mask_type !=0 ) {/* The generic routines know nothing of memory types */
PATCH 6/98 agp: fix OOM and buffer overflow
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Vasiliy Kulikov <[email protected]>
[ upstream commit b522f02184b413955f3bc952e3776ce41edc6355 ]
page_count is copied from userspace. agp_allocate_memory() tries to check whether this number is too big, but doesn't take into account the wrap case. Also agp_create_user_memory() doesn't check whether alloc_size is calculated from num_agp_pages variable without overflow. This may lead to allocation of too small buffer with following buffer overflow.
Another problem in agp code is not addressed in the patch - kernel memory exhaustion (AGPIOC_RESERVE and AGPIOC_ALLOCATE ioctls). It is not checked whether requested pid is a pid of the caller (no check in agpioc_reserve_wrap()). Each allocation is limited to 16KB, though, there is no per-process limit. This might lead to OOM situation, which is not even solved in case of the caller death by OOM killer - the memory is allocated for another (faked) process.
drivers/char/agp/generic.c +7 -1
@@ -122,6 +122,9 @@ static struct agp_memory *agp_create_usestruct agp_memory *new;unsigned long alloc_size = num_agp_pages*sizeof (struct page *); +if (INT_MAX /sizeof (struct page *) < num_agp_pages) +return NULL ; + new =kzalloc (sizeof (struct agp_memory ),GFP_KERNEL );if (new ==NULL )return NULL ;
@@ -241,11 +244,14 @@ struct agp_memory *agp_allocate_memory(sint scratch_pages;struct agp_memory *new;size_t i; +int cur_memory;if (!bridge)return NULL ; -if ((atomic_read (&bridge->current_memory_agp) + page_count) > bridge->max_memory_agp) + cur_memory =atomic_read (&bridge->current_memory_agp); +if ((cur_memory + page_count > bridge->max_memory_agp) || + (cur_memory + page_count < page_count))return NULL ;if (type >=AGP_USER_TYPES ) {
PATCH 7/98 i8k: Tell gcc that *regs gets clobbered
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Jim Bos <[email protected]>
[ upstream commit 6b4e81db2552bad04100e7d5ddeed7e848f53b48 ]
More recent GCC caused the i8k driver to stop working, on Slackware compiler was upgraded from gcc-4.4.4 to gcc-4.5.1 after which it didn't work anymore, meaning the driver didn't load or gave total nonsensical output.
As it turned out the asm(..) statement forgot to mention it modifies the *regs variable.
Credits to Andi Kleen and Andreas Schwab for providing the fix.
drivers/char/i8k.c +3 -2
@@ -141,7 +141,7 @@ static int i8k_smm(struct smm_regs *regs "lahf\n\t" "shrl $8,%%eax\n\t" "andl $1,%%eax\n" - :"=a"(rc) + :"=a"(rc), "+m" (*regs) : "a"(regs) : "%ebx", "%ecx", "%edx", "%esi", "%edi", "memory");#else
@@ -166,7 +166,8 @@ static int i8k_smm(struct smm_regs *regs "movl %%edx,0(%%eax)\n\t" "lahf\n\t" "shrl $8,%%eax\n\t" - "andl $1,%%eax\n":"=a"(rc) + "andl $1,%%eax\n" + :"=a"(rc), "+m" (*regs) : "a"(regs) : "%ebx", "%ecx", "%edx", "%esi", "%edi", "memory");#endif
PATCH 8/98 Fix gcc 4.5.1 miscompiling drivers/char/i8k.c (again)
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Jim Bos <[email protected]>
[ upstream commit 22d3243de86bc92d874abb7c5b185d5c47aba323 ]
The fix in commit 6b4e81db2552 ("i8k: Tell gcc that *regs gets clobbered") to work around the gcc miscompiling i8k.c to add "+m (*regs)" caused register pressure problems and a build failure.
Changing the 'asm' statement to 'asm volatile' instead should prevent that and works around the gcc bug as well, so we can remove the "+m".
[ Background on the gcc bug: a memory clobber fails to mark the function
the asm resides in as non-pure (aka "__attribute__((const))"), so if the function does nothing else that triggers the non-pure logic, gcc will think that that function has no side effects at all. As a result, callers will be mis-compiled.
Adding the "+m" made gcc see that it's not a pure function, and so does "asm volatile". The problem was never really the need to mark "*regs" as changed, since the memory clobber did that part - the problem was just a bug in the gcc "pure" function analysis - Linus ]
drivers/char/i8k.c +4 -4
@@ -119,7 +119,7 @@ static int i8k_smm(struct smm_regs *regsint eax = regs->eax;#if defined(CONFIG_X86_64 ) - asm("pushq %%rax\n\t" + asmvolatile ("pushq %%rax\n\t" "movl 0(%%rax),%%edx\n\t" "pushq %%rdx\n\t" "movl 4(%%rax),%%ebx\n\t"
@@ -141,11 +141,11 @@ static int i8k_smm(struct smm_regs *regs "lahf\n\t" "shrl $8,%%eax\n\t" "andl $1,%%eax\n" - :"=a"(rc), "+m" (*regs) + :"=a"(rc) : "a"(regs) : "%ebx", "%ecx", "%edx", "%esi", "%edi", "memory");#else - asm("pushl %%eax\n\t" + asmvolatile ("pushl %%eax\n\t" "movl 0(%%eax),%%edx\n\t" "push %%edx\n\t" "movl 4(%%eax),%%ebx\n\t"
@@ -167,7 +167,7 @@ static int i8k_smm(struct smm_regs *regs "lahf\n\t" "shrl $8,%%eax\n\t" "andl $1,%%eax\n" - :"=a"(rc), "+m" (*regs) + :"=a"(rc) : "a"(regs) : "%ebx", "%ecx", "%edx", "%esi", "%edi", "memory");#endif
PATCH 9/98 USB: serial/usb_wwan, fix tty NULL dereference
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Slaby <[email protected]>
[ upstream commit 38237fd2be9421c104f84cc35665097bdce89013 ]
tty_port_tty_get may return without any problems NULL. Handle this case and do not oops in usb_wwan_indat_callback by dereferencing it.
The oops:
Unable to handle kernel paging request for data at address 0x000000d8 Faulting instruction address: 0xc0175b3c Oops: Kernel access of bad area, sig: 11 [#1] PowerPC 40x Platform last sysfs file: /sys/devices/pci0000:00/0000:00:00.0/0000:01:00.0/0000:02:09.2/usb1/idVendor Modules linked in: NIP: c0175b3c LR: c0175e7c CTR: c0215c90 REGS: c77f7d50 TRAP: 0300 Not tainted (2.6.37-rc5) MSR: 00021030 <ME,CE,IR,DR> CR: 88482028 XER: 2000005f DEAR: 000000d8, ESR: 00000000
TASK = c7141b90[1149] 'wvdial' THREAD: c2750000
GPR00: 00021030 c77f7e00 c7141b90 00000000 0000000e 00000000 0000000e c0410680
GPR08: c683db00 00000000 00000001 c03c81f8 88482028 10073ef4 ffffffb9 ffffff94
GPR16: 00000000 fde036c0 00200200 00100100 00000001 ffffff8d c34fabcc 00000000
GPR24: c71120d4 00000000 00000000 0000000e 00021030 00000000 00000000 0000000e NIP [c0175b3c] tty_buffer_request_room+0x2c/0x194
LR [c0175e7c] tty_insert_flip_string_fixed_flag+0x3c/0xb0
Call Trace:
[c77f7e00] [00000003] 0x3 (unreliable)
[c77f7e30] [c0175e7c] tty_insert_flip_string_fixed_flag+0x3c/0xb0 [c77f7e60] [c0215df4] usb_wwan_indat_callback+0x164/0x170
...
References: https://bugzilla.kernel.org/show_bug.cgi?id=24582
drivers/usb/serial/usb_wwan.c +9 -6
@@ -216,12 +216,15 @@ static void usb_wwan_indat_callback(stru __func__, status, endpoint); }else { tty =tty_port_tty_get (&port->port); -if (urb->actual_length) { -tty_insert_flip_string (tty, data, urb->actual_length); -tty_flip_buffer_push (tty); - }else -dbg ("%s: empty read urb received" , __func__); -tty_kref_put (tty); +if (tty) { +if (urb->actual_length) { +tty_insert_flip_string (tty, data, + urb->actual_length); +tty_flip_buffer_push (tty); + }else +dbg ("%s: empty read urb received" , __func__); +tty_kref_put (tty); + }/* Resubmit urb so we continue receiving */ if (status != -ESHUTDOWN ) {
PATCH 10/98 ipv6: add special mode accept_ra=2 to accept RA while configured as router
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Graf <[email protected]>
[ upstream commit 65e9b62d4503849b10bedfc29bff0473760cc597 ]
The current IPv6 behavior is to not accept router advertisements while forwarding, i.e. configured as router.
This does make sense, a router is typically not supposed to be auto configured. However there are exceptions and we should allow the current behavior to be overwritten.
Therefore this patch enables the user to overrule the "if forwarding enabled then don't listen to RAs" rule by setting accept_ra to the special value of 2.
An alternative would be to ignore the forwarding switch alltogether and solely accept RAs based on the value of accept_ra. However, I found that if not intended, accepting RAs as a router can lead to strange unwanted behavior therefore we it seems wise to only do so if the user explicitely asks for this behavior.
net/ipv6/ndisc.c +14 -4
@@ -1105,6 +1105,18 @@ errout:rtnl_set_sk_err (net,RTNLGRP_ND_USEROPT , err); } +static inline int accept_ra (struct inet6_dev *in6_dev) +{ +/* +* If forwarding is enabled, RA are not accepted unless the special +* hybrid mode (accept_ra=2) is enabled. +*/ +if (in6_dev->cnf.forwarding && in6_dev->cnf.accept_ra <2 ) +return 0 ; + +return in6_dev->cnf.accept_ra; +} +static void ndisc_router_discovery (struct sk_buff *skb) {struct ra_msg *ra_msg = (struct ra_msg *)skb_transport_header (skb);
@@ -1158,8 +1170,7 @@ static void ndisc_router_discovery(strucreturn ; } -/* skip route and link configuration on routers */ -if (in6_dev->cnf.forwarding || !in6_dev->cnf.accept_ra) +if (!accept_ra (in6_dev)) goto skip_linkparms;#ifdef CONFIG_IPV6_NDISC_NODETYPE
@@ -1309,8 +1320,7 @@ skip_linkparms: NEIGH_UPDATE_F_ISROUTER); } -/* skip route and link configuration on routers */ -if (in6_dev->cnf.forwarding || !in6_dev->cnf.accept_ra) +if (!accept_ra (in6_dev)) goto out;#ifdef CONFIG_IPV6_ROUTE_INFO
Re: [PATCH] [10/98] ipv6: add special mode accept_ra=2 to accept RA while configured as router
Quoted 64 lines · Andi Kleen
2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Graf<[email protected]>[ upstream commit
65e9b62d4503849b10bedfc29bff0473760cc597]The current IPv6 behavior is to not accept router advertisements while forwarding, i.e. configured as router.
This does make sense, a router is typically not supposed to be auto configured. However there are exceptions and we should allow the current behavior to be overwritten.
Therefore this patch enables the user to overrule the "if forwarding enabled then don't listen to RAs" rule by setting
accept_rato the special value of 2.An alternative would be to ignore the forwarding switch alltogether and solely accept RAs based on the value of
accept_ra. However, I found that if not intended, accepting RAs as a router can lead to strange unwanted behavior therefore we it seems wise to only do so if the user explicitely asks for this behavior.Signed-off-by Thomas Graf<[email protected]>Signed-off-by David S. Miller<[email protected]>Signed-off-by Andi Kleen<[email protected]>Index:
linux-2.6.35.y/net/ipv6/ndisc.c
===================================================================net/ipv6/ndisc.c +13
-2@@ -1105,6 +1105,18 @@ errout:rtnl_set_sk_err (net,RTNLGRP_ND_USEROPT , err); } +static inline int accept_ra (struct inet6_dev *in6_dev) +{ +/* +* If forwarding is enabled, RA are not accepted unless the special +* hybrid mode (accept_ra=2) is enabled. +*/ +if (in6_dev->cnf.forwarding&& in6_dev->cnf.accept_ra<2 ) +return 0 ; + +return in6_dev->cnf.accept_ra; +} +static void ndisc_router_discovery (struct sk_buff *skb) {struct ra_msg *ra_msg = (struct ra_msg *)skb_transport_header (skb);@@ -1158,8 +1170,7 @@ static void ndisc_router_discovery(strucreturn ; } -/* skip route and link configuration on routers */ -if (in6_dev->cnf.forwarding || !in6_dev->cnf.accept_ra) +if (!accept_ra (in6_dev)) goto skip_linkparms;#ifdef CONFIG_IPV6_NDISC_NODETYPE
net/ipv6/ndisc.c skip_linkparms: · line 1326
Quoted 9 lines
net/ipv6/ndisc.c +1
-2@@ -1309,8 +1320,7 @@ skip_linkparms: NEIGH_UPDATE_F_ISROUTER); } -/* skip route and link configuration on routers */ -if (in6_dev->cnf.forwarding || !in6_dev->cnf.accept_ra) +if (!accept_ra (in6_dev)) goto out;#ifdef CONFIG_IPV6_ROUTE_INFO
Hi Andi,
I only saw patches upto 38/98 so I don't know whether the following is also included but it should be. It is a corresponding patch to the one above.
author Thomas Graf <[email protected]>
Fri, 3 Sep 2010 03:04:20 +0000 (03:04 +0000)
committer David S. Miller <[email protected]>
Fri, 3 Sep 2010 16:43:14 +0000 (09:43 -0700)
commit c3bccac2fa76f1619dfe4fb7b9bee69de7f066d8
tree f2271f01bae9c3d5c0557a550d62757b0061bf63 tree | snapshot
parent 65e9b62d4503849b10bedfc29bff0473760cc597 commit | diff
ipv6: add special mode forwarding=2 to send RS while configured as router
Similar to accepting router advertisement, the IPv6 stack does not send router solicitations if forwarding is enabled.
This patch enables this behavior to be overruled by setting forwarding to the special value 2.
-
Re: [PATCH] [10/98] ipv6: add special mode accept_ra=2 to accept RA while configured as router
Quoted 3 lines
I only saw patches upto 38/98 so I don't know whether the following is also included but it should be.
It is a corresponding patch to the one above.
Added thanks.
-Andi
PATCH 11/98 mpt2sas: prevent heap overflows and unchecked reads
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Dan Rosenberg <[email protected]>
[ upstream commit a1f74ae82d133ebb2aabb19d181944b4e83e9960 ]
At two points in handling device ioctls via /dev/mpt2ctl, user-supplied length values are used to copy data from userspace into heap buffers without bounds checking, allowing controllable heap corruption and subsequently privilege escalation.
Additionally, user-supplied values are used to determine the size of a copy_to_user() as well as the offset into the buffer to be read, with no bounds checking, allowing users to read arbitrary kernel memory.
drivers/scsi/mpt2sas/mpt2sas_ctl.c +21 -2
@@ -637,6 +637,13 @@ _ctl_do_mpt_command(struct MPT2SAS_ADAPT data_out_sz = karg.data_out_size; data_in_sz = karg.data_in_size; +/* Check for overflow and wraparound */ +if (karg.data_sge_offset *4 > ioc->request_sz || + karg.data_sge_offset > (UINT_MAX /4 )) { + ret = -EINVAL ; + goto out; + } +/* copy in request message frame from user */ if (copy_from_user (mpi_request, mf, karg.data_sge_offset*4 )) { printk(KERN_ERR "failure at %s:%d/%s()!\n", __FILE__, __LINE__,
@@ -1883,7 +1890,7 @@ _ctl_diag_read_buffer(void __user *arg,Mpi2DiagBufferPostReply_t *mpi_reply;int rc, i;u8 buffer_type; -unsigned long timeleft; +unsigned long timeleft, request_size, copy_size;u16 smid;u16 ioc_status;u8 issue_reset =0 ;
@@ -1919,6 +1926,8 @@ _ctl_diag_read_buffer(void __user *arg,return -ENOMEM ; } + request_size = ioc->diag_buffer_sz[buffer_type]; +if ((karg.starting_offset %4 ) || (karg.bytes_to_read %4 )) { printk(MPT2SAS_ERR_FMT "%s: either the starting_offset " "or bytes_to_read are not 4 byte aligned\n", ioc->name,
@@ -1926,13 +1935,23 @@ _ctl_diag_read_buffer(void __user *arg,return -EINVAL ; } +if (karg.starting_offset > request_size) +return -EINVAL ; + diag_data = (void *)(request_data + karg.starting_offset);dctlprintk (ioc,printk (MPT2SAS_DEBUG_FMT "%s: diag_buffer(%p), " "offset(%d), sz(%d)\n" , ioc->name, __func__, diag_data, karg.starting_offset, karg.bytes_to_read)); +/* Truncate data on requests that are too large */ +if ((diag_data + karg.bytes_to_read < diag_data) || + (diag_data + karg.bytes_to_read > request_data + request_size)) + copy_size = request_size - karg.starting_offset; +else + copy_size = karg.bytes_to_read; +if (copy_to_user ((void __user *)uarg->diagnostic_data, - diag_data, karg.bytes_to_read)) { + diag_data, copy_size)) {printk (MPT2SAS_ERR_FMT "%s: Unable to write " "mpt_diag_read_buffer_t data @ %p\n" , ioc->name, __func__, diag_data);
PATCH 12/98 slub: fix panic with DISCONTIGMEM
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: James Bottomley <[email protected]>
commit 4a5fa3590f09999f6db41bc386bce40848fa9f63 upstream.
Slub makes assumptions about page_to_nid() which are violated by DISCONTIGMEM and !NUMA. This violation results in a panic because page_to_nid() can be non-zero for pages in the discontiguous ranges and this leads to a null return by get_node(). The assertion by the maintainer is that DISCONTIGMEM should only be allowed when NUMA is also defined. However, at least six architectures: alpha, ia64, m32r, m68k, mips, parisc violate this. The panic is a regression against slab, so just mark slub broken in the problem configuration to prevent users reporting these panics.
--- init/Kconfig | 1 + 1 file changed, 1 insertion(+)
init/Kconfig +1 -0
@@ -1087,6 +1087,7 @@ config SLAB per cpu and per node queues. config SLUB + depends on BROKEN || NUMA || !DISCONTIGMEM bool "SLUB (Unqueued Allocator)" help SLUB is a slab allocator that minimizes cache line usage
David Rientjes
NAKRe: [PATCH] [12/98] slub: fix panic with DISCONTIGMEM
init/Kconfig config SLAB · line 1093
Quoted 13 lines · Andi Kleen
Index: linux-2.6.35.y/init/Kconfig
===================================================================init/Kconfig +1
-0@@ -1087,6 +1087,7 @@ config SLAB per cpu and per node queues. config SLUB + depends on BROKEN || NUMA || !DISCONTIGMEM bool "SLUB (Unqueued Allocator)" help SLUB is a slab allocator that minimizes cache line usage
NACK, this got reverted by 21a43e397e7f ("slub: Revert '[PARISC] slub: fix panic with DISCONTIGMEM'"). Merging d9b41e0b54fd ("[PARISC] set memory ranges in N_NORMAL_MEMORY when onlined") does not require this change.
Re: [PATCH] [12/98] slub: fix panic with DISCONTIGMEM
Quoted 3 lines
NACK, this got reverted by
21a43e397e7f("slub: Revert '[PARISC] slub: fix panic with DISCONTIGMEM'"). Mergingd9b41e0b54fd("[PARISC] set memory ranges inN_NORMAL_MEMORYwhen onlined") does not require this change.
Dropped.
-Andi
PATCH 13/98 set memory ranges in N_NORMAL_MEMORY when onlined
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: David Rientjes <[email protected]>
commit d9b41e0b54fd7e164daf1e9c539c1070398aa02e upstream.
When a DISCONTIGMEM memory range is brought online as a NUMA node, it also needs to have its bet set in N_NORMAL_MEMORY. This is necessary for generic kernel code that utilizes N_NORMAL_MEMORY as a subset of N_ONLINE for memory savings.
These types of hacks can hopefully be removed once DISCONTIGMEM is either removed or abstracted away from CONFIG_NUMA.
Fixes a panic in the slub code which only initializes structures for N_NORMAL_MEMORY to save memory:
Backtrace: [<000000004021c938>] add_partial+0x28/0x98 [<000000004021faa0>] __slab_free+0x1d0/0x1d8 [<000000004021fd04>] kmem_cache_free+0xc4/0x128 [<000000004033bf9c>] ida_get_new_above+0x21c/0x2c0 [<00000000402a8980>] sysfs_new_dirent+0xd0/0x238 [<00000000402a974c>] create_dir+0x5c/0x168 [<00000000402a9ab0>] sysfs_create_dir+0x98/0x128 [<000000004033d6c4>] kobject_add_internal+0x114/0x258 [<000000004033d9ac>] kobject_add_varg+0x7c/0xa0 [<000000004033df20>] kobject_add+0x50/0x90 [<000000004033dfb4>] kobject_create_and_add+0x54/0xc8 [<00000000407862a0>] cgroup_init+0x138/0x1f0 [<000000004077ce50>] start_kernel+0x5a0/0x840 [<000000004011fa3c>] start_parisc+0xa4/0xb8 [<00000000404bb034>] packet_ioctl+0x16c/0x208 [<000000004049ac30>] ip_mroute_setsockopt+0x260/0xf20
--- arch/parisc/mm/init.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
arch/parisc/mm/init.c +3 -1
@@ -266,8 +266,10 @@ static void __init setup_bootmem(void) }memset (pfnnid_map,0xff ,sizeof (pfnnid_map)); -for (i =0 ; i < npmem_ranges; i++) +for (i =0 ; i < npmem_ranges; i++) { +node_set_state (i,N_NORMAL_MEMORY );node_set_online (i); + }#endif /*
PATCH 14/98 FLEXCOP-PCI: fix __xlate_proc_name-warning for flexcop-pci
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Patrick Boettcher <[email protected]>
commit b934c20de1398d4a82d2ecfeb588a214a910f13f upstream.
This patch fixes the warning about bad names for sys-fs and other kernel-things. The flexcop-pci driver was using '/'-characters in it, which is not good. This has been fixed in several attempts by several people, but obviously never made it into the kernel.
--- drivers/media/dvb/b2c2/flexcop-pci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/media/dvb/b2c2/flexcop-pci.c +1 -1
@@ -38,7 +38,7 @@ MODULE_PARM_DESC(debug, DEBSTATUS);#define DRIVER_VERSION "0.1" -#define DRIVER_NAME "Technisat/B2C2 FlexCop II/IIb/III Digital TV PCI Driver" +#define DRIVER_NAME "flexcop-pci"#define DRIVER_AUTHOR "Patrick Boettcher <[email protected]>"struct flexcop_pci {
PATCH 15/98 m68k/mm: Set all online nodes in N_NORMAL_MEMORY
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Michael Schmitz <[email protected]>
commit 4aac0b4815ba592052758f4b468f253d383dc9d6 upstream.
For m68k, N_NORMAL_MEMORY represents all nodes that have present memory since it does not support HIGHMEM. This patch sets the bit at the time node_present_pages has been set by free_area_init_node.
At the time the node is brought online, the node state would have to be done unconditionally since information about present memory has not yet been recorded.
If N_NORMAL_MEMORY is not accurate, slub may encounter errors since it uses this nodemask to setup per-cache kmem_cache_node data structures.
This pach is an alternative to the one proposed by David Rientjes <[email protected]> attempting to set node state immediately when bringing the node online.
--- arch/m68k/mm/motorola.c | 2 ++ 1 file changed, 2 insertions(+)
arch/m68k/mm/motorola.c +2 -0
@@ -300,6 +300,8 @@ void __init paging_init(void) zones_size[ZONE_DMA ] = m68k_memory[i].size >>PAGE_SHIFT ;free_area_init_node (i, zones_size, m68k_memory[i].addr >>PAGE_SHIFT ,NULL ); +if (node_present_pages (i)) +node_set_state (i,N_NORMAL_MEMORY ); } }
PATCH 16/98 nfs: don't lose MS_SYNCHRONOUS on remount of noac mount
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Jeff Layton <[email protected]>
commit 26c4c170731f00008f4317a2888a0a07ac99d90d upstream.
On a remount, the VFS layer will clear the MS_SYNCHRONOUS bit on the assumption that the flags on the mount syscall will have it set if the remounted fs is supposed to keep it.
In the case of "noac" though, MS_SYNCHRONOUS is implied. A remount of such a mount will lose the MS_SYNCHRONOUS flag since "sync" isn't part of the mount options.
--- fs/nfs/super.c | 9 +++++++++ 1 file changed, 9 insertions(+)
fs/nfs/super.c +9 -0
@@ -2001,6 +2001,15 @@ nfs_remount(struct super_block *sb, intif (error <0 ) goto out; +/* +* noac is a special case. It implies -o sync, but that's not +* necessarily reflected in the mtab options. do_remount_sb +* will clear MS_SYNCHRONOUS if -o sync wasn't specified in the +* remount options, so we have to explicitly reset it. +*/ +if (data->flags &NFS_MOUNT_NOAC ) + *flags |=MS_SYNCHRONOUS ; +/* compare new mount options with old ones */ error =nfs_compare_remount_data (nfss, data); out:
PATCH 17/98 NFSv4.1: Ensure state manager thread dies on last umount
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Trond Myklebust <[email protected]>
commit 47c2199b6eb5fbe38ddb844db7cdbd914d304f9c upstream.
Currently, the state manager may continue to try recovering state forever even after the last filesystem to reference that nfs_client has umounted.
--- fs/nfs/nfs4state.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
fs/nfs/nfs4state.c +2 -2
@@ -1410,7 +1410,7 @@ static void nfs4_state_manager(struct nfint status =0 ;/* Ensure exclusive access to NFSv4 state */ -for (;;) { + do { if (test_and_clear_bit(NFS4CLNT_LEASE_EXPIRED, &clp->cl_state)) { /* We're going to have to re-establish a clientid */ status = nfs4_reclaim_lease(clp);
@@ -1493,7 +1493,7 @@ static void nfs4_state_manager(struct nfbreak ;if (test_and_set_bit (NFS4CLNT_MANAGER_RUNNING , &clp->cl_state) !=0 )break ; - } + }while (atomic_read (&clp->cl_count) >1 );return ; out_error: printk(KERN_WARNING "Error: state manager failed on NFSv4 server %s"
PATCH 18/98 Input: xen-kbdfront - fix mouse getting stuck after save/restore
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Igor Mammedov <[email protected]>
commit c36b58e8a9112017c2bcc322cc98e71241814303 upstream.
Mouse gets "stuck" after restore of PV guest but buttons are in working condition.
If driver has been configured for ABS coordinates at start it will get XENKBD_TYPE_POS events and then suddenly after restore it'll start getting XENKBD_TYPE_MOTION events, that will be dropped later and they won't get into user-space.
Regression was introduced by hunk 5 and 6 of 5ea5254aa0ad269cfbd2875c973ef25ab5b5e9db
("Input: xen-kbdfront - advertise either absolute or relative coordinates").
Driver on restore should ask xen for request-abs-pointer again if it is available. So restore parts that did it before 5ea5254.
--- drivers/input/xen-kbdfront.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
drivers/input/xen-kbdfront.c +11 -1
@@ -285,7 +285,7 @@ static void xenkbd_backend_changed(struc enum xenbus_state backend_state) {struct xenkbd_info *info =dev_get_drvdata (&dev->dev); -int val; +int ret, val;switch (backend_state) {case XenbusStateInitialising:
@@ -296,6 +296,16 @@ static void xenkbd_backend_changed(struccase XenbusStateInitWait: InitWait: + ret =xenbus_scanf (XBT_NIL , info->xbdev->otherend, +"feature-abs-pointer" ,"%d" , &val); +if (ret <0 ) + val =0 ; +if (val) { + ret =xenbus_printf (XBT_NIL , info->xbdev->nodename, +"request-abs-pointer" ,"1" ); +if (ret) +pr_warning ("can't request abs-pointer\n" ); + }xenbus_switch_state (dev, XenbusStateConnected);break ;
PATCH 19/98 pmcraid: reject negative request size
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Dan Rosenberg <[email protected]>
commit 5f6279da3760ce48f478f2856aacebe0c59a39f3 upstream.
There's a code path in pmcraid that can be reached via device ioctl that causes all sorts of ugliness, including heap corruption or triggering the OOM killer due to consecutive allocation of large numbers of pages. Not especially relevant from a security perspective, since users must have CAP_SYS_ADMIN to open the character device.
First, the user can call pmcraid_chr_ioctl() with a type PMCRAID_PASSTHROUGH_IOCTL. A pmcraid_passthrough_ioctl_buffer is copied in, and the request_size variable is set to buffer->ioarcb.data_transfer_length, which is an arbitrary 32-bit signed value provided by the user.
If a negative value is provided here, bad things can happen. For example, pmcraid_build_passthrough_ioadls() is called with this request_size, which immediately calls pmcraid_alloc_sglist() with a negative size. The resulting math on allocating a scatter list can result in an overflow in the kzalloc() call (if num_elem is 0, the sglist will be smaller than expected), or if num_elem is unexpectedly large the subsequent loop will call alloc_pages() repeatedly, a high number of pages will be allocated and the OOM killer might be invoked.
Prevent this value from being negative in pmcraid_ioctl_passthrough().
--- drivers/scsi/pmcraid.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/scsi/pmcraid.c +3 -0
@@ -3528,6 +3528,9 @@ static long pmcraid_ioctl_passthrough( rc = -EFAULT ; goto out_free_buffer; } + }else if (request_size <0 ) { + rc = -EINVAL ; + goto out_free_buffer; }/* check if we have any additional command parameters */
PATCH 20/98 put stricter guards on queue dead checks
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: James Bottomley <[email protected]>
commit 86cbfb5607d4b81b1a993ff689bbd2addd5d3a9b upstream.
SCSI uses request_queue->queuedata == NULL as a signal that the queue is dying. We set this state in the sdev release function. However, this allows a small window where we release the last reference but haven't quite got to this stage yet and so something will try to take a reference in scsi_request_fn and oops. It's very rare, but we had a report here, so we're pushing this as a bug fix
The actual fix is to set request_queue->queuedata to NULL in scsi_remove_device() before we drop the reference. This causes correct automatic rejects from scsi_request_fn as people who hold additional references try to submit work and prevents anything from getting a new reference to the sdev that way.
--- drivers/scsi/scsi_sysfs.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-)
drivers/scsi/scsi_sysfs.c +8 -8
@@ -319,14 +319,8 @@ static void scsi_device_dev_release_userkfree (evt); } -if (sdev->request_queue) { - sdev->request_queue->queuedata =NULL ; -/* user context needed to free queue */ -scsi_free_queue (sdev->request_queue); -/* temporary expedient, try to catch use of queue lock -* after free of sdev */ - sdev->request_queue =NULL ; - } +/* NULL queue means the device can't be used */ + sdev->request_queue =NULL ;scsi_target_reap (scsi_target (sdev));
@@ -961,6 +955,12 @@ void __scsi_remove_device(struct scsi_deif (sdev->host->hostt->slave_destroy) sdev->host->hostt->slave_destroy (sdev);transport_destroy_device (dev); + +/* cause the request function to reject all I/O requests */ + sdev->request_queue->queuedata =NULL ; + +/* Freeing the queue signals to block that we're done */ +scsi_free_queue (sdev->request_queue);put_device (dev); }
PATCH 21/98 mmc: sdhci-pci: Fix error case in sdhci_pci_probe_slot()
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Chris Ball <[email protected]>
commit 9fdcdbb0d84922e7ccda2f717a04ea62629f7e18 upstream.
If pci_ioremap_bar() fails during probe, we "goto release;" and free the host, but then we return 0 -- which tells sdhci_pci_probe() that the probe succeeded. Since we think the probe succeeded, when we unload sdhci we'll go to sdhci_pci_remove_slot() and it will try to dereference slot->host, which is now NULL because we freed it in the error path earlier.
The patch simply sets ret appropriately, so that sdhci_pci_probe() will detect the failure immediately and bail out.
--- drivers/mmc/host/sdhci-pci.c | 1 + 1 file changed, 1 insertion(+)
drivers/mmc/host/sdhci-pci.c +1 -0
@@ -653,6 +653,7 @@ static struct sdhci_pci_slot * __devinit host->ioaddr =pci_ioremap_bar (pdev, bar);if (!host->ioaddr) {dev_err (&pdev->dev,"failed to remap registers\n" ); + ret = -ENOMEM ; goto release; }
PATCH 22/98 mmc: sdhci: Check mrq->cmd in sdhci_tasklet_finish
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Ben Dooks <[email protected]>
commit b7b4d3426d2b5ecab21578eb20d8e456a1aace8f upstream.
It seems that under certain circumstances that the sdhci_tasklet_finish() call can be entered with mrq->cmd set to NULL, causing the system to crash with a NULL pointer de-reference.
Unable to handle kernel NULL pointer dereference at virtual address 00000000 PC is at sdhci_tasklet_finish+0x34/0xe8 LR is at sdhci_tasklet_finish+0x24/0xe8
Seen on S3C6410 system.
--- drivers/mmc/host/sdhci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mmc/host/sdhci.c +1 -1
@@ -1289,7 +1289,7 @@ static void sdhci_tasklet_finish(unsigne* upon error conditions. */ if (!(host->flags &SDHCI_DEVICE_DEAD ) && - (mrq->cmd->error || + ((mrq->cmd && mrq->cmd->error) || (mrq->data && (mrq->data->error || (mrq->data->stop && mrq->data->stop->error))) || (host->quirks &SDHCI_QUIRK_RESET_AFTER_REQUEST ))) {
PATCH 23/98 mmc: sdhci: Check mrq != NULL in sdhci_tasklet_finish
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Chris Ball <[email protected]>
commit 0c9c99a765321104cc5f9c97f949382a9ba4927e upstream.
It seems that under certain circumstances the sdhci_tasklet_finish() call can be entered with mrq set to NULL, causing the system to crash with a NULL pointer de-reference.
Seen on S3C6410 system. Based on a patch by Dimitris Papastamos.
--- drivers/mmc/host/sdhci.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/mmc/host/sdhci.c +7 -0
@@ -1278,6 +1278,13 @@ static void sdhci_tasklet_finish(unsigne host = (struct sdhci_host *)param; +/* +* If this tasklet gets rescheduled while running, it will +* be run again afterwards but without any active request. +*/ +if (!host->mrq) +return ; +spin_lock_irqsave (&host->lock, flags);del_timer (&host->timer);
PATCH 24/98 USB: fix regression in usbip by setting has_tt flag
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Alan Stern <[email protected]>
commit cee6a262550f53a13acfefbc1e3e5ff35c96182c upstream.
This patch (as1460) fixes a regression in the usbip driver caused by the new check for Transaction Translators in USB-2 hubs. The root hub registered by vhci_hcd needs to have the has_tt flag set, because it can connect to low- and full-speed devices as well as high-speed devices.
--- drivers/staging/usbip/vhci_hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/staging/usbip/vhci_hcd.c +1 -1
@@ -1135,7 +1135,7 @@ static int vhci_hcd_probe(struct platforusbip_uerr ("create hcd failed\n" );return -ENOMEM ; } - + hcd->has_tt =1 ;/* this is private data for vhci_hcd */ the_controller =hcd_to_vhci (hcd);
PATCH 25/98 x86, AMD: Fix APIC timer erratum 400 affecting K8 Rev.A-E processors
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Boris Ostrovsky <[email protected]>
commit e20a2d205c05cef6b5783df339a7d54adeb50962 upstream.
Older AMD K8 processors (Revisions A-E) are affected by erratum 400 (APIC timer interrupts don't occur in C states greater than C1). This, for example, means that X86_FEATURE_ARAT flag should not be set for these parts.
This addresses regression introduced by commit b87cf80af3ba4b4c008b4face3c68d604e1715c6 ("x86, AMD: Set ARAT feature on AMD processors") where the system may become unresponsive until external interrupt (such as keyboard input) occurs. This results, for example, in time not being reported correctly, lack of progress on the system and other lockups.
--- arch/x86/kernel/cpu/amd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/kernel/cpu/amd.c +1 -1
@@ -651,7 +651,7 @@ cpu_dev_register(amd_cpu_dev);*/ const int amd_erratum_400[] = -AMD_OSVW_ERRATUM (1 ,AMD_MODEL_RANGE (0xf ,0x41 ,0x2 ,0xff ,0xf ), +AMD_OSVW_ERRATUM (1 ,AMD_MODEL_RANGE (0x0f ,0x4 ,0x2 ,0xff ,0xf ),AMD_MODEL_RANGE (0x10 ,0x2 ,0x1 ,0xff ,0xf ));
Re: [PATCH] [25/98] x86, AMD: Fix APIC timer erratum 400 affecting K8 Rev.A-E processors
Quoted 38 lines · Andi Kleen
2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Boris Ostrovsky<[email protected]>commit
e20a2d205c05cef6b5783df339a7d54adeb50962upstream.Older AMD K8 processors (Revisions A-E) are affected by erratum 400 (APIC timer interrupts don't occur in C states greater than C1). This, for example, means that
X86_FEATURE_ARATflag should not be set for these parts.This addresses regression introduced by commit
b87cf80af3ba4b4c008b4face3c68d604e1715c6("x86, AMD: Set ARAT feature on AMD processors") where the system may become unresponsive until external interrupt (such as keyboard input) occurs. This results, for example, in time not being reported correctly, lack of progress on the system and other lockups.Reported-by Joerg-Volker Peetz<[email protected]>Tested-by Joerg-Volker Peetz<[email protected]>Acked-by Borislav Petkov<[email protected]>Signed-off-by Boris Ostrovsky<[email protected]>Signed-off-by Andi Kleen<[email protected]>Signed-off-by Ingo Molnar<[email protected]>Signed-off-by Greg Kroah-Hartman<[email protected]>--- arch/x86/kernel/cpu/amd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)Index:
linux-2.6.35.y/arch/x86/kernel/cpu/amd.c
===================================================================
arch/x86/kernel/cpu/amd.c cpu_dev_register(amd_cpu_dev); · line 657
Quoted 8 lines
arch/x86/kernel/cpu/amd.c +1
-1@@ -651,7 +651,7 @@ cpu_dev_register(amd_cpu_dev);*/ const int amd_erratum_400[] = -AMD_OSVW_ERRATUM (1 ,AMD_MODEL_RANGE (0xf ,0x41 ,0x2 ,0xff ,0xf ), +AMD_OSVW_ERRATUM (1 ,AMD_MODEL_RANGE (0x0f ,0x4 ,0x2 ,0xff ,0xf ),AMD_MODEL_RANGE (0x10 ,0x2 ,0x1 ,0xff ,0xf ));
Andi, this patch is unnecessary.
It (as well as 328935e6348c6a7cb34798a68c326f4b8372e68a and 14fb57dccb6e1defe9f89a66f548fcb24c374c1d) is superseded by e9cdd343a5e42c43bcda01e609fa23089e026470 upstream
-boris
Re: [PATCH] [25/98] x86, AMD: Fix APIC timer erratum 400 affecting K8 Rev.A-E processors
Quoted 5 lines
Andi, this patch is unnecessary.
It (as well as
328935e6348c6a7cb34798a68c326f4b8372e68aand14fb57dccb6e1defe9f89a66f548fcb24c374c1d) is superseded bye9cdd343a5e42c43bcda01e609fa23089e026470upstream
Is it obsolete in 2.6.35 too?
So what should I do? Drop this one and merge some other? Or just drop?
If yes why do the other ones not have Cc: stable marks?
Thanks,
-Andi
Re: [PATCH] [25/98] x86, AMD: Fix APIC timer erratum 400 affecting K8 Rev.A-E processors
Quoted 7 lines · Andi Kleen
Quoted 5 lines
Andi, this patch is unnecessary.
It (as well as
328935e6348c6a7cb34798a68c326f4b8372e68aand14fb57dccb6e1defe9f89a66f548fcb24c374c1d) is superseded bye9cdd343a5e42c43bcda01e609fa23089e026470upstreamIs it obsolete in 2.6.35 too?
Yes.
Quoted 3 lines
So what should I do? Drop this one and merge some other? Or just drop?
Please drop it (and skip the other two that I mentioned above) and apply e9cdd343a5e42c43bcda01e609fa23089e026470.
Quoted 2 lines
If yes why do the other ones not have Cc: stable marks?
That was a mistake on my part, sorry about this.
-boris
Re: [PATCH] [25/98] x86, AMD: Fix APIC timer erratum 400 affecting K8 Rev.A-E processors
Quoted 9 lines · Boris Ostrovsky
Quoted 7 lines · Andi Kleen
Quoted 5 lines
Andi, this patch is unnecessary.
It (as well as
328935e6348c6a7cb34798a68c326f4b8372e68aand14fb57dccb6e1defe9f89a66f548fcb24c374c1d) is superseded bye9cdd343a5e42c43bcda01e609fa23089e026470upstreamIs it obsolete in 2.6.35 too?
Quoted 8 lines
Yes.
Quoted 3 lines
So what should I do? Drop this one and merge some other? Or just drop?
Please drop it (and skip the other two that I mentioned above) and apply
e9cdd343a5e42c43bcda01e609fa23089e026470.
Looks like I already had a revert and that one too. I dropped the patch+revert
-Andi
PATCH 26/98 af_unix: Only allow recv on connected seqpacket sockets.
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Eric W. Biederman <[email protected]>
commit a05d2ad1c1f391c7f514a1d1e09b5417968a7d07 upstream.
This fixes the following oops discovered by Dan Aloni:
Quoted 11 lines
Anyway, the following is the output of the Oops that I got on the Ubuntu kernel on which I first detected the problem (2.6.37-12-generic). The Oops that followed will be more useful, I guess.
[ 5594.669852] BUG: unable to handle kernel NULL pointer dereference at (null) [ 5594.681606] IP: [<ffffffff81550b7b>] unix_dgram_recvmsg+0x1fb/0x420 [ 5594.687576] PGD 2a05d067 PUD 2b951067 PMD 0 [ 5594.693720] Oops: 0002 [#1] SMP [ 5594.699888] last sysfs file:
The bug was that unix domain sockets use a pseduo packet for connecting and accept uses that psudo packet to get the socket. In the buggy seqpacket case we were allowing unconnected sockets to call recvmsg and try to receive the pseudo packet.
That is always wrong and as of commit 7361c36c5 the pseudo packet had become enough different from a normal packet that the kernel started oopsing.
Do for seqpacket_recv what was done for seqpacket_send in 2.5 and only allow it on connected seqpacket sockets.
--- net/unix/af_unix.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-)
net/unix/af_unix.c +15 -1
@@ -504,6 +504,8 @@ static int unix_dgram_connect(struct soc int, int);static int unix_seqpacket_sendmsg (struct kiocb *,struct socket *,struct msghdr *,size_t ); +static int unix_seqpacket_recvmsg (struct kiocb *,struct socket *, +struct msghdr *,size_t ,int );static const struct proto_ops unix_stream_ops = { .family =PF_UNIX ,
@@ -563,7 +565,7 @@ static const struct proto_ops unix_seqpa .setsockopt = sock_no_setsockopt, .getsockopt = sock_no_getsockopt, .sendmsg = unix_seqpacket_sendmsg, - .recvmsg = unix_dgram_recvmsg, + .recvmsg = unix_seqpacket_recvmsg, .mmap = sock_no_mmap, .sendpage = sock_no_sendpage, };
@@ -1676,6 +1678,18 @@ static int unix_seqpacket_sendmsg(structreturn unix_dgram_sendmsg (kiocb, sock, msg, len); } +static int unix_seqpacket_recvmsg (struct kiocb *iocb,struct socket *sock, +struct msghdr *msg,size_t size, +int flags) +{ +struct sock *sk = sock->sk; + +if (sk->sk_state !=TCP_ESTABLISHED ) +return -ENOTCONN ; + +return unix_dgram_recvmsg (iocb, sock, msg, size, flags); +} +static void unix_copy_addr (struct msghdr *msg,struct sock *sk) {struct unix_sock *u =unix_sk (sk);
Re: [stable] [PATCH] [26/98] af_unix: Only allow recv on connected seqpacket sockets.
Quoted 87 lines · Andi Kleen
2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Eric W. Biederman<[email protected]>commit
a05d2ad1c1f391c7f514a1d1e09b5417968a7d07upstream.This fixes the following oops discovered by Dan Aloni:
Quoted 11 lines
Anyway, the following is the output of the Oops that I got on the Ubuntu kernel on which I first detected the problem (2.6.37-12-generic). The Oops that followed will be more useful, I guess.
[ 5594.669852] BUG: unable to handle kernel NULL pointer dereference at      (null) [ 5594.681606] IP: [<ffffffff81550b7b>] unix_dgram_recvmsg+0x1fb/0x420 [ 5594.687576] PGD 2a05d067 PUD 2b951067 PMD 0 [ 5594.693720] Oops: 0002 [#1] SMP [ 5594.699888] last sysfs file:The bug was that unix domain sockets use a pseduo packet for connecting and accept uses that psudo packet to get the socket. In the buggy seqpacket case we were allowing unconnected sockets to call recvmsg and try to receive the pseudo packet.
That is always wrong and as of commit
7361c36c5the pseudo packet had become enough different from a normal packet that the kernel started oopsing.Do for
seqpacket_recvwhat was done forseqpacket_sendin 2.5 and only allow it on connected seqpacket sockets.Tested-by Dan Aloni<[email protected]>Signed-off-by Eric W. Biederman<[email protected]>Signed-off-by David S. Miller<[email protected]>Signed-off-by Greg Kroah-Hartman<[email protected]>Signed-off-by Andi Kleen<[email protected]>--- net/unix/af_unix.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-)Index:
linux-2.6.35.y/net/unix/af_unix.c
===================================================================net/unix/af_unix.c +15
-1@@ -504,6 +504,8 @@ static int unix_dgram_connect(struct soc int, int);static int unix_seqpacket_sendmsg (struct kiocb *,struct socket *,struct msghdr *,size_t ); +static int unix_seqpacket_recvmsg (struct kiocb *,struct socket *, +struct msghdr *,size_t ,int );static const struct proto_ops unix_stream_ops = { .family =PF_UNIX ,@@ -563,7 +565,7 @@ static const struct proto_ops unix_seqpa .setsockopt = sock_no_setsockopt, .getsockopt = sock_no_getsockopt, .sendmsg = unix_seqpacket_sendmsg, - .recvmsg = unix_dgram_recvmsg, + .recvmsg = unix_seqpacket_recvmsg, .mmap = sock_no_mmap, .sendpage = sock_no_sendpage, };@@ -1676,6 +1678,18 @@ static int unix_seqpacket_sendmsg(structreturn unix_dgram_sendmsg (kiocb, sock, msg, len); } +static int unix_seqpacket_recvmsg (struct kiocb *iocb,struct socket *sock, +struct msghdr *msg,size_t size, +int flags) +{ +struct sock *sk = sock->sk; + +if (sk->sk_state !=TCP_ESTABLISHED ) +return -ENOTCONN ; + +return unix_dgram_recvmsg (iocb, sock, msg, size, flags); +} +static void unix_copy_addr (struct msghdr *msg,struct sock *sk) {struct unix_sock *u =unix_sk (sk);
Quoted 4 lines
_______________________________________________
stable mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/stable
Andi - Ubuntu has reverted this patch for both Lucid (2.6.32) and Natty (2.6.38) as it appears to cause a networking regression, though we never really figured out root cause. Empirically, reverting the patch solved the issue. Eric Biederman theorized that it uncovered a user space issue (trying to read before listen), but the bug reporter seems to have lost interest in testing kernels so we couldn't ever pin it down.
http://bugs.launchpad.net/bugs/791512
We also decided that reverting this patch was likely OK because we couldn't find any Launchpad reports of the Ooops mentioned in the patch commit log, nor does a google search turn up any hits.
rtg
Signature · 1 line
Tim Gardner [email protected]
Re: [stable] [PATCH] [26/98] af_unix: Only allow recv on connected seqpacket sockets.
Quoted 6 lines
Andi - Ubuntu has reverted this patch for both Lucid (2.6.32) and Natty (2.6.38) as it appears to cause a networking regression, though we never really figured out root cause. Empirically, reverting the patch solved the issue. Eric Biederman theorized that it uncovered a user space issue (trying to read before listen), but the bug reporter seems to have lost interest in testing kernels so we couldn't ever pin it down.
http://bugs.launchpad.net/bugs/791512
We also decided that reverting this patch was likely OK because we couldn't find any Launchpad reports of the Ooops mentioned in the patch commit log, nor does a google search turn up any hits.
Thanks for the heads-up. I'm dropping it.
-Andi
Re: [stable] [PATCH] [26/98] af_unix: Only allow recv on connected seqpacket sockets.
In reply to Tim GardnerQuoted 88 lines · Tim Gardner
Quoted 87 lines · Andi Kleen
2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Eric W. Biederman<[email protected]>commit
a05d2ad1c1f391c7f514a1d1e09b5417968a7d07upstream.This fixes the following oops discovered by Dan Aloni:
Quoted 11 lines
Anyway, the following is the output of the Oops that I got on the Ubuntu kernel on which I first detected the problem (2.6.37-12-generic). The Oops that followed will be more useful, I guess.
[ 5594.669852] BUG: unable to handle kernel NULL pointer dereference at      (null) [ 5594.681606] IP: [<ffffffff81550b7b>] unix_dgram_recvmsg+0x1fb/0x420 [ 5594.687576] PGD 2a05d067 PUD 2b951067 PMD 0 [ 5594.693720] Oops: 0002 [#1] SMP [ 5594.699888] last sysfs file:The bug was that unix domain sockets use a pseduo packet for connecting and accept uses that psudo packet to get the socket. In the buggy seqpacket case we were allowing unconnected sockets to call recvmsg and try to receive the pseudo packet.
That is always wrong and as of commit
7361c36c5the pseudo packet had become enough different from a normal packet that the kernel started oopsing.Do for
seqpacket_recvwhat was done forseqpacket_sendin 2.5 and only allow it on connected seqpacket sockets.Tested-by Dan Aloni<[email protected]>Signed-off-by Eric W. Biederman<[email protected]>Signed-off-by David S. Miller<[email protected]>Signed-off-by Greg Kroah-Hartman<[email protected]>Signed-off-by Andi Kleen<[email protected]>--- net/unix/af_unix.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-)Index:
linux-2.6.35.y/net/unix/af_unix.c
===================================================================net/unix/af_unix.c +15
-1@@ -504,6 +504,8 @@ static int unix_dgram_connect(struct soc int, int);static int unix_seqpacket_sendmsg (struct kiocb *,struct socket *,struct msghdr *,size_t ); +static int unix_seqpacket_recvmsg (struct kiocb *,struct socket *, +struct msghdr *,size_t ,int );static const struct proto_ops unix_stream_ops = { .family =PF_UNIX ,@@ -563,7 +565,7 @@ static const struct proto_ops unix_seqpa .setsockopt = sock_no_setsockopt, .getsockopt = sock_no_getsockopt, .sendmsg = unix_seqpacket_sendmsg, - .recvmsg = unix_dgram_recvmsg, + .recvmsg = unix_seqpacket_recvmsg, .mmap = sock_no_mmap, .sendpage = sock_no_sendpage, };@@ -1676,6 +1678,18 @@ static int unix_seqpacket_sendmsg(structreturn unix_dgram_sendmsg (kiocb, sock, msg, len); } +static int unix_seqpacket_recvmsg (struct kiocb *iocb,struct socket *sock, +struct msghdr *msg,size_t size, +int flags) +{ +struct sock *sk = sock->sk; + +if (sk->sk_state !=TCP_ESTABLISHED ) +return -ENOTCONN ; + +return unix_dgram_recvmsg (iocb, sock, msg, size, flags); +} +static void unix_copy_addr (struct msghdr *msg,struct sock *sk) {struct unix_sock *u =unix_sk (sk);
Quoted 11 lines
Quoted 4 lines
_______________________________________________
stable mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/stableAndi - Ubuntu has reverted this patch for both Lucid (2.6.32) and Natty (2.6.38) as it appears to cause a networking regression, though we never really figured out root cause. Empirically, reverting the patch solved the issue. Eric Biederman theorized that it uncovered a user space issue (trying to read before listen), but the bug reporter seems to have lost interest in testing kernels so we couldn't ever pin it down.
No. This patch is no more likely to have caused your network regression than any other patch you added to your kernel at that time. Touching af_unix.c in a trivial way will not affect tcp/ip networking.
I am insulted that you said this change caused your problem rather than saying it was simply correlated with your problem.
Quoted 5 lines
http://bugs.launchpad.net/bugs/791512
We also decided that reverting this patch was likely OK because we couldn't find any Launchpad reports of the Ooops mentioned in the patch commit log, nor does a google search turn up any hits.
That you did not find the original bug report I find as dubious as the rest of your analysis of this patch.
The only kernels that can oops in the way that was reported are kernels that have the fix to the make it safe to pass credentials between processes in different user or pid namespaces.
My patch only affects attempting to send or recv packets on an af_unix after calling listen, where accept is the only valid operation. Only broken application can possibly care about this case.
For 2.6.32 you are not open to the chance of an oops. So shrug who cares if you defend against it.
For 2.6.38, and Andi's 2.6.35 which has the potential for an unprivileged process to trigger an oops, it seems irresponsible to me to not include this change. People who exploit kernel flaws seem good at taking random Oops's and converting them into methods for privilege escalation.
Tim your argument against the patch feels like an argument that we should revert this patch from the networking stack in Linus's kernel. Is that what you were trying to say?
Eric
Re: [stable] [PATCH] [26/98] af_unix: Only allow recv on connected seqpacket sockets.
Quoted 5 lines
For 2.6.38, and Andi's 2.6.35 which has the potential for an unprivileged process to trigger an oops, it seems irresponsible to me to not include this change. People who exploit kernel flaws seem good at taking random Oops's and converting them into methods for privilege escalation.
I'll ship 2.6.25.14 without the patch, but can you guys please come to a conclusion whether the patch is useful or not. I'll reconsider it for .15.
Thanks,
-Andi
Re: [stable] [PATCH] [26/98] af_unix: Only allow recv on connected seqpacket sockets.
Quoted 6 lines · Andi Kleen
Quoted 5 lines
For 2.6.38, and Andi's 2.6.35 which has the potential for an unprivileged process to trigger an oops, it seems irresponsible to me to not include this change. People who exploit kernel flaws seem good at taking random Oops's and converting them into methods for privilege escalation.
Quoted 7 lines
I'll ship 2.6.25.14 without the patch, but can you guys please come to a conclusion whether the patch is useful or not. I'll reconsider it for .15.
Thanks,
-Andi
I'd go with Eric's assessment. He knows way more about this then I do. I am much less confident that the problem Ubuntu experienced with 2.6.35 was related, it only felt the same (similar network issues).
rtg
Signature · 1 line
Tim Gardner [email protected]
PATCH 27/98 ARM: 6891/1: prevent heap corruption in OABI semtimedop
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Dan Rosenberg <[email protected]>
commit 0f22072ab50cac7983f9660d33974b45184da4f9 upstream.
When CONFIG_OABI_COMPAT is set, the wrapper for semtimedop does not bound the nsops argument. A sufficiently large value will cause an integer overflow in allocation size, followed by copying too much data into the allocated buffer. Fix this by restricting nsops to SEMOPM. Untested.
--- arch/arm/kernel/sys_oabi-compat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/kernel/sys_oabi-compat.c +1 -1
@@ -311,7 +311,7 @@ asmlinkage long sys_oabi_semtimedop(intlong err;int i; -if (nsops <1 ) +if (nsops <1 || nsops >SEMOPM )return -EINVAL ; sops =kmalloc (sizeof (*sops) * nsops,GFP_KERNEL );if (!sops)
PATCH 28/98 Open with O_CREAT flag set fails to open existing files on non writable directories
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Sachin Prabhu <[email protected]>
commit 1574dff8996ab1ed92c09012f8038b5566fce313 upstream.
An open on a NFS4 share using the O_CREAT flag on an existing file for which we have permissions to open but contained in a directory with no write permissions will fail with EACCES.
A tcpdump shows that the client had set the open mode to UNCHECKED which indicates that the file should be created if it doesn't exist and encountering an existing flag is not an error. Since in this case the file exists and can be opened by the user, the NFS server is wrong in attempting to check create permissions on the parent directory.
The patch adds a conditional statement to check for create permissions only if the file doesn't exist.
--- fs/nfsd/vfs.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
fs/nfsd/vfs.c +8 -1
@@ -1386,7 +1386,7 @@ nfsd_create_v3(struct svc_rqst *rqstp, s goto out;if (!(iap->ia_valid &ATTR_MODE )) iap->ia_mode =0 ; - err =fh_verify (rqstp, fhp,S_IFDIR ,NFSD_MAY_CREATE ); + err =fh_verify (rqstp, fhp,S_IFDIR ,NFSD_MAY_EXEC );if (err) goto out;
@@ -1408,6 +1408,13 @@ nfsd_create_v3(struct svc_rqst *rqstp, sif (IS_ERR (dchild)) goto out_nfserr; +/* If file doesn't exist, check for permissions to create one */ +if (!dchild->d_inode) { + err =fh_verify (rqstp, fhp,S_IFDIR ,NFSD_MAY_CREATE ); +if (err) + goto out; + } + err =fh_compose (resfhp, fhp->fh_export, dchild, fhp);if (err) goto out;
PATCH 29/98 can: Add missing socket check in can/bcm release.
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Dave Jones <[email protected]>
commit c6914a6f261aca0c9f715f883a353ae7ff51fe83 upstream.
We can get here with a NULL socket argument passed from userspace, so we need to handle it accordingly.
--- net/can/bcm.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
net/can/bcm.c +6 -1
@@ -1424,9 +1424,14 @@ static int bcm_init(struct sock *sk)static int bcm_release (struct socket *sock) {struct sock *sk = sock->sk; -struct bcm_sock *bo =bcm_sk (sk); +struct bcm_sock *bo;struct bcm_op *op, *next; +if (sk ==NULL ) +return 0 ; + + bo =bcm_sk (sk); +/* remove bcm_ops, timer, rx_unregister(), etc. */ unregister_netdevice_notifier (&bo->notifier);
PATCH 30/98 fs/partitions/ldm.c: fix oops caused by corrupted partition table
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Timo Warns <[email protected]>
commit c340b1d640001c8c9ecff74f68fd90422ae2448a upstream.
The kernel automatically evaluates partition tables of storage devices. The code for evaluating LDM partitions (in fs/partitions/ldm.c) contains a bug that causes a kernel oops on certain corrupted LDM partitions. A kernel subsystem seems to crash, because, after the oops, the kernel no longer recognizes newly connected storage devices.
The patch validates the value of vblk_size.
--- fs/partitions/ldm.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-)
fs/partitions/ldm.c +12 -4
@@ -1299,6 +1299,11 @@ static bool ldm_frag_add (const u8 *dataBUG_ON (!data || !frags); +if (size <2 *VBLK_SIZE_HEAD ) { +ldm_error ("Value of size is to small." ); +return false; + } + group =get_unaligned_be32 (data +0x08 ); rec =get_unaligned_be16 (data +0x0C ); num =get_unaligned_be16 (data +0x0E );
@@ -1306,6 +1311,10 @@ static bool ldm_frag_add (const u8 *dataldm_error ("A VBLK claims to have %d parts." , num);return false; } +if (rec >= num) { +ldm_error ("REC value (%d) exceeds NUM value (%d)" , rec, num); +return false; + } list_for_each (item, frags) { f = list_entry (item, struct frag, list);
@@ -1334,10 +1343,9 @@ found: f->map |= (1 << rec); -if (num >0 ) { - data +=VBLK_SIZE_HEAD ; - size -=VBLK_SIZE_HEAD ; - } + data +=VBLK_SIZE_HEAD ; + size -=VBLK_SIZE_HEAD ; +memcpy (f->data+rec*(size-VBLK_SIZE_HEAD )+VBLK_SIZE_HEAD , data, size);return true;
PATCH 31/98 Input: elantech - discard the first 2 positions on some firmwares
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Éric Piel <[email protected]>
commit 7f29f17b57255b6395046805a98bc663ded63fb8 upstream.
According to the Dell/Ubuntu driver, what was previously observed as "jumpy cursor" corresponds to the hardware sending incorrect data for the first two reports of a one touch finger. So let's use the same workaround as in the other driver. Also, detect another firmware version with the same behaviour, as in the other driver.
--- drivers/input/mouse/elantech.c | 21 ++++++++++----------- drivers/input/mouse/elantech.h | 7 ++++--- 2 files changed, 14 insertions(+), 14 deletions(-)
drivers/input/mouse/elantech.c +13 -13
@@ -185,7 +185,6 @@ static void elantech_report_absolute_v1(struct elantech_data *etd = psmouse->private;unsigned char *packet = psmouse->packet;int fingers; -static int old_fingers;if (etd->fw_version <0x020000 ) {/*
@@ -203,11 +202,14 @@ static void elantech_report_absolute_v1( }if (etd->jumpy_cursor) { -/* Discard packets that are likely to have bogus coordinates */ -if (fingers > old_fingers) { -elantech_debug ("discarding packet\n" ); - goto discard_packet_v1; - } +if (fingers !=1 ) { + etd->single_finger_reports =0 ; + }else if (etd->single_finger_reports <2 ) { +/* Discard first 2 reports of one finger, bogus */ + etd->single_finger_reports++; +elantech_debug ("elantech.c: discarding packet\n" ); +return ; + } }input_report_key (dev,BTN_TOUCH , fingers !=0 );
@@ -238,9 +240,6 @@ static void elantech_report_absolute_v1( }input_sync (dev); - - discard_packet_v1: - old_fingers = fingers; }/*
@@ -733,13 +732,14 @@ int elantech_init(struct psmouse *psmous etd->capabilities = param[0 ];/* -* This firmware seems to suffer from misreporting coordinates when +* This firmware suffers from misreporting coordinates when * a touch action starts causing the mouse cursor or scrolled page * to jump. Enable a workaround. */ -if (etd->fw_version ==0x020022 ) { -pr_info ("firmware version 2.0.34 detected, enabling jumpy cursor workaround\n" ); - etd->jumpy_cursor =1 ; +if (etd->fw_version ==0x020022 || etd->fw_version ==0x020600 ) { +pr_info ("elantech.c: firmware version 2.0.34/2.6.0 detected, " +"enabling jumpy cursor workaround\n" ); + etd->jumpy_cursor = true; }if (elantech_set_absolute_mode (psmouse)) {
drivers/input/mouse/elantech.h +4 -3
@@ -100,10 +100,11 @@ struct elantech_data {unsigned char reg_26;unsigned char debug;unsigned char capabilities; -unsigned char paritycheck; -unsigned char jumpy_cursor; +bool paritycheck; +bool jumpy_cursor;unsigned char hw_version; -unsigned int fw_version; +unsigned int fw_version; +unsigned int single_finger_reports;unsigned char parity[256 ]; };
PATCH 32/98 Staging: rtl8192su: Clean up in case of an error in module initialisation
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Ben Hutchings <[email protected]>
commit 9a3dfa0555130952517b9a9c3918729495aa709a upstream.
Currently various resources may be leaked in case of an error.
--- drivers/staging/rtl8192su/r8192U_core.c | 43 ++++++++++++++++++++++++++------ 1 file changed, 36 insertions(+), 7 deletions(-)
drivers/staging/rtl8192su/r8192U_core.c +36 -7
@@ -991,10 +991,11 @@ static int proc_get_stats_rx(char *page,return len; } -void rtl8192_proc_module_init (void ) +int rtl8192_proc_module_init (void ) {RT_TRACE (COMP_INIT ,"Initializing proc filesystem" ); rtl8192_proc=create_proc_entry (RTL819xU_MODULE_NAME,S_IFDIR , init_net.proc_net); +return rtl8192_proc ?0 : -ENOMEM ; }
@@ -7474,35 +7475,63 @@ static int __init rtl8192_usb_module_ini ret =ieee80211_crypto_init ();if (ret) {printk (KERN_ERR "ieee80211_crypto_init() failed %d\n" , ret); -return ret; + goto fail_crypto; } ret =ieee80211_crypto_tkip_init ();if (ret) {printk (KERN_ERR "ieee80211_crypto_tkip_init() failed %d\n" , ret); -return ret; + goto fail_crypto_tkip; } ret =ieee80211_crypto_ccmp_init ();if (ret) {printk (KERN_ERR "ieee80211_crypto_ccmp_init() failed %d\n" , ret); -return ret; + goto fail_crypto_ccmp; } ret =ieee80211_crypto_wep_init ();if (ret) {printk (KERN_ERR "ieee80211_crypto_wep_init() failed %d\n" , ret); -return ret; + goto fail_crypto_wep; }printk (KERN_INFO "\nLinux kernel driver for RTL8192 based WLAN cards\n" );printk (KERN_INFO "Copyright (c) 2007-2008, Realsil Wlan\n" );RT_TRACE (COMP_INIT ,"Initializing module" );RT_TRACE (COMP_INIT ,"Wireless extensions version %d" ,WIRELESS_EXT ); -rtl8192_proc_module_init (); -return usb_register (&rtl8192_usb_driver); + + ret =rtl8192_proc_module_init (); +if (ret) { +pr_err ("rtl8192_proc_module_init() failed %d\n" , ret); + goto fail_proc; + } + + ret =usb_register (&rtl8192_usb_driver); +if (ret) { +pr_err ("usb_register() failed %d\n" , ret); + goto fail_usb; + } + +return 0 ; + +fail_usb: +rtl8192_proc_module_remove (); +fail_proc: +ieee80211_crypto_wep_exit (); +fail_crypto_wep: +ieee80211_crypto_ccmp_exit (); +fail_crypto_ccmp: +ieee80211_crypto_tkip_exit (); +fail_crypto_tkip: +ieee80211_crypto_deinit (); +fail_crypto: +#ifdef CONFIG_IEEE80211_DEBUG +ieee80211_debug_exit (); +#endif +return ret; }
PATCH 33/98 Staging: rtl8192su: Fix procfs code for interfaces not named wlan0
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Ben Hutchings <[email protected]>
commit 41a38d9e632f7c9ec5ad8fc627567d97f4302c4a upstream.
The current code creates directories in procfs named after interfaces, but doesn't handle renaming. This can result in name collisions and consequent WARNINGs. It also means that the interface name cannot reliably be used to remove the directory - in fact the current code doesn't even try, and always uses "wlan0"!
Since the name of a proc_dir_entry is embedded in it, use that when removing it.
Add a netdev notifier to catch interface renaming, and remove and re-add the directory at this point.
--- drivers/staging/rtl8192su/r8192U_core.c | 35 +++++++++++++++++++++++++++++--- 1 file changed, 32 insertions(+), 3 deletions(-)
drivers/staging/rtl8192su/r8192U_core.c +32 -3
@@ -27,6 +27,7 @@#include <linux/vmalloc.h> #include <linux/slab.h> #include <linux/eeprom_93cx6.h> +#include <linux/notifier.h> #undef LOOP_TEST#undef DUMP_RX
@@ -162,6 +163,8 @@ MODULE_PARM_DESC(channels," Channel bitmstatic int __devinit rtl8192_usb_probe (struct usb_interface *intf,const struct usb_device_id *id); static void __devexit rtl8192_usb_disconnect(struct usb_interface *intf); +static const struct net_device_ops rtl8192_netdev_ops; +static struct notifier_block proc_netdev_notifier;static struct usb_driver rtl8192_usb_driver = { .name = RTL819xU_MODULE_NAME,/* Driver name */
@@ -993,14 +996,22 @@ static int proc_get_stats_rx(char *page,int rtl8192_proc_module_init (void ) { +int ret; +RT_TRACE (COMP_INIT ,"Initializing proc filesystem" ); rtl8192_proc=create_proc_entry (RTL819xU_MODULE_NAME,S_IFDIR , init_net.proc_net); -return rtl8192_proc ?0 : -ENOMEM ; +if (!rtl8192_proc) +return -ENOMEM ; + ret =register_netdevice_notifier (&proc_netdev_notifier); +if (ret) +remove_proc_entry (RTL819xU_MODULE_NAME, init_net.proc_net); +return ret; }void rtl8192_proc_module_remove (void ) { +unregister_netdevice_notifier (&proc_netdev_notifier);remove_proc_entry (RTL819xU_MODULE_NAME, init_net.proc_net); }
@@ -1028,8 +1039,7 @@ void rtl8192_proc_remove_one(struct net_remove_proc_entry ("registers-e" , priv->dir_dev);// remove_proc_entry("cck-registers",priv->dir_dev); // remove_proc_entry("ofdm-registers",priv->dir_dev); -//remove_proc_entry(dev->name, rtl8192_proc); -remove_proc_entry ("wlan0" , rtl8192_proc); +remove_proc_entry (priv->dir_dev->name, rtl8192_proc); priv->dir_dev =NULL ; } }
@@ -1146,6 +1156,25 @@ void rtl8192_proc_init_one(struct net_de dev->name); } } + +static int proc_netdev_event (struct notifier_block *this, +unsigned long event,void *ptr) +{ +struct net_device *net_dev = ptr; + +if (net_dev->netdev_ops == &rtl8192_netdev_ops && + event ==NETDEV_CHANGENAME ) { +rtl8192_proc_remove_one (net_dev); +rtl8192_proc_init_one (net_dev); + } + +return NOTIFY_DONE ; +} + +static struct notifier_block proc_netdev_notifier = { + .notifier_call = proc_netdev_event, +}; +/**************************************************************************** -----------------------------MISC STUFF------------------------- *****************************************************************************/
PATCH 34/98 USB: teach "devices" file about Wireless and SuperSpeed USB
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Alan Stern <[email protected]>
commit 834e2312e7a384877a876b0d34dffc3046c96bcb upstream.
USB: teach "devices" file about Wireless and SuperSpeed USB
The /sys/kernel/debug/usb/devices file doesn't know about Wireless or SuperSpeed USB. This patch (as1416b) teaches it, and updates the Documentation/usb/proc_sub_info.txt file accordingly.
[Julien Blache: The original commit also added the correct speed for
USB_SPEED_WIRELESS, I removed it as it's not supported in 2.6.32.]
--- Documentation/usb/proc_usb_info.txt | 36 +++++++++++++++++++++++------------- drivers/usb/core/devices.c | 10 ++++++---- 2 files changed, 29 insertions(+), 17 deletions(-)
Documentation/usb/proc_usb_info.txt +23 -13
@@ -1,12 +1,17 @@ /proc/bus/usb filesystem output =============================== -(version 2003.05.30) +(version 2010.09.13) The usbfs filesystem for USB devices is traditionally mounted at /proc/bus/usb. It provides the /proc/bus/usb/devices file, as well as the /proc/bus/usb/BBB/DDD files. +In many modern systems the usbfs filsystem isn't used at all. Instead +USB device nodes are created under /dev/usb/ or someplace similar. The +"devices" file is available in debugfs, typically as +/sys/kernel/debug/usb/devices. + **NOTE**: If /proc/bus/usb appears empty, and a host controller driver has been linked, then you need to mount the
@@ -106,8 +111,8 @@ Legend: Topology info: -T: Bus=dd Lev=dd Prnt=dd Port=dd Cnt=dd Dev#=ddd Spd=ddd MxCh=dd -| | | | | | | | |__MaxChildren +T: Bus=dd Lev=dd Prnt=dd Port=dd Cnt=dd Dev#=ddd Spd=dddd MxCh=dd +| | | | | | | | |__MaxChildren | | | | | | | |__Device Speed in Mbps | | | | | | |__DeviceNumber | | | | | |__Count of devices at this level
@@ -120,8 +125,13 @@ T: Bus=dd Lev=dd Prnt=dd Port=dd Cnt=dd Speed may be: 1.5 Mbit/s for low speed USB 12 Mbit/s for full speed USB - 480 Mbit/s for high speed USB (added for USB 2.0) - + 480 Mbit/s for high speed USB (added for USB 2.0); + also used for Wireless USB, which has no fixed speed + 5000 Mbit/s for SuperSpeed USB (added for USB 3.0) + + For reasons lost in the mists of time, the Port number is always + too low by 1. For example, a device plugged into port 4 will + show up with "Port=03". Bandwidth info: B: Alloc=ddd/ddd us (xx%), #Int=ddd, #Iso=ddd
@@ -291,7 +301,7 @@ Here's an example, from a system which h an external hub connected to the root hub, and a mouse and a serial converter connected to the external hub. -T: Bus=00 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 +T: Bus=00 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 28/900 us ( 3%), #Int= 2, #Iso= 0 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0000 ProdID=0000 Rev= 0.00
@@ -301,21 +311,21 @@ C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms -T: Bus=00 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 4 +T: Bus=00 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 4 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0451 ProdID=1446 Rev= 1.00 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=255ms -T: Bus=00 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=1.5 MxCh= 0 +T: Bus=00 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=1.5 MxCh= 0 D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=04b4 ProdID=0001 Rev= 0.00 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=mouse E: Ad=81(I) Atr=03(Int.) MxPS= 3 Ivl= 10ms -T: Bus=00 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 4 Spd=12 MxCh= 0 +T: Bus=00 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0565 ProdID=0001 Rev= 1.08 S: Manufacturer=Peracom Networks, Inc.
@@ -330,12 +340,12 @@ E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl= Selecting only the "T:" and "I:" lines from this (for example, by using "procusb ti"), we have: -T: Bus=00 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 -T: Bus=00 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 4 +T: Bus=00 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 +T: Bus=00 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 4 I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub -T: Bus=00 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=1.5 MxCh= 0 +T: Bus=00 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=1.5 MxCh= 0 I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=mouse -T: Bus=00 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 4 Spd=12 MxCh= 0 +T: Bus=00 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 4 Spd=12 MxCh= 0 I: If#= 0 Alt= 0 #EPs= 3 Cls=00(>ifc ) Sub=00 Prot=00 Driver=serial
drivers/usb/core/devices.c +6 -4
@@ -66,8 +66,8 @@#define ALLOW_SERIAL_NUMBER static const char *format_topo = -/* T: Bus=dd Lev=dd Prnt=dd Port=dd Cnt=dd Dev#=ddd Spd=ddd MxCh=dd */ -"\nT: Bus=%2.2d Lev=%2.2d Prnt=%2.2d Port=%2.2d Cnt=%2.2d Dev#=%3d Spd=%3s MxCh=%2d\n" ; +/* T: Bus=dd Lev=dd Prnt=dd Port=dd Cnt=dd Dev#=ddd Spd=dddd MxCh=dd */ +"\nT: Bus=%2.2d Lev=%2.2d Prnt=%2.2d Port=%2.2d Cnt=%2.2d Dev#=%3d Spd=%-4s MxCh=%2d\n" ;static const char *format_string_manufacturer = /* S: Manufacturer=xxxx */
@@ -521,11 +521,13 @@ static ssize_t usb_device_dump(char __us speed ="1.5" ;break ;case USB_SPEED_UNKNOWN :/* usb 1.1 root hub code */ case USB_SPEED_FULL : - speed ="12 " ;break ; + speed ="12" ;break ;case USB_SPEED_HIGH : speed ="480" ;break ; +case USB_SPEED_SUPER : + speed ="5000" ;break ;default : - speed ="?? " ; + speed ="??" ; } data_end = pages_start + sprintf(pages_start, format_topo, bus->busnum, level, parent_devnum,
PATCH 35/98 SUNRPC: fix NFS client over TCP hangs due to packet loss (Bug 16494)
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Andy Chittenden <[email protected]>
commit 669502ff31d7dba1849aec7ee2450a3c61f57d39 upstream.
When reusing a TCP connection, ensure that it's aborted if a previous shutdown attempt has been made on that connection so that the RPC over TCP recovery mechanism succeeds.
--- net/sunrpc/xprtsock.c | 28 ++++++++++++++++++++++------ 1 file changed, 22 insertions(+), 6 deletions(-)
net/sunrpc/xprtsock.c +22 -6
@@ -1307,10 +1307,11 @@ static void xs_tcp_state_change(struct sif (!(xprt =xprt_from_sock (sk))) goto out;dprintk ("RPC: xs_tcp_state_change client %p...\n" , xprt); -dprintk ("RPC: state %x conn %d dead %d zapped %d\n" , +dprintk ("RPC: state %x conn %d dead %d zapped %d sk_shutdown %d\n" , sk->sk_state,xprt_connected (xprt),sock_flag (sk,SOCK_DEAD ), -sock_flag (sk,SOCK_ZAPPED )); +sock_flag (sk,SOCK_ZAPPED ), + sk->sk_shutdown);switch (sk->sk_state) {case TCP_ESTABLISHED :
@@ -1781,10 +1782,25 @@ static void xs_tcp_reuse_connection(stru {unsigned int state = transport->inet->sk_state; -if (state ==TCP_CLOSE && transport->sock->state ==SS_UNCONNECTED ) -return ; -if ((1 << state) & (TCPF_ESTABLISHED |TCPF_SYN_SENT )) -return ; +if (state ==TCP_CLOSE && transport->sock->state ==SS_UNCONNECTED ) { +/* we don't need to abort the connection if the socket +* hasn't undergone a shutdown +*/ +if (transport->inet->sk_shutdown ==0 ) +return ; +dprintk ("RPC: %s: TCP_CLOSEd and sk_shutdown set to %d\n" , + __func__, transport->inet->sk_shutdown); + } +if ((1 << state) & (TCPF_ESTABLISHED |TCPF_SYN_SENT )) { +/* we don't need to abort the connection if the socket +* hasn't undergone a shutdown +*/ +if (transport->inet->sk_shutdown ==0 ) +return ; +dprintk ("RPC: %s: ESTABLISHED/SYN_SENT " +"sk_shutdown set to %d\n" , + __func__, transport->inet->sk_shutdown); + }xs_abort_connection (xprt, transport); }
PATCH 36/98 nfs4: Ensure that ACL pages sent over NFS were not allocated from the slab (v3)
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Neil Horman <[email protected]>
commit e9e3d724e2145f5039b423c290ce2b2c3d8f94bc upstream.
The "bad_page()" page allocator sanity check was reported recently (call chain as follows):
bad_page+0x69/0x91 free_hot_cold_page+0x81/0x144 skb_release_data+0x5f/0x98 __kfree_skb+0x11/0x1a tcp_ack+0x6a3/0x1868 tcp_rcv_established+0x7a6/0x8b9 tcp_v4_do_rcv+0x2a/0x2fa tcp_v4_rcv+0x9a2/0x9f6 do_timer+0x2df/0x52c ip_local_deliver+0x19d/0x263 ip_rcv+0x539/0x57c netif_receive_skb+0x470/0x49f :virtio_net:virtnet_poll+0x46b/0x5c5 net_rx_action+0xac/0x1b3 __do_softirq+0x89/0x133 call_softirq+0x1c/0x28 do_softirq+0x2c/0x7d do_IRQ+0xec/0xf5 default_idle+0x0/0x50 ret_from_intr+0x0/0xa default_idle+0x29/0x50 cpu_idle+0x95/0xb8 start_kernel+0x220/0x225 _sinittext+0x22f/0x236
It occurs because an skb with a fraglist was freed from the tcp retransmit queue when it was acked, but a page on that fraglist had PG_Slab set (indicating it was allocated from the Slab allocator (which means the free path above can't safely free it via put_page.
We tracked this back to an nfsv4 setacl operation, in which the nfs code attempted to fill convert the passed in buffer to an array of pages in __nfs4_proc_set_acl, which gets used by the skb->frags list in xs_sendpages. __nfs4_proc_set_acl just converts each page in the buffer to a page struct via virt_to_page, but the vfs allocates the buffer via kmalloc, meaning the PG_slab bit is set. We can't create a buffer with kmalloc and free it later in the tcp ack path with put_page, so we need to either:
1) ensure that when we create the list of pages, no page struct has PG_Slab set
or
2) not use a page list to send this data
Given that these buffers can be multiple pages and arbitrarily sized, I think (1) is the right way to go. I've written the below patch to allocate a page from the buddy allocator directly and copy the data over to it. This ensures that we have a put_page free-able page for every entry that winds up on an skb frag list, so it can be safely freed when the frame is acked. We do a put page on each entry after the rpc_call_sync call so as to drop our own reference count to the page, leaving only the ref count taken by tcp_sendpages. This way the data will be properly freed when the ack comes in
Successfully tested by myself to solve the above oops.
Note, as this is the result of a setacl operation that exceeded a page of data, I think this amounts to a local DOS triggerable by an uprivlidged user, so I'm CCing security on this as well.
--- fs/nfs/nfs4proc.c | 43 +++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 41 insertions(+), 2 deletions(-)
fs/nfs/nfs4proc.c +41 -2
@@ -3275,6 +3275,35 @@ static void buf_to_pages(const void *buf } } +static int buf_to_pages_noslab (const void *buf,size_t buflen, +struct page **pages,unsigned int *pgbase) +{ +struct page *newpage, **spages; +int rc =0 ; +size_t len; + spages = pages; + +do { + len =min (PAGE_CACHE_SIZE , buflen); + newpage =alloc_page (GFP_KERNEL ); + +if (newpage ==NULL ) + goto unwind; +memcpy (page_address (newpage), buf, len); + buf += len; + buflen -= len; + *pages++ = newpage; + rc++; + }while (buflen !=0 ); + +return rc; + +unwind: +for (; rc >0 ; rc--) +__free_page (spages[rc-1 ]); +return -ENOMEM ; +} +struct nfs4_cached_acl {int cached;size_t len;
@@ -3441,13 +3470,23 @@ static int __nfs4_proc_set_acl(struct in .rpc_argp = &arg, .rpc_resp = &res, }; -int ret; +int ret, i;if (!nfs4_server_supports_acls (server))return -EOPNOTSUPP ; + i =buf_to_pages_noslab (buf, buflen, arg.acl_pages, &arg.acl_pgbase); +if (i <0 ) +return i;nfs_inode_return_delegation (inode); -buf_to_pages (buf, buflen, arg.acl_pages, &arg.acl_pgbase); ret =nfs4_call_sync (server, &msg, &arg, &res,1 ); + +/* +* Free each page after tx, so the only ref left is +* held by the network stack +*/ +for (; i >0 ; i--) +put_page (pages[i-1 ]); +nfs_access_zap_cache (inode);nfs_zap_acl_cache (inode);return ret;
PATCH 37/98 nfs: fix compilation warning
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Jovi Zhang <[email protected]>
commit 43b7c3f051dea504afccc39bcb56d8e26c2e0b77 upstream.
this commit fix compilation warning as following:linux-2.6/fs/nfs/nfs4proc.c:3265: warning: comparison of distinct pointer types lacks a cast
--- fs/nfs/nfs4proc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/nfs/nfs4proc.c +1 -1
@@ -3284,7 +3284,7 @@ static int buf_to_pages_noslab(const voi spages = pages; do { - len = min(PAGE_CACHE_SIZE, buflen); + len = min_t(size_t, PAGE_CACHE_SIZE, buflen); newpage = alloc_page(GFP_KERNEL); if (newpage == NULL)
PATCH 38/98 Fix corrupted OSF partition table parsing
In reply to Andi Kleen2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Timo Warns <[email protected]>
commit 1eafbfeb7bdf59cfe173304c76188f3fd5f1fd05 upstream.
The kernel automatically evaluates partition tables of storage devices. The code for evaluating OSF partitions contains a bug that leaks data from kernel heap memory to userspace for certain corrupted OSF partitions.
In more detail:
for (i = 0 ; i < le16_to_cpu(label->d_npartitions); i++, partition++) {iterates from 0 to d_npartitions - 1, where d_npartitions is read from the partition table without validation and partition is a pointer to an array of at most 8 d_partitions.
Add the proper and obvious validation.
[ Changed the patch trivially to not repeat the whole le16_to_cpu()
thing, and to use an explicit constant for the magic value '8' ]
--- fs/partitions/osf.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
fs/partitions/osf.c +10 -2
@@ -10,10 +10,13 @@#include "check.h" #include "osf.h" +#define MAX_OSF_PARTITIONS 8 +int osf_partition (struct parsed_partitions *state) {int i;int slot =1 ; +unsigned int npartitions;Sector sect;unsigned char *data; struct disklabel {
@@ -45,7 +48,7 @@ int osf_partition(struct parsed_partitiou8 p_fstype;u8 p_frag;__le16 p_cpg; - } d_partitions[8 ]; + } d_partitions[MAX_OSF_PARTITIONS ]; } * label;struct d_partition * partition;
@@ -63,7 +66,12 @@ int osf_partition(struct parsed_partitioput_dev_sector (sect);return 0 ; } -for (i =0 ; i <le16_to_cpu (label->d_npartitions); i++, partition++) { + npartitions =le16_to_cpu (label->d_npartitions); +if (npartitions >MAX_OSF_PARTITIONS ) { +put_dev_sector (sect); +return 0 ; + } +for (i =0 ; i < npartitions; i++, partition++) {if (slot == state->limit)break ;if (le32_to_cpu (partition->p_size))