ghsa-3659-jjmv-v338
Vulnerability from github
Published
2024-02-29 12:31
Modified
2024-02-29 12:31
Details

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

drm/bridge: sii902x: Fix probing race issue

A null pointer dereference crash has been observed rarely on TI platforms using sii9022 bridge:

[ 53.271356] sii902x_get_edid+0x34/0x70 [sii902x] [ 53.276066] sii902x_bridge_get_edid+0x14/0x20 [sii902x] [ 53.281381] drm_bridge_get_edid+0x20/0x34 [drm] [ 53.286305] drm_bridge_connector_get_modes+0x8c/0xcc [drm_kms_helper] [ 53.292955] drm_helper_probe_single_connector_modes+0x190/0x538 [drm_kms_helper] [ 53.300510] drm_client_modeset_probe+0x1f0/0xbd4 [drm] [ 53.305958] __drm_fb_helper_initial_config_and_unlock+0x50/0x510 [drm_kms_helper] [ 53.313611] drm_fb_helper_initial_config+0x48/0x58 [drm_kms_helper] [ 53.320039] drm_fbdev_dma_client_hotplug+0x84/0xd4 [drm_dma_helper] [ 53.326401] drm_client_register+0x5c/0xa0 [drm] [ 53.331216] drm_fbdev_dma_setup+0xc8/0x13c [drm_dma_helper] [ 53.336881] tidss_probe+0x128/0x264 [tidss] [ 53.341174] platform_probe+0x68/0xc4 [ 53.344841] really_probe+0x188/0x3c4 [ 53.348501] __driver_probe_device+0x7c/0x16c [ 53.352854] driver_probe_device+0x3c/0x10c [ 53.357033] __device_attach_driver+0xbc/0x158 [ 53.361472] bus_for_each_drv+0x88/0xe8 [ 53.365303] __device_attach+0xa0/0x1b4 [ 53.369135] device_initial_probe+0x14/0x20 [ 53.373314] bus_probe_device+0xb0/0xb4 [ 53.377145] deferred_probe_work_func+0xcc/0x124 [ 53.381757] process_one_work+0x1f0/0x518 [ 53.385770] worker_thread+0x1e8/0x3dc [ 53.389519] kthread+0x11c/0x120 [ 53.392750] ret_from_fork+0x10/0x20

The issue here is as follows:

  • tidss probes, but is deferred as sii902x is still missing.
  • sii902x starts probing and enters sii902x_init().
  • sii902x calls drm_bridge_add(). Now the sii902x bridge is ready from DRM's perspective.
  • sii902x calls sii902x_audio_codec_init() and platform_device_register_data()
  • The registration of the audio platform device causes probing of the deferred devices.
  • tidss probes, which eventually causes sii902x_bridge_get_edid() to be called.
  • sii902x_bridge_get_edid() tries to use the i2c to read the edid. However, the sii902x driver has not set up the i2c part yet, leading to the crash.

Fix this by moving the drm_bridge_add() to the end of the sii902x_init(), which is also at the very end of sii902x_probe().

Show details on source website


{
  "affected": [],
  "aliases": [
    "CVE-2024-26607"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-29T12:15:47Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/bridge: sii902x: Fix probing race issue\n\nA null pointer dereference crash has been observed rarely on TI\nplatforms using sii9022 bridge:\n\n[   53.271356]  sii902x_get_edid+0x34/0x70 [sii902x]\n[   53.276066]  sii902x_bridge_get_edid+0x14/0x20 [sii902x]\n[   53.281381]  drm_bridge_get_edid+0x20/0x34 [drm]\n[   53.286305]  drm_bridge_connector_get_modes+0x8c/0xcc [drm_kms_helper]\n[   53.292955]  drm_helper_probe_single_connector_modes+0x190/0x538 [drm_kms_helper]\n[   53.300510]  drm_client_modeset_probe+0x1f0/0xbd4 [drm]\n[   53.305958]  __drm_fb_helper_initial_config_and_unlock+0x50/0x510 [drm_kms_helper]\n[   53.313611]  drm_fb_helper_initial_config+0x48/0x58 [drm_kms_helper]\n[   53.320039]  drm_fbdev_dma_client_hotplug+0x84/0xd4 [drm_dma_helper]\n[   53.326401]  drm_client_register+0x5c/0xa0 [drm]\n[   53.331216]  drm_fbdev_dma_setup+0xc8/0x13c [drm_dma_helper]\n[   53.336881]  tidss_probe+0x128/0x264 [tidss]\n[   53.341174]  platform_probe+0x68/0xc4\n[   53.344841]  really_probe+0x188/0x3c4\n[   53.348501]  __driver_probe_device+0x7c/0x16c\n[   53.352854]  driver_probe_device+0x3c/0x10c\n[   53.357033]  __device_attach_driver+0xbc/0x158\n[   53.361472]  bus_for_each_drv+0x88/0xe8\n[   53.365303]  __device_attach+0xa0/0x1b4\n[   53.369135]  device_initial_probe+0x14/0x20\n[   53.373314]  bus_probe_device+0xb0/0xb4\n[   53.377145]  deferred_probe_work_func+0xcc/0x124\n[   53.381757]  process_one_work+0x1f0/0x518\n[   53.385770]  worker_thread+0x1e8/0x3dc\n[   53.389519]  kthread+0x11c/0x120\n[   53.392750]  ret_from_fork+0x10/0x20\n\nThe issue here is as follows:\n\n- tidss probes, but is deferred as sii902x is still missing.\n- sii902x starts probing and enters sii902x_init().\n- sii902x calls drm_bridge_add(). Now the sii902x bridge is ready from\n  DRM\u0027s perspective.\n- sii902x calls sii902x_audio_codec_init() and\n  platform_device_register_data()\n- The registration of the audio platform device causes probing of the\n  deferred devices.\n- tidss probes, which eventually causes sii902x_bridge_get_edid() to be\n  called.\n- sii902x_bridge_get_edid() tries to use the i2c to read the edid.\n  However, the sii902x driver has not set up the i2c part yet, leading\n  to the crash.\n\nFix this by moving the drm_bridge_add() to the end of the\nsii902x_init(), which is also at the very end of sii902x_probe().",
  "id": "GHSA-3659-jjmv-v338",
  "modified": "2024-02-29T12:31:06Z",
  "published": "2024-02-29T12:31:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26607"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/08ac6f132dd77e40f786d8af51140c96c6d739c9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2a4c6af7934a7b4c304542c38fee35e09cc1770c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/56f96cf6eb11a1c2d594367c3becbfb06a855ec1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e0f83c234ea7a3dec1f84e5d02caa1c51664a076"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading...

Loading...

Loading...

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.