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

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

[Xose Vazquez Perez]

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.

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

[Benjamin Marzinski]

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 

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

[Martin Wilck]

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