From: Sasha Levin <sashal@kernel.org>
To: stable@vger.kernel.org
Cc: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>,
Helge Deller <deller@gmx.de>, Sasha Levin <sashal@kernel.org>
Subject: [PATCH 5.10.y] fbdev: udlfb: check for fb_deferred_io_init() error
Date: Wed, 11 Nov 2026 09:38:49 -0500 [thread overview]
Message-ID: <20261111143826.2357715-1-sashal@kernel.org> (raw)
In-Reply-To: <20261107062159-failed-5.10-eae055f33e41@kernel.org>
From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
[ Upstream commit eae055f33e41e1d3e1a7e905bdcb1e9f196ed31d ]
fb_deferred_io_init() allocates deferred I/O state, populating
info->fbdefio_state, or leaving it NULL if an error occurs.
Currently dlfb_ops_open() ignores its return value.
Therefore if an error arises in fb_deferred_io_init() (for instance, due to
an allocation failure) info->fbdefio_state is left NULL.
fb_open() will then dereference a NULL pointer (calling
fb_deferred_io_open()) as soon as dlfb_ops_open() returns.
Additionally, if the allocation of info->fbdefio itself fails,
dlfb_ops_open() sets info->fbdefio to NULL and invokes
fb_deferred_io_init() regardless, hitting BUG_ON(!fbdefio).
Fix this by only invoking fb_deferred_io_init() if the allocation
succeeded, and checking for the error.
The driver already supports operating without deferred I/O, so in either
case fall back to that by setting info->fbdefio to NULL.
The ignored return value was introduced in commit 56c134f7f1b5 ("fbdev:
Track deferred-I/O pages in pageref struct").
However, the BUG_ON() issue originates from the earlier
commit 5bea1fbf9423 ("staging: udlfb: fix incorrect fb_defio
implementation for multiple framebuffers"), so target that for the fix.
Fixes: 5bea1fbf9423 ("staging: udlfb: fix incorrect fb_defio implementation for multiple framebuffers")
Cc: stable@vger.kernel.org
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Signed-off-by: Helge Deller <deller@gmx.de>
[ sashal: Omitted fb_deferred_io_init() error handling because the older API returns void and cannot fail. ]
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/video/fbdev/udlfb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c
index 23097d190e0b1..d3e7c8f6ae7eb 100644
--- a/drivers/video/fbdev/udlfb.c
+++ b/drivers/video/fbdev/udlfb.c
@@ -1006,10 +1006,10 @@ static int dlfb_ops_open(struct fb_info *info, int user)
if (fbdefio) {
fbdefio->delay = DL_DEFIO_WRITE_DELAY;
fbdefio->deferred_io = dlfb_dpy_deferred_io;
- }
- info->fbdefio = fbdefio;
- fb_deferred_io_init(info);
+ info->fbdefio = fbdefio;
+ fb_deferred_io_init(info);
+ }
}
dev_dbg(info->dev, "open, user=%d fb_info=%p count=%d\n",
--
2.53.0
prev parent reply other threads:[~2026-11-11 14:38 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-07 11:21 FAILED: patch "[PATCH] fbdev: udlfb: check for fb_deferred_io_init() error" failed to apply to 5.10-stable tree Sasha Levin
2026-11-11 14:38 ` Sasha Levin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261111143826.2357715-1-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=deller@gmx.de \
--cc=ljs@kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.