linux-kernel - Re: 2.6.19-git13: uts banner changes break SLES9 (at least)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20061211201611.GA20131@aepfle.de>
Date:	Mon, 11 Dec 2006 21:16:11 +0100
From:	Olaf Hering <olaf@...fle.de>
To:	Andy Whitcroft <apw@...dowen.org>, sfrench@...ba.org
Cc:	Linus Torvalds <torvalds@...l.org>,
	Herbert Poetzl <herbert@...hfloor.at>, Andi Kleen <ak@...e.de>,
	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org,
	Steve Fox <drfickle@...ibm.com>
Subject: Re: 2.6.19-git13: uts banner changes break SLES9 (at least)

On Mon, Dec 11, Olaf Hering wrote:

> On Mon, Dec 11, Andy Whitcroft wrote:
> 
> > I am afraid to report that this second version also fails for me, as you 
> > point out CIFS can break us if defined.  In fact we used to get away 
> > with this on my test system due to ordering magic luck, I presume the 
> > move to __initdata has triggered this.  Much as I agree that this is 
> > wrong we are still going to break people with this.
> 
> I'm looking at cifs_strtoUCS and wonder if its safe to check 'len &&
> *from'. IF it really is, the functions could snprintf to the stack and
> pass this to cifs_strtoUCS.
> 
> Quick, compile tested, patch below.
> 
> 
> Index: linux-2.6/fs/cifs/connect.c
> ===================================================================
> --- linux-2.6.orig/fs/cifs/connect.c
> +++ linux-2.6/fs/cifs/connect.c
> @@ -2070,6 +2070,7 @@ CIFSSessSetup(unsigned int xid, struct c
>  	      char session_key[CIFS_SESS_KEY_SIZE],
>  	      const struct nls_table *nls_codepage)
>  {
> +	char banner[2*32+1];
>  	struct smb_hdr *smb_buffer;
>  	struct smb_hdr *smb_buffer_response;
>  	SESSION_SETUP_ANDX *pSMB;
> @@ -2135,6 +2136,8 @@ CIFSSessSetup(unsigned int xid, struct c
>  	memcpy(bcc_ptr, (char *) session_key, CIFS_SESS_KEY_SIZE);
>  	bcc_ptr += CIFS_SESS_KEY_SIZE;
>  
> +	snprintf(banner, sizeof(banner), "%s version %s", utsname()->sysname,
> +		utsname()->release);
>  	if (ses->capabilities & CAP_UNICODE) {
>  		if ((long) bcc_ptr % 2) { /* must be word aligned for Unicode */
>  			*bcc_ptr = 0;
> @@ -2160,12 +2163,8 @@ CIFSSessSetup(unsigned int xid, struct c
>  		bcc_ptr += 2 * bytes_returned;
>  		bcc_ptr += 2;
>  		bytes_returned =
> -		    cifs_strtoUCS((__le16 *) bcc_ptr, "Linux version ",
> -				  32, nls_codepage);
> -		bcc_ptr += 2 * bytes_returned;
> -		bytes_returned =
> -		    cifs_strtoUCS((__le16 *) bcc_ptr, utsname()->release,
> -				  32, nls_codepage);
> +		    cifs_strtoUCS((__le16 *) bcc_ptr, banner,
> +				  64, nls_codepage);
>  		bcc_ptr += 2 * bytes_returned;
>  		bcc_ptr += 2;
>  		bytes_returned =

new_utsname->release is 65 bytes, so with a very long uname -r, the
current code already truncates release.

Steve, is 32 a hard limit in the protocol?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/