fkie_cve-2024-56693
Vulnerability from fkie_nvd
Published
2024-12-28 10:15
Modified
2025-02-10 18:15
Severity ?
7.8 (High) - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Summary
In the Linux kernel, the following vulnerability has been resolved: brd: defer automatic disk creation until module initialization succeeds My colleague Wupeng found the following problems during fault injection: BUG: unable to handle page fault for address: fffffbfff809d073 PGD 6e648067 P4D 123ec8067 PUD 123ec4067 PMD 100e38067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 5 UID: 0 PID: 755 Comm: modprobe Not tainted 6.12.0-rc3+ #17 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:__asan_load8+0x4c/0xa0 ... Call Trace: <TASK> blkdev_put_whole+0x41/0x70 bdev_release+0x1a3/0x250 blkdev_release+0x11/0x20 __fput+0x1d7/0x4a0 task_work_run+0xfc/0x180 syscall_exit_to_user_mode+0x1de/0x1f0 do_syscall_64+0x6b/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e loop_init() is calling loop_add() after __register_blkdev() succeeds and is ignoring disk_add() failure from loop_add(), for loop_add() failure is not fatal and successfully created disks are already visible to bdev_open(). brd_init() is currently calling brd_alloc() before __register_blkdev() succeeds and is releasing successfully created disks when brd_init() returns an error. This can cause UAF for the latter two case: case 1: T1: modprobe brd brd_init brd_alloc(0) // success add_disk disk_scan_partitions bdev_file_open_by_dev // alloc file fput // won't free until back to userspace brd_alloc(1) // failed since mem alloc error inject // error path for modprobe will release code segment // back to userspace __fput blkdev_release bdev_release blkdev_put_whole bdev->bd_disk->fops->release // fops is freed now, UAF! case 2: T1: T2: modprobe brd brd_init brd_alloc(0) // success open(/dev/ram0) brd_alloc(1) // fail // error path for modprobe close(/dev/ram0) ... /* UAF! */ bdev->bd_disk->fops->release Fix this problem by following what loop_init() does. Besides, reintroduce brd_devices_mutex to help serialize modifications to brd_list.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/259bf925583ec9e3781df778cadf00594095090d
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/410896624db639500f24f46478b4bfa05c76bf56
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/41219c147df8bbd6591f59af5d695fb6c9a1cbff
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/63dfd728b30f79495dacc886127695a379805152
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/826cc42adf44930a633d11a5993676d85ddb0842
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/c0c2744cd2939ec5999c51dbaf2af16886548b7b
Impacted products
Vendor Product Version


To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbrd: defer automatic disk creation until module initialization succeeds\n\nMy colleague Wupeng found the following problems during fault injection:\n\nBUG: unable to handle page fault for address: fffffbfff809d073\nPGD 6e648067 P4D 123ec8067 PUD 123ec4067 PMD 100e38067 PTE 0\nOops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 5 UID: 0 PID: 755 Comm: modprobe Not tainted 6.12.0-rc3+ #17\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.1-2.fc37 04/01/2014\nRIP: 0010:__asan_load8+0x4c/0xa0\n...\nCall Trace:\n \u003cTASK\u003e\n blkdev_put_whole+0x41/0x70\n bdev_release+0x1a3/0x250\n blkdev_release+0x11/0x20\n __fput+0x1d7/0x4a0\n task_work_run+0xfc/0x180\n syscall_exit_to_user_mode+0x1de/0x1f0\n do_syscall_64+0x6b/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nloop_init() is calling loop_add() after __register_blkdev() succeeds and\nis ignoring disk_add() failure from loop_add(), for loop_add() failure\nis not fatal and successfully created disks are already visible to\nbdev_open().\n\nbrd_init() is currently calling brd_alloc() before __register_blkdev()\nsucceeds and is releasing successfully created disks when brd_init()\nreturns an error. This can cause UAF for the latter two case:\n\ncase 1:\n    T1:\nmodprobe brd\n  brd_init\n    brd_alloc(0) // success\n      add_disk\n        disk_scan_partitions\n          bdev_file_open_by_dev // alloc file\n          fput // won\u0027t free until back to userspace\n    brd_alloc(1) // failed since mem alloc error inject\n  // error path for modprobe will release code segment\n  // back to userspace\n  __fput\n    blkdev_release\n      bdev_release\n        blkdev_put_whole\n          bdev-\u003ebd_disk-\u003efops-\u003erelease // fops is freed now, UAF!\n\ncase 2:\n    T1:                            T2:\nmodprobe brd\n  brd_init\n    brd_alloc(0) // success\n                                   open(/dev/ram0)\n    brd_alloc(1) // fail\n  // error path for modprobe\n\n                                   close(/dev/ram0)\n                                   ...\n                                   /* UAF! */\n                                   bdev-\u003ebd_disk-\u003efops-\u003erelease\n\nFix this problem by following what loop_init() does. Besides,\nreintroduce brd_devices_mutex to help serialize modifications to\nbrd_list."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: brd: aplazar la creaci\u00f3n autom\u00e1tica de discos hasta que la inicializaci\u00f3n del m\u00f3dulo tenga \u00e9xito. Mi colega Wupeng encontr\u00f3 los siguientes problemas durante la inyecci\u00f3n de fallas: ERROR: no se puede gestionar la falla de p\u00e1gina para la direcci\u00f3n: fffffbfff809d073 PGD 6e648067 P4D 123ec8067 PUD 123ec4067 PMD 100e38067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 5 UID: 0 PID: 755 Comm: modprobe No contaminado 6.12.0-rc3+ #17 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:__asan_load8+0x4c/0xa0 ... Seguimiento de llamadas:  blkdev_put_whole+0x41/0x70 bdev_release+0x1a3/0x250 blkdev_release+0x11/0x20 __fput+0x1d7/0x4a0 task_work_run+0xfc/0x180 syscall_exit_to_user_mode+0x1de/0x1f0 do_syscall_64+0x6b/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e loop_init() est\u00e1 llamando a loop_add() despu\u00e9s de que __register_blkdev() tenga \u00e9xito e ignora el error de disk_add() de loop_add(), ya que el error de loop_add() no es fatal y los discos creados correctamente ya est\u00e1n visibles para bdev_open().brd_init() actualmente est\u00e1 llamando a brd_alloc() antes de que __register_blkdev() tenga \u00e9xito y est\u00e1 liberando discos creados exitosamente cuando brd_init() devuelve un error. Esto puede causar UAF para los \u00faltimos dos casos: caso 1: T1: modprobe brd brd_init brd_alloc(0) // \u00e9xito add_disk disk_scan_partitions bdev_file_open_by_dev // asignar archivo fput // no se liberar\u00e1 hasta que regrese al espacio de usuario brd_alloc(1) // fall\u00f3 debido a un error de asignaci\u00f3n de memoria inject // error la ruta para modprobe liberar\u00e1 el segmento de c\u00f3digo // de regreso al espacio de usuario __fput blkdev_release bdev_release blkdev_put_whole bdev-\u0026gt;bd_disk-\u0026gt;fops-\u0026gt;release // fops est\u00e1 liberado ahora, \u00a1UAF! caso 2: T1: T2: modprobe brd brd_init brd_alloc(0) // \u00e9xito open(/dev/ram0) brd_alloc(1) // error // ruta de error para modprobe close(/dev/ram0) ... /* UAF! */ bdev-\u0026gt;bd_disk-\u0026gt;fops-\u0026gt;release Solucione este problema siguiendo lo que hace loop_init(). Adem\u00e1s, vuelva a introducir brd_devices_mutex para ayudar a serializar las modificaciones a brd_list."
    }
  ],
  "id": "CVE-2024-56693",
  "lastModified": "2025-02-10T18:15:32.100",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 7.8,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.8,
        "impactScore": 5.9,
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "type": "Secondary"
      }
    ]
  },
  "published": "2024-12-28T10:15:14.833",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/259bf925583ec9e3781df778cadf00594095090d"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/410896624db639500f24f46478b4bfa05c76bf56"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/41219c147df8bbd6591f59af5d695fb6c9a1cbff"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/63dfd728b30f79495dacc886127695a379805152"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/826cc42adf44930a633d11a5993676d85ddb0842"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/c0c2744cd2939ec5999c51dbaf2af16886548b7b"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-416"
        }
      ],
      "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
      "type": "Secondary"
    }
  ]
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




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.