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
