Описание
In the Linux kernel, the following vulnerability has been resolved:
s390/ipl: Fix NULL deref in dump_reipl without re-IPL parm block
Unlike kdump, which passes the re-IPL parameter block through os_info,
the stand-alone dump passes it through the IPL parm block address and
checksum in lowcore.
Some IPL types, like HMC FTP boot or QEMU direct kernel boot, might not
provide an IPL parameter block. In this case reipl_type_init() selects
IPL_TYPE_UNKNOWN and reipl_block_actual remains NULL. Nevertheless,
dump_reipl_run() unconditionally dereferences it when preparing the
lowcore fields. This may happen to work by chance when address zero
contains readable lowcore data. A zero IPL parameter block address is
then stored in lowcore, causing the stand-alone dumper to enter disabled
wait after completing the dump.
Explicitly store a zero IPL parameter block address and checksum when no
re-IPL parameter block is available. This does not change the behavior:
the stand-alone dumper completes the dump and halts, while valid re-IPL
parameter blocks continue to be handled as before.
A flaw was found in the Linux kernel. On s390 (IBM Z) systems booted without an Initial Program Load (IPL) parameter block, such as during direct kernel boot, the kernel does not verify the parameter block before dereferencing it during dump operations. A local privileged user could trigger this condition during system shutdown or dump preparation, causing a null pointer dereference. This issue results in a kernel crash, leading to a denial of service (DoS).
Отчет
A low severity flaw was found in the Linux kernel s390 (IBM Z) IPL subsystem. On systems booted without an IPL parameter block, such as via HMC FTP boot or QEMU direct kernel boot, reipl_type_init() selects IPL_TYPE_UNKNOWN and reipl_block_actual remains NULL, yet dump_reipl_run() unconditionally dereferences that pointer while preparing the lowcore fields for a stand-alone dump. A local privileged user who triggers a stand-alone dump on such a system can cause a NULL pointer dereference and kernel crash, resulting in a denial of service; alternatively, when address zero happens to contain readable lowcore data, the stand-alone dumper completes the dump and enters disabled wait, preventing the expected automatic re-IPL. Only availability is impacted; there is no effect on confidentiality or integrity. Red Hat Enterprise Linux 6 is an out-of-support stream (OOSS), while the kernel and kernel-rt packages in Red Hat Enterprise Linux 7, 8, 9, and 10, Red Hat In-Vehicle OS, and the OpenShift Container Platform RHEL CoreOS kernels are affected with fixes currently deferred: triggering the flaw requires local administrative privileges on an s390 system booted in an uncommon configuration, and the residual risk is limited to a denial of service during stand-alone dump or shutdown workflows. Red Hat assesses this issue as LOW severity, lower than the upstream rating, because exploitation requires local privileged access and an uncommon s390 boot configuration, and the impact is confined to availability.
Меры по смягчению последствий
On affected s390 systems booted without an IPL parameter block (for example via HMC FTP boot or QEMU direct kernel boot), using kdump instead of the stand-alone dumper avoids the vulnerable code path, because kdump passes the re-IPL parameter block through os_info rather than through the lowcore IPL parameter block address and checksum. For environments that rely on the stand-alone dumper, booting the system with a valid IPL parameter block also avoids the NULL dereference path, as valid re-IPL parameter blocks are handled as before. Fixes for the affected Red Hat kernel streams are currently deferred and no fixed package version is available at this time.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Red Hat Enterprise Linux 10 | kernel | Fix deferred | ||
| Red Hat Enterprise Linux 6 | kernel | Out of support scope | ||
| Red Hat Enterprise Linux 7 | kernel | Fix deferred | ||
| Red Hat Enterprise Linux 7 | kernel-rt | Fix deferred | ||
| Red Hat Enterprise Linux 8 | kernel | Fix deferred | ||
| Red Hat Enterprise Linux 8 | kernel-rt | Fix deferred | ||
| Red Hat Enterprise Linux 9 | kernel | Fix deferred | ||
| Red Hat Enterprise Linux 9 | kernel-rt | Fix deferred | ||
| Red Hat OpenShift Container Platform 4 | openshift/ose-rhel-coreos-8 | Fix deferred | ||
| Red Hat OpenShift Container Platform 4 | openshift/ose-rhel-coreos-9 | Fix deferred |
Показывать по
Дополнительная информация
Статус:
5.5 Medium
CVSS3
Связанные уязвимости
In the Linux kernel, the following vulnerability has been resolved: s390/ipl: Fix NULL deref in dump_reipl without re-IPL parm block Unlike kdump, which passes the re-IPL parameter block through os_info, the stand-alone dump passes it through the IPL parm block address and checksum in lowcore. Some IPL types, like HMC FTP boot or QEMU direct kernel boot, might not provide an IPL parameter block. In this case reipl_type_init() selects IPL_TYPE_UNKNOWN and reipl_block_actual remains NULL. Nevertheless, dump_reipl_run() unconditionally dereferences it when preparing the lowcore fields. This may happen to work by chance when address zero contains readable lowcore data. A zero IPL parameter block address is then stored in lowcore, causing the stand-alone dumper to enter disabled wait after completing the dump. Explicitly store a zero IPL parameter block address and checksum when no re-IPL parameter block is available. This does not change the behavior: the stand-alone dumper completes th...
In the Linux kernel, the following vulnerability has been resolved: s390/ipl: Fix NULL deref in dump_reipl without re-IPL parm block Unlike kdump, which passes the re-IPL parameter block through os_info, the stand-alone dump passes it through the IPL parm block address and checksum in lowcore. Some IPL types, like HMC FTP boot or QEMU direct kernel boot, might not provide an IPL parameter block. In this case reipl_type_init() selects IPL_TYPE_UNKNOWN and reipl_block_actual remains NULL. Nevertheless, dump_reipl_run() unconditionally dereferences it when preparing the lowcore fields. This may happen to work by chance when address zero contains readable lowcore data. A zero IPL parameter block address is then stored in lowcore, causing the stand-alone dumper to enter disabled wait after completing the dump. Explicitly store a zero IPL parameter block address and checksum when no re-IPL parameter block is available. This does not change the behavior: the stand-alone dumper completes t
In the Linux kernel, the following vulnerability has been resolved: s ...
In the Linux kernel, the following vulnerability has been resolved: s390/ipl: Fix NULL deref in dump_reipl without re-IPL parm block Unlike kdump, which passes the re-IPL parameter block through os_info, the stand-alone dump passes it through the IPL parm block address and checksum in lowcore. Some IPL types, like HMC FTP boot or QEMU direct kernel boot, might not provide an IPL parameter block. In this case reipl_type_init() selects IPL_TYPE_UNKNOWN and reipl_block_actual remains NULL. Nevertheless, dump_reipl_run() unconditionally dereferences it when preparing the lowcore fields. This may happen to work by chance when address zero contains readable lowcore data. A zero IPL parameter block address is then stored in lowcore, causing the stand-alone dumper to enter disabled wait after completing the dump. Explicitly store a zero IPL parameter block address and checksum when no re-IPL parameter block is available. This does not change the behavior: the stand-alone dumper complete...
5.5 Medium
CVSS3