Π›ΠΎΠ³ΠΎΡ‚ΠΈΠΏ exploitDog
Консоль
Π›ΠΎΠ³ΠΎΡ‚ΠΈΠΏ exploitDog

exploitDog

redhat Π»ΠΎΠ³ΠΎΡ‚ΠΈΠΏ

CVE-2025-39724

ΠžΠΏΡƒΠ±Π»ΠΈΠΊΠΎΠ²Π°Π½ΠΎ: 05 сСнт. 2025
Π˜ΡΡ‚ΠΎΡ‡Π½ΠΈΠΊ: redhat
CVSS3: 4.4
EPSS Низкий

ОписаниС

In the Linux kernel, the following vulnerability has been resolved: serial: 8250: fix panic due to PSLVERR When the PSLVERR_RESP_EN parameter is set to 1, the device generates an error response if an attempt is made to read an empty RBR (Receive Buffer Register) while the FIFO is enabled. In serial8250_do_startup(), calling serial_port_out(port, UART_LCR, UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter function enables the FIFO via serial_out(p, UART_FCR, p->fcr). Execution proceeds to the serial_port_in(port, UART_RX). This satisfies the PSLVERR trigger condition. When another CPU (e.g., using printk()) is accessing the UART (UART is busy), the current CPU fails the check (value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter dw8250_force_idle(). Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lock to fix this issue. Panic backtrace: [ 0.442336] Oops - unknown exception [#1] [ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a [ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e ... [ 0.442416] console_on_rootfs+0x26/0x70

ΠžΡ‚Ρ‡Π΅Ρ‚

A race condition in the 8250 DW UART driver could trigger a PSLVERR and kernel panic when concurrent access occurs during device startup. The bug is only reachable with privileged access (e.g., console or driver initialization) and does not expose memory or data integrity risks. Impact is limited to a local denial of service.

Π—Π°Ρ‚Ρ€ΠΎΠ½ΡƒΡ‚Ρ‹Π΅ ΠΏΠ°ΠΊΠ΅Ρ‚Ρ‹

ΠŸΠ»Π°Ρ‚Ρ„ΠΎΡ€ΠΌΠ°ΠŸΠ°ΠΊΠ΅Ρ‚Π‘ΠΎΡΡ‚ΠΎΡΠ½ΠΈΠ΅Π Π΅ΠΊΠΎΠΌΠ΅Π½Π΄Π°Ρ†ΠΈΡΠ Π΅Π»ΠΈΠ·
Red Hat Enterprise Linux 10kernelFix deferred
Red Hat Enterprise Linux 6kernelNot affected
Red Hat Enterprise Linux 7kernelNot affected
Red Hat Enterprise Linux 7kernel-rtNot affected
Red Hat Enterprise Linux 8kernelFix deferred
Red Hat Enterprise Linux 8kernel-rtFix deferred
Red Hat Enterprise Linux 9kernelFix deferred
Red Hat Enterprise Linux 9kernel-rtFix deferred

ΠŸΠΎΠΊΠ°Π·Ρ‹Π²Π°Ρ‚ΡŒ ΠΏΠΎ

Π”ΠΎΠΏΠΎΠ»Π½ΠΈΡ‚Π΅Π»ΡŒΠ½Π°Ρ информация

Бтатус:

Low
Π”Π΅Ρ„Π΅ΠΊΡ‚:
CWE-362
https://bugzilla.redhat.com/show_bug.cgi?id=2393486kernel: serial: 8250: fix panic due to PSLVERR

EPSS

ΠŸΡ€ΠΎΡ†Π΅Π½Ρ‚ΠΈΠ»ΡŒ: 8%
0.00181
Низкий

4.4 Medium

CVSS3

БвязанныС уязвимости

CVSS3: 5.5
ubuntu
ΠΎΠΊΠΎΠ»ΠΎ 1 Π³ΠΎΠ΄Π° Π½Π°Π·Π°Π΄

In the Linux kernel, the following vulnerability has been resolved: serial: 8250: fix panic due to PSLVERR When the PSLVERR_RESP_EN parameter is set to 1, the device generates an error response if an attempt is made to read an empty RBR (Receive Buffer Register) while the FIFO is enabled. In serial8250_do_startup(), calling serial_port_out(port, UART_LCR, UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter function enables the FIFO via serial_out(p, UART_FCR, p->fcr). Execution proceeds to the serial_port_in(port, UART_RX). This satisfies the PSLVERR trigger condition. When another CPU (e.g., using printk()) is accessing the UART (UART is busy), the current CPU fails the check (value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter dw8250_force_idle(). Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lock to fix this issue. Panic backtrace: [ 0.4...

CVSS3: 5.5
nvd
ΠΎΠΊΠΎΠ»ΠΎ 1 Π³ΠΎΠ΄Π° Π½Π°Π·Π°Π΄

In the Linux kernel, the following vulnerability has been resolved: serial: 8250: fix panic due to PSLVERR When the PSLVERR_RESP_EN parameter is set to 1, the device generates an error response if an attempt is made to read an empty RBR (Receive Buffer Register) while the FIFO is enabled. In serial8250_do_startup(), calling serial_port_out(port, UART_LCR, UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter function enables the FIFO via serial_out(p, UART_FCR, p->fcr). Execution proceeds to the serial_port_in(port, UART_RX). This satisfies the PSLVERR trigger condition. When another CPU (e.g., using printk()) is accessing the UART (UART is busy), the current CPU fails the check (value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter dw8250_force_idle(). Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lock to fix this issue. Panic backtrace: [

CVSS3: 5.5
msrc
ΠΎΠΊΠΎΠ»ΠΎ 1 Π³ΠΎΠ΄Π° Π½Π°Π·Π°Π΄

serial: 8250: fix panic due to PSLVERR

CVSS3: 5.5
debian
ΠΎΠΊΠΎΠ»ΠΎ 1 Π³ΠΎΠ΄Π° Π½Π°Π·Π°Π΄

In the Linux kernel, the following vulnerability has been resolved: s ...

CVSS3: 5.5
github
ΠΎΠΊΠΎΠ»ΠΎ 1 Π³ΠΎΠ΄Π° Π½Π°Π·Π°Π΄

In the Linux kernel, the following vulnerability has been resolved: serial: 8250: fix panic due to PSLVERR When the PSLVERR_RESP_EN parameter is set to 1, the device generates an error response if an attempt is made to read an empty RBR (Receive Buffer Register) while the FIFO is enabled. In serial8250_do_startup(), calling serial_port_out(port, UART_LCR, UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter function enables the FIFO via serial_out(p, UART_FCR, p->fcr). Execution proceeds to the serial_port_in(port, UART_RX). This satisfies the PSLVERR trigger condition. When another CPU (e.g., using printk()) is accessing the UART (UART is busy), the current CPU fails the check (value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter dw8250_force_idle(). Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lock to fix this issue. Panic backtrace: [ ...

EPSS

ΠŸΡ€ΠΎΡ†Π΅Π½Ρ‚ΠΈΠ»ΡŒ: 8%
0.00181
Низкий

4.4 Medium

CVSS3

Π£ΡΠ·Π²ΠΈΠΌΠΎΡΡ‚ΡŒ CVE-2025-39724 Π² Red Hat CVE β€” exploitDog