linux-kernel - hfsplus mount regression in 2.6.38

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

Date:	Wed, 25 May 2011 09:25:21 -0500
From:	Seth Forshee <seth.forshee@...onical.com>
To:	Christoph Hellwig <hch@...era.com>
Cc:	Anton Salikhmetov <alexo@...era.com>, linux-kernel@...r.kernel.org
Subject: hfsplus mount regression in 2.6.38

We've been receiving reports of problems mounting HFS+ formatted volumes
(iPods mostly, but not exclusively) starting with the 2.6.38 kernel,
with messages like the following in dmesg.

  usb 2-2: new high speed USB device using ehci_hcd and address 12
  scsi7 : usb-storage 2-2:1.0
  scsi 7:0:0:0: Direct-Access Apple iPod 1.62 PQ: 0 ANSI: 0
  sd 7:0:0:0: Attached scsi generic sg2 type 0
  sd 7:0:0:0: [sdb] 1982464 2048-byte logical blocks: (4.06 GB/3.78 GiB)
  sd 7:0:0:0: [sdb] Write Protect is off
  sd 7:0:0:0: [sdb] Mode Sense: 68 00 00 08
  sd 7:0:0:0: [sdb] No Caching mode page present
  sd 7:0:0:0: [sdb] Assuming drive cache: write through
  sd 7:0:0:0: [sdb] 1982464 2048-byte logical blocks: (4.06 GB/3.78 GiB)
  sd 7:0:0:0: [sdb] No Caching mode page present
  sd 7:0:0:0: [sdb] Assuming drive cache: write through
  sdb: [mac] sdb1 sdb2 sdb3
  sd 7:0:0:0: [sdb] 1982464 2048-byte logical blocks: (4.06 GB/3.78 GiB)
  sd 7:0:0:0: [sdb] No Caching mode page present
  sd 7:0:0:0: [sdb] Assuming drive cache: write through
  sd 7:0:0:0: [sdb] Attached SCSI removable disk
  sd 7:0:0:0: [sdb] Bad block number requested
  hfs: unable to find HFS+ superblock
  sd 7:0:0:0: [sdb] Bad block number requested
  hfs: unable to find HFS+ superblock

Reverting commits 52399b1 (hfsplus: use raw bio access for the volume
headers) and 358f26d5 (hfsplus: use raw bio access for partition tables)
fixes the problems. It appears the problems are due to hfsplus
submitting 512 byte bios to a block device whose sector size is larger
than 512 byts (2 KB in the log above), and the block driver is quite
reasonably rejecting any requests without proper sector alignment.

How would you suggest fixing this?  Most file systems are using
sb_bread() for this sort of thing, but since the offending patches are
intended to stop using buffer_heads I'm assuming that's not an option.

Thanks,
Seth

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