omapdss: Division by zero in kernel

DISCUSSION Pali Rohár 4 participants 11 messages Jul 24, 2015 – Sep 25, 2015 Framebuffer layer

lore

Share & tools

lore

Pali Rohár

author

2015-07-24 16:03 UTC #0 lore raw

Hello,

when on N900 (real HW or qemu) I run this command

/ # echo 0 > /sys/devices/platform/omapdss/overlay0/enabled && echo 0 > /sys/class/graphics/fb0/size

then kernel crash with this error message

/ # [ 29.904113] Division by zero in kernel.
** 3375 printk messages dropped ** [ 29.963836] [<c01e0008>] (__aeabi_uidivmod) from [<c022071c>]
(cfb_imageblit+0xac/0x464)
** 8426 printk messages dropped ** [ 30.111083] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 8380 printk messages dropped ** [ 30.258209] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 7813 printk messages dropped ** [ 30.400054] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 7666 printk messages dropped ** [ 30.538391] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 7687 printk messages dropped ** [ 30.676544] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 7960 printk messages dropped ** [ 30.819915] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 8317 printk messages dropped ** [ 30.966979] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 8590 printk messages dropped ** [ 31.122528] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 8885 printk messages dropped ** [ 31.287658] [<c0218ed0>] (fbcon_scroll) from [<c025af90>] (scrup+0x60/0x128)
** 9408 printk messages dropped ** [ 31.461425] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 9787 printk messages dropped ** [ 31.644287] [<c02187e8>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10081 printk messages dropped ** [ 31.833984] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10501 printk messages dropped ** [ 32.031066] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10816 printk messages dropped ** [ 32.233001] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10900 printk messages dropped ** [ 32.440490] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10837 printk messages dropped ** [ 32.645233] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10837 printk messages dropped ** [ 32.848999] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10837 printk messages dropped ** [ 33.053833] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10838 printk messages dropped ** [ 33.258361] [<c0218ed0>] (fbcon_scroll) from [<c025af90>] (scrup+0x60/0x128)

I suspect that problem is in omapdss.

I do not know if size 0 make sense, but Maemo userspace is calling above commands and on Nokia's 2.6.28 kernel there is no crash or error message.

IMHO Division by zero in kernel should not be there even if userspace call "incorrect" command.

Signature · 2 lines

Pali Rohár
[email protected]

Pali Rohár

author

2015-07-28 11:56 UTC #1 lore raw

Quoted 48 lines · On Friday 24 July 2015 18:03:42 Pali Rohár wrote:

Hello,
when on N900 (real HW or qemu) I run this command
/ # echo 0 > /sys/devices/platform/omapdss/overlay0/enabled && echo 0 > /sys/class/graphics/fb0/size
then kernel crash with this error message
/ # [ 29.904113] Division by zero in kernel.
** 3375 printk messages dropped ** [ 29.963836] [<c01e0008>] (__aeabi_uidivmod) from [<c022071c>]
(cfb_imageblit+0xac/0x464)
** 8426 printk messages dropped ** [ 30.111083] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 8380 printk messages dropped ** [ 30.258209] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 7813 printk messages dropped ** [ 30.400054] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 7666 printk messages dropped ** [ 30.538391] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 7687 printk messages dropped ** [ 30.676544] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 7960 printk messages dropped ** [ 30.819915] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 8317 printk messages dropped ** [ 30.966979] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 8590 printk messages dropped ** [ 31.122528] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 8885 printk messages dropped ** [ 31.287658] [<c0218ed0>] (fbcon_scroll) from [<c025af90>] (scrup+0x60/0x128)
** 9408 printk messages dropped ** [ 31.461425] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 9787 printk messages dropped ** [ 31.644287] [<c02187e8>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10081 printk messages dropped ** [ 31.833984] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10501 printk messages dropped ** [ 32.031066] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10816 printk messages dropped ** [ 32.233001] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10900 printk messages dropped ** [ 32.440490] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10837 printk messages dropped ** [ 32.645233] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10837 printk messages dropped ** [ 32.848999] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10837 printk messages dropped ** [ 33.053833] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10838 printk messages dropped ** [ 33.258361] [<c0218ed0>] (fbcon_scroll) from [<c025af90>] (scrup+0x60/0x128)

Quoted 8 lines

I suspect that problem is in omapdss.
I do not know if size 0 make sense, but Maemo userspace is calling above commands and on Nokia's 2.6.28 kernel there is no crash or error message.
IMHO Division by zero in kernel should not be there even if userspace call "incorrect" command.

PING! Any idea what to do with Division by zero in kernel?

Signature · 2 lines

Pali Rohár
[email protected]

Pali Rohár

author

2015-08-18 14:00 UTC #2 lore raw

Quoted 51 lines · On Tuesday 28 July 2015 13:56:02 Pali Rohár wrote:

Quoted 50 lines · On Friday 24 July 2015 18:03:42 Pali Rohár wrote:
Hello,
when on N900 (real HW or qemu) I run this command
/ # echo 0 > /sys/devices/platform/omapdss/overlay0/enabled && echo 0 > /sys/class/graphics/fb0/size
then kernel crash with this error message
/ # [ 29.904113] Division by zero in kernel.
** 3375 printk messages dropped ** [ 29.963836] [<c01e0008>] (__aeabi_uidivmod) from [<c022071c>]
(cfb_imageblit+0xac/0x464)
** 8426 printk messages dropped ** [ 30.111083] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 8380 printk messages dropped ** [ 30.258209] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 7813 printk messages dropped ** [ 30.400054] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 7666 printk messages dropped ** [ 30.538391] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 7687 printk messages dropped ** [ 30.676544] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 7960 printk messages dropped ** [ 30.819915] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 8317 printk messages dropped ** [ 30.966979] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 8590 printk messages dropped ** [ 31.122528] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 8885 printk messages dropped ** [ 31.287658] [<c0218ed0>] (fbcon_scroll) from [<c025af90>] (scrup+0x60/0x128)
** 9408 printk messages dropped ** [ 31.461425] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 9787 printk messages dropped ** [ 31.644287] [<c02187e8>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10081 printk messages dropped ** [ 31.833984] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10501 printk messages dropped ** [ 32.031066] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10816 printk messages dropped ** [ 32.233001] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10900 printk messages dropped ** [ 32.440490] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10837 printk messages dropped ** [ 32.645233] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10837 printk messages dropped ** [ 32.848999] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10837 printk messages dropped ** [ 33.053833] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10838 printk messages dropped ** [ 33.258361] [<c0218ed0>] (fbcon_scroll) from [<c025af90>] (scrup+0x60/0x128)
I suspect that problem is in omapdss.

Quoted 9 lines

Quoted 6 lines
I do not know if size 0 make sense, but Maemo userspace is calling above commands and on Nokia's 2.6.28 kernel there is no crash or error message.
IMHO Division by zero in kernel should not be there even if userspace call "incorrect" command.
PING! Any idea what to do with Division by zero in kernel?

PING again! Can somebody look at this Division by zero in kernel?

Signature · 2 lines

Pali Rohár
[email protected]

Peter Teoh

2015-08-18 14:11 UTC #3 lore raw

In reply to Pali Rohár

Quoted 54 lines · Pali Rohár

Hello,
when on N900 (real HW or qemu) I run this command
/ # echo 0 > /sys/devices/platform/omapdss/overlay0/enabled && echo 0 > /sys/class/graphics/fb0/size
then kernel crash with this error message
/ # [ 29.904113] Division by zero in kernel.
** 3375 printk messages dropped ** [ 29.963836] [<c01e0008>] (__aeabi_uidivmod) from [<c022071c>]
(cfb_imageblit+0xac/0x464)
** 8426 printk messages dropped ** [ 30.111083] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 8380 printk messages dropped ** [ 30.258209] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 7813 printk messages dropped ** [ 30.400054] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 7666 printk messages dropped ** [ 30.538391] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 7687 printk messages dropped ** [ 30.676544] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 7960 printk messages dropped ** [ 30.819915] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 8317 printk messages dropped ** [ 30.966979] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 8590 printk messages dropped ** [ 31.122528] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 8885 printk messages dropped ** [ 31.287658] [<c0218ed0>] (fbcon_scroll) from [<c025af90>] (scrup+0x60/0x128)
** 9408 printk messages dropped ** [ 31.461425] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 9787 printk messages dropped ** [ 31.644287] [<c02187e8>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10081 printk messages dropped ** [ 31.833984] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10501 printk messages dropped ** [ 32.031066] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10816 printk messages dropped ** [ 32.233001] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10900 printk messages dropped ** [ 32.440490] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10837 printk messages dropped ** [ 32.645233] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10837 printk messages dropped ** [ 32.848999] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10837 printk messages dropped ** [ 33.053833] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10838 printk messages dropped ** [ 33.258361] [<c0218ed0>] (fbcon_scroll) from [<c025af90>] (scrup+0x60/0x128)
I suspect that problem is in omapdss.
I do not know if size 0 make sense, but Maemo userspace is calling above commands and on Nokia's 2.6.28 kernel there is no crash or error message.

Quoted 6 lines

IMHO Division by zero in kernel should not be there even if userspace call "incorrect" command.
--
Pali Rohár
[email protected]

Not sure if my analysis is correct. According to the recent pull
(4.2.0-rc4+), the code is still vulnerable to this division by zero:

Inside drivers/video/fbdev/core/cfbimgblt.c:

void cfb_imageblit(struct fb_info *p, const struct fb_image *image)

{
        u32 fgcolor, bgcolor, start_index, bitstart, pitch_index = 0;
        u32 bpl = sizeof(u32), bpp = p->var.bits_per_pixel;
        u32 width = image->width;
        u32 dx = image->dx, dy = image->dy;
        u8 __iomem *dst1;

        if (p->state != FBINFO_STATE_RUNNING)
                return;

        bitstart = (dy * p->fix.line_length * 8) + (dx * bpp);
        start_index = bitstart & (32 - 1);
        pitch_index = (p->fix.line_length & (bpl - 1)) * 8;

        bitstart /= 8;
        bitstart &= ~(bpl - 1);
        dst1 = p->screen_base + bitstart;

        if (p->fbops->fb_sync)
                p->fbops->fb_sync(p);

        if (image->depth = 1) {
                if (p->fix.visual = FB_VISUAL_TRUECOLOR ||
                    p->fix.visual = FB_VISUAL_DIRECTCOLOR) {
                        fgcolor = ((u32*)(p->pseudo_palette))[image->fg_color];
                        bgcolor = ((u32*)(p->pseudo_palette))[image->bg_color];
                } else {
                        fgcolor = image->fg_color;
                        bgcolor = image->bg_color;
                }

                if (32 % bpp = 0 && !start_index && !pitch_index &&
                    ((width & (32/bpp-1)) = 0) &&
                    bpp >= 8 && bpp <= 32)
                        fast_imageblit(image, p, dst1, fgcolor, bgcolor);
                else
                        slow_imageblit(image, p, dst1, fgcolor, bgcolor,
                                        start_index, pitch_index);
        } else
                color_imageblit(image, p, dst1, start_index, pitch_i

Notice that bpp is not checked for zero, and thus bpp=0 is totally
feasible? resulting in 32/bpp crashing the kernel?

Signature · 2 lines

Regards,
Peter Teoh

Pali Rohár

author

2015-08-19 08:11 UTC #4 lore raw

Quoted 112 lines · On Tuesday 18 August 2015 07:11:27 Peter Teoh wrote:

Quoted 54 lines · Pali Rohár
Hello,
when on N900 (real HW or qemu) I run this command
/ # echo 0 > /sys/devices/platform/omapdss/overlay0/enabled && echo 0 > /sys/class/graphics/fb0/size
then kernel crash with this error message
/ # [ 29.904113] Division by zero in kernel.
** 3375 printk messages dropped ** [ 29.963836] [<c01e0008>] (__aeabi_uidivmod) from [<c022071c>]
(cfb_imageblit+0xac/0x464)
** 8426 printk messages dropped ** [ 30.111083] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 8380 printk messages dropped ** [ 30.258209] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 7813 printk messages dropped ** [ 30.400054] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 7666 printk messages dropped ** [ 30.538391] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 7687 printk messages dropped ** [ 30.676544] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 7960 printk messages dropped ** [ 30.819915] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 8317 printk messages dropped ** [ 30.966979] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 8590 printk messages dropped ** [ 31.122528] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 8885 printk messages dropped ** [ 31.287658] [<c0218ed0>] (fbcon_scroll) from [<c025af90>] (scrup+0x60/0x128)
** 9408 printk messages dropped ** [ 31.461425] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 9787 printk messages dropped ** [ 31.644287] [<c02187e8>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10081 printk messages dropped ** [ 31.833984] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10501 printk messages dropped ** [ 32.031066] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10816 printk messages dropped ** [ 32.233001] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10900 printk messages dropped ** [ 32.440490] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10837 printk messages dropped ** [ 32.645233] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10837 printk messages dropped ** [ 32.848999] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10837 printk messages dropped ** [ 33.053833] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10838 printk messages dropped ** [ 33.258361] [<c0218ed0>] (fbcon_scroll) from [<c025af90>] (scrup+0x60/0x128)
I suspect that problem is in omapdss.
I do not know if size 0 make sense, but Maemo userspace is calling above commands and on Nokia's 2.6.28 kernel there is no crash or error message.
Quoted 6 lines
IMHO Division by zero in kernel should not be there even if userspace call "incorrect" command.
--
Pali Rohár
[email protected]
Not sure if my analysis is correct. According to the recent pull
(4.2.0-rc4+), the code is still vulnerable to this division by zero:
Inside drivers/video/fbdev/core/cfbimgblt.c:
void cfb_imageblit(struct fb_info *p, const struct fb_image *image)
{
        u32 fgcolor, bgcolor, start_index, bitstart, pitch_index = 0;
        u32 bpl = sizeof(u32), bpp = p->var.bits_per_pixel;
        u32 width = image->width;
        u32 dx = image->dx, dy = image->dy;
        u8 __iomem *dst1;

        if (p->state != FBINFO_STATE_RUNNING)
                return;

        bitstart = (dy * p->fix.line_length * 8) + (dx * bpp);
        start_index = bitstart & (32 - 1);
        pitch_index = (p->fix.line_length & (bpl - 1)) * 8;

        bitstart /= 8;
        bitstart &= ~(bpl - 1);
        dst1 = p->screen_base + bitstart;

        if (p->fbops->fb_sync)
                p->fbops->fb_sync(p);

        if (image->depth = 1) {
                if (p->fix.visual = FB_VISUAL_TRUECOLOR ||
                    p->fix.visual = FB_VISUAL_DIRECTCOLOR) {
                        fgcolor = ((u32*)(p->pseudo_palette))[image->fg_color];
                        bgcolor = ((u32*)(p->pseudo_palette))[image->bg_color];
                } else {
                        fgcolor = image->fg_color;
                        bgcolor = image->bg_color;
                }

                if (32 % bpp = 0 && !start_index && !pitch_index &&
                    ((width & (32/bpp-1)) = 0) &&
                    bpp >= 8 && bpp <= 32)
                        fast_imageblit(image, p, dst1, fgcolor, bgcolor);
                else
                        slow_imageblit(image, p, dst1, fgcolor, bgcolor,
                                        start_index, pitch_index);
        } else
                color_imageblit(image, p, dst1, start_index, pitch_i

Quoted 3 lines

Notice that bpp is not checked for zero, and thus bpp=0 is totally
feasible? resulting in 32/bpp crashing the kernel?

Hm... this could really be a problem! But how to patch it? Which branch should be called (fast_ or slow_ function) if bpp is zero?

And is there some way to force kernel to dump backtrace into dmesg when division by zero occur?

Signature · 2 lines

Pali Rohár
[email protected]

Pavel Machek

2015-09-17 05:16 UTC #5 lore raw

Quoted 26 lines

Quoted 22 lines

        if (image->depth = 1) {
                if (p->fix.visual = FB_VISUAL_TRUECOLOR ||
                    p->fix.visual = FB_VISUAL_DIRECTCOLOR) {
                        fgcolor = ((u32*)(p->pseudo_palette))[image->fg_color];
                        bgcolor = ((u32*)(p->pseudo_palette))[image->bg_color];
                } else {
                        fgcolor = image->fg_color;
                        bgcolor = image->bg_color;
                }

                if (32 % bpp = 0 && !start_index && !pitch_index &&
                    ((width & (32/bpp-1)) = 0) &&
                    bpp >= 8 && bpp <= 32)
                        fast_imageblit(image, p, dst1, fgcolor, bgcolor);
                else
                        slow_imageblit(image, p, dst1, fgcolor, bgcolor,
                                        start_index, pitch_index);
        } else
                color_imageblit(image, p, dst1, start_index, pitch_i

Quoted 3 lines

Notice that bpp is not checked for zero, and thus bpp=0 is totally
feasible? resulting in 32/bpp crashing the kernel?

Quoted 5 lines

Hm... this could really be a problem! But how to patch it? Which branch should be called (fast_ or slow_ function) if bpp is zero?
And is there some way to force kernel to dump backtrace into dmesg when division by zero occur?

You can do WARN_ON(bpp=1) ... and should probably return in that case.

Pavel

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Pali Rohár

author

2015-09-25 11:34 UTC #6 lore raw

Quoted 29 lines · On Thursday 17 September 2015 07:16:44 Pavel Machek wrote:

Quoted 29 lines

Quoted 22 lines

        if (image->depth = 1) {
                if (p->fix.visual = FB_VISUAL_TRUECOLOR ||
                    p->fix.visual = FB_VISUAL_DIRECTCOLOR) {
                        fgcolor = ((u32*)(p->pseudo_palette))[image->fg_color];
                        bgcolor = ((u32*)(p->pseudo_palette))[image->bg_color];
                } else {
                        fgcolor = image->fg_color;
                        bgcolor = image->bg_color;
                }

                if (32 % bpp = 0 && !start_index && !pitch_index &&
                    ((width & (32/bpp-1)) = 0) &&
                    bpp >= 8 && bpp <= 32)
                        fast_imageblit(image, p, dst1, fgcolor, bgcolor);
                else
                        slow_imageblit(image, p, dst1, fgcolor, bgcolor,
                                        start_index, pitch_index);
        } else
                color_imageblit(image, p, dst1, start_index, pitch_i

Quoted 3 lines

Notice that bpp is not checked for zero, and thus bpp=0 is totally
feasible? resulting in 32/bpp crashing the kernel?

Hm... this could really be a problem! But how to patch it? Which branch should be called (fast_ or slow_ function) if bpp is zero?

Quoted 7 lines

Quoted 2 lines
And is there some way to force kernel to dump backtrace into dmesg when division by zero occur?
You can do WARN_ON(bpp=1) ... and should probably return in that case.
Pavel

Does not make sense to call slow_ function? In that if condition check also that bpp is nonzero...

Signature · 2 lines

Pali RohÃ¡r
[email protected]

Tomi Valkeinen

2015-08-21 08:42 UTC #7 lore raw

In reply to Pali Rohár

Quoted 9 lines · Pali Rohár

Hello,
when on N900 (real HW or qemu) I run this command
/ # echo 0 > /sys/devices/platform/omapdss/overlay0/enabled && echo 0 > /sys/class/graphics/fb0/size
then kernel crash with this error message
/ # [ 29.904113] Division by zero in kernel.

The problem is that fb console uses the kernel mmapped framebuffer, but omapfb is not aware of the fb console. So the above commands free the framebuffer, as omapfb thinks no one is using it, and then fb console tries to touch the fb.

omapfb tracks mmaps from userspace, and refuses to free a fb it it's mmapped.

I don't know how to fix it straight away. Maybe there's a way for omapfb to check if the fbcon uses the fb in question, and if so, refuses to release/resize the memory.

Tomi

Pali Rohár

author

2015-08-21 08:48 UTC #8 lore raw

Quoted 5 lines · On Friday 21 August 2015 11:42:14 Tomi Valkeinen wrote:

Quoted 2 lines · Pali Rohár
Hello,

Quoted 8 lines

Quoted 7 lines
when on N900 (real HW or qemu) I run this command
/ # echo 0 > /sys/devices/platform/omapdss/overlay0/enabled && echo 0 > /sys/class/graphics/fb0/size
then kernel crash with this error message
/ # [ 29.904113] Division by zero in kernel.

Hi! Thanks for explaining.

Quoted 5 lines

The problem is that fb console uses the kernel mmapped framebuffer, but omapfb is not aware of the fb console. So the above commands free the framebuffer, as omapfb thinks no one is using it, and then fb console tries to touch the fb.

What about refusing those calls from fb console? So fb console will not know about this problem and omapfb will just ignore drawn functions?

Quoted 9 lines

omapfb tracks mmaps from userspace, and refuses to free a fb it it's mmapped.
I don't know how to fix it straight away. Maybe there's a way for omapfb to check if the fbcon uses the fb in question, and if so, refuses to release/resize the memory.
Tomi

Maemo userspace (on Nokia N900) uses above commands to initialize graphic and Xserver. So it would be nice if disabling framebuffer would work even if fbcon.ko is loaded (or compiled directly into zImage).

Signature · 2 lines

Pali Rohár
[email protected]

Tomi Valkeinen

2015-08-21 09:17 UTC #9 lore raw

Quoted 17 lines · Pali Rohár

Quoted 5 lines · On Friday 21 August 2015 11:42:14 Tomi Valkeinen wrote:
Quoted 2 lines · Pali Rohár
Hello,
Quoted 8 lines
Quoted 7 lines
when on N900 (real HW or qemu) I run this command
/ # echo 0 > /sys/devices/platform/omapdss/overlay0/enabled && echo 0 > /sys/class/graphics/fb0/size
then kernel crash with this error message
/ # [ 29.904113] Division by zero in kernel.
Hi! Thanks for explaining.

Quoted 8 lines

Quoted 5 lines
The problem is that fb console uses the kernel mmapped framebuffer, but omapfb is not aware of the fb console. So the above commands free the framebuffer, as omapfb thinks no one is using it, and then fb console tries to touch the fb.
What about refusing those calls from fb console? So fb console will not know about this problem and omapfb will just ignore drawn functions?

Hmm, I'm not sure I understand what you mean... omapfb is not drawing anything, fbcon is doing the drawing independently to the fb. And the fb suddenly disappears without fbcon realizing that.

Quoted 7 lines

Quoted 7 lines
omapfb tracks mmaps from userspace, and refuses to free a fb it it's mmapped.
I don't know how to fix it straight away. Maybe there's a way for omapfb to check if the fbcon uses the fb in question, and if so, refuses to release/resize the memory.

Quoted 6 lines

Quoted 2 lines
Tomi
Maemo userspace (on Nokia N900) uses above commands to initialize graphic and Xserver. So it would be nice if disabling framebuffer would work even if fbcon.ko is loaded (or compiled directly into zImage).

Ok. And N900 has fbcon enabled? I wonder how it survives...

fbcon can be unbound from userspace with something like:

echo 0 > /sys/class/vtconsole/vtcon1/bind

After that I think the memory can be freed.

But obviously the kernel should not crash here, no question about that.

Tomi

Pali Rohár

author

2015-08-26 10:16 UTC #10 lore raw

Quoted 40 lines · On Friday 21 August 2015 12:17:41 Tomi Valkeinen wrote:

Quoted 17 lines · Pali Rohár
Quoted 5 lines · On Friday 21 August 2015 11:42:14 Tomi Valkeinen wrote:
Quoted 2 lines · Pali Rohár
Hello,
Quoted 8 lines
Quoted 7 lines
when on N900 (real HW or qemu) I run this command
/ # echo 0 > /sys/devices/platform/omapdss/overlay0/enabled && echo 0 > /sys/class/graphics/fb0/size
then kernel crash with this error message
/ # [ 29.904113] Division by zero in kernel.
Hi! Thanks for explaining.
Quoted 8 lines
Quoted 5 lines
The problem is that fb console uses the kernel mmapped framebuffer, but omapfb is not aware of the fb console. So the above commands free the framebuffer, as omapfb thinks no one is using it, and then fb console tries to touch the fb.
What about refusing those calls from fb console? So fb console will not know about this problem and omapfb will just ignore drawn functions?
Hmm, I'm not sure I understand what you mean... omapfb is not drawing anything, fbcon is doing the drawing independently to the fb. And the fb suddenly disappears without fbcon realizing that.
Quoted 7 lines
Quoted 7 lines
omapfb tracks mmaps from userspace, and refuses to free a fb it it's mmapped.
I don't know how to fix it straight away. Maybe there's a way for omapfb to check if the fbcon uses the fb in question, and if so, refuses to release/resize the memory.

Quoted 9 lines

Quoted 6 lines
Quoted 2 lines
Tomi
Maemo userspace (on Nokia N900) uses above commands to initialize graphic and Xserver. So it would be nice if disabling framebuffer would work even if fbcon.ko is loaded (or compiled directly into zImage).
Ok. And N900 has fbcon enabled? I wonder how it survives...

Depends on compiled kernel. Original stock Nokia kernel 2.6.28 has it disabled, but when I recompiled it with fbcon (either static linked into zImage or external fbcon.ko) it works and I do not see any problem.

So I think it survives...

Quoted 10 lines

fbcon can be unbound from userspace with something like:
echo 0 > /sys/class/vtconsole/vtcon1/bind
After that I think the memory can be freed.
But obviously the kernel should not crash here, no question about that.
Tomi

Maybe just adding that test for zero to prevent division by zero?

Signature · 2 lines

Pali Rohár
[email protected]