linux-kernel - Re: [PATCH 0/2] rsxx: Two important bug fixes for the rsxx block driver.

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] [day] [month] [year] [list]

Message-ID: <20131023112539.GZ14598@kernel.dk>
Date:	Wed, 23 Oct 2013 12:25:39 +0100
From:	Jens Axboe <axboe@...nel.dk>
To:	"Philip J. Kelleher" <pjk1939@...ux.vnet.ibm.com>
Cc:	linux-kernel@...r.kernel.org, brking@...ux.vnet.ibm.com
Subject: Re: [PATCH 0/2] rsxx: Two important bug fixes for the rsxx block
 driver.

On Fri, Oct 18 2013, Philip J. Kelleher wrote:
> The incoming patches are for the rsxx driver (drivers/block/rsxx)
> 
> Patch1:
> This patch fixes a bug in which discards were always
> calling pci_unmap_page. Discards should never call the
> pci_unmap_page function call because they are never mapped.
> 
> This caused a race condition on PowerPC systems when issuing
> discards, writes, and reads all at the same time. The
> pci_map_page function would eventually map logical address
> 0 for a read or write. Discards are always assigned a DMA
> address of 0 because they are never mapped. So if
> pci_map_page mapped address 0 for a DMA and a discard was
> "unmapped" then the address would be freed and would cause 
> an EEH event to occur when Hardware accesses the address.
> 
> This was injected/uncovered in commit:
> b347f9cf0bc8d42ee95ba1d3837fd93045ab336b
> 
> The pci_dma_mapping_error function declares -1 a DMA_ERROR
> not 0 like initially thought.
> 
> This patch should fall on top of commit id:
> fc1967bb08a6184ed44ef990e1dd4389901b809c
> 
> 
> Patch2:
> This patch fixes a possible Kernel Panic on driver load if 
> the configuration on the card is messed up or not yet set.
> The driver could possible give a 32 bit unsigned all Fs to
> the kernel as the device's block size.
> 
> Now we only write the block size to the kernel if the
> configuration from the card is valid.

Applied both for 3.13. Please stop putting that ----- line at the end of
your patches. It goes into the git commit messages and just makes
everything look ugly, I have to fix those up manually.

-- 
Jens Axboe

--
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/