Out-of-bounds Write Affecting kernel-zfcpdump-devel package, versions <0:4.18.0-477.74.1.el8_8


Severity

Recommended
high

Based on Red Hat Enterprise Linux security rating.

Threat Intelligence

EPSS
0.04% (15th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-RHEL8-KERNELZFCPDUMPDEVEL-8085442
  • published24 Sept 2024
  • disclosed29 May 2024

Introduced: 29 May 2024

CVE-2024-36016  (opens in a new tab)
CWE-787  (opens in a new tab)

How to fix?

Upgrade RHEL:8 kernel-zfcpdump-devel to version 0:4.18.0-477.74.1.el8_8 or higher.
This issue was patched in RHSA-2024:6993.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-zfcpdump-devel package and not the kernel-zfcpdump-devel package as distributed by RHEL. See How to fix? for RHEL:8 relevant fixed versions and status.

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

tty: n_gsm: fix possible out-of-bounds in gsm0_receive()

Assuming the following:

  • side A configures the n_gsm in basic option mode
  • side B sends the header of a basic option mode frame with data length 1
  • side A switches to advanced option mode
  • side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode.
  • side A switches to basic option mode
  • side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration.

Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAX_MRU in gsm0_receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru.

All other checks remain as we still need to limit the data according to the user configuration and actual payload size.

CVSS Scores

version 3.1