https://launchpad.net/ubuntu/+source/linux/4.4.0-109.132 :

    linux (4.4.0-109.132) xenial; urgency=low
    
      * linux: 4.4.0-109.132 -proposed tracker (LP: #1742252)
    
      * Kernel trace with xenial 4.4  (4.4.0-108.131, Candidate kernels for PTI fix)
        (LP: #1741934)
        - SAUCE: kaiser: fix perf crashes - fix to original commit

diff'ing the two changes it was this:

    > diff -u linux-4.4.0/arch/x86/events/intel/ds.c linux-4.4.0/arch/x86/events/intel/ds.c
    > --- linux-4.4.0/arch/x86/events/intel/ds.c
    > +++ linux-4.4.0/arch/x86/events/intel/ds.c
    > @@ -415,7 +415,6 @@
    >  		return;
    >  
    >  	per_cpu(cpu_hw_events, cpu).ds = NULL;
    > -	kfree(ds);
    >  }
    >  
    >  void release_ds_buffers(void)

plus it's here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1741934...

They consider a bug that renders the OS unable to boot a "low" urgency!?!

I don't think the urgency field is meaningful in Ubuntu, especially for post-release fixes - I believe a package migrates as soon as it's approved and passes builds/tests. The urgency field comes from Debian, which uses it to describe how many days a package should sit in Debian unstable before migrating to Debian testing, in the hopes that if it's buggy, people will file a bug before it migrates to testing. The Debian default is now "medium" (5 days) instead of "low" (10 days), but people with older tools tend to generate changelog entries that say "low". (And even in Debian, I don't think the field has any meaning for post-release updates; I think it only applies to unstable-to-testing migrations.)

Given this seems to be affecting a relatively small number of systems, that's not necessarily unreasonable. It might be very urgent for the people affected, but still low urgency for the userbase overall as compared to other problems.

Though it seems more likely to me that this bug was filed as a placeholder for the already-written patch and verification thereof, and the person filing it simply didn't bother with the urgency field since it wasn't really a bug-report-as-such.

I think it's fair to say build 108 has no security issues :P in fact, it's the most secure one yet.

Yup. It's so secure that they don't even load userspace into RAM!