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
