CVE-2024-47706: block, bfq: fix possible UAF for bfqq->bic with merge chain

Published Oct 21, 2024
·
Updated

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

block, bfq: fix possible UAF for bfqq->bic with merge chain

1) initial state, three tasks:

Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) | Λ | Λ | Λ | | | | | | V | V | V | bfqq1 bfqq2 bfqq3 process ref: 1 1 1

2) bfqq1 merged to bfqq2:

Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) | | | Λ \--------------\| | | V V | bfqq1--------->bfqq2 bfqq3 process ref: 0 2 1

3) bfqq2 merged to bfqq3:

Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) here -> Λ | | \--------------\ \-------------\| V V bfqq1--------->bfqq2---------->bfqq3 process ref: 0 1 3

In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then get bfqq3 through merge chain, and finially handle IO by bfqq3. Howerver, current code will think bfqq2 is owned by BIC1, like initial state, and set bfqq2->bic to BIC1.

bfqinsertrequest -> by Process 1 bfqq = bfqinitrq(rq) bfqq = bfqgetbfqqhandlesplit bfqq = bictobfqq -> get bfqq2 from BIC1 bfqq->ref++ rq->elv.priv[0] = bic rq->elv.priv[1] = bfqq if (bfqqprocessrefs(bfqq) == 1) bfqq->bic = bic -> record BIC1 to bfqq2

bfqinsertrequest newbfqq = bfqsetupcooperator -> get bfqq3 from bfqq2->newbfqq bfqqrequestfreed(bfqq) newbfqq->ref++ rq->elv.priv[1] = newbfqq -> handle IO by bfqq3

Fix the problem by checking bfqq is from merge chain fist. And this might fix a following problem reported by our syzkaller(unreproducible):

================================================================== BUG: KASAN: slab-use-after-free in bfqdoearlystablemerge block/bfq-iosched.c:5692 [inline] BUG: KASAN: slab-use-after-free in bfqdoorschedstablemerge block/bfq-iosched.c:5805 [inline] BUG: KASAN: slab-use-after-free in bfqgetqueue+0x25b0/0x2610 block/bfq-iosched.c:5889 Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595

CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blkmqrequeuework Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x91/0xf0 lib/dumpstack.c:106 printaddressdescription mm/kasan/report.c:364 [inline] printreport+0x10d/0x610 mm/kasan/report.c:475 kasanreport+0x8e/0xc0 mm/kasan/report.c:588 bfqdoearlystablemerge block/bfq-iosched.c:5692 [inline] bfqdoorschedstablemerge block/bfq-iosched.c:5805 [inline] bfqgetqueue+0x25b0/0x2610 block/bfq-iosched.c:5889 bfqgetbfqqhandlesplit+0x169/0x5d0 block/bfq-iosched.c:6757 bfqinitrq block/bfq-iosched.c:6876 [inline] bfqinsertrequest block/bfq-iosched.c:6254 [inline] bfqinsertrequests+0x1112/0x5cf0 block/bfq-iosched.c:6304 blkmqinsertrequest+0x290/0x8d0 block/blk-mq.c:2593 blkmqrequeuework+0x6bc/0xa70 block/blk-mq.c:1502 processonework kernel/workqueue.c:2627 [inline] processscheduledworks+0x432/0x13f0 kernel/workqueue.c:2700 workerthread+0x6f2/0x1160 kernel/workqueue.c:2781 kthread+0x33c/0x440 kernel/kthread.c:388 retfromfork+0x4d/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1b/0x30 arch/x86/entry/entry64.S:305 </TASK>

Allocated by task 20776: kasansavestack+0x20/0x40 mm/kasan/common.c:45 kasansettrack+0x25/0x30 mm/kasan/common.c:52 kasanslaballoc+0x87/0x90 mm/kasan/common.c:328 kasanslaballoc include/linux/kasan.h:188 [inline] slabpostallochook mm/slab.h:763 [inline] slaballocnode mm/slub.c:3458 [inline] kmemcacheallocnode+0x1a4/0x6f0 mm/slub.c:3503 ioccreateicq block/blk-ioc.c:370 [inline] ---truncated---

Other sources

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

block, bfq: fix possible UAF for bfqq->bic with merge chain

1) initial state, three tasks:

Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) | Λ | Λ | Λ | | | | | | V | V | V | bfqq1 bfqq2 bfqq3 process ref: 1 1 1

2) bfqq1 merged to bfqq2:

Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) | | | Λ \--------------\| | | V V | bfqq1--------->bfqq2 bfqq3 process ref: 0 2 1

3) bfqq2 merged to bfqq3:

Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) here -> Λ | | \--------------\ \-------------\| V V bfqq1--------->bfqq2---------->bfqq3 process ref: 0 1 3

In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then get bfqq3 through merge chain, and finially handle IO by bfqq3. Howerver, current code will think bfqq2 is owned by BIC1, like initial state, and set bfqq2->bic to BIC1.

bfqinsertrequest -> by Process 1 bfqq = bfqinitrq(rq) bfqq = bfqgetbfqqhandlesplit bfqq = bictobfqq -> get bfqq2 from BIC1 bfqq->ref++ rq->elv.priv[0] = bic rq->elv.priv[1] = bfqq if (bfqqprocessrefs(bfqq) == 1) bfqq->bic = bic -> record BIC1 to bfqq2

bfqinsertrequest newbfqq = bfqsetupcooperator -> get bfqq3 from bfqq2->newbfqq bfqqrequestfreed(bfqq) newbfqq->ref++ rq->elv.priv[1] = newbfqq -> handle IO by bfqq3

Fix the problem by checking bfqq is from merge chain fist. And this might fix a following problem reported by our syzkaller(unreproducible):

================================================================== BUG: KASAN: slab-use-after-free in bfqdoearlystablemerge block/bfq-iosched.c:5692 [inline] BUG: KASAN: slab-use-after-free in bfqdoorschedstablemerge block/bfq-iosched.c:5805 [inline] BUG: KASAN: slab-use-after-free in bfqgetqueue+0x25b0/0x2610 block/bfq-iosched.c:5889 Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595

CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blkmqrequeuework Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x91/0xf0 lib/dumpstack.c:106 printaddressdescription mm/kasan/report.c:364 [inline] printreport+0x10d/0x610 mm/kasan/report.c:475 kasanreport+0x8e/0xc0 mm/kasan/report.c:588 bfqdoearlystablemerge block/bfq-iosched.c:5692 [inline] bfqdoorschedstablemerge block/bfq-iosched.c:5805 [inline] bfqgetqueue+0x25b0/0x2610 block/bfq-iosched.c:5889 bfqgetbfqqhandlesplit+0x169/0x5d0 block/bfq-iosched.c:6757 bfqinitrq block/bfq-iosched.c:6876 [inline] bfqinsertrequest block/bfq-iosched.c:6254 [inline] bfqinsertrequests+0x1112/0x5cf0 block/bfq-iosched.c:6304 blkmqinsertrequest+0x290/0x8d0 block/blk-mq.c:2593 blkmqrequeuework+0x6bc/0xa70 block/blk-mq.c:1502 processonework kernel/workqueue.c:2627 [inline] processscheduledworks+0x432/0x13f0 kernel/workqueue.c:2700 workerthread+0x6f2/0x1160 kernel/workqueue.c:2781 kthread+0x33c/0x440 kernel/kthread.c:388 retfromfork+0x4d/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1b/0x30 arch/x86/entry/entry64.S:305 </TASK>

Allocated by task 20776: kasansavestack+0x20/0x40 mm/kasan/common.c:45 kasansettrack+0x25/0x30 mm/kasan/common.c:52 kasanslaballoc+0x87/0x90 mm/kasan/common.c:328 kasanslaballoc include/linux/kasan.h:188 [inline] slabpostallochook mm/slab.h:763 [inline] slaballocnode mm/slub.c:3458 [inline] kmemcacheallocnode+0x1a4/0x6f0 mm/slub.c:3503 ioccreateicq block/blk-ioc.c:370 [inline] ---truncated---

NVD

This CVE was automatically created from a reference found in an email or other text. If you are reading this, then this CVE entry is probably erroneous, since this text should be replaced by the official CVE description automatically.

Launchpad

Affected Software

8 affected componentsFixes available
Linux Linux kernel>=4.12<5.10.227
Linux Linux kernel>=5.11<5.15.168
Linux Linux kernel>=5.16<6.1.113
Linux Linux kernel>=6.2<6.6.54
Linux Linux kernel>=6.7<6.10.13
Linux Linux kernel>=6.11<6.11.2
debian/linux<=5.10.223-1
5.10.234-16.1.129-16.1.135-16.12.25-16.12.27-1
debian/linux-6.1
6.1.129-1~deb11u1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade debian/linux to a version that resolves this vulnerability.

    Fixed in 5.10.234-1Fixed in 6.1.129-1Fixed in 6.1.135-1Fixed in 6.12.25-1Fixed in 6.12.27-1
  2. Upgrade

    Upgrade debian/linux-6.1 to a version that resolves this vulnerability.

    Fixed in 6.1.129-1~deb11u1
  3. Configuration

    Apply the upstream fix described in: "block, bfq: fix possible UAF for bfqq->bic with merge chain" / "Fix the problem by checking bfqq is from merge chain fist." Ensure the code does not incorrectly treat bfqq2 as owned by BIC1 after bfqq2 has been merged into bfqq3; update the bfq logic in bfq_get_queue path so bfqq->bic is set only when bfqq originates from the proper merge chain.

    Linux kernel BFQ (block/bfq-iosched.c) bfqq->bic assignment during merge-chain handling = Check that bfqq is from the merge chain first; only set bfqq->bic based on the correct merge-chain owner (avoid setting bfqq2->bic to BIC1 in the merge-chain scenario).

Event History

Oct 21, 2024
CVE Published
via MITRE·11:53 AM
Data Sourced
via MITRE·11:53 AM
DescriptionSeverity
Data Sourced
via NVD·12:15 PM
RemedyDescriptionSeverityWeaknessAffected Software
Data Sourced
via Red Hat·01:04 PM
DescriptionSeverityAffected Software
Feb 12, 2025
Data Sourced
via Launchpad·05:14 AM
Description
May 3, 2025
Data Sourced
via Ubuntu·06:25 AM
RemedyDescriptionSeverityAffected Software
Jan 6, 58561
Event
via MITRE·11:28 AM
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2024-47706?

CVE-2024-47706 is classified as a medium severity vulnerability in the Linux kernel.

2

Which versions of the Linux kernel are affected by CVE-2024-47706?

CVE-2024-47706 affects Linux kernel versions from 4.12 to 6.6.54, including several specific version ranges.

3

How do I fix CVE-2024-47706?

To fix CVE-2024-47706, update your Linux kernel to a version that is not affected, such as 6.1.123-1 or later.

4

What type of vulnerability is CVE-2024-47706?

CVE-2024-47706 is a use-after-free (UAF) vulnerability that affects the block layer in the Linux kernel.

5

Is there a workaround for CVE-2024-47706?

Currently, there are no specific workarounds for CVE-2024-47706 other than applying the necessary kernel updates.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203