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

On Tue, 2026-05-26 at 15:28 -0400, Benjamin Marzinski wrote:
> 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?

I agree. And as -v3 is already a moderate debugging level for us, I
don't see the log message as problematic, either.

Martin