A possible divide by zero bug in blk_mq_map_queues

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



In block/blk-mq-cpumap.c, blk_mq_map_queues has the following code:

int blk_mq_map_queues(struct blk_mq_queue_map *qmap) {
    ...
    unsigned int nr_queues = qmap->nr_queues;
    unsigned q = 0;
    ...
    for_each_present_cpu(cpu) {
        if (q >= nr_queues)
            break;
        ...
    }

    for_each_possible_cpu(cpu) {
        ...
        if (q < nr_queues) {
            map[cpu] = queue_index(qmap, nr_queues, q++);
        } else {
           ...
            if (first_sibling == cpu)
                map[cpu] = queue_index(qmap, nr_queues, q++);

        }
    }
}

if qmap->nr_queues equals to zero when entering the function, then by
passing zero to function queue_index we have a divide by zero bug:

static int queue_index(struct blk_mq_queue_map *qmap,
               unsigned int nr_queues, const int q)
{
    return qmap->queue_offset + (q % nr_queues);
}

It seems possible to me that qmap->nr_queues may equal zero because
this field is explicitly checked in other functions.

For example, in the function blk_mq_map_swqueue (block/blk-mq.c),
there is a check comparing nr_queues with 0:

for (j = 0; j < set->nr_maps; j++) {
            if (!set->map[j].nr_queues) {
                ...
                continue;
            }
            ...
}



[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux