| Message ID | 20230606121009.1942606-1-shaozhengchao@huawei.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [net] net/sched: taprio: fix slab-out-of-bounds Read in taprio_dequeue_from_txq | expand |
| Context | Check | Description |
|---|---|---|
| netdev/series_format | success | Single patches do not need cover letters |
| netdev/tree_selection | success | Clearly marked for net |
| netdev/fixes_present | success | Fixes tag present in non-next series |
| netdev/header_inline | success | No static functions without inline keyword in header files |
| netdev/build_32bit | success | Errors and warnings before: 8 this patch: 8 |
| netdev/cc_maintainers | success | CCed 10 of 10 maintainers |
| netdev/build_clang | success | Errors and warnings before: 8 this patch: 8 |
| netdev/verify_signedoff | success | Signed-off-by tag matches author and committer |
| netdev/deprecated_api | success | None detected |
| netdev/check_selftest | success | No net selftest shell script |
| netdev/verify_fixes | success | Fixes tag looks correct |
| netdev/build_allmodconfig_warn | success | Errors and warnings before: 8 this patch: 8 |
| netdev/checkpatch | warning | WARNING: line length of 93 exceeds 80 columns |
| netdev/kdoc | success | Errors and warnings before: 0 this patch: 0 |
| netdev/source_inline | success | Was 0 now: 0 |
On 06/06/2023 09:10, Zhengchao Shao wrote: > As shown in [1], when qdisc of the taprio type is set, count and offset in > tc_to_txq can be set to 0. In this case, the value of *txq in > taprio_next_tc_txq() will increases continuously. When the number of > accessed queues exceeds the number of queues on the device, out-of-bounds > access occurs. Now the restriction on the queue number is added. > > [1] https://groups.google.com/g/syzkaller-bugs/c/_lYOKgkBVMg > Fixes: 2f530df76c8c ("net/sched: taprio: give higher priority to higher TCs in software dequeue mode") > Reported-by: syzbot+04afcb3d2c840447559a@syzkaller.appspotmail.com > Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com> > --- > net/sched/sch_taprio.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c > index 3c4c2c334878..dccb64425852 100644 > --- a/net/sched/sch_taprio.c > +++ b/net/sched/sch_taprio.c > @@ -801,7 +801,7 @@ static struct sk_buff *taprio_dequeue_tc_priority(struct Qdisc *sch, > > if (skb) > return skb; > - } while (q->cur_txq[tc] != first_txq); > + } while (q->cur_txq[tc] != first_txq && q->cur_txq[tc] < dev->num_tx_queues); I'm not sure this is the correct fix. If q->cur_txg[tc] == dev->num_tx_queues the next call to taprio_dequeue_tc_priority() for the same tc index will have first_txq set to dev->num_tx_queues (no wrap around to first_txq happens). If count and offset are 0 it will increment q->cur_txg[tc] and then bail on the while condition but still growing unbounded (just slower than before). > } > taprio_dequeue_tc_priority > return NULL;
On 2023/6/6 23:10, Pedro Tammela wrote: > On 06/06/2023 09:10, Zhengchao Shao wrote: >> As shown in [1], when qdisc of the taprio type is set, count and >> offset in >> tc_to_txq can be set to 0. In this case, the value of *txq in >> taprio_next_tc_txq() will increases continuously. When the number of >> accessed queues exceeds the number of queues on the device, out-of-bounds >> access occurs. Now the restriction on the queue number is added. >> >> [1] https://groups.google.com/g/syzkaller-bugs/c/_lYOKgkBVMg >> Fixes: 2f530df76c8c ("net/sched: taprio: give higher priority to >> higher TCs in software dequeue mode") >> Reported-by: syzbot+04afcb3d2c840447559a@syzkaller.appspotmail.com >> Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com> >> --- >> net/sched/sch_taprio.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c >> index 3c4c2c334878..dccb64425852 100644 >> --- a/net/sched/sch_taprio.c >> +++ b/net/sched/sch_taprio.c >> @@ -801,7 +801,7 @@ static struct sk_buff >> *taprio_dequeue_tc_priority(struct Qdisc *sch, >> if (skb) >> return skb; >> - } while (q->cur_txq[tc] != first_txq); >> + } while (q->cur_txq[tc] != first_txq && q->cur_txq[tc] < >> dev->num_tx_queues); > Hi Pedro: Thank you for youe reply. > I'm not sure this is the correct fix. > If q->cur_txg[tc] == dev->num_tx_queues the next call to > taprio_dequeue_tc_priority() for the same tc index will have > first_txq set to dev->num_tx_queues (no wrap around to first_txq happens). yes, maybe the same problem will occur at the next dequeue skb. It can be changed to the following: taprio_next_tc_txq(dev, tc, &q->cur_txq[tc]); + if (q->cur_txq[tc] == dev->num_tx_queues) + q->cur_txq[tc] = first_txq; + if (skb) return skb; } while (q->cur_txq[tc] != first_txq); However, I prefer to limit the value of count in taprio_change(), so that I don't add extra judgment to the data path. Hi Vinicius, Do you have any better suggestions? > If count and offset are 0 it will increment q->cur_txg[tc] and then bail > on the while condition but still growing unbounded (just slower than > before). > >> } >> taprio_dequeue_tc_priority >> return NULL; > >
Hi vinicius,jamal: Based on this question, I'm also thinking about whether it's appropriate to set the tc parameter for dev in taprio_change. The taprio_change maybe will fail and .graft() will not be invoked to make qdisc take effect. However, the tc parameter of dev has been modified, which seems to be incorrect when dequeuing packets. I think the tc parameter of dev should be configured in .graft() so that the new qdisc and tc parameters of dev can take effect together. Thank you. Zhengchao Shao On 2023/6/7 9:15, shaozhengchao wrote: > > On 2023/6/6 23:10, Pedro Tammela wrote: >> On 06/06/2023 09:10, Zhengchao Shao wrote: >>> As shown in [1], when qdisc of the taprio type is set, count and >>> offset in >>> tc_to_txq can be set to 0. In this case, the value of *txq in >>> taprio_next_tc_txq() will increases continuously. When the number of >>> accessed queues exceeds the number of queues on the device, >>> out-of-bounds >>> access occurs. Now the restriction on the queue number is added. >>> >>> [1] https://groups.google.com/g/syzkaller-bugs/c/_lYOKgkBVMg >>> Fixes: 2f530df76c8c ("net/sched: taprio: give higher priority to >>> higher TCs in software dequeue mode") >>> Reported-by: syzbot+04afcb3d2c840447559a@syzkaller.appspotmail.com >>> Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com> >>> --- >>> net/sched/sch_taprio.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c >>> index 3c4c2c334878..dccb64425852 100644 >>> --- a/net/sched/sch_taprio.c >>> +++ b/net/sched/sch_taprio.c >>> @@ -801,7 +801,7 @@ static struct sk_buff >>> *taprio_dequeue_tc_priority(struct Qdisc *sch, >>> if (skb) >>> return skb; >>> - } while (q->cur_txq[tc] != first_txq); >>> + } while (q->cur_txq[tc] != first_txq && q->cur_txq[tc] < >>> dev->num_tx_queues); >> > Hi Pedro: > Thank you for youe reply. >> I'm not sure this is the correct fix. >> If q->cur_txg[tc] == dev->num_tx_queues the next call to >> taprio_dequeue_tc_priority() for the same tc index will have >> first_txq set to dev->num_tx_queues (no wrap around to first_txq >> happens). > yes, maybe the same problem will occur at the next dequeue skb. It can > be changed to the following: > taprio_next_tc_txq(dev, tc, &q->cur_txq[tc]); > > + if (q->cur_txq[tc] == dev->num_tx_queues) > + q->cur_txq[tc] = first_txq; > + > if (skb) > return skb; > } while (q->cur_txq[tc] != first_txq); > However, I prefer to limit the value of count in taprio_change(), so > that I don't add extra judgment to the data path. > > Hi Vinicius, > Do you have any better suggestions? >> If count and offset are 0 it will increment q->cur_txg[tc] and then >> bail on the while condition but still growing unbounded (just slower >> than before). >> >>> } >>> taprio_dequeue_tc_priority >>> return NULL; >> >>
shaozhengchao <shaozhengchao@huawei.com> writes: > On 2023/6/6 23:10, Pedro Tammela wrote: >> On 06/06/2023 09:10, Zhengchao Shao wrote: >>> As shown in [1], when qdisc of the taprio type is set, count and >>> offset in >>> tc_to_txq can be set to 0. In this case, the value of *txq in >>> taprio_next_tc_txq() will increases continuously. When the number of >>> accessed queues exceeds the number of queues on the device, out-of-bounds >>> access occurs. Now the restriction on the queue number is added. >>> >>> [1] https://groups.google.com/g/syzkaller-bugs/c/_lYOKgkBVMg >>> Fixes: 2f530df76c8c ("net/sched: taprio: give higher priority to >>> higher TCs in software dequeue mode") >>> Reported-by: syzbot+04afcb3d2c840447559a@syzkaller.appspotmail.com >>> Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com> >>> --- >>> net/sched/sch_taprio.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c >>> index 3c4c2c334878..dccb64425852 100644 >>> --- a/net/sched/sch_taprio.c >>> +++ b/net/sched/sch_taprio.c >>> @@ -801,7 +801,7 @@ static struct sk_buff >>> *taprio_dequeue_tc_priority(struct Qdisc *sch, >>> if (skb) >>> return skb; >>> - } while (q->cur_txq[tc] != first_txq); >>> + } while (q->cur_txq[tc] != first_txq && q->cur_txq[tc] < >>> dev->num_tx_queues); >> > Hi Pedro: > Thank you for youe reply. >> I'm not sure this is the correct fix. >> If q->cur_txg[tc] == dev->num_tx_queues the next call to >> taprio_dequeue_tc_priority() for the same tc index will have >> first_txq set to dev->num_tx_queues (no wrap around to first_txq happens). > yes, maybe the same problem will occur at the next dequeue skb. It can > be changed to the following: > taprio_next_tc_txq(dev, tc, &q->cur_txq[tc]); > > + if (q->cur_txq[tc] == dev->num_tx_queues) > + q->cur_txq[tc] = first_txq; > + > if (skb) > return skb; > } while (q->cur_txq[tc] != first_txq); > However, I prefer to limit the value of count in taprio_change(), so > that I don't add extra judgment to the data path. > > Hi Vinicius, > Do you have any better suggestions? From a very quick look at the syzkaller report, I couldn't come up with a config to trigger the issue. But reading your report, the problematic case is having a bunch of '0@0' in the "queues" map in the config, right? A '0@0' would mean, in my opinion, that the user wants that a specific TC to not have any queues associated with it, i.e. that it should be ignored. Either that, or a configuration error. Am I missing something? >> If count and offset are 0 it will increment q->cur_txg[tc] and then bail >> on the while condition but still growing unbounded (just slower than >> before). >> >>> } >>> taprio_dequeue_tc_priority >>> return NULL; >> >>
On 2023/6/8 3:05, Vinicius Costa Gomes wrote: > shaozhengchao <shaozhengchao@huawei.com> writes: > >> On 2023/6/6 23:10, Pedro Tammela wrote: >>> On 06/06/2023 09:10, Zhengchao Shao wrote: >>>> As shown in [1], when qdisc of the taprio type is set, count and >>>> offset in >>>> tc_to_txq can be set to 0. In this case, the value of *txq in >>>> taprio_next_tc_txq() will increases continuously. When the number of >>>> accessed queues exceeds the number of queues on the device, out-of-bounds >>>> access occurs. Now the restriction on the queue number is added. >>>> >>>> [1] https://groups.google.com/g/syzkaller-bugs/c/_lYOKgkBVMg >>>> Fixes: 2f530df76c8c ("net/sched: taprio: give higher priority to >>>> higher TCs in software dequeue mode") >>>> Reported-by: syzbot+04afcb3d2c840447559a@syzkaller.appspotmail.com >>>> Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com> >>>> --- >>>> net/sched/sch_taprio.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c >>>> index 3c4c2c334878..dccb64425852 100644 >>>> --- a/net/sched/sch_taprio.c >>>> +++ b/net/sched/sch_taprio.c >>>> @@ -801,7 +801,7 @@ static struct sk_buff >>>> *taprio_dequeue_tc_priority(struct Qdisc *sch, >>>> if (skb) >>>> return skb; >>>> - } while (q->cur_txq[tc] != first_txq); >>>> + } while (q->cur_txq[tc] != first_txq && q->cur_txq[tc] < >>>> dev->num_tx_queues); >>> >> Hi Pedro: >> Thank you for youe reply. >>> I'm not sure this is the correct fix. >>> If q->cur_txg[tc] == dev->num_tx_queues the next call to >>> taprio_dequeue_tc_priority() for the same tc index will have >>> first_txq set to dev->num_tx_queues (no wrap around to first_txq happens). >> yes, maybe the same problem will occur at the next dequeue skb. It can >> be changed to the following: >> taprio_next_tc_txq(dev, tc, &q->cur_txq[tc]); >> >> + if (q->cur_txq[tc] == dev->num_tx_queues) >> + q->cur_txq[tc] = first_txq; >> + >> if (skb) >> return skb; >> } while (q->cur_txq[tc] != first_txq); >> However, I prefer to limit the value of count in taprio_change(), so >> that I don't add extra judgment to the data path. >> >> Hi Vinicius, >> Do you have any better suggestions? > Hi Vinicius: Thank you for your reply. >>From a very quick look at the syzkaller report, I couldn't come up with > a config to trigger the issue. > > But reading your report, the problematic case is having a bunch of > '0@0' in the "queues" map in the config, right? > Yes, it is right. > A '0@0' would mean, in my opinion, that the user wants that a specific > TC to not have any queues associated with it, i.e. that it should be > ignored. Either that, or a configuration error. > After verification, when the qdisc of the taprio type is used to replace the previously configured taprio, the validity of count and offset is not verified because tc may have been configured on the dev device. Maybe the same issue to mqprio->num_tc? mqprio->num_tc will be set to large than TC_MAX_QUEUE, this also will trigger out-of-bounds access in taprio_change()? > Am I missing something? Zhengchao Shao >>> If count and offset are 0 it will increment q->cur_txg[tc] and then bail >>> on the while condition but still growing unbounded (just slower than >>> before). >>> >>>> } >>>> taprio_dequeue_tc_priority >>>> return NULL; >>> >>> >
diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c index 3c4c2c334878..dccb64425852 100644 --- a/net/sched/sch_taprio.c +++ b/net/sched/sch_taprio.c @@ -801,7 +801,7 @@ static struct sk_buff *taprio_dequeue_tc_priority(struct Qdisc *sch, if (skb) return skb; - } while (q->cur_txq[tc] != first_txq); + } while (q->cur_txq[tc] != first_txq && q->cur_txq[tc] < dev->num_tx_queues); } return NULL;
As shown in [1], when qdisc of the taprio type is set, count and offset in tc_to_txq can be set to 0. In this case, the value of *txq in taprio_next_tc_txq() will increases continuously. When the number of accessed queues exceeds the number of queues on the device, out-of-bounds access occurs. Now the restriction on the queue number is added. [1] https://groups.google.com/g/syzkaller-bugs/c/_lYOKgkBVMg Fixes: 2f530df76c8c ("net/sched: taprio: give higher priority to higher TCs in software dequeue mode") Reported-by: syzbot+04afcb3d2c840447559a@syzkaller.appspotmail.com Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com> --- net/sched/sch_taprio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)