Bug#890891: systemd: PID1 getting stuck printing "systemd[1]: Time has been changed" continuously

On Tue, 20 Feb 2018 19:38:08 +0100 Gert Wollny wrote: > Am Dienstag, den 20.02.2018, 15:31 +0100 schrieb Michael Biebl: > > > > > Kernel: Linux 4.15.1-cm-fx6-my (SMP w/4 CPU cores; PREEMPT) > > > > > > Does this also happen with a Debian provided kernel? If so, which > >

Bug#890891: systemd: PID1 getting stuck printing "systemd[1]: Time has been changed" continuously

Am Dienstag, den 20.02.2018, 15:31 +0100 schrieb Michael Biebl: > > > Kernel: Linux 4.15.1-cm-fx6-my (SMP w/4 CPU cores; PREEMPT) > > > Does this also happen with a Debian provided kernel? If so, which > kernel version is that? I haven't tried this so far, for that reason I was initially also

Bug#890891: systemd: PID1 getting stuck printing "systemd[1]: Time has been changed" continuously

Am 20.02.2018 um 12:40 schrieb Gert Wollny: > on an 32 bit arm system when the RTC is set to a wrong time booting the > system might > fail because systemd gets stuck in a loop printing "systemd[1]: Time has been > changed". > > The problem is known upstream and claimed to be a problem of the

Bug#890891: systemd: PID1 getting stuck printing "systemd[1]: Time has been changed" continuously

Am Dienstag, den 20.02.2018, 14:09 +0100 schrieb Michael Biebl: > > As for the other cases, those are all hypothetical at this point, > right? > Yes, and that's why I did set this bug to severity normal and not higher. In the original bug report I just wanted to point out that there might be

Bug#890891: systemd: PID1 getting stuck printing "systemd[1]: Time has been changed" continuously

Am 20.02.2018 um 13:57 schrieb Gert Wollny: > Am Dienstag, den 20.02.2018, 13:33 +0100 schrieb Michael Biebl: >> Am >> >>> make it lock up in this loop, but if someone can spoof this kind of >>> message and the system locks up because of this, wouldn't this be a >>> typical DoS attack? >> >> How

Bug#890891: systemd: PID1 getting stuck printing "systemd[1]: Time has been changed" continuously

Am Dienstag, den 20.02.2018, 13:33 +0100 schrieb Michael Biebl: > Am > > > make it lock up in this loop, but if someone can spoof this kind of > > message and the system locks up because of this, wouldn't this be a > > typical DoS attack? > > How could an unprivileged user spoof such messages?

Bug#890891: systemd: PID1 getting stuck printing "systemd[1]: Time has been changed" continuously

Am 20.02.2018 um 13:19 schrieb Gert Wollny: > Am Dienstag, den 20.02.2018, 12:56 +0100 schrieb Michael Biebl: >> Am 20.02.2018 um 12:40 schrieb Gert Wollny: >>> However, while upstream is certainly correct that a kernel bug is >>> the trigger of the lockup, systemd should not hang on this, >>>

Bug#890891: systemd: PID1 getting stuck printing "systemd[1]: Time has been changed" continuously

Am Dienstag, den 20.02.2018, 12:56 +0100 schrieb Michael Biebl: > Am 20.02.2018 um 12:40 schrieb Gert Wollny: > > However, while upstream is certainly correct that a kernel bug is > > the trigger of the lockup, systemd should not hang on this, > > because if sending messages to systemd can lock

Bug#890891: systemd: PID1 getting stuck printing "systemd[1]: Time has been changed" continuously

Am 20.02.2018 um 12:40 schrieb Gert Wollny: > However, while upstream is certainly correct that a kernel bug is the trigger > of > the lockup, systemd should not hang on this, because if sending messages to > systemd > can lock up the system then this is actually an attack vector for a DoS >

Bug#890891: systemd: PID1 getting stuck printing "systemd[1]: Time has been changed" continuously

Package: systemd Version: 236-3 Severity: normal Tags: upstream Dear Maintainer, on an 32 bit arm system when the RTC is set to a wrong time booting the system might fail because systemd gets stuck in a loop printing "systemd[1]: Time has been changed". The problem is known upstream and