fkie_cve-2023-53469
Vulnerability from fkie_nvd
Published
2025-10-01 12:15
Modified
2025-10-10 16:15
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix null-ptr-deref in unix_stream_sendpage(). Bing-Jhong Billy Jheng reported null-ptr-deref in unix_stream_sendpage() with detailed analysis and a nice repro. unix_stream_sendpage() tries to add data to the last skb in the peer's recv queue without locking the queue. If the peer's FD is passed to another socket and the socket's FD is passed to the peer, there is a loop between them. If we close both sockets without receiving FD, the sockets will be cleaned up by garbage collection. The garbage collection iterates such sockets and unlinks skb with FD from the socket's receive queue under the queue's lock. So, there is a race where unix_stream_sendpage() could access an skb locklessly that is being released by garbage collection, resulting in use-after-free. To avoid the issue, unix_stream_sendpage() must lock the peer's recv queue. Note the issue does not exist in 6.5+ thanks to the recent sendpage() refactoring. This patch is originally written by Linus Torvalds. BUG: unable to handle page fault for address: ffff988004dd6870 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present page PGD 0 P4D 0 PREEMPT SMP PTI CPU: 4 PID: 297 Comm: garbage_uaf Not tainted 6.1.46 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:kmem_cache_alloc_node+0xa2/0x1e0 Code: c0 0f 84 32 01 00 00 41 83 fd ff 74 10 48 8b 00 48 c1 e8 3a 41 39 c5 0f 85 1c 01 00 00 41 8b 44 24 28 49 8b 3c 24 48 8d 4a 40 <49> 8b 1c 06 4c 89 f0 65 48 0f c7 0f 0f 94 c0 84 c0 74 a1 41 8b 44 RSP: 0018:ffffc9000079fac0 EFLAGS: 00000246 RAX: 0000000000000070 RBX: 0000000000000005 RCX: 000000000001a284 RDX: 000000000001a244 RSI: 0000000000400cc0 RDI: 000000000002eee0 RBP: 0000000000400cc0 R08: 0000000000400cc0 R09: 0000000000000003 R10: 0000000000000001 R11: 0000000000000000 R12: ffff888003970f00 R13: 00000000ffffffff R14: ffff988004dd6800 R15: 00000000000000e8 FS: 00007f174d6f3600(0000) GS:ffff88807db00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff988004dd6870 CR3: 00000000092be000 CR4: 00000000007506e0 PKRU: 55555554 Call Trace: <TASK> ? __die_body.cold+0x1a/0x1f ? page_fault_oops+0xa9/0x1e0 ? fixup_exception+0x1d/0x310 ? exc_page_fault+0xa8/0x150 ? asm_exc_page_fault+0x22/0x30 ? kmem_cache_alloc_node+0xa2/0x1e0 ? __alloc_skb+0x16c/0x1e0 __alloc_skb+0x16c/0x1e0 alloc_skb_with_frags+0x48/0x1e0 sock_alloc_send_pskb+0x234/0x270 unix_stream_sendmsg+0x1f5/0x690 sock_sendmsg+0x5d/0x60 ____sys_sendmsg+0x210/0x260 ___sys_sendmsg+0x83/0xd0 ? kmem_cache_alloc+0xc6/0x1c0 ? avc_disable+0x20/0x20 ? percpu_counter_add_batch+0x53/0xc0 ? alloc_empty_file+0x5d/0xb0 ? alloc_file+0x91/0x170 ? alloc_file_pseudo+0x94/0x100 ? __fget_light+0x9f/0x120 __sys_sendmsg+0x54/0xa0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x69/0xd3 RIP: 0033:0x7f174d639a7d Code: 28 89 54 24 1c 48 89 74 24 10 89 7c 24 08 e8 8a c1 f4 ff 8b 54 24 1c 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 33 44 89 c7 48 89 44 24 08 e8 de c1 f4 ff 48 RSP: 002b:00007ffcb563ea50 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f174d639a7d RDX: 0000000000000000 RSI: 00007ffcb563eab0 RDI: 0000000000000007 RBP: 00007ffcb563eb10 R08: 0000000000000000 R09: 00000000ffffffff R10: 00000000004040a0 R11: 0000000000000293 R12: 00007ffcb563ec28 R13: 0000000000401398 R14: 0000000000403e00 R15: 00007f174d72c000 </TASK>
Impacted products
Vendor Product Version



{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\naf_unix: Fix null-ptr-deref in unix_stream_sendpage().\n\nBing-Jhong Billy Jheng reported null-ptr-deref in unix_stream_sendpage()\nwith detailed analysis and a nice repro.\n\nunix_stream_sendpage() tries to add data to the last skb in the peer\u0027s\nrecv queue without locking the queue.\n\nIf the peer\u0027s FD is passed to another socket and the socket\u0027s FD is\npassed to the peer, there is a loop between them.  If we close both\nsockets without receiving FD, the sockets will be cleaned up by garbage\ncollection.\n\nThe garbage collection iterates such sockets and unlinks skb with\nFD from the socket\u0027s receive queue under the queue\u0027s lock.\n\nSo, there is a race where unix_stream_sendpage() could access an skb\nlocklessly that is being released by garbage collection, resulting in\nuse-after-free.\n\nTo avoid the issue, unix_stream_sendpage() must lock the peer\u0027s recv\nqueue.\n\nNote the issue does not exist in 6.5+ thanks to the recent sendpage()\nrefactoring.\n\nThis patch is originally written by Linus Torvalds.\n\nBUG: unable to handle page fault for address: ffff988004dd6870\nPF: supervisor read access in kernel mode\nPF: error_code(0x0000) - not-present page\nPGD 0 P4D 0\nPREEMPT SMP PTI\nCPU: 4 PID: 297 Comm: garbage_uaf Not tainted 6.1.46 #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nRIP: 0010:kmem_cache_alloc_node+0xa2/0x1e0\nCode: c0 0f 84 32 01 00 00 41 83 fd ff 74 10 48 8b 00 48 c1 e8 3a 41 39 c5 0f 85 1c 01 00 00 41 8b 44 24 28 49 8b 3c 24 48 8d 4a 40 \u003c49\u003e 8b 1c 06 4c 89 f0 65 48 0f c7 0f 0f 94 c0 84 c0 74 a1 41 8b 44\nRSP: 0018:ffffc9000079fac0 EFLAGS: 00000246\nRAX: 0000000000000070 RBX: 0000000000000005 RCX: 000000000001a284\nRDX: 000000000001a244 RSI: 0000000000400cc0 RDI: 000000000002eee0\nRBP: 0000000000400cc0 R08: 0000000000400cc0 R09: 0000000000000003\nR10: 0000000000000001 R11: 0000000000000000 R12: ffff888003970f00\nR13: 00000000ffffffff R14: ffff988004dd6800 R15: 00000000000000e8\nFS:  00007f174d6f3600(0000) GS:ffff88807db00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffff988004dd6870 CR3: 00000000092be000 CR4: 00000000007506e0\nPKRU: 55555554\nCall Trace:\n \u003cTASK\u003e\n ? __die_body.cold+0x1a/0x1f\n ? page_fault_oops+0xa9/0x1e0\n ? fixup_exception+0x1d/0x310\n ? exc_page_fault+0xa8/0x150\n ? asm_exc_page_fault+0x22/0x30\n ? kmem_cache_alloc_node+0xa2/0x1e0\n ? __alloc_skb+0x16c/0x1e0\n __alloc_skb+0x16c/0x1e0\n alloc_skb_with_frags+0x48/0x1e0\n sock_alloc_send_pskb+0x234/0x270\n unix_stream_sendmsg+0x1f5/0x690\n sock_sendmsg+0x5d/0x60\n ____sys_sendmsg+0x210/0x260\n ___sys_sendmsg+0x83/0xd0\n ? kmem_cache_alloc+0xc6/0x1c0\n ? avc_disable+0x20/0x20\n ? percpu_counter_add_batch+0x53/0xc0\n ? alloc_empty_file+0x5d/0xb0\n ? alloc_file+0x91/0x170\n ? alloc_file_pseudo+0x94/0x100\n ? __fget_light+0x9f/0x120\n __sys_sendmsg+0x54/0xa0\n do_syscall_64+0x3b/0x90\n entry_SYSCALL_64_after_hwframe+0x69/0xd3\nRIP: 0033:0x7f174d639a7d\nCode: 28 89 54 24 1c 48 89 74 24 10 89 7c 24 08 e8 8a c1 f4 ff 8b 54 24 1c 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 2e 00 00 00 0f 05 \u003c48\u003e 3d 00 f0 ff ff 77 33 44 89 c7 48 89 44 24 08 e8 de c1 f4 ff 48\nRSP: 002b:00007ffcb563ea50 EFLAGS: 00000293 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f174d639a7d\nRDX: 0000000000000000 RSI: 00007ffcb563eab0 RDI: 0000000000000007\nRBP: 00007ffcb563eb10 R08: 0000000000000000 R09: 00000000ffffffff\nR10: 00000000004040a0 R11: 0000000000000293 R12: 00007ffcb563ec28\nR13: 0000000000401398 R14: 0000000000403e00 R15: 00007f174d72c000\n \u003c/TASK\u003e"
    }
  ],
  "id": "CVE-2023-53469",
  "lastModified": "2025-10-10T16:15:50.517",
  "metrics": {},
  "published": "2025-10-01T12:15:48.973",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/2dde18cd1d8fac735875f2e4987f11817cc0bc2c"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/4a3fcfc3b51796e5e6974041c9a7cf7808d16f9e"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


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.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • 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.


Loading…

Loading…