Loading the lustre-client KMP from OpenHPC
(http://build.openhpc.community/OpenHPC:/1.3/SLE_12/) on a SLE-12-SP2 system
(running any officially released kernel) fails with -ERANGE:

# modprobe lustre
modprobe: ERROR: could not insert 'lustre': Numerical result out of range

strace reveals that the failing syscall is:
finit_module(3, "", 0)                  = -1 ERANGE (Numerical result out of
range)

Hunting this down in the kernel one finds that 
in crypto/asymmetric_keys/rsa.c:RSA_I2OSP() the test below fails and returns
-ERANGE: 
        x_size = mpi_get_nbits(x);
        pr_devel("size(x)=%u xLen*8=%zu\n", x_size, xLen * 8);
        if (x_size != xLen * 8 - 15)
                return -ERANGE;

In this case, no attempt is made to actually load the module unlike when an
unsigned module is loaded as long as no strict signature checking is required
(ie in the non-secureboot case).
This indicates that the signature in this kernel module is bogus.

The build was done on an OBS system at OpenHPC. OpenHPC doesn't seem to run a
signing server, and the '# needssslcertforbuild' magic was not set in the spec
file.
Still the OBS voodoo for kernel module signing runs and the test for a cert
fails and the fallback is taken as can be seen by the message:
warning: No buildservice project certificate found, add
warning: # needssslcertforbuild to the specfile
warning: Using /usr/lib/rpm/pesign/pesign-cert.x509 as fallback

Check:
https://build.openhpc.community/build/OpenHPC:1.3/SLE_12/x86_64/lustre-client/_log

I don't think this behaviour is intended as the built modules are useless
unless a signing server is run. I'm not sure how relevant secure boot and
signed kernel modules are in the HPC realm.

Right now this looks to me like an issue in pesign-obs-integration, thus the
assignment.

The same issue can be found when building this package in the openSUSE OBS (as
well as in IBS).