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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20070402192940.GA6644@lst.de>
Date:	Mon, 2 Apr 2007 21:29:40 +0200
From:	Christoph Hellwig <hch@....de>
To:	David Miller <davem@...emloft.net>
Cc:	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org,
	hch@....de, tcallawa@...hat.com
Subject: Re: [PATCH]: Fix scsi_send_eh_cmnd scatterlist handling

On Mon, Apr 02, 2007 at 12:24:39PM -0700, David Miller wrote:
> 
> This fixes a regression caused by commit:
> 
> 2dc611de5a3fd955cd0298c50691d4c05046db97
> 
> The sense buffer code in scsi_send_eh_cmnd was changed to use
> alloc_page() and a scatter list, but the sense data copy was not
> updated to match so what we actually get in the sense buffer is total
> grabage starting with the kernel address of the struct page we got.
> Basically the stack frame of scsi_send_eh_cmd() is what ends up
> in the sense buffer.
> 
> Depending upon how pointers look on a given platform, you can
> end up getting sr_ioctl.c errors when you mount a cdrom.  If
> the CDROM gives a check condition for GPCMD_GET_CONFIGURATION issued
> by drivers/cdrom/cdrom.c:cdrom_mmc_profile(), sr_ioctl will
> spit out this error message in sr_do_ioctl() with the way pointers
> are on sparc64:
> 
> 		default:
> 			printk(KERN_ERR "%s: CDROM (ioctl) error, command: ", cd->cdi.name);
> 			__scsi_print_command(cgc->cmd);
> 			scsi_print_sense_hdr("sr", &sshdr);
> 			err = -EIO;
> 
> This is the error Tom Callaway reported in:
> 
> http://marc.info/?l=linux-sparc&m=117407453208101&w=2
> 
> Anyways, fix this by using page_address(sgl.page) which is OK
> because we know this is low-mem due to GFP_ATOMIC.

The patch looks correct to me and thanks for spotting this stupid
bug!
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ