On Tue, May 25, 2021 at 06:06:15PM -0300, Igor Torrente wrote:
Hi Pavel,
On 5/25/21 5:47 PM, Pavel Machek wrote:
Hi!
From: Igor Matheus Andrade Torrente igormtorrente@gmail.com
commit dc13cac4862cc68ec74348a80b6942532b7735fa upstream.
The return of ioremap if not checked, and can lead to a NULL to be assigned to hga_vram. Potentially leading to a NULL pointer dereference.
The fix adds code to deal with this case in the error label and changes how the hgafb_probe handles the return of hga_card_detect.
This will break hgafb completely, right? And crash system without hga card as a bonus.
+++ b/drivers/video/fbdev/hgafb.c @@ -285,6 +285,8 @@ static int hga_card_detect(void) hga_vram_len = 0x08000; hga_vram = ioremap(0xb0000, hga_vram_len);
- if (!hga_vram)
if (request_region(0x3b0, 12, "hgafb")) release_io_ports = 1;return -ENOMEM;
@@ -344,13 +346,18 @@ static int hga_card_detect(void) hga_type_name = "Hercules"; break; }
- return 1;
- return 0;
Ok, so calling convention is now "0 means detected".
@@ -548,13 +555,11 @@ static struct fb_ops hgafb_ops = { static int hgafb_probe(struct platform_device *pdev) { struct fb_info *info;
- int ret;
...
- ret = hga_card_detect();
- if (!ret)
printk(KERN_INFO "hgafb: %s with %ldK of memory detected.\n", hga_type_name, hga_vram_len/1024);return ret;
If the card is detected, 0 is returned, !0 is true, and we abort detection....
Yes, you are right! There's a patch that fixes it:
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/commit/...
As far as I know, this patch should be queue up soon to all stable branches.
Greg should have more details about it.
Good catch, I'll go queue that up now, thanks.
greg k-h