Re: [BUG] multipath-tools: 0 cyl reported on large disks due to overflow

[Benjamin Marzinski <bmarzins@redhat.com>]

On Fri, May 22, 2026 at 11:10:36PM +0200, Xose Vazquez Perez wrote:
> Hi,
> 
> An integer overflow occurs in libmultipath/discovery.c:get_geometry() when
> querying geometry on large disks resulting in "0 cyl" being reported:
> 
> # multipath -ll -d -v3
> ... | sdgm: 0 cyl, 64 heads, 32 sectors/track, start at 0
> 
> # fdisk -l /dev/sdgm
> Disk /dev/sdgm: 12 TiB, 13194139533312 bytes, 25769803776 sectors
> Units: sectors of 1 * 512 = 512 bytes
> 
> # dmesg | grep sdgm
> sd 5:0:3:100: [sdgm] 25769803776 512-byte logical blocks: (13.2 TB/12.0TiB)
> 
> 
> The root cause is that struct hd_geometry, from libmultipath/structs.h,
> defines cylinders as an unsigned short.
> 
> Since it is a legacy interface, it should either sanitize the log output
> or avoid relying on CHS geometry for large devices.

I'm totally fine with never reporting the geometry info or moving it to
log level 4 (since there can be value to even pointless debugging
messages. They can show you where you made it to if you happned to hang
in a function)

But I don't personally have a problem with multipath simply passing
along the geometry data it gets from the disk. Sure, it may be garbage,
but then DM's garbage matches the disk's garbage. I highly doubt that
anything actually cares what geometry a DM device reports. But I don't
see any benefit to changing what it currently does.

Thoughts?
-Ben