Skip to contentSkip to conversation

-stable review

PATCH In review Greg KH 6 participants 16 messages Oct 7, 2005 – Oct 8, 2005

Subsystems (8)
lore
Share & tools
lore
author
#5 lore raw

PATCH 2/7 orinoco: Information leakage due to incorrect padding

In reply to Greg KH

From: Pavel Roskin <[email protected]>

The orinoco driver can send uninitialized data exposing random pieces of the system memory. This happens because data is not padded with zeroes when its length needs to be increased.

Reported by Meder Kydyraliev <[email protected]>

---
 drivers/net/wireless/orinoco.c |   14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)
drivers/net/wireless/orinoco.c +9 -5
@@ -502,9 +502,14 @@ static int orinoco_xmit(struct sk_buff *
 		return 0;
 	}
 
-	/* Length of the packet body */
-	/* FIXME: what if the skb is smaller than this? */
-	len = max_t(int,skb->len - ETH_HLEN, ETH_ZLEN - ETH_HLEN);
+	/* Check packet length, pad short packets, round up odd length */
+	len = max_t(int, ALIGN(skb->len, 2), ETH_ZLEN);
+	if (skb->len < len) {
+		skb = skb_padto(skb, len);
+		if (skb == NULL)
+			goto fail;
+	}
+	len -= ETH_HLEN;
 
 	eh = (struct ethhdr *)skb->data;
 
@@ -556,8 +561,7 @@ static int orinoco_xmit(struct sk_buff *
 		p = skb->data;
 	}
 
-	/* Round up for odd length packets */
-	err = hermes_bap_pwrite(hw, USER_BAP, p, ALIGN(data_len, 2),
+	err = hermes_bap_pwrite(hw, USER_BAP, p, data_len,
 				txfid, data_off);
 	if (err) {
 		printk(KERN_ERR "%s: Error %d writing packet to BAP\n",

--

author
#1 lore raw

PATCH 1/7 ieee1394/sbp2: fixes for hot-unplug and module unloading

In reply to Greg KH

From: Stefan Richter <[email protected]>

Fixes for reference counting problems, deadlocks, and delays when SBP-2 devices are unplugged or unbound from sbp2, or when unloading of sbp2/ ohci1394/ pcilynx is attempted.

Most often reported symptoms were hotplugs remaining undetected once a FireWire disk was unplugged since the knodemgrd kernel thread went to uninterruptible sleep, and "modprobe -r sbp2" being unable to complete because still being in use.

Patch is equivalent to commit abd559b1052e28d8b9c28aabde241f18fa89090b in 2.6.14-rc3 plus a fix which is necessary together with 2.6.13's scsi core API (linux1394.org commit r1308 by Ben Collins).

---
 drivers/ieee1394/sbp2.c |   38 +++++++++++++++++++++++++++++++++++---
 1 file changed, 35 insertions(+), 3 deletions(-)
drivers/ieee1394/sbp2.c +35 -3
@@ -596,6 +596,11 @@ static void sbp2util_mark_command_comple
 	spin_unlock_irqrestore(&scsi_id->sbp2_command_orb_lock, flags);
 }
 
+static inline int sbp2util_node_is_available(struct scsi_id_instance_data *scsi_id)
+{
+	return scsi_id && scsi_id->ne && !scsi_id->ne->in_limbo;
+}
+
 
 
 /*********************************************
@@ -631,11 +636,23 @@ static int sbp2_remove(struct device *de
 {
 	struct unit_directory *ud;
 	struct scsi_id_instance_data *scsi_id;
+	struct scsi_device *sdev;
 
 	SBP2_DEBUG("sbp2_remove");
 
 	ud = container_of(dev, struct unit_directory, device);
 	scsi_id = ud->device.driver_data;
+	if (!scsi_id)
+		return 0;
+
+	/* Trigger shutdown functions in scsi's highlevel. */
+	if (scsi_id->scsi_host)
+		scsi_unblock_requests(scsi_id->scsi_host);
+	sdev = scsi_id->sdev;
+	if (sdev) {
+		scsi_id->sdev = NULL;
+		scsi_remove_device(sdev);
+	}
 
 	sbp2_logout_device(scsi_id);
 	sbp2_remove_device(scsi_id);
@@ -944,6 +961,7 @@ alloc_fail:
 		SBP2_ERR("scsi_add_device failed");
 		return PTR_ERR(sdev);
 	}
+	scsi_device_put(sdev);
 
 	return 0;
 }
@@ -2480,7 +2498,7 @@ static int sbp2scsi_queuecommand(struct 
 	 * If scsi_id is null, it means there is no device in this slot,
 	 * so we should return selection timeout.
 	 */
-	if (!scsi_id) {
+	if (!sbp2util_node_is_available(scsi_id)) {
 		SCpnt->result = DID_NO_CONNECT << 16;
 		done (SCpnt);
 		return 0;
@@ -2683,6 +2701,18 @@ static void sbp2scsi_complete_command(st
 }
 
 
+static int sbp2scsi_slave_alloc(struct scsi_device *sdev)
+{
+	((struct scsi_id_instance_data *)sdev->host->hostdata[0])->sdev = sdev;
+	return 0;
+}
+
+static void sbp2scsi_slave_destroy(struct scsi_device *sdev)
+{
+	((struct scsi_id_instance_data *)sdev->host->hostdata[0])->sdev = NULL;
+	return;
+}
+
 static int sbp2scsi_slave_configure (struct scsi_device *sdev)
 {
 	blk_queue_dma_alignment(sdev->request_queue, (512 - 1));
@@ -2705,7 +2735,7 @@ static int sbp2scsi_abort(struct scsi_cm
 	SBP2_ERR("aborting sbp2 command");
 	scsi_print_command(SCpnt);
 
-	if (scsi_id) {
+	if (sbp2util_node_is_available(scsi_id)) {
 
 		/*
 		 * Right now, just return any matching command structures
@@ -2749,7 +2779,7 @@ static int __sbp2scsi_reset(struct scsi_
 
 	SBP2_ERR("reset requested");
 
-	if (scsi_id) {
+	if (sbp2util_node_is_available(scsi_id)) {
 		SBP2_ERR("Generating sbp2 fetch agent reset");
 		sbp2_agent_reset(scsi_id, 0);
 	}
@@ -2817,7 +2847,9 @@ static struct scsi_host_template scsi_dr
 	.eh_device_reset_handler =	sbp2scsi_reset,
 	.eh_bus_reset_handler =		sbp2scsi_reset,
 	.eh_host_reset_handler =	sbp2scsi_reset,
+	.slave_alloc =			sbp2scsi_slave_alloc,
 	.slave_configure =		sbp2scsi_slave_configure,
+	.slave_destroy =		sbp2scsi_slave_destroy,
 	.this_id =			-1,
 	.sg_tablesize =			SG_ALL,
 	.use_clustering =		ENABLE_CLUSTERING,

--

Greg KH

author
#0 lore raw

cover -stable review

This is the start of the stable review cycle for the 2.6.13.4 release. There are 7 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us 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.

These patches are sent out with a number of different people on the Cc:
line. If you wish to be a reviewer, please email [email protected] to add your name to the list. If you want to be off the reviewer list, also email us.

Responses should be made by Sunday, October 9, 24:00:00 UTC. Anything received after that time, might be too late.

thanks,

the -stable release team (i.e. the ones wearing the joker hat in the corner...)

author
#6 lore raw

PATCH 3/7 : BIC coding bug in Linux 2.6.13

From: Stephen Hemminger <[email protected]>

Please consider this change for 2.6.13-stable Since BIC is
the default congestion control algorithm, this fix is quite important.

Missing parenthesis in causes BIC to be slow in increasing congestion window.

Spotted by Injong Rhee.

---
 net/ipv4/tcp_bic.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/ipv4/tcp_bic.c +1 -1
@@ -136,7 +136,7 @@ static inline void bictcp_update(struct 
 		else if (cwnd < ca->last_max_cwnd + max_increment*(BICTCP_B-1))
 			/* slow start */
 			ca->cnt = (cwnd * (BICTCP_B-1))
-				/ cwnd-ca->last_max_cwnd;
+				/ (cwnd - ca->last_max_cwnd);
 		else
 			/* linear increase */
 			ca->cnt = cwnd / max_increment;

--

author
#7 lore raw

PATCH 4/7 sysfs: Signedness problem

In reply to Greg KH

From: Dave Jones <[email protected]>

Please consider for next 2.6.13, it is a minor security issue allowing users to turn on drm debugging when they shouldn't...

This fell through the cracks. Until Josh pointed me at
http://bugs.gentoo.org/show_bug.cgi?id=107893

---
 drivers/char/drm/drm_stub.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/char/drm/drm_stub.c +1 -1
@@ -47,7 +47,7 @@ MODULE_PARM_DESC(cards_limit, "Maximum n
 MODULE_PARM_DESC(debug, "Enable debug output");
 
 module_param_named(cards_limit, drm_cards_limit, int, 0444);
-module_param_named(debug, drm_debug, int, 0666);
+module_param_named(debug, drm_debug, int, 0600);
 
 drm_head_t **drm_heads;
 struct drm_sysfs_class *drm_class;

--

author
#14 lore raw

PATCH 6/7 Avoid 'names_cache' memory leak with CONFIG_AUDITSYSCALL

In reply to Greg KH

From: Linus Torvalds <[email protected]>

Avoid 'names_cache' memory leak with CONFIG_AUDITSYSCALL

The nameidata "last.name" is always allocated with "__getname()", and should always be free'd with "__putname()".

Using "putname()" without the underscores will leak memory, because the allocation will have been hidden from the AUDITSYSCALL code.

Arguably the real bug is that the AUDITSYSCALL code is really broken, but in the meantime this fixes the problem people see.

Reported by Robert Derr, patch by Rick Lindsley.

---
 fs/namei.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
fs/namei.c +3 -3
@@ -1557,19 +1557,19 @@ do_link:
 	if (nd->last_type != LAST_NORM)
 		goto exit;
 	if (nd->last.name[nd->last.len]) {
-		putname(nd->last.name);
+		__putname(nd->last.name);
 		goto exit;
 	}
 	error = -ELOOP;
 	if (count++==32) {
-		putname(nd->last.name);
+		__putname(nd->last.name);
 		goto exit;
 	}
 	dir = nd->dentry;
 	down(&dir->d_inode->i_sem);
 	path.dentry = __lookup_hash(&nd->last, nd->dentry, nd);
 	path.mnt = nd->mnt;
-	putname(nd->last.name);
+	__putname(nd->last.name);
 	goto do_last;
 }
 

--

author
#13 lore raw

PATCH 5/7 Fix userland FPU state corruption.

In reply to Greg KH

From: "David S. Miller" <[email protected]>

We need to use stricter memory barriers around the block load and store instructions we use to save and restore the FPU register file.

---
 arch/sparc64/kernel/entry.S |   39 +++++++++++++++++++++------------------
 arch/sparc64/kernel/rtrap.S |    7 ++++---
 arch/sparc64/lib/VISsave.S  |    8 +++++---
 3 files changed, 30 insertions(+), 24 deletions(-)
arch/sparc64/kernel/entry.S +21 -18
@@ -186,7 +186,7 @@ vmalloc_addr:
 	/* This is trivial with the new code... */
 	.globl		do_fpdis
 do_fpdis:
-	sethi		%hi(TSTATE_PEF), %g4					! IEU0
+	sethi		%hi(TSTATE_PEF), %g4
 	rdpr		%tstate, %g5
 	andcc		%g5, %g4, %g0
 	be,pt		%xcc, 1f
@@ -203,18 +203,18 @@ do_fpdis:
 	add		%g0, %g0, %g0
 	ba,a,pt		%xcc, rtrap_clr_l6
 
-1:	ldub		[%g6 + TI_FPSAVED], %g5					! Load	Group
-	wr		%g0, FPRS_FEF, %fprs					! LSU	Group+4bubbles
-	andcc		%g5, FPRS_FEF, %g0					! IEU1	Group
-	be,a,pt		%icc, 1f						! CTI
-	 clr		%g7							! IEU0
-	ldx		[%g6 + TI_GSR], %g7					! Load	Group
-1:	andcc		%g5, FPRS_DL, %g0					! IEU1
-	bne,pn		%icc, 2f						! CTI
-	 fzero		%f0							! FPA
-	andcc		%g5, FPRS_DU, %g0					! IEU1  Group
-	bne,pn		%icc, 1f						! CTI
-	 fzero		%f2							! FPA
+1:	ldub		[%g6 + TI_FPSAVED], %g5
+	wr		%g0, FPRS_FEF, %fprs
+	andcc		%g5, FPRS_FEF, %g0
+	be,a,pt		%icc, 1f
+	 clr		%g7
+	ldx		[%g6 + TI_GSR], %g7
+1:	andcc		%g5, FPRS_DL, %g0
+	bne,pn		%icc, 2f
+	 fzero		%f0
+	andcc		%g5, FPRS_DU, %g0
+	bne,pn		%icc, 1f
+	 fzero		%f2
 	faddd		%f0, %f2, %f4
 	fmuld		%f0, %f2, %f6
 	faddd		%f0, %f2, %f8
@@ -257,8 +257,10 @@ cplus_fptrap_insn_1:
 	add		%g6, TI_FPREGS + 0xc0, %g2
 	faddd		%f0, %f2, %f8
 	fmuld		%f0, %f2, %f10
-	ldda		[%g1] ASI_BLK_S, %f32	! grrr, where is ASI_BLK_NUCLEUS 8-(
+	membar		#Sync
+	ldda		[%g1] ASI_BLK_S, %f32
 	ldda		[%g2] ASI_BLK_S, %f48
+	membar		#Sync
 	faddd		%f0, %f2, %f12
 	fmuld		%f0, %f2, %f14
 	faddd		%f0, %f2, %f16
@@ -269,7 +271,6 @@ cplus_fptrap_insn_1:
 	fmuld		%f0, %f2, %f26
 	faddd		%f0, %f2, %f28
 	fmuld		%f0, %f2, %f30
-	membar		#Sync
 	b,pt		%xcc, fpdis_exit
 	 nop
 2:	andcc		%g5, FPRS_DU, %g0
@@ -286,8 +287,10 @@ cplus_fptrap_insn_2:
 	add		%g6, TI_FPREGS + 0x40, %g2
 	faddd		%f32, %f34, %f36
 	fmuld		%f32, %f34, %f38
-	ldda		[%g1] ASI_BLK_S, %f0	! grrr, where is ASI_BLK_NUCLEUS 8-(
+	membar		#Sync
+	ldda		[%g1] ASI_BLK_S, %f0
 	ldda		[%g2] ASI_BLK_S, %f16
+	membar		#Sync
 	faddd		%f32, %f34, %f40
 	fmuld		%f32, %f34, %f42
 	faddd		%f32, %f34, %f44
@@ -300,7 +303,6 @@ cplus_fptrap_insn_2:
 	fmuld		%f32, %f34, %f58
 	faddd		%f32, %f34, %f60
 	fmuld		%f32, %f34, %f62
-	membar		#Sync
 	ba,pt		%xcc, fpdis_exit
 	 nop
 3:	mov		SECONDARY_CONTEXT, %g3
@@ -311,7 +313,8 @@ cplus_fptrap_insn_3:
 	stxa		%g2, [%g3] ASI_DMMU
 	membar		#Sync
 	mov		0x40, %g2
-	ldda		[%g1] ASI_BLK_S, %f0		! grrr, where is ASI_BLK_NUCLEUS 8-(
+	membar		#Sync
+	ldda		[%g1] ASI_BLK_S, %f0
 	ldda		[%g1 + %g2] ASI_BLK_S, %f16
 	add		%g1, 0x80, %g1
 	ldda		[%g1] ASI_BLK_S, %f32
arch/sparc64/kernel/rtrap.S +4 -3
@@ -310,32 +310,33 @@ kern_fpucheck:	ldub			[%g6 + TI_FPDEPTH]
 		wr			%g1, FPRS_FEF, %fprs
 		ldx			[%o1 + %o5], %g1
 		add			%g6, TI_XFSR, %o1
-		membar			#StoreLoad | #LoadLoad
 		sll			%o0, 8, %o2
 		add			%g6, TI_FPREGS, %o3
 		brz,pn			%l6, 1f
 		 add			%g6, TI_FPREGS+0x40, %o4
 
+		membar			#Sync
 		ldda			[%o3 + %o2] ASI_BLK_P, %f0
 		ldda			[%o4 + %o2] ASI_BLK_P, %f16
+		membar			#Sync
 1:		andcc			%l2, FPRS_DU, %g0
 		be,pn			%icc, 1f
 		 wr			%g1, 0, %gsr
 		add			%o2, 0x80, %o2
+		membar			#Sync
 		ldda			[%o3 + %o2] ASI_BLK_P, %f32
 		ldda			[%o4 + %o2] ASI_BLK_P, %f48
-
 1:		membar			#Sync
 		ldx			[%o1 + %o5], %fsr
 2:		stb			%l5, [%g6 + TI_FPDEPTH]
 		ba,pt			%xcc, rt_continue
 		 nop
 5:		wr			%g0, FPRS_FEF, %fprs
-		membar			#StoreLoad | #LoadLoad
 		sll			%o0, 8, %o2
 
 		add			%g6, TI_FPREGS+0x80, %o3
 		add			%g6, TI_FPREGS+0xc0, %o4
+		membar			#Sync
 		ldda			[%o3 + %o2] ASI_BLK_P, %f32
 		ldda			[%o4 + %o2] ASI_BLK_P, %f48
 		membar			#Sync
arch/sparc64/lib/VISsave.S +5 -3
@@ -59,15 +59,17 @@ vis1:	ldub		[%g6 + TI_FPSAVED], %g3
 	be,pn		%icc, 9b
 	 add		%g6, TI_FPREGS, %g2
 	andcc		%o5, FPRS_DL, %g0
-	membar		#StoreStore | #LoadStore
 
 	be,pn		%icc, 4f
 	 add		%g6, TI_FPREGS+0x40, %g3
+	membar		#Sync
 	stda		%f0, [%g2 + %g1] ASI_BLK_P
 	stda		%f16, [%g3 + %g1] ASI_BLK_P
+	membar		#Sync
 	andcc		%o5, FPRS_DU, %g0
 	be,pn		%icc, 5f
 4:	 add		%g1, 128, %g1
+	membar		#Sync
 	stda		%f32, [%g2 + %g1] ASI_BLK_P
 
 	stda		%f48, [%g3 + %g1] ASI_BLK_P
@@ -87,7 +89,7 @@ vis1:	ldub		[%g6 + TI_FPSAVED], %g3
 	sll		%g1, 5, %g1
 	add		%g6, TI_FPREGS+0xc0, %g3
 	wr		%g0, FPRS_FEF, %fprs
-	membar		#StoreStore | #LoadStore
+	membar		#Sync
 	stda		%f32, [%g2 + %g1] ASI_BLK_P
 	stda		%f48, [%g3 + %g1] ASI_BLK_P
 	membar		#Sync
@@ -128,8 +130,8 @@ VISenterhalf:
 	be,pn		%icc, 4f
 	 add		%g6, TI_FPREGS, %g2
 
-	membar		#StoreStore | #LoadStore
 	add		%g6, TI_FPREGS+0x40, %g3
+	membar		#Sync
 	stda		%f0, [%g2 + %g1] ASI_BLK_P
 	stda		%f16, [%g3 + %g1] ASI_BLK_P
 	membar		#Sync

--

author
#15 lore raw

PATCH 7/7 key: plug request_key_auth memleak

In reply to Greg KH

From: David Howells <[email protected]>

Plug request_key_auth memleak. This can be triggered by unprivileged users, so is local DoS.

---
 security/keys/request_key_auth.c |    1 +
 1 file changed, 1 insertion(+)
security/keys/request_key_auth.c +1 -0
@@ -96,6 +96,7 @@ static void request_key_auth_destroy(str
 	kenter("{%d}", key->serial);
 
 	key_put(rka->target_key);
+	kfree(rka);
 
 } /* end request_key_auth_destroy() */
 

--

#8 lore raw

Re: [patch 4/7] sysfs: Signedness problem

In reply to Greg KH
Quoted 8 lines · Greg KH

Please consider for next 2.6.13, it is a minor security issue allowing users to turn on drm debugging when they shouldn't...

This fell through the cracks. Until Josh pointed me at
http://bugs.gentoo.org/show_bug.cgi?id=107893

For those scratching their heads, the subject line came about as a result of my following up an older issue. This has nothing to do with signedness of course :-)

Dave

#9 lore raw

Re: [stable] Re: [patch 4/7] sysfs: Signedness problem

Quoted 8 lines · Dave Jones
Quoted 6 lines · Greg KH

Please consider for next 2.6.13, it is a minor security issue allowing users to turn on drm debugging when they shouldn't...

This fell through the cracks. Until Josh pointed me at
http://bugs.gentoo.org/show_bug.cgi?id=107893

Quoted 6 lines
Quoted 2 lines

For those scratching their heads, the subject line came about as a result of my following up an older issue. This has nothing to do with signedness of course :-)

Heh, ok, care to suggest a better Subject: ?

thanks,

greg k-h

#12 lore raw

Re: [stable] Re: [patch 4/7] sysfs: Signedness problem

In reply to Dave Jones
Quoted 3 lines · * Dave Jones ([email protected]) wrote:

For those scratching their heads, the subject line came about as a result of my following up an older issue. This has nothing to do with signedness of course :-)

Yes, you're right. That's my fault for not editing the patch better before adding it to the queue.

thanks,
-chris

#11 lore raw

Re: [stable] Re: [patch 4/7] sysfs: Signedness problem

In reply to Greg KH
Quoted 9 lines · Greg Kroah-Hartman
Quoted 8 lines · Dave Jones
Quoted 6 lines · Greg KH

Please consider for next 2.6.13, it is a minor security issue allowing users to turn on drm debugging when they shouldn't...

This fell through the cracks. Until Josh pointed me at
http://bugs.gentoo.org/show_bug.cgi?id=107893

Quoted 8 lines
Quoted 6 lines
Quoted 2 lines

For those scratching their heads, the subject line came about as a result of my following up an older issue. This has nothing to do with signedness of course :-)

Heh, ok, care to suggest a better Subject: ?

"Fix incorrect permissions on DRM debug sysfs entry" ?

Dave

#2 lore raw

Re: [patch 1/7] ieee1394/sbp2: fixes for hot-unplug and module unloading

In reply to Greg KH
Quoted 6 lines · Greg KH
drivers/ieee1394/sbp2.c +5 -0
+static inline int sbp2util_node_is_available(struct scsi_id_instance_data *scsi_id)
+{
+	return scsi_id && scsi_id->ne && !scsi_id->ne->in_limbo;
+}
+

^^^^^ How did that 0x0c character sneak in there?

Grant.

#3 lore raw

Re: [stable] Re: [patch 1/7] ieee1394/sbp2: fixes for hot-unplug and module unloading

Quoted 9 lines · * Grant Coady ([email protected]) wrote:
Quoted 6 lines · Greg KH
drivers/ieee1394/sbp2.c +5 -0
+static inline int sbp2util_node_is_available(struct scsi_id_instance_data *scsi_id)
+{
+	return scsi_id && scsi_id->ne && !scsi_id->ne->in_limbo;
+}
+

^^^^^ How did that 0x0c character sneak in there?

It's from the patched file (predating the patch, yes it should go, but that's another story).

thanks,
-chris

#4 lore raw

Re: [stable] Re: [patch 1/7] ieee1394/sbp2: fixes for hot-unplug and module unloading

Quoted 5 lines · Chris Wright
Quoted 1 line · * Grant Coady ([email protected]) wrote:

^^^^^ How did that 0x0c character sneak in there?

It's from the patched file (predating the patch, yes it should go, but that's another story).

Thanks. A code formatting cleanup is on my todo list.

Signature · 3 lines
Stefan Richter
-=====-=-=-= =-=- -=---
http://arcgraph.de/sr/