From owner-freebsd-audit Mon Feb 4 3:25: 9 2002 Delivered-To: freebsd-audit@freebsd.org Received: from prg.traveller.cz (prg.traveller.cz [193.85.2.77]) by hub.freebsd.org (Postfix) with ESMTP id 9E47937B41F; Mon, 4 Feb 2002 03:24:56 -0800 (PST) Received: from prg.traveller.cz (localhost [127.0.0.1]) by prg.traveller.cz (8.12.1[KQ-CZ](1)/8.12.1/pukvis) with ESMTP id g14BOjG2038655; Mon, 4 Feb 2002 12:24:45 +0100 (CET) Received: from localhost (mime@localhost) by prg.traveller.cz (8.12.1[KQ-CZ](1)/pukvis) with ESMTP id g14BOisN038652; Mon, 4 Feb 2002 12:24:44 +0100 (CET) Date: Mon, 4 Feb 2002 12:24:44 +0100 (CET) From: Michal Mertl To: audit@freebsd.org Cc: jhb@freebsd.org, Subject: request for review: i386 64bit atomic patch Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --- atomic.h.ori Sat Feb 2 12:31:36 2002 +++ atomic.h Mon Feb 4 12:08:05 2002 @@ -407,5 +407,162 @@ return (result); } #endif /* !defined(WANT_FUNCTIONS) */ + +#if 1 +#define _ATOMIC_HAVE_QUAD +#endif + +#ifdef _ATOMIC_HAVE_QUAD +#define atomic_set_acq_64 atomic_set_64 +#define atomic_set_rel_64 atomic_set_64 +#define atomic_clear_acq_64 atomic_clear_64 +#define atomic_clear_rel_64 atomic_clear_64 +#define atomic_add_acq_64 atomic_add_64 +#define atomic_add_rel_64 atomic_add_64 +#define atomic_subtract_acq_64 atomic_subtract_64 +#define atomic_subtract_rel_64 atomic_subtract_64 +#define atomic_cmpset_acq_64 atomic_cmpset_64 +#define atomic_cmpset_rel_64 atomic_cmpset_64 +#define atomic_readandclear_64 atomic_readandclear_64 + +#if !defined(KLD_MODULE) + +static __inline int +atomic_cmpset_64(volatile u_int64_t *dst, u_int64_t exp, u_int64_t src) +{ + int res; + + __asm __volatile ( + " " MPLOCKED " " + " cmpxchg8b %1 ; " + " setz %%al ; " + " movzbl %%al,%0 ; " + "#atomic_cmpset_64" + : "=a" (res), /* 0 */ + "+m" (*(dst)) /* 1 */ + : "a" ((u_long)exp), + "d" ((u_long)((u_long *)&exp)[1]), + "b" ((u_long)src), + "c" ((u_long)((u_long *)&src)[1]) + : "memory" ); + return res; +} + +static __inline void +atomic_store_rel_64(volatile u_int64_t *p, u_int64_t v) +{ + u_int64_t exp, src; + + do { + exp = *p; + src = v; + } while (atomic_cmpset_64(p, exp, src) == 0); +} + + +static __inline void +atomic_add_64(volatile u_int64_t *p, u_int64_t v) +{ +#if 1 +/* + * Generic implementation (below) is about 20% slower on p2. + * We may need to use this function in time-critical contexts + * (e.g. 64-bit counters). + */ + __asm __volatile ( + " movl (%0),%%eax ; " + " movl 4(%0),%%edx ; " + " 1:movl (%1),%%ebx ; " + " movl 4(%1),%%ecx ; " + " addl %%eax,%%ebx ; " + " adcl %%edx,%%ecx ; " + " " MPLOCKED " " + " cmpxchg8b (%0) ; " + " jnz 1b ; " + "#atomic_add_64" + : + : "S" (p), /* 0 */ + "D" (&v) /* 1 */ + : "eax", "ebx", "ecx", "edx", "memory" ); +#else + u_int64_t exp, src; + + do { + exp = *p; + src = exp + v; + } while (atomic_cmpset_64(p, exp, src) == 0); +#endif +} + +static __inline void +atomic_subtract_64(volatile u_int64_t *p, u_int64_t v) +{ + u_int64_t exp, src; + + do { + exp = *p; + src = exp - v; + } while (atomic_cmpset_64(p, exp, src) == 0); +} + +static __inline void +atomic_clear_64(volatile u_int64_t *p, u_int64_t v) +{ + u_int64_t exp, src, notv = ~v; + + do { + exp = *p; + src = exp & notv; + } while (atomic_cmpset_64(p, exp, src) == 0); +} + +static __inline void +atomic_set_64(volatile u_int64_t *p, u_int64_t v) +{ + u_int64_t exp, src; + + do { + exp = *p; + src = exp | v; + } while (atomic_cmpset_64(p, exp, src) == 0); +} + +static __inline u_int64_t +atomic_load_acq_64(volatile u_int64_t *p) +{ + u_int64_t exp; + + do { + exp = *p; + } while (atomic_cmpset_64(p, exp, exp) == 0); + return (exp); +} + +static __inline u_int64_t +atomic_readandclear_64(volatile u_int64_t *p) +{ + u_int64_t exp; + + do { + exp = *p; + } while (atomic_cmpset_64(p, exp, 0) == 0); + return (exp); +} + +#else /* defined(KLD_MODULE) */ + +void atomic_set_64(volatile u_int64_t *, u_int64_t); +void atomic_store_rel_64(volatile u_int64_t *, u_int64_t); +void atomic_clear_64(volatile u_int64_t *, u_int64_t); +void atomic_add_64(volatile u_int64_t *, u_int64_t); +void atomic_subtract_64(volatile u_int64_t *, u_int64_t); +u_int64_t atomic_load_acq_64(volatile u_int64_t *); +int atomic_cmpset_64(volatile u_int64_t *,u_int64_t,u_int64_t); +u_int64_t atomic_readandclear_64(volatile u_int64_t *); +#endif + +#endif /*defined(_ATOMIC_HAVE_QUAD)*/ + #endif /* !defined(LOCORE) */ + #endif /* ! _MACHINE_ATOMIC_H_ */ ------------ Thank Peter and John for your advices. What do you think now? Can someone commit it? -- Michal Mertl mime@traveller.cz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Mon Feb 4 12:19:15 2002 Delivered-To: freebsd-audit@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id BA3A437B422; Mon, 4 Feb 2002 12:19:04 -0800 (PST) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id HAA07459; Tue, 5 Feb 2002 07:18:57 +1100 (EDT) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37645) with ESMTP id <01KDWNFYN7QO5IK551@cim.alcatel.com.au>; Tue, 5 Feb 2002 07:19:04 +1100 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.6/8.11.6) id g14KIsH85819; Tue, 05 Feb 2002 07:18:54 +1100 Content-return: prohibited Date: Tue, 05 Feb 2002 07:18:54 +1100 From: Peter Jeremy Subject: Re: request for review: i386 64bit atomic patch In-reply-to: ; from mime@traveller.cz on Mon, Feb 04, 2002 at 12:24:44PM +0100 To: Michal Mertl Cc: audit@freebsd.org, jhb@freebsd.org Mail-Followup-To: Michal Mertl , audit@freebsd.org, jhb@freebsd.org Message-id: <20020205071853.H72285@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 2002-Feb-04 12:24:44 +0100, Michal Mertl wrote: >+ " setz %%al ; " >+ " movzbl %%al,%0 ; " "%%al" could alternatively be written as "%b0" (From i386.md: 'b' => print the QImode name of the register for the indicated operand). >+ "#atomic_cmpset_64" >+ : "=a" (res), /* 0 */ The above change means that the "=a" could safely become "=q", which would allow gcc the freedom to pick something other than %eax. As a straight function, this doesn't help, but it may help for an inline. >+ : "a" ((u_long)exp), >+ "d" ((u_long)((u_long *)&exp)[1]), >+ "b" ((u_long)src), >+ "c" ((u_long)((u_long *)&src)[1]) I'd change these "u_long"s to "u_int32_t" or "u_register_t". This will stop the code breaking on bde's "long has 64 bits" test system. You might like to compare the code for "(u_long)((u_long *)&exp)[1]" with "(u_long)(exp >> 32)". >Thank Peter and John for your advices. What do you think now? Can someone >commit it? I don't see anything obviously wrong. Have you tested it with both gcc 2.95.1 and 3.x at various different optimisations? Constraint incompatibilities cause enough problems that we don't want to add any more. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Mon Feb 4 23:57: 6 2002 Delivered-To: freebsd-audit@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 9D3F337B400; Mon, 4 Feb 2002 23:56:58 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id SAA21321; Tue, 5 Feb 2002 18:56:45 +1100 Date: Tue, 5 Feb 2002 18:59:10 +1100 (EST) From: Bruce Evans X-X-Sender: To: Peter Jeremy Cc: Michal Mertl , , Subject: Re: request for review: i386 64bit atomic patch In-Reply-To: <20020205071853.H72285@gsmx07.alcatel.com.au> Message-ID: <20020205183716.D25833-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 5 Feb 2002, Peter Jeremy wrote: > On 2002-Feb-04 12:24:44 +0100, Michal Mertl wrote: > >+ " setz %%al ; " > >+ " movzbl %%al,%0 ; " > > "%%al" could alternatively be written as "%b0" (From i386.md: 'b' => > print the QImode name of the register for the indicated operand). It's good not to use hard register names all over, but even better not to use them at all. I changed the corresponding code in atomic_cmpset_int to: " setz %0 ; " " /* no movzbl here */ My %0 has type u_char, so 'b' and the movzbl pessimization are not needed, and it has the constraint "=r", so that gcc can pick a better register for it if possible. Most of 'b's elsewhere in atomic.h are also unnecessary. A couple are necessary to convert expressions involving u_char's back to u_char and the otheres are for superstitious reasons. > >+ "#atomic_cmpset_64" > >+ : "=a" (res), /* 0 */ > > The above change means that the "=a" could safely become "=q", which > would allow gcc the freedom to pick something other than %eax. As a > straight function, this doesn't help, but it may help for an inline. Right. In practice, I found that gcc -O usually made a mess of this optimization. gcc -O2 does better without the optimization hints in my version. > >+ : "a" ((u_long)exp), > >+ "d" ((u_long)((u_long *)&exp)[1]), > >+ "b" ((u_long)src), > >+ "c" ((u_long)((u_long *)&src)[1]) > > I'd change these "u_long"s to "u_int32_t" or "u_register_t". This > will stop the code breaking on bde's "long has 64 bits" test system. > You might like to compare the code for "(u_long)((u_long *)&exp)[1]" > with "(u_long)(exp >> 32)". Don't worry about this. I haven't fixed the atomic operations on longs on i386's with 64-bit longs, since this would be nontrivial (it basically requires Michal's 64-bit support) and I don't really want i386's with 64-bit longs to use longs for counters :-). If we use register_t then we really shouldn't make assumptions about its size. Writing asms is difficult without such assumptions. > >Thank Peter and John for your advices. What do you think now? Can someone > >commit it? > > I don't see anything obviously wrong. Have you tested it with both > gcc 2.95.1 and 3.x at various different optimisations? Constraint > incompatibilities cause enough problems that we don't want to add any > more. gcc-3 is reported to not like the "+a" to "=r" (output) and "a" (input) conversion that I made. The patch only fixes the !i386 case. I have written but not tested the corresponding change for the i386 case. %%% Index: atomic.h =================================================================== RCS file: /home/ncvs/src/sys/i386/include/atomic.h,v retrieving revision 1.24 diff -u -1 -r1.24 atomic.h --- atomic.h 18 Dec 2001 08:51:34 -0000 1.24 +++ atomic.h 3 Feb 2002 03:26:30 -0000 @@ -141,17 +133,48 @@ { - int res = exp; + u_int exp_copy; + u_char result; + /* + * The optimization hints prevent gcc-2.95 -O from preferring to + * keep exp in a register that would be better used for `result'. + * This function is often used to build spinloops, and gcc does + * not know that spinloops are usually iterated only once so that + * keeping loop variables in registers is usually a pessimization. + * However, gcc-2.95 -O2 somehow avoids the pessimizations without + * these hints. I hope gcc-3 -O doesn't need them. + */ + exp_copy = exp; /* Optimization hint. */ +#if 0 + /* + * Here is a version without the bogus memory clobber. We don't + * use it (yet?) since it causes "invalid constraint in asm" errors + * for i386's with 64-bit longs. It also causes larger code for + * all i386's, so it is not clear that it is better. + */ + __asm __volatile ( + " " MPLOCKED_STR " ; " + " cmpxchgl %2,%1 ; " + " setz %0 ; " + "1: " + "# atomic_cmpset_int" + : "=r" (result), /* 0 */ + "+m" (*dst) /* 1 */ + : "r" (src), /* 2 */ + "a" (exp_copy)); /* 3 */ +#else __asm __volatile ( - " " MPLOCKED " " + " " MPLOCKED_STR " ; " " cmpxchgl %1,%2 ; " - " setz %%al ; " - " movzbl %%al,%0 ; " + " setz %0 ; " "1: " "# atomic_cmpset_int" - : "+a" (res) /* 0 (result) */ + : "=r" (result) /* 0 */ : "r" (src), /* 1 */ - "m" (*(dst)) /* 2 */ + "m" (*dst), /* 2 */ + "a" (exp_copy) /* 3 */ : "memory"); +#endif + exp_copy = 0xDEAD; /* Another optimization hint. */ - return (res); + return (result); } %%% Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Tue Feb 5 11:43: 2 2002 Delivered-To: freebsd-audit@freebsd.org Received: from amdext.amd.com (amdext.amd.com [139.95.251.1]) by hub.freebsd.org (Postfix) with ESMTP id 990F937B419; Tue, 5 Feb 2002 11:42:56 -0800 (PST) Received: from ssvlgs01.amd.com (ssvlgs01.amd.com [139.95.250.16]) by amdext.amd.com (8.9.3/8.9.3/AMD) with SMTP id LAA24464; Tue, 5 Feb 2002 11:42:55 -0800 (PST) From: marc.miller@amd.com Received: from 139.95.250.1 by ssvlgs01.amd.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.7)); Tue, 05 Feb 2002 11:42:54 -0800 X-Server-Uuid: 02753650-11b0-11d5-bbc5-00508bf987eb Received: from caexmta3.amd.com (caexmta3.amd.com [139.95.53.7]) by amdint.amd.com (8.9.3/8.9.3/AMD) with ESMTP id LAA07315; Tue, 5 Feb 2002 11:42:54 -0800 (PST) Received: by caexmta3.amd.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Feb 2002 11:42:53 -0800 Message-ID: <858788618A93D111B45900805F85267A047D6508@caexmta3.amd.com> To: hackers@freebsd.org, freebsd-audit@freebsd.org Cc: netbsd-users@netbsd.org, port-i386@netbsd.org Subject: Athlon XP SSE flag not set? (AMD's response) Date: Tue, 5 Feb 2002 11:42:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 107EEA342557478-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Sorry for the cross-post, but this may be relevant to multiple operating systems. Some users have noticed that on certain motherboards the SSE flag is not being detected when using an Athlon XP, even though all Athlon XP processors we have produced to date support SSE. AMD responds with the following: - Our website has supported motherboards. - These motherboards have BIOSes that enable SSE on AthlonXP. - The end user should upgrade their BIOS if they have these motherboards. - If BIOS upgrade doesn't work for a listed MB, contact AMD (ask.amd.com) and the MB vendor. - If the MB is not on our list of recommended MB and does not properly enable SSE on Athlon XP, call the MB vendor to find out why not. Marc J. Miller Open Source Relations Engineer marc.miller@amd.com 1-800-538-8450 x43325 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Tue Feb 5 12:35:10 2002 Delivered-To: freebsd-audit@freebsd.org Received: from chylonia.3miasto.net (chylonia.3miasto.net [217.96.12.12]) by hub.freebsd.org (Postfix) with ESMTP id 101D337B423; Tue, 5 Feb 2002 12:35:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by chylonia.3miasto.net (8.11.3nb1/8.11.3) with ESMTP id g15KcSM01956; Tue, 5 Feb 2002 21:38:28 +0100 (CET) Date: Tue, 5 Feb 2002 21:38:28 +0100 (CET) From: Wojciech Puchar To: Cc: , , , Subject: Re: Athlon XP SSE flag not set? (AMD's response) In-Reply-To: <858788618A93D111B45900805F85267A047D6508@caexmta3.amd.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > - Our website has supported motherboards. > > - These motherboards have BIOSes that enable SSE on AthlonXP. it's strange that BIOS have to do it. > - The end user should upgrade their BIOS if they have these motherboards. ask AMD how to enable it - it's probably few lines of assembly that could be added to NetBSD initialization code To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Tue Feb 5 13:28:48 2002 Delivered-To: freebsd-audit@freebsd.org Received: from amdext.amd.com (amdext.amd.com [139.95.251.1]) by hub.freebsd.org (Postfix) with ESMTP id ED72137B419; Tue, 5 Feb 2002 13:28:38 -0800 (PST) Received: from ssvlgs01.amd.com (ssvlgs01.amd.com [139.95.250.16]) by amdext.amd.com (8.9.3/8.9.3/AMD) with SMTP id NAA21692; Tue, 5 Feb 2002 13:28:35 -0800 (PST) From: marc.miller@amd.com Received: from 139.95.250.1 by ssvlgs01.amd.com with ESMTP (Tumbleweed MMS SMTP Relay (MMS v4.7)); Tue, 05 Feb 2002 13:28:33 -0800 X-Server-Uuid: 02753650-11b0-11d5-bbc5-00508bf987eb Received: from caexmta3.amd.com (caexmta3.amd.com [139.95.53.7]) by amdint.amd.com (8.9.3/8.9.3/AMD) with ESMTP id NAA01973; Tue, 5 Feb 2002 13:28:33 -0800 (PST) Received: by caexmta3.amd.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Feb 2002 13:28:32 -0800 Message-ID: <858788618A93D111B45900805F85267A047D6519@caexmta3.amd.com> To: wojtek@chylonia.3miasto.net Cc: hackers@freebsd.org, freebsd-audit@freebsd.org, netbsd-users@netbsd.org, port-i386@netbsd.org Subject: RE: Athlon XP SSE flag not set? (AMD's response) Date: Tue, 5 Feb 2002 13:28:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 107E910B2570715-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Public document 20734 (http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/20734.pdf) should help with that. Marc J. Miller Open Source Relations Engineer marc.miller@amd.com 1-800-538-8450 x43325 -----Original Message----- From: Wojciech Puchar [mailto:wojtek@chylonia.3miasto.net] Sent: Tuesday, February 05, 2002 12:38 PM To: Miller, Marc Cc: hackers@freebsd.org; freebsd-audit@freebsd.org; netbsd-users@netbsd.org; port-i386@netbsd.org Subject: Re: Athlon XP SSE flag not set? (AMD's response) > > - Our website has supported motherboards. > > - These motherboards have BIOSes that enable SSE on AthlonXP. it's strange that BIOS have to do it. > - The end user should upgrade their BIOS if they have these motherboards. ask AMD how to enable it - it's probably few lines of assembly that could be added to NetBSD initialization code To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Wed Feb 6 14:33:57 2002 Delivered-To: freebsd-audit@freebsd.org Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by hub.freebsd.org (Postfix) with ESMTP id 7BDCA37B420 for ; Wed, 6 Feb 2002 14:33:54 -0800 (PST) Received: from hades.hell.gr (patr530-a059.otenet.gr [212.205.215.59]) by mailsrv.otenet.gr (8.12.2/8.12.2) with ESMTP id g16MXor6023133 for ; Thu, 7 Feb 2002 00:33:51 +0200 (EET) Received: (from charon@localhost) by hades.hell.gr (8.11.6/8.11.6) id g16MXng08795 for audit@freebsd.org; Thu, 7 Feb 2002 00:33:49 +0200 (EET) (envelope-from keramida@freebsd.org) Date: Thu, 7 Feb 2002 00:33:49 +0200 From: Giorgos Keramidas To: audit@freebsd.org Subject: CVSROOT/modules:fdisk Message-ID: <20020206223348.GA2457@hades.hell.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG The fdisk entry in CVSROOT/modules points to src/sbin/i386/fdisk. This has been obsoleted when fdisk was moved to src/sbin though. Do I change this to the new location, or leave it to someone of the src/ people, or even leave it like it is now? - Giorgos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Wed Feb 6 15: 2:51 2002 Delivered-To: freebsd-audit@freebsd.org Received: from out006.verizon.net (out006pub.verizon.net [206.46.170.106]) by hub.freebsd.org (Postfix) with ESMTP id 5442A37B422 for ; Wed, 6 Feb 2002 15:02:45 -0800 (PST) Received: from there ([4.61.185.117]) by out006.verizon.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020206230233.DUPK10804.out006.verizon.net@there> for ; Wed, 6 Feb 2002 17:02:33 -0600 From: biometrix Reply-To: bio.metrix@gte.net Organization: NAIS To: audit@freebsd.org Subject: GNU rcs suite - RCSLOCALID overflow. Date: Tue, 5 Feb 2002 17:06:15 +0000 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="------------Boundary-00=_FUK211FKIDLZVTFCWHMX" Message-Id: <20020206230233.DUPK10804.out006.verizon.net@there> Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --------------Boundary-00=_FUK211FKIDLZVTFCWHMX Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit There is a buffer overflow in the GNU RCS suite. It occurs in the handling of the RCSLOCALID environment variable. in /usr/src/gnu/usr.bin/rcs/lib/rcskeys.c the function setRCSLocalId() the variable ("string") is set from the earlier call cgetenv("RCSLOCALID"))) If RCSLOCALID string is to large for the buffer that is about to be strcpy'd into local_id a warning is given in the form of : error("LocalId is too long"); The error is not trapped and so a segmentation fault occurs at this line: VOID strcpy(local_id, key); I truncated the RCSLOCALID variable to the size of "keylength" with a strlcpy() call. This probably wasn't the best way of handling it? but it does seem to handle the error Ok. example: bash-2.05# export RCSLOCALID=`perl -e 'print "A" x 5000'` bash-2.05# rcs rcs: LocalId is too long Segmentation fault (core dumped) bash-2.05# /usr/src/gnu/usr.bin/rcs/rcs/rcs rcs: LocalId is too long. truncated RCSLOCALID bash-2.05# The problem effects the following binaries: rcs rcsclean rcsdiff rcsmerge and rlog None of the RCS suite is setuid so no privilege escalation occurs. John Johnson. --------------Boundary-00=_FUK211FKIDLZVTFCWHMX Content-Type: text/x-diff; charset="iso-8859-1"; name="rcskeys.patch" Content-Transfer-Encoding: base64 Content-Description: patch for RCSLOCALID overflow Content-Disposition: attachment; filename="rcskeys.patch" LS0tIHJjc2tleXMub3JpZwlUdWUgRmViICA1IDE1OjAyOjQwIDIwMDIKKysrIHJjc2tleXMuYwlU dWUgRmViICA1IDE2OjM3OjA2IDIwMDIKQEAgLTIyLDExICsyMiwxNSBAQAogNTkgVGVtcGxlIFBs YWNlIC0gU3VpdGUgMzMwLCBCb3N0b24sIE1BIDAyMTExLTEzMDcsIFVTQS4KIAogUmVwb3J0IHBy b2JsZW1zIGFuZCBkaXJlY3QgYWxsIHF1ZXN0aW9ucyB0bzoKIAogICAgIHJjcy1idWdzQGNzLnB1 cmR1ZS5lZHUKKyovCiAKKy8qIFJldmlzaW9uIDUuNSAgMjAwMi8wMi8wNiAwMzo0NTo1MCAgampv aG5zb24KKyAqIHByb2JsZW0gd2l0aCBzZXRSQ1NMb2NhbElkIGZ1bmN0aW9uIHdvdWxkIGNhdXNl IHNlZ21lbnRhdGlvbiBmYXVsdAorICogaWYgUkNTTE9DQUxJRCBlbnZpcm9tZW50IHZhcmlhYmxl IHdhcyB0byBsYXJnZS4KICovCiAKIC8qCiAgKiBSZXZpc2lvbiA1LjQgIDE5OTUvMDYvMTYgMDY6 MTk6MjQgIGVnZ2VydAogICogVXBkYXRlIEZTRiBhZGRyZXNzLgpAQCAtMTY0LDEzICsxNjgsMTUg QEAKIAlpbnQgajsKIAogCWNvcHkgPSBzdHJkdXAoc3RyaW5nKTsKIAluZXh0ID0gY29weTsKIAlr ZXkgPSBzdHJ0b2sobmV4dCwgIj0iKTsKLQlpZiAoc3RybGVuKGtleSkgPiBrZXlsZW5ndGgpCi0J CWVycm9yKCJMb2NhbElkIGlzIHRvbyBsb25nIik7Ci0JVk9JRCBzdHJjcHkobG9jYWxfaWQsIGtl eSk7CisJaWYgKHN0cmxlbihrZXkpID4ga2V5bGVuZ3RoKXsKKwkJZXJyb3IoIkxvY2FsSWQgaXMg dG9vIGxvbmcuIHRydW5jYXRlZCBSQ1NMT0NBTElEIik7CisJCXN0cmxjcHkobG9jYWxfaWQsa2V5 LHNpemVvZihrZXlsZW5ndGgpKTsKKwkgICAgICAgIH0KKwlWT0lEIHN0cmxjcHkobG9jYWxfaWQs IGtleSxzaXplb2Yoa2V5bGVuZ3RoKSk7CiAJS2V5d29yZFtMb2NhbElkXSA9IGxvY2FsX2lkOwog CiAJLyogb3B0aW9ucz8gKi8KIAl3aGlsZSAoa2V5ID0gc3RydG9rKE5VTEwsICIsIikpIHsKIAkJ aWYgKCFzdHJjbXAoa2V5LCBLZXl3b3JkW0lkXSkpCg== --------------Boundary-00=_FUK211FKIDLZVTFCWHMX-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Wed Feb 6 17: 2: 3 2002 Delivered-To: freebsd-audit@freebsd.org Received: from out008.verizon.net (out008pub.verizon.net [206.46.170.108]) by hub.freebsd.org (Postfix) with ESMTP id 2DA9037B404 for ; Wed, 6 Feb 2002 17:02:00 -0800 (PST) Received: from there ([4.61.185.117]) by out008.verizon.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020207010159.EFLX12982.out008.verizon.net@there> for ; Wed, 6 Feb 2002 19:01:59 -0600 Content-Type: text/plain; charset="iso-8859-1" From: biometrix Reply-To: bio.metrix@gte.net Organization: NAIS To: audit@freebsd.org Subject: tmpfile() libc call causes buffer overflow? Date: Tue, 5 Feb 2002 19:05:30 +0000 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020207010159.EFLX12982.out008.verizon.net@there> Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I found if I altered TMPDIR exported variable to an a long string (X50 "G") /usr/bin/pr would exit with a segmentation fault. export TMPDIR=`perl -e 'print "G" x 50'` bash-2.05# pr Cannot defer diagnostic messages Segmentation fault (core dumped) The code executed just before the segmentation fault is : if ((err = tmpfile()) == NULL) { (void)fputs("Cannot defer diagnosticm essages\n",stderr); return(1); } In : /usr/src/lib/libc/stdio/tmpfile.c there is a call for "tmpdir = getenv("TMPDIR");" so it returns a filename based on the enviroment variable "TMPDIR" so the result of tmpfile() can be poisoned by altering TMPDIR ? I tested it using most of the code found in "tmpfile.c" and got the result: ./test GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG/tmp.XXXXXX gdb says the error occurs in: #0 0x280dca59 in __sfvwrite () from /usr/lib/libc.so.4 when pr crashes and the core file contains the string: strings pr.core | grep -i tmp GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG/tmp.XXXXXX GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG/tmp.GIvbJl TMPDIR /tmp TMPDIR=GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG pr is the only binary I can find in the source tree that uses the tmpfile() call so cannot test against anything else. Am I incorrect that this problem is caused by the getenv() for TMPDIR in tmpfile.c? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Wed Feb 6 17:39:30 2002 Delivered-To: freebsd-audit@freebsd.org Received: from descent.robbins.dropbear.id.au (228.c.010.mel.iprimus.net.au [210.50.202.228]) by hub.freebsd.org (Postfix) with ESMTP id 316F937B59E for ; Wed, 6 Feb 2002 17:39:03 -0800 (PST) Received: (from tim@localhost) by descent.robbins.dropbear.id.au (8.11.6/8.11.6) id g171ZRN01211; Thu, 7 Feb 2002 12:35:27 +1100 (EST) (envelope-from tim) Date: Thu, 7 Feb 2002 12:35:27 +1100 From: "Tim J. Robbins" To: biometrix Cc: audit@FreeBSD.ORG Subject: Re: tmpfile() libc call causes buffer overflow? Message-ID: <20020207123527.B425@descent.robbins.dropbear.id.au> References: <20020207010159.EFLX12982.out008.verizon.net@there> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020207010159.EFLX12982.out008.verizon.net@there>; from bio.metrix@gte.net on Tue, Feb 05, 2002 at 07:05:30PM +0000 Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Feb 05, 2002 at 07:05:30PM +0000, biometrix wrote: > The code executed just before the segmentation fault is : > > if ((err = tmpfile()) == NULL) { > (void)fputs("Cannot defer diagnosticm > essages\n",stderr); > return(1); > } This is a bug in pr. Its usage() function writes to `err', which is NULL at this point, instead of stderr. tmpfile() returns NULL because it can't create a temporary file in a directory that doesn't exist (the length of TMPDIR does not matter at all, it can even be empty). There is no buffer overflow here. Index: pr/pr.c =================================================================== RCS file: /home/ncvs/src/usr.bin/pr/pr.c,v retrieving revision 1.11 diff -u -r1.11 pr.c --- pr/pr.c 2001/03/21 14:32:02 1.11 +++ pr/pr.c 2002/02/07 01:38:18 @@ -1561,11 +1561,11 @@ usage() { (void)fputs( - "usage: pr [+page] [-col] [-adFmrt] [-e[ch][gap]] [-h header]\n",err); +"usage: pr [+page] [-col] [-adFmrt] [-e[ch][gap]] [-h header]\n", stderr); (void)fputs( - " [-i[ch][gap]] [-l line] [-n[ch][width]] [-o offset]\n",err); - (void)fputs( - " [-L locale] [-s[ch]] [-w width] [-] [file ...]\n", err); +" [-i[ch][gap]] [-l line] [-n[ch][width]] [-o offset]\n", stderr); +(void)fputs( +" [-L locale] [-s[ch]] [-w width] [-] [file ...]\n", stderr); } /* Tim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Wed Feb 6 17:44:46 2002 Delivered-To: freebsd-audit@freebsd.org Received: from descent.robbins.dropbear.id.au (228.c.010.mel.iprimus.net.au [210.50.202.228]) by hub.freebsd.org (Postfix) with ESMTP id 734C837B404 for ; Wed, 6 Feb 2002 17:44:33 -0800 (PST) Received: (from tim@localhost) by descent.robbins.dropbear.id.au (8.11.6/8.11.6) id g171eqa01285; Thu, 7 Feb 2002 12:40:52 +1100 (EST) (envelope-from tim) Date: Thu, 7 Feb 2002 12:40:52 +1100 From: "Tim J. Robbins" To: "Tim J. Robbins" Cc: audit@FreeBSD.ORG Subject: Re: tmpfile() libc call causes buffer overflow? Message-ID: <20020207124052.A1271@descent.robbins.dropbear.id.au> References: <20020207010159.EFLX12982.out008.verizon.net@there> <20020207123527.B425@descent.robbins.dropbear.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020207123527.B425@descent.robbins.dropbear.id.au>; from tim@robbins.dropbear.id.au on Thu, Feb 07, 2002 at 12:35:27PM +1100 Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Feb 07, 2002 at 12:35:27PM +1100, Tim J. Robbins wrote: > This is a bug in pr. Its usage() function writes to `err', which is NULL I should point out that flsh_errs() also needs to be corrected. Tim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Wed Feb 6 17:49:26 2002 Delivered-To: freebsd-audit@freebsd.org Received: from peitho.fxp.org (peitho.fxp.org [209.26.95.40]) by hub.freebsd.org (Postfix) with ESMTP id 02F6637B417 for ; Wed, 6 Feb 2002 17:49:15 -0800 (PST) Received: by peitho.fxp.org (Postfix, from userid 1501) id 7EF4B13667; Wed, 6 Feb 2002 20:49:08 -0500 (EST) Date: Wed, 6 Feb 2002 20:49:08 -0500 From: Chris Faulhaber To: biometrix Cc: audit@freebsd.org Subject: Re: tmpfile() libc call causes buffer overflow? Message-ID: <20020207014908.GA88916@peitho.fxp.org> References: <20020207010159.EFLX12982.out008.verizon.net@there> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/9DWx/yDrRhgMJTb" Content-Disposition: inline In-Reply-To: <20020207010159.EFLX12982.out008.verizon.net@there> User-Agent: Mutt/1.3.24i Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 05, 2002 at 07:05:30PM +0000, biometrix wrote: > I found if I altered TMPDIR exported variable to an a long string (X50 "G= ")=20 > /usr/bin/pr would exit with a segmentation fault. >=20 > export TMPDIR=3D`perl -e 'print "G" x 50'` > bash-2.05# pr > Cannot defer diagnostic messages > Segmentation fault (core dumped) >=20 > The code executed just before the segmentation fault is : >=20 > if ((err =3D tmpfile()) =3D=3D NULL) { > (void)fputs("Cannot defer diagnosticm=20 > essages\n",stderr); > return(1); > } >=20 actually: =2E.. This GDB was configured as "i386-unknown-freebsd"... Core was generated by `pr'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libc.so.4...done. Reading symbols from /usr/libexec/ld-elf.so.1...done. #0 0x280dac49 in __sfvwrite () from /usr/lib/libc.so.4 (gdb) bt #0 0x280dac49 in __sfvwrite () from /usr/lib/libc.so.4 #1 0x280c69ce in fputs () from /usr/lib/libc.so.4 #2 0x804a87d in usage () at pr.c:1562 #3 0x8048b69 in main (argc=3D1, argv=3D0xbfbffa84) at pr.c:133 (gdb)=20 __sfvwrite() dies when fed a NULL stream. This is triggered by pr(1) attempting to use fputs() with an invalid stream caused by tmpfile() failing. It does not appear to be specific to a long TMPDIR but to any TMPDIR (i.e. any invalid directory) that will cause tmpfile() to fail. The fix to pr(1) is to explicitely set err =3D stderr before eventually calling usage(): Index: pr.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/usr.bin/pr/pr.c,v retrieving revision 1.9.2.1 diff -u -r1.9.2.1 pr.c --- usr.bin/pr/pr.c 4 Mar 2001 08:54:51 -0000 1.9.2.1 +++ usr.bin/pr/pr.c 7 Feb 2002 01:34:58 -0000 @@ -1588,6 +1588,7 @@ * defer diagnostics until processing is done */ if ((err =3D tmpfile()) =3D=3D NULL) { + err =3D stderr; (void)fputs("Cannot defer diagnostic messages\n",stderr); return(1); } The fix to __sfvwrite() is to ensure that fp !=3D NULL: Index: lib/libc/stdio/fvwrite.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/lib/libc/stdio/fvwrite.c,v retrieving revision 1.10 diff -u -r1.10 fvwrite.c --- lib/libc/stdio/fvwrite.c 28 Aug 1999 00:01:06 -0000 1.10 +++ lib/libc/stdio/fvwrite.c 7 Feb 2002 01:44:47 -0000 @@ -42,6 +42,7 @@ "$FreeBSD: src/lib/libc/stdio/fvwrite.c,v 1.10 1999/08/28 00:01:06 peter= Exp $"; #endif /* LIBC_SCCS and not lint */ =20 +#include #include #include #include @@ -68,6 +69,10 @@ =20 if ((len =3D uio->uio_resid) =3D=3D 0) return (0); + if (fp =3D=3D NULL) { + errno =3D EBADF; + return (EOF); + } /* make sure we can write */ if (cantwrite(fp)) return (EOF); >=20 > In : /usr/src/lib/libc/stdio/tmpfile.c there is a call for > "tmpdir =3D getenv("TMPDIR");" >=20 > so it returns a filename based on the enviroment variable "TMPDIR" so the= =20 > result of tmpfile() can be poisoned by altering TMPDIR ? >=20 Have you read tmpfile(3)? --=20 Chris D. Faulhaber - jedgar@fxp.org - jedgar@FreeBSD.org -------------------------------------------------------- FreeBSD: The Power To Serve - http://www.FreeBSD.org --/9DWx/yDrRhgMJTb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: FreeBSD: The Power To Serve iEYEARECAAYFAjxh3RMACgkQObaG4P6BelALpACffIyeBSudpkf73TIQ9CQUivko ybAAn0EVqlX/WV5nXl2+V1q9rZyS6xJR =nf14 -----END PGP SIGNATURE----- --/9DWx/yDrRhgMJTb-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Thu Feb 7 2:48:53 2002 Delivered-To: freebsd-audit@freebsd.org Received: from tao.org.uk (genius.tao.org.uk [212.135.162.51]) by hub.freebsd.org (Postfix) with ESMTP id 85D7C37B41C; Thu, 7 Feb 2002 02:48:47 -0800 (PST) Received: by tao.org.uk (Postfix, from userid 100) id D3B6B84; Thu, 7 Feb 2002 10:48:46 +0000 (GMT) Date: Thu, 7 Feb 2002 10:48:46 +0000 From: Josef Karthauser To: Giorgos Keramidas Cc: audit@freebsd.org Subject: Re: CVSROOT/modules:fdisk Message-ID: <20020207104846.E32360@genius.tao.org.uk> References: <20020206223348.GA2457@hades.hell.gr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="EgVrEAR5UttbsTXg" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020206223348.GA2457@hades.hell.gr>; from keramida@freebsd.org on Thu, Feb 07, 2002 at 12:33:49AM +0200 Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --EgVrEAR5UttbsTXg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Feb 07, 2002 at 12:33:49AM +0200, Giorgos Keramidas wrote: > The fdisk entry in CVSROOT/modules points to src/sbin/i386/fdisk. > This has been obsoleted when fdisk was moved to src/sbin though. > Do I change this to the new location, > or leave it to someone of the src/ people, > or even leave it like it is now? It should be changed to point to the new location. Joe --EgVrEAR5UttbsTXg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjxiW44ACgkQXVIcjOaxUBYLPQCdHVGLS22Leb2nyCiSf3ri31bg u9sAn3ARMnxmzEe6DHKvQqkeQEH3tDTf =J5lF -----END PGP SIGNATURE----- --EgVrEAR5UttbsTXg-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Thu Feb 7 3:42:18 2002 Delivered-To: freebsd-audit@freebsd.org Received: from diogenis.ceid.upatras.gr (diogenis.ceid.upatras.gr [150.140.141.181]) by hub.freebsd.org (Postfix) with SMTP id 0080B37B428 for ; Thu, 7 Feb 2002 03:42:14 -0800 (PST) Received: (qmail 29334 invoked by uid 1465); 7 Feb 2002 11:40:35 -0000 Message-ID: <20020207114035.29332.qmail@diogenis.ceid.upatras.gr> From: "Giorgos Keramidas" Date: Thu, 7 Feb 2002 13:40:35 +0200 (EET) To: Josef Karthauser Cc: audit@freebsd.org Subject: Re: CVSROOT/modules:fdisk In-Reply-To: <20020207104846.E32360@genius.tao.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Feb 2002, Josef Karthauser wrote: > On Thu, Feb 07, 2002 at 12:33:49AM +0200, Giorgos Keramidas wrote: > > The fdisk entry in CVSROOT/modules points to src/sbin/i386/fdisk. > > This has been obsoleted when fdisk was moved to src/sbin though. > > Do I change this to the new location, > > or leave it to someone of the src/ people, > > or even leave it like it is now? > > It should be changed to point to the new location. Thanks. I only have my SSH key at home, so I'll do later tonight, unless someone else has already done it. - Giorgos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Fri Feb 8 3:59:42 2002 Delivered-To: freebsd-audit@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id AE20737B419 for ; Fri, 8 Feb 2002 03:59:33 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g18BxBW63101; Fri, 8 Feb 2002 13:59:11 +0200 (EET) (envelope-from ru) Date: Fri, 8 Feb 2002 13:59:11 +0200 From: Ruslan Ermilov To: biometrix Cc: audit@FreeBSD.ORG Subject: Re: GNU rcs suite - RCSLOCALID overflow. Message-ID: <20020208135911.B54593@sunbay.com> References: <20020206230233.DUPK10804.out006.verizon.net@there> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020206230233.DUPK10804.out006.verizon.net@there> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Feb 05, 2002 at 05:06:15PM +0000, biometrix wrote: > There is a buffer overflow in the GNU RCS suite. > It occurs in the handling of the RCSLOCALID environment variable. > > in /usr/src/gnu/usr.bin/rcs/lib/rcskeys.c the function setRCSLocalId() the > variable ("string") is set from the earlier call cgetenv("RCSLOCALID"))) > If RCSLOCALID string is to large for the buffer that is about to be strcpy'd > into local_id a warning is given in the form of : > error("LocalId is too long"); > The error is not trapped and so a segmentation fault occurs at this line: > VOID strcpy(local_id, key); > > I truncated the RCSLOCALID variable to the size of "keylength" with a > strlcpy() call. This probably wasn't the best way of handling it? but it does > seem to handle the error Ok. > > example: > bash-2.05# export RCSLOCALID=`perl -e 'print "A" x 5000'` > bash-2.05# rcs > rcs: LocalId is too long > Segmentation fault (core dumped) > bash-2.05# /usr/src/gnu/usr.bin/rcs/rcs/rcs > rcs: LocalId is too long. truncated RCSLOCALID > bash-2.05# > Thanks for the spot! I've committed a different fix. Cheers, -- Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Sat Feb 9 8:51:51 2002 Delivered-To: freebsd-audit@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id AC70837B41D for ; Sat, 9 Feb 2002 08:51:49 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id DDB4C5341; Sat, 9 Feb 2002 17:51:47 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: audit@freebsd.org Subject: OpenPAM Calamite + integration patches From: Dag-Erling Smorgrav Date: 09 Feb 2002 17:51:46 +0100 Message-ID: Lines: 8 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG OpenPAM is now available from . Integration patches and (brief) instructions are available from . A fully patched tree is also available from the p4 depot, under //depot/user/des/pam/. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message