Серьезная (возможно уязвимость) проблема в механизме ввода и последующей обработки осью пароля ( например шифрования диска)

Товарищи, Предлагаю обсудить следующую проблему.

Сразу говорю, что я не линуксист. Возможно я что то где то не учел, и ошибки нет, но в програмиировании и работе компьютеров я разбираюсь хорошо и как программист вещь замеченная мной, кажется абсолютным нонсенсом.
Ошибка(в скорости набора) видимо заключается только в консольной функции/процедуре (которая задействуется при установке ос и при вводе пароля перед расшифровкой диска после установки), либо это вообще баг генерации хэша, а возможно и признак бекдура, оставленный по понянтым причинам разработчиками. Возможно проблема куда серьезнее и развить ее можно до уровня серьезной уязвимости.
Суть в следующем - если у вас в пароле есть одинаковые подряд идущие символы, то введя их очень быстро мы получаем неоднозначность(пример):

пароль - aabcdd.
При установке ос какие то одинаковые подряд идущие символы вводим очень быстро.
После установки, начале загрузки и запросе пароля для расшифровки диска с ос получается следующее.
Введя в нормальном темпе пароль - aabcdd - мы получаем - пароль не верен.
но если ввести в нем (возможно любые/точно любые подряд идущие одинаковые ) символы очень быстро например aa, либо dd. то пароль принимается и происходит загрузка и расшифровка.(замечено было в Suse 12.1, но видимо актуально и в других).
пароль лишь пример - это относится и к паролям вида abc99deFFgh и т.п.

то есть...
aabcdee(нормальная скорость ввода) - false.
(aa)(быстро)bcdee - true
aabcd(ee)(быстро) - true
------------------

с точки зрения программирования, при отсутсвии ошибок в коде, такого происходить не должно. Как минимум таким образом можно по нелепости утратить полностью доступ к ос и ко всем данным. Это уже неприятно. Но самая главная непонятка не в этом. А в том почему подходит второй вариант введения пароля в примере.
Можно было бы все списать на то что при быстром нажатии одной и той же кнопки ось символ вводит лишь один, или что то вроде - вводится пустой(например 0x00) и в результате у нас просто ошибочный пароль. Но это не так! Можно ввести быстро любую часть пароля и тогда то хэш совпадает...
Одним из объяснений может быть следующее - при быстром вводе происходит сбой, например NPE - и пароль становится NULL (или что то в этом духе), и из за сбоя генерируется хэш на NULL пароль. Соотвественно в дальнейшем быстро вводя пароль вы повторяете этот баг - получается что информация зашифрована «условно пустым» паролем, то есть по сути как если бы вы вобще не вводили пароля. Однако пароль отличный от исходного нс быстро введенными символами не подходит. Ни времени ни желания в исходниках оси копаться нет и разбиратся как там это устроено, поэтому и пишу здесь, так как проблема может быть очень серьезной. Возможно там пароль для большей безопастности перед хэшированием, разбавляется солью, причем той, которая зависит от исходного пароля (а вернее того что было введено) - это единственое объяснение которое приходит на ум.