Dear Maintainer,

In libfprint/drivers/goodixmoc/goodix.c, gx_fp_probe() reads the device's
serial number string descriptor and treats any failure as fatal:

    serial = g_usb_device_get_string_descriptor (usb_dev,
               g_usb_device_get_serial_number_index (usb_dev), &error);
    if (error)
      {
        g_usb_device_release_interface (fpi_device_get_usb_device (FP_DEVICE (device)),
                                        0, 0, NULL);
        goto err_close;
      }

If a device exposes no serial-number string, its descriptor has iSerial 0, so
g_usb_device_get_serial_number_index() returns 0. Reading string descriptor
index 0 is not valid, so libusb returns LIBUSB_ERROR_INVALID_PARAM (-2) and the
probe aborts with:

    libfprint-context-Message: Ignoring device due to initialization error:
        USB error on device <vid:pid> : Invalid parameter [-2]

The code path is unconditional, so it affects any device handled by this driver
that exposes no serial string, independent of its USB ID.

I have filed this as severity minor deliberately: every sensor currently in the
driver's id_table presumably carries a serial string, so as far as I know this
has no user-visible effect on supported hardware today. It is a latent
robustness problem rather than a regression.

Suggested fix: skip the lookup when the serial index is 0, or tolerate the
failure and pass a NULL serial to fpi_device_probe_complete(), which accepts
NULL.

How I found it: a Goodix 27c6:5503 (Lenovo ThinkPad E14 Gen 3) has iSerial 0.
That device is not in the driver's id_table and is not otherwise supported, and
I am explicitly not asking for support for it. I hit this code path while
testing whether the sensor spoke the match-on-chip protocol at all (it does
not), and the serial handling looked like a genuine defect worth reporting on
its own.

I verified the affected code is still present in 1.94.10, the newest release. I
was not able to check current upstream git master.

Reproducing without this hardware: any USB device with iSerial 0 whose vid:pid
is in the goodixmoc id_table would trigger it. libfprint's virtual-device test
infrastructure is likely a simpler route than real hardware.

Full diagnostics, patch script and logs, including the probe failure and what
happens after patching past it:
https://gist.github.com/twitu/baf65d454cf5ddadbdfeef480c6e618c

Observed on Ubuntu 24.04 with the distribution build of libfprint 1.94.7+tod1;
the defect is unchanged in the 1.94.10 source.

Disclosure, per Debian's 2026 resolution on generative AI: this report was
prepared with AI assistance. The findings were verified on real hardware and
against the 1.94.10 source by me before sending, and I am accountable for their
accuracy.

Thanks for maintaining this package.