{"api_version":"1","generated_at":"2026-08-15T08:44:36+00:00","cve":"CVE-2026-74388","urls":{"html":"https://cve.report/CVE-2026-74388","api":"https://cve.report/api/cve/CVE-2026-74388.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-74388","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-74388"},"summary":{"title":"ALSA: seq: oss: Fix UAF at handling events with embedded SysEx data","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: seq: oss: Fix UAF at handling events with embedded SysEx data\n\nThe OSS sequencer processes the input MIDI bytes into a sequencer\nevent to be dispatched later (in snd_seq_oss_midi_putc() called from\nsnd_seq_oss_process_event()).  When it's a SysEx data, the event\nrecord contains data.ext.ptr pointer to the original SysEx bytes, and\nthe referred data is copied into the pool afterwards at dispatching.\nThe problem is that, if the sequencer port gets closed concurrently\nbefore the dispatch, the OSS sequencer core also releases the\nresources (in snd_seq_oss_midi_check_exit_port()), while the pending\nevent may hold a stale pointer, eventually leading to a UAF at a later\ndispatch.\n\nFortunately, there is already a refcounting mechanism (snd_use_lock_t)\nfor the OSS MIDI device access, and for addressing the issue above, we\njust need to extend the refcount until the event gets dispatched.\n\nThis patch extends snd_seq_oss_process_event() to give back the\nrefcount object, which is in turn released after calling the sequencer\ndispatcher with the given event in the caller side.\n\nAccording to the original report, KASAN report as below:\n\nKASAN slab-use-after-free in snd_seq_event_dup+0x40c/0x470\nRIP: 0033:0x7f2cb66a6340\nRead of size 6\nCall trace:\n  dump_stack_lvl+0x73/0xb0 (?:?)\n  print_report+0xd1/0x650 (?:?)\n  srso_alias_return_thunk+0x5/0xfbef5 (?:?)\n  __virt_addr_valid+0x1a7/0x340 (?:?)\n  kasan_complete_mode_report_info+0x64/0x200 (?:?)\n  kasan_report+0xf7/0x130 (?:?)\n  snd_seq_event_dup+0x40c/0x470 (?:?)\n  kasan_check_range+0x10c/0x1c0 (?:?)\n  __asan_memcpy+0x27/0x70 (?:?)\n  snd_seq_event_dup+0x9/0x470 (?:?)\n  snd_seq_client_enqueue_event+0x139/0x240 (?:?)\n  _raw_spin_unlock_irqrestore+0x4b/0x60 (?:?)\n  snd_seq_kernel_client_enqueue+0x102/0x120 (?:?)\n  snd_seq_oss_write+0x416/0x4e0 (?:?)\n  apparmor_file_permission+0x20/0x30 (?:?)\n  odev_write+0x3b/0x60 (?:?)\n  vfs_write+0x1ce/0x850 (?:?)\n  lock_release+0xc8/0x2a0 (?:?)\n  __kasan_check_write+0x18/0x20 (?:?)\n  __mutex_unlock_slowpath+0x129/0x510 (?:?)\n  ksys_write+0xe1/0x180 (?:?)\n  mutex_unlock+0x16/0x20 (?:?)\n  odev_ioctl+0x65/0xc0 (?:?)\n  __x64_sys_write+0x46/0x60 (?:?)\n  x64_sys_call+0x7d/0x20d0 (?:?)\n  do_syscall_64+0xc1/0x360 (arch/x86/entry/syscall_64.c:87)\n  entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)","state":"PUBLISHED","assigner":"Linux","published_at":"2026-08-15 06:22:40","updated_at":"2026-08-15 06:22:40"},"problem_types":[],"metrics":[],"references":[{"url":"https://git.kernel.org/stable/c/7c349b4f2a603202fb8c363bd2774a22ac2fddf3","name":"https://git.kernel.org/stable/c/7c349b4f2a603202fb8c363bd2774a22ac2fddf3","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/7aad70cabd8f34cf11a9593fcd3f2ac3f5496943","name":"https://git.kernel.org/stable/c/7aad70cabd8f34cf11a9593fcd3f2ac3f5496943","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/6dc781778b595be94c31395b2cb167f65145d91f","name":"https://git.kernel.org/stable/c/6dc781778b595be94c31395b2cb167f65145d91f","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-74388","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74388","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 6dc781778b595be94c31395b2cb167f65145d91f git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 7aad70cabd8f34cf11a9593fcd3f2ac3f5496943 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 7c349b4f2a603202fb8c363bd2774a22ac2fddf3 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 2.6.12","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 2.6.12 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18.40 6.18.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.1.5 7.1.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2-rc1 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["sound/core/seq/oss/seq_oss_event.c","sound/core/seq/oss/seq_oss_event.h","sound/core/seq/oss/seq_oss_ioctl.c","sound/core/seq/oss/seq_oss_midi.c","sound/core/seq/oss/seq_oss_midi.h","sound/core/seq/oss/seq_oss_rw.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"6dc781778b595be94c31395b2cb167f65145d91f","status":"affected","version":"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2","versionType":"git"},{"lessThan":"7aad70cabd8f34cf11a9593fcd3f2ac3f5496943","status":"affected","version":"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2","versionType":"git"},{"lessThan":"7c349b4f2a603202fb8c363bd2774a22ac2fddf3","status":"affected","version":"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["sound/core/seq/oss/seq_oss_event.c","sound/core/seq/oss/seq_oss_event.h","sound/core/seq/oss/seq_oss_ioctl.c","sound/core/seq/oss/seq_oss_midi.c","sound/core/seq/oss/seq_oss_midi.h","sound/core/seq/oss/seq_oss_rw.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"2.6.12"},{"lessThan":"2.6.12","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"6.18.*","status":"unaffected","version":"6.18.40","versionType":"semver"},{"lessThanOrEqual":"7.1.*","status":"unaffected","version":"7.1.5","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.2-rc1","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.18.40","versionStartIncluding":"2.6.12","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.1.5","versionStartIncluding":"2.6.12","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.2-rc1","versionStartIncluding":"2.6.12","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: seq: oss: Fix UAF at handling events with embedded SysEx data\n\nThe OSS sequencer processes the input MIDI bytes into a sequencer\nevent to be dispatched later (in snd_seq_oss_midi_putc() called from\nsnd_seq_oss_process_event()).  When it's a SysEx data, the event\nrecord contains data.ext.ptr pointer to the original SysEx bytes, and\nthe referred data is copied into the pool afterwards at dispatching.\nThe problem is that, if the sequencer port gets closed concurrently\nbefore the dispatch, the OSS sequencer core also releases the\nresources (in snd_seq_oss_midi_check_exit_port()), while the pending\nevent may hold a stale pointer, eventually leading to a UAF at a later\ndispatch.\n\nFortunately, there is already a refcounting mechanism (snd_use_lock_t)\nfor the OSS MIDI device access, and for addressing the issue above, we\njust need to extend the refcount until the event gets dispatched.\n\nThis patch extends snd_seq_oss_process_event() to give back the\nrefcount object, which is in turn released after calling the sequencer\ndispatcher with the given event in the caller side.\n\nAccording to the original report, KASAN report as below:\n\nKASAN slab-use-after-free in snd_seq_event_dup+0x40c/0x470\nRIP: 0033:0x7f2cb66a6340\nRead of size 6\nCall trace:\n  dump_stack_lvl+0x73/0xb0 (?:?)\n  print_report+0xd1/0x650 (?:?)\n  srso_alias_return_thunk+0x5/0xfbef5 (?:?)\n  __virt_addr_valid+0x1a7/0x340 (?:?)\n  kasan_complete_mode_report_info+0x64/0x200 (?:?)\n  kasan_report+0xf7/0x130 (?:?)\n  snd_seq_event_dup+0x40c/0x470 (?:?)\n  kasan_check_range+0x10c/0x1c0 (?:?)\n  __asan_memcpy+0x27/0x70 (?:?)\n  snd_seq_event_dup+0x9/0x470 (?:?)\n  snd_seq_client_enqueue_event+0x139/0x240 (?:?)\n  _raw_spin_unlock_irqrestore+0x4b/0x60 (?:?)\n  snd_seq_kernel_client_enqueue+0x102/0x120 (?:?)\n  snd_seq_oss_write+0x416/0x4e0 (?:?)\n  apparmor_file_permission+0x20/0x30 (?:?)\n  odev_write+0x3b/0x60 (?:?)\n  vfs_write+0x1ce/0x850 (?:?)\n  lock_release+0xc8/0x2a0 (?:?)\n  __kasan_check_write+0x18/0x20 (?:?)\n  __mutex_unlock_slowpath+0x129/0x510 (?:?)\n  ksys_write+0xe1/0x180 (?:?)\n  mutex_unlock+0x16/0x20 (?:?)\n  odev_ioctl+0x65/0xc0 (?:?)\n  __x64_sys_write+0x46/0x60 (?:?)\n  x64_sys_call+0x7d/0x20d0 (?:?)\n  do_syscall_64+0xc1/0x360 (arch/x86/entry/syscall_64.c:87)\n  entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)"}],"providerMetadata":{"dateUpdated":"2026-08-15T05:59:03.147Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/6dc781778b595be94c31395b2cb167f65145d91f"},{"url":"https://git.kernel.org/stable/c/7aad70cabd8f34cf11a9593fcd3f2ac3f5496943"},{"url":"https://git.kernel.org/stable/c/7c349b4f2a603202fb8c363bd2774a22ac2fddf3"}],"title":"ALSA: seq: oss: Fix UAF at handling events with embedded SysEx data","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-74388","datePublished":"2026-08-15T05:59:03.147Z","dateReserved":"2026-08-15T05:44:03.891Z","dateUpdated":"2026-08-15T05:59:03.147Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-08-15 06:22:40","lastModifiedDate":"2026-08-15 06:22:40","problem_types":[],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"74388","Ordinal":"1","Title":"ALSA: seq: oss: Fix UAF at handling events with embedded SysEx d","CVE":"CVE-2026-74388","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"74388","Ordinal":"1","NoteData":"In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: seq: oss: Fix UAF at handling events with embedded SysEx data\n\nThe OSS sequencer processes the input MIDI bytes into a sequencer\nevent to be dispatched later (in snd_seq_oss_midi_putc() called from\nsnd_seq_oss_process_event()).  When it's a SysEx data, the event\nrecord contains data.ext.ptr pointer to the original SysEx bytes, and\nthe referred data is copied into the pool afterwards at dispatching.\nThe problem is that, if the sequencer port gets closed concurrently\nbefore the dispatch, the OSS sequencer core also releases the\nresources (in snd_seq_oss_midi_check_exit_port()), while the pending\nevent may hold a stale pointer, eventually leading to a UAF at a later\ndispatch.\n\nFortunately, there is already a refcounting mechanism (snd_use_lock_t)\nfor the OSS MIDI device access, and for addressing the issue above, we\njust need to extend the refcount until the event gets dispatched.\n\nThis patch extends snd_seq_oss_process_event() to give back the\nrefcount object, which is in turn released after calling the sequencer\ndispatcher with the given event in the caller side.\n\nAccording to the original report, KASAN report as below:\n\nKASAN slab-use-after-free in snd_seq_event_dup+0x40c/0x470\nRIP: 0033:0x7f2cb66a6340\nRead of size 6\nCall trace:\n  dump_stack_lvl+0x73/0xb0 (?:?)\n  print_report+0xd1/0x650 (?:?)\n  srso_alias_return_thunk+0x5/0xfbef5 (?:?)\n  __virt_addr_valid+0x1a7/0x340 (?:?)\n  kasan_complete_mode_report_info+0x64/0x200 (?:?)\n  kasan_report+0xf7/0x130 (?:?)\n  snd_seq_event_dup+0x40c/0x470 (?:?)\n  kasan_check_range+0x10c/0x1c0 (?:?)\n  __asan_memcpy+0x27/0x70 (?:?)\n  snd_seq_event_dup+0x9/0x470 (?:?)\n  snd_seq_client_enqueue_event+0x139/0x240 (?:?)\n  _raw_spin_unlock_irqrestore+0x4b/0x60 (?:?)\n  snd_seq_kernel_client_enqueue+0x102/0x120 (?:?)\n  snd_seq_oss_write+0x416/0x4e0 (?:?)\n  apparmor_file_permission+0x20/0x30 (?:?)\n  odev_write+0x3b/0x60 (?:?)\n  vfs_write+0x1ce/0x850 (?:?)\n  lock_release+0xc8/0x2a0 (?:?)\n  __kasan_check_write+0x18/0x20 (?:?)\n  __mutex_unlock_slowpath+0x129/0x510 (?:?)\n  ksys_write+0xe1/0x180 (?:?)\n  mutex_unlock+0x16/0x20 (?:?)\n  odev_ioctl+0x65/0xc0 (?:?)\n  __x64_sys_write+0x46/0x60 (?:?)\n  x64_sys_call+0x7d/0x20d0 (?:?)\n  do_syscall_64+0xc1/0x360 (arch/x86/entry/syscall_64.c:87)\n  entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)","Type":"Description","Title":"ALSA: seq: oss: Fix UAF at handling events with embedded SysEx d"}]}}}