* Re: [PATCH v2] fbdev: fbcon: fix out-of-bounds read in err_out of fbcon_do_set_font()
From: Helge Deller @ 2026-06-25 16:18 UTC (permalink / raw)
To: Mingyu Wang, tzimmermann, simona
Cc: syoshida, dri-devel, linux-fbdev, linux-kernel, w15303746062,
stable
In-Reply-To: <20260625160306.438847-1-25181214217@stu.xidian.edu.cn>
On 6/25/26 18:03, Mingyu Wang wrote:
> When fbcon_do_set_font() fails (e.g., due to a memory allocation failure
> inside vc_resize() under heavy memory pressure), it jumps to the `err_out`
> label to roll back the console state. However, the current rollback logic
> forgets to restore the `hi_font` state, leading to a severe state machine
> corruption.
>
> Earlier in the function, `set_vc_hi_font()` might be called to change
> `vc->vc_hi_font_mask` and mutate the screen buffer. If `vc_resize()`
> subsequently fails, the `err_out` path restores `vc_font.charcount`
> but entirely skips rolling back the `vc_hi_font_mask` and the screen
> buffer.
>
> This mismatch leaves the terminal in a desynchronized state. Because
> `vc_hi_font_mask` remains set, the VT subsystem will still accept
> character indices greater than 255 from userspace and write them to the
> screen buffer. Subsequent rendering calls (e.g., `fbcon_putcs()`) will
> then use these inflated indices to access the reverted, 256-character
> font array, leading to a deterministic out-of-bounds read and potential
> kernel memory disclosure.
>
> Fix this by adding the missing rollback logic for the `hi_font` mask
> and screen buffer in the error path.
>
> Fixes: a5a923038d70 ("fbdev: fbcon: Properly revert changes when vc_resize() failed")
> Cc: stable@vger.kernel.org
> Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
applied.
Thanks!
Helge
^ permalink raw reply
* [PATCH v2] fbdev: fbcon: fix out-of-bounds read in err_out of fbcon_do_set_font()
From: Mingyu Wang @ 2026-06-25 16:03 UTC (permalink / raw)
To: deller, tzimmermann, simona
Cc: syoshida, dri-devel, linux-fbdev, linux-kernel, w15303746062,
Mingyu Wang, stable
When fbcon_do_set_font() fails (e.g., due to a memory allocation failure
inside vc_resize() under heavy memory pressure), it jumps to the `err_out`
label to roll back the console state. However, the current rollback logic
forgets to restore the `hi_font` state, leading to a severe state machine
corruption.
Earlier in the function, `set_vc_hi_font()` might be called to change
`vc->vc_hi_font_mask` and mutate the screen buffer. If `vc_resize()`
subsequently fails, the `err_out` path restores `vc_font.charcount`
but entirely skips rolling back the `vc_hi_font_mask` and the screen
buffer.
This mismatch leaves the terminal in a desynchronized state. Because
`vc_hi_font_mask` remains set, the VT subsystem will still accept
character indices greater than 255 from userspace and write them to the
screen buffer. Subsequent rendering calls (e.g., `fbcon_putcs()`) will
then use these inflated indices to access the reverted, 256-character
font array, leading to a deterministic out-of-bounds read and potential
kernel memory disclosure.
Fix this by adding the missing rollback logic for the `hi_font` mask
and screen buffer in the error path.
Fixes: a5a923038d70 ("fbdev: fbcon: Properly revert changes when vc_resize() failed")
Cc: stable@vger.kernel.org
Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/core/fbcon.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 9077d3b99357..37beb93045af 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2405,6 +2405,7 @@ static int fbcon_do_set_font(struct vc_data *vc, int w, int h, int charcount,
int resize, ret, old_width, old_height, old_charcount;
font_data_t *old_fontdata = p->fontdata;
const u8 *old_data = vc->vc_font.data;
+ unsigned short old_hi_font_mask = vc->vc_hi_font_mask;
font_data_get(data);
@@ -2451,6 +2452,12 @@ static int fbcon_do_set_font(struct vc_data *vc, int w, int h, int charcount,
vc->vc_font.height = old_height;
vc->vc_font.charcount = old_charcount;
+ /* Restore the hi_font state and screen buffer */
+ if (old_hi_font_mask && !vc->vc_hi_font_mask)
+ set_vc_hi_font(vc, true);
+ else if (!old_hi_font_mask && vc->vc_hi_font_mask)
+ set_vc_hi_font(vc, false);
+
font_data_put(data);
return ret;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] fbdev: fbcon: fix out-of-bounds read in err_out of fbcon_do_set_font()
From: Mingyu Wang @ 2026-06-25 15:18 UTC (permalink / raw)
To: Thomas Zimmermann, w15303746062, deller, simona
Cc: syoshida, dri-devel, linux-fbdev, linux-kernel, stable
In-Reply-To: <7dd87e55-5170-4317-8c9e-38a7868f68fc@suse.de>
Hi Thomas,
>
> The email in your S-o-b tag differs from the one in the mail's From:
> line. I think this is not accepted in the kernel. Can you please
> resubmit with the email addresses synchronized.
>
>
Thank you very much for the review and the Reviewed-by tag!
The email mismatch was due to my university's SMTP server restrictions,
which forced me to use my personal 163 email to route the patch. I
apologize for the confusion.
I will synchronize my git authorship and Signed-off-by tags, and send a
v2 patch shortly with your Reviewed-by tag included.
Best regards,
Mingyu
^ permalink raw reply
* Re: [PATCH] fbdev: fbcon: fix out-of-bounds read in err_out of fbcon_do_set_font()
From: Thomas Zimmermann @ 2026-06-25 15:04 UTC (permalink / raw)
To: w15303746062, deller, simona
Cc: syoshida, dri-devel, linux-fbdev, linux-kernel, Mingyu Wang,
stable
In-Reply-To: <20260624083316.389677-1-w15303746062@163.com>
Hi
Am 24.06.26 um 10:33 schrieb w15303746062@163.com:
> From: Mingyu Wang <25181214217@stu.xidian.edu.cn>
>
> When fbcon_do_set_font() fails (e.g., due to a memory allocation failure
> inside vc_resize() under heavy memory pressure), it jumps to the `err_out`
> label to roll back the console state. However, the current rollback logic
> forgets to restore the `hi_font` state, leading to a severe state machine
> corruption.
>
> Earlier in the function, `set_vc_hi_font()` might be called to change
> `vc->vc_hi_font_mask` and mutate the screen buffer. If `vc_resize()`
> subsequently fails, the `err_out` path restores `vc_font.charcount`
> but entirely skips rolling back the `vc_hi_font_mask` and the screen
> buffer.
>
> This mismatch leaves the terminal in a desynchronized state. Because
> `vc_hi_font_mask` remains set, the VT subsystem will still accept
> character indices greater than 255 from userspace and write them to the
> screen buffer. Subsequent rendering calls (e.g., `fbcon_putcs()`) will
> then use these inflated indices to access the reverted, 256-character
> font array, leading to a deterministic out-of-bounds read and potential
> kernel memory disclosure.
>
> Fix this by adding the missing rollback logic for the `hi_font` mask
> and screen buffer in the error path.
>
> Fixes: a5a923038d70 ("fbdev: fbcon: Properly revert changes when vc_resize() failed")
> Cc: stable@vger.kernel.org
> Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
The email in your S-o-b tag differs from the one in the mail's From:
line. I think this is not accepted in the kernel. Can you please
resubmit with the email addresses synchronized.
Apart from that:
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Thanks for fixing this problem.
Best regards
Thomas
> ---
> drivers/video/fbdev/core/fbcon.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index 9077d3b99357..5880ab9f3cde 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -2405,6 +2405,7 @@ static int fbcon_do_set_font(struct vc_data *vc, int w, int h, int charcount,
> int resize, ret, old_width, old_height, old_charcount;
> font_data_t *old_fontdata = p->fontdata;
> const u8 *old_data = vc->vc_font.data;
> + int old_hi_font_mask = vc->vc_hi_font_mask;
>
> font_data_get(data);
>
> @@ -2451,6 +2452,12 @@ static int fbcon_do_set_font(struct vc_data *vc, int w, int h, int charcount,
> vc->vc_font.height = old_height;
> vc->vc_font.charcount = old_charcount;
>
> + /* Restore the hi_font state and screen buffer */
> + if (old_hi_font_mask && !vc->vc_hi_font_mask)
> + set_vc_hi_font(vc, true);
> + else if (!old_hi_font_mask && vc->vc_hi_font_mask)
> + set_vc_hi_font(vc, false);
> +
> font_data_put(data);
>
> return ret;
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH] staging: fbtft: replace empty modifier argument with no-op macro
From: Andy Shevchenko @ 2026-06-25 14:09 UTC (permalink / raw)
To: Sai Madhu
Cc: Dan Carpenter, andy, gregkh, dri-devel, linux-fbdev,
linux-staging, linux-kernel
In-Reply-To: <CAB0uMAeMOV4Xhq2cNVjxne89yqF8vdubM8-OpPYGK4f4yBLMNw@mail.gmail.com>
On Thu, Jun 25, 2026 at 04:00:24PM +0530, Sai Madhu wrote:
First of all, do not top-post!
> Thank you for the feedback. I understand and will drop this patch.
>
> I have also noticed two pre-existing bugs in the same file
> (unaligned access and buffer size calculation when startbyte is used)
> and have sent a separate patch to fix those.
> On Thu, 25 Jun 2026 at 15:58, Dan Carpenter <error27@gmail.com> wrote:
> > On Thu, Jun 25, 2026 at 05:27:21PM +0800, suryasaimadhu wrote:
> > I don't hate this patch, but I think we've decided to leave this
> > as-is.
Yep. as Dan said,
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] staging: fbtft: fix unaligned access and buffer size when startbyte is used
From: Andy Shevchenko @ 2026-06-25 14:08 UTC (permalink / raw)
To: suryasaimadhu
Cc: andy, gregkh, dri-devel, linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <20260625103041.281190-1-suryasaimadhu369@gmail.com>
On Thu, Jun 25, 2026 at 06:30:41PM +0800, suryasaimadhu wrote:
> When par->startbyte is non-zero, buf is advanced by one byte creating
> an unaligned pointer for 16-bit types (u16, __be16). Dereferencing this
> unaligned pointer can cause a kernel panic on strict-alignment
> architectures.
>
> Fix by using put_unaligned() instead of direct pointer dereference.
>
> Also fix incorrect buffer size calculation in fbtft_write_buf_dc() call:
> len * (sizeof(data_type) + offset) /* wrong: multiplies offset by len */
> len * sizeof(data_type) + offset /* correct: one startbyte +
> len items */
Same comments as per your other patch contributions. Make it cleaner next time.
So it seem a v2 should be a mini-series with fixes for different
issues/drivers/et cetera.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] staging: fbtft: fix unaligned access and txbuf safety issues
From: Andy Shevchenko @ 2026-06-25 14:05 UTC (permalink / raw)
To: suryasaimadhu
Cc: andy, gregkh, dri-devel, linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <20260625114215.325973-1-suryasaimadhu369@gmail.com>
On Thu, Jun 25, 2026 at 07:42:15PM +0800, suryasaimadhu wrote:
> This patch addresses several pre-existing issues in the fbtft driver:
>
> 1. define_fbtft_write_reg(): when par->startbyte is set, buf is
> advanced by one byte creating a misaligned pointer for 16-bit types.
> Use put_unaligned() for register writes and fix the SPI transfer
> size from len * (sizeof(data_type) + offset) to
> len * sizeof(data_type) + offset.
>
> 2. fbtft_write_vmem16_bus8() and fb_ra8875 write_vmem16_bus8(): same
> unaligned 16-bit stores when txbuf is byte-offset for a start
> prefix. Use put_unaligned() for pixel data copies.
>
> 3. tx_array_size underflow: both vmem helpers subtract 2 from
> tx_array_size when a startbyte prefix is used. A small txbuflen
> device property causes unsigned underflow and out-of-bounds heap
> writes. Fall back to the non-buffered write path when the buffer
> is too small.
>
> 4. fb_ra8875 write_vmem16_bus8(): missing NULL check for
> par->txbuf.buf, which remains NULL on big-endian when txbuflen is
> 0 because the PAGE_SIZE fallback is little-endian only. Fall back
> to direct write when the buffer is missing.
>
> Also replace empty modifier arguments in define_fbtft_write_reg() with
> a no-op macro to fix checkpatch warnings.
This looks like v2 of the thing without changelog and addressing the comments
that have been given against v1. I'm not even going to review that.
Please, consolidate feedback, take your time to study process documentation
(Documentation/process/* in the Linux kernel source tree) and try again a bit
later.
(The fix and report are valuable in general, thanks for doing that.)
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] staging: fbtft: fix unaligned vmem writes when txbuf is byte-offset
From: Andy Shevchenko @ 2026-06-25 13:59 UTC (permalink / raw)
To: suryasaimadhu
Cc: andy, gregkh, dri-devel, linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <20260625110237.304435-1-suryasaimadhu369@gmail.com>
On Thu, Jun 25, 2026 at 07:02:37PM +0800, suryasaimadhu wrote:
> fbtft_write_vmem16_bus8() and fb_ra8875's write_vmem16_bus8() offset
> txbuf16 by one byte for a command/start prefix, then store 16-bit pixel
> data via txbuf16[i]. On strict-alignment architectures this can fault
> the same way as the write_reg path fixed in the previous patch.
.write_reg()
Can you provide a real world example of the failure?
> Use put_unaligned() for these stores.
Sounds like a fix without Fixes tag.
> Signed-off-by: suryasaimadhu <suryasaimadhu369@gmail.com>
Use your name in accordance with your official documents.
...
> +++ b/drivers/staging/fbtft/fb_ra8875.c
> @@ -10,6 +10,7 @@
> #include <linux/delay.h>
>
You should move this blank line to be...
> #include <linux/gpio/consumer.h>
> +#include <linux/unaligned.h>
...here.
> #include "fbtft.h"
...
> #define DRVNAME "fb_ra8875"
Are other drivers also being affected?
...
> +++ b/drivers/staging/fbtft/fbtft-bus.c
Also needs linux/unaligned.h.
> + put_unaligned(cpu_to_be16(vmem16[i]), &txbuf16[i]);
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] staging: fbtft: fix unaligned vmem writes when txbuf is byte-offset
From: kernel test robot @ 2026-06-25 13:53 UTC (permalink / raw)
To: suryasaimadhu, andy
Cc: llvm, oe-kbuild-all, gregkh, dri-devel, linux-fbdev,
linux-staging, linux-kernel, suryasaimadhu
In-Reply-To: <20260625110237.304435-1-suryasaimadhu369@gmail.com>
Hi suryasaimadhu,
kernel test robot noticed the following build errors:
[auto build test ERROR on staging/staging-testing]
url: https://github.com/intel-lab-lkp/linux/commits/suryasaimadhu/staging-fbtft-fix-unaligned-vmem-writes-when-txbuf-is-byte-offset/20260625-190423
base: staging/staging-testing
patch link: https://lore.kernel.org/r/20260625110237.304435-1-suryasaimadhu369%40gmail.com
patch subject: [PATCH] staging: fbtft: fix unaligned vmem writes when txbuf is byte-offset
config: hexagon-allmodconfig (https://download.01.org/0day-ci/archive/20260625/202606252144.F56jkpaD-lkp@intel.com/config)
compiler: clang version 23.0.0git (https://github.com/llvm/llvm-project 6cc609bb250b21b47fc7d394b4019101e9983597)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260625/202606252144.F56jkpaD-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606252144.F56jkpaD-lkp@intel.com/
All errors (new ones prefixed by >>):
>> drivers/staging/fbtft/fbtft-bus.c:157:4: error: call to undeclared function 'put_unaligned'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
157 | put_unaligned(cpu_to_be16(vmem16[i]), &txbuf16[i]);
| ^
1 error generated.
vim +/put_unaligned +157 drivers/staging/fbtft/fbtft-bus.c
113
114 /*****************************************************************************
115 *
116 * int (*write_vmem)(struct fbtft_par *par);
117 *
118 *****************************************************************************/
119
120 /* 16 bit pixel over 8-bit databus */
121 int fbtft_write_vmem16_bus8(struct fbtft_par *par, size_t offset, size_t len)
122 {
123 u16 *vmem16;
124 __be16 *txbuf16 = par->txbuf.buf;
125 size_t remain;
126 size_t to_copy;
127 size_t tx_array_size;
128 int i;
129 int ret = 0;
130 size_t startbyte_size = 0;
131
132 remain = len / 2;
133 vmem16 = (u16 *)(par->info->screen_buffer + offset);
134
135 gpiod_set_value(par->gpio.dc, 1);
136
137 /* non buffered write */
138 if (!par->txbuf.buf)
139 return par->fbtftops.write(par, vmem16, len);
140
141 /* buffered write */
142 tx_array_size = par->txbuf.len / 2;
143
144 if (par->startbyte) {
145 txbuf16 = par->txbuf.buf + 1;
146 tx_array_size -= 2;
147 *(u8 *)(par->txbuf.buf) = par->startbyte | 0x2;
148 startbyte_size = 1;
149 }
150
151 while (remain) {
152 to_copy = min(tx_array_size, remain);
153 dev_dbg(par->info->device, "to_copy=%zu, remain=%zu\n",
154 to_copy, remain - to_copy);
155
156 for (i = 0; i < to_copy; i++)
> 157 put_unaligned(cpu_to_be16(vmem16[i]), &txbuf16[i]);
158
159 vmem16 = vmem16 + to_copy;
160 ret = par->fbtftops.write(par, par->txbuf.buf,
161 startbyte_size + to_copy * 2);
162 if (ret < 0)
163 return ret;
164 remain -= to_copy;
165 }
166
167 return ret;
168 }
169 EXPORT_SYMBOL(fbtft_write_vmem16_bus8);
170
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] staging: fbtft: fix unaligned vmem writes when txbuf is byte-offset
From: kernel test robot @ 2026-06-25 13:20 UTC (permalink / raw)
To: suryasaimadhu, andy
Cc: oe-kbuild-all, gregkh, dri-devel, linux-fbdev, linux-staging,
linux-kernel, suryasaimadhu
In-Reply-To: <20260625110237.304435-1-suryasaimadhu369@gmail.com>
Hi suryasaimadhu,
kernel test robot noticed the following build errors:
[auto build test ERROR on staging/staging-testing]
url: https://github.com/intel-lab-lkp/linux/commits/suryasaimadhu/staging-fbtft-fix-unaligned-vmem-writes-when-txbuf-is-byte-offset/20260625-190423
base: staging/staging-testing
patch link: https://lore.kernel.org/r/20260625110237.304435-1-suryasaimadhu369%40gmail.com
patch subject: [PATCH] staging: fbtft: fix unaligned vmem writes when txbuf is byte-offset
config: sh-allmodconfig (https://download.01.org/0day-ci/archive/20260625/202606252119.rClVa8On-lkp@intel.com/config)
compiler: sh4-linux-gcc (GCC) 16.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260625/202606252119.rClVa8On-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606252119.rClVa8On-lkp@intel.com/
All errors (new ones prefixed by >>):
drivers/staging/fbtft/fbtft-bus.c: In function 'fbtft_write_vmem16_bus8':
>> drivers/staging/fbtft/fbtft-bus.c:157:25: error: implicit declaration of function 'put_unaligned' [-Wimplicit-function-declaration]
157 | put_unaligned(cpu_to_be16(vmem16[i]), &txbuf16[i]);
| ^~~~~~~~~~~~~
vim +/put_unaligned +157 drivers/staging/fbtft/fbtft-bus.c
113
114 /*****************************************************************************
115 *
116 * int (*write_vmem)(struct fbtft_par *par);
117 *
118 *****************************************************************************/
119
120 /* 16 bit pixel over 8-bit databus */
121 int fbtft_write_vmem16_bus8(struct fbtft_par *par, size_t offset, size_t len)
122 {
123 u16 *vmem16;
124 __be16 *txbuf16 = par->txbuf.buf;
125 size_t remain;
126 size_t to_copy;
127 size_t tx_array_size;
128 int i;
129 int ret = 0;
130 size_t startbyte_size = 0;
131
132 remain = len / 2;
133 vmem16 = (u16 *)(par->info->screen_buffer + offset);
134
135 gpiod_set_value(par->gpio.dc, 1);
136
137 /* non buffered write */
138 if (!par->txbuf.buf)
139 return par->fbtftops.write(par, vmem16, len);
140
141 /* buffered write */
142 tx_array_size = par->txbuf.len / 2;
143
144 if (par->startbyte) {
145 txbuf16 = par->txbuf.buf + 1;
146 tx_array_size -= 2;
147 *(u8 *)(par->txbuf.buf) = par->startbyte | 0x2;
148 startbyte_size = 1;
149 }
150
151 while (remain) {
152 to_copy = min(tx_array_size, remain);
153 dev_dbg(par->info->device, "to_copy=%zu, remain=%zu\n",
154 to_copy, remain - to_copy);
155
156 for (i = 0; i < to_copy; i++)
> 157 put_unaligned(cpu_to_be16(vmem16[i]), &txbuf16[i]);
158
159 vmem16 = vmem16 + to_copy;
160 ret = par->fbtftops.write(par, par->txbuf.buf,
161 startbyte_size + to_copy * 2);
162 if (ret < 0)
163 return ret;
164 remain -= to_copy;
165 }
166
167 return ret;
168 }
169 EXPORT_SYMBOL(fbtft_write_vmem16_bus8);
170
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] staging: fbtft: fix unaligned access and txbuf safety issues
From: Dan Carpenter @ 2026-06-25 12:00 UTC (permalink / raw)
To: suryasaimadhu
Cc: andy, gregkh, dri-devel, linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <20260625114215.325973-1-suryasaimadhu369@gmail.com>
On Thu, Jun 25, 2026 at 07:42:15PM +0800, suryasaimadhu wrote:
> This patch addresses several pre-existing issues in the fbtft driver:
>
> 1. define_fbtft_write_reg(): when par->startbyte is set, buf is
> advanced by one byte creating a misaligned pointer for 16-bit types.
> Use put_unaligned() for register writes and fix the SPI transfer
> size from len * (sizeof(data_type) + offset) to
> len * sizeof(data_type) + offset.
>
> 2. fbtft_write_vmem16_bus8() and fb_ra8875 write_vmem16_bus8(): same
> unaligned 16-bit stores when txbuf is byte-offset for a start
> prefix. Use put_unaligned() for pixel data copies.
>
> 3. tx_array_size underflow: both vmem helpers subtract 2 from
> tx_array_size when a startbyte prefix is used. A small txbuflen
> device property causes unsigned underflow and out-of-bounds heap
> writes. Fall back to the non-buffered write path when the buffer
> is too small.
>
> 4. fb_ra8875 write_vmem16_bus8(): missing NULL check for
> par->txbuf.buf, which remains NULL on big-endian when txbuflen is
> 0 because the PAGE_SIZE fallback is little-endian only. Fall back
> to direct write when the buffer is missing.
>
> Also replace empty modifier arguments in define_fbtft_write_reg() with
> a no-op macro to fix checkpatch warnings.
>
> Signed-off-by: suryasaimadhu <suryasaimadhu369@gmail.com>
Is this how you would sign a legal document?
This patch does too many things at once. Split it up. Also please
a delay between sending us patches. Otherwise it's overwhelming to
deal with. Bunch them together in a patchset instead of sending them
one by one.
regards,
dan carpenter
^ permalink raw reply
* [PATCH] staging: fbtft: fix unaligned access and txbuf safety issues
From: suryasaimadhu @ 2026-06-25 11:42 UTC (permalink / raw)
To: andy
Cc: gregkh, dri-devel, linux-fbdev, linux-staging, linux-kernel,
suryasaimadhu
In-Reply-To: <20260625111602.438761F000E9@smtp.kernel.org>
This patch addresses several pre-existing issues in the fbtft driver:
1. define_fbtft_write_reg(): when par->startbyte is set, buf is
advanced by one byte creating a misaligned pointer for 16-bit types.
Use put_unaligned() for register writes and fix the SPI transfer
size from len * (sizeof(data_type) + offset) to
len * sizeof(data_type) + offset.
2. fbtft_write_vmem16_bus8() and fb_ra8875 write_vmem16_bus8(): same
unaligned 16-bit stores when txbuf is byte-offset for a start
prefix. Use put_unaligned() for pixel data copies.
3. tx_array_size underflow: both vmem helpers subtract 2 from
tx_array_size when a startbyte prefix is used. A small txbuflen
device property causes unsigned underflow and out-of-bounds heap
writes. Fall back to the non-buffered write path when the buffer
is too small.
4. fb_ra8875 write_vmem16_bus8(): missing NULL check for
par->txbuf.buf, which remains NULL on big-endian when txbuflen is
0 because the PAGE_SIZE fallback is little-endian only. Fall back
to direct write when the buffer is missing.
Also replace empty modifier arguments in define_fbtft_write_reg() with
a no-op macro to fix checkpatch warnings.
Signed-off-by: suryasaimadhu <suryasaimadhu369@gmail.com>
---
drivers/staging/fbtft/fb_ra8875.c | 10 +++++++++-
drivers/staging/fbtft/fbtft-bus.c | 25 +++++++++++++++++--------
2 files changed, 26 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/fbtft/fb_ra8875.c b/drivers/staging/fbtft/fb_ra8875.c
index 0ab1de664..06f650aac 100644
--- a/drivers/staging/fbtft/fb_ra8875.c
+++ b/drivers/staging/fbtft/fb_ra8875.c
@@ -10,6 +10,7 @@
#include <linux/delay.h>
#include <linux/gpio/consumer.h>
+#include <linux/unaligned.h>
#include "fbtft.h"
#define DRVNAME "fb_ra8875"
@@ -250,7 +251,14 @@ static int write_vmem16_bus8(struct fbtft_par *par, size_t offset, size_t len)
remain = len / 2;
vmem16 = (u16 *)(par->info->screen_buffer + offset);
+
+ if (!par->txbuf.buf)
+ return par->fbtftops.write(par, vmem16, len);
+
tx_array_size = par->txbuf.len / 2;
+ if (tx_array_size <= 2)
+ return par->fbtftops.write(par, vmem16, len);
+
txbuf16 = par->txbuf.buf + 1;
tx_array_size -= 2;
*(u8 *)(par->txbuf.buf) = 0x00;
@@ -262,7 +270,7 @@ static int write_vmem16_bus8(struct fbtft_par *par, size_t offset, size_t len)
to_copy, remain - to_copy);
for (i = 0; i < to_copy; i++)
- txbuf16[i] = cpu_to_be16(vmem16[i]);
+ put_unaligned(cpu_to_be16(vmem16[i]), &txbuf16[i]);
vmem16 = vmem16 + to_copy;
ret = par->fbtftops.write(par, par->txbuf.buf,
diff --git a/drivers/staging/fbtft/fbtft-bus.c b/drivers/staging/fbtft/fbtft-bus.c
index 30e436ff1..52a0c5c0c 100644
--- a/drivers/staging/fbtft/fbtft-bus.c
+++ b/drivers/staging/fbtft/fbtft-bus.c
@@ -4,6 +4,7 @@
#include <linux/gpio/consumer.h>
#include <linux/spi/spi.h>
#include "fbtft.h"
+#include <linux/unaligned.h>
/*****************************************************************************
*
@@ -11,6 +12,7 @@
*
*****************************************************************************/
+#define fbtft_write_reg_no_modifier(x) (x)
#define define_fbtft_write_reg(func, buffer_type, data_type, modifier) \
void func(struct fbtft_par *par, int len, ...) \
{ \
@@ -39,7 +41,7 @@ void func(struct fbtft_par *par, int len, ...) \
offset = 1; \
} \
\
- *buf = modifier((data_type)va_arg(args, unsigned int)); \
+ put_unaligned(modifier((data_type)va_arg(args, unsigned int)), buf); \
ret = fbtft_write_buf_dc(par, par->buf, sizeof(data_type) + offset, \
0); \
if (ret < 0) \
@@ -51,20 +53,22 @@ void func(struct fbtft_par *par, int len, ...) \
\
if (len) { \
i = len; \
- while (i--) \
- *buf++ = modifier((data_type)va_arg(args, \
- unsigned int)); \
+ while (i--) { \
+ put_unaligned(modifier((data_type)va_arg(args, \
+ unsigned int)), buf); \
+ buf++; \
+ } \
fbtft_write_buf_dc(par, par->buf, \
- len * (sizeof(data_type) + offset), 1); \
+ len * sizeof(data_type) + offset, 1); \
} \
out: \
va_end(args); \
} \
EXPORT_SYMBOL(func);
-define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8, )
+define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8, fbtft_write_reg_no_modifier)
define_fbtft_write_reg(fbtft_write_reg16_bus8, __be16, u16, cpu_to_be16)
-define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16, )
+define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16, fbtft_write_reg_no_modifier)
void fbtft_write_reg8_bus9(struct fbtft_par *par, int len, ...)
{
@@ -142,19 +146,24 @@ int fbtft_write_vmem16_bus8(struct fbtft_par *par, size_t offset, size_t len)
tx_array_size = par->txbuf.len / 2;
if (par->startbyte) {
+ if (tx_array_size <= 2)
+ return par->fbtftops.write(par, vmem16, len);
txbuf16 = par->txbuf.buf + 1;
tx_array_size -= 2;
*(u8 *)(par->txbuf.buf) = par->startbyte | 0x2;
startbyte_size = 1;
}
+ if (!tx_array_size)
+ return par->fbtftops.write(par, vmem16, len);
+
while (remain) {
to_copy = min(tx_array_size, remain);
dev_dbg(par->info->device, "to_copy=%zu, remain=%zu\n",
to_copy, remain - to_copy);
for (i = 0; i < to_copy; i++)
- txbuf16[i] = cpu_to_be16(vmem16[i]);
+ put_unaligned(cpu_to_be16(vmem16[i]), &txbuf16[i]);
vmem16 = vmem16 + to_copy;
ret = par->fbtftops.write(par, par->txbuf.buf,
--
2.47.3
^ permalink raw reply related
* [PATCH] staging: fbtft: fix unaligned vmem writes when txbuf is byte-offset
From: suryasaimadhu @ 2026-06-25 11:02 UTC (permalink / raw)
To: andy
Cc: gregkh, dri-devel, linux-fbdev, linux-staging, linux-kernel,
suryasaimadhu
In-Reply-To: <20260625104220.21E5A1F00A3D@smtp.kernel.org>
fbtft_write_vmem16_bus8() and fb_ra8875's write_vmem16_bus8() offset
txbuf16 by one byte for a command/start prefix, then store 16-bit pixel
data via txbuf16[i]. On strict-alignment architectures this can fault
the same way as the write_reg path fixed in the previous patch.
Use put_unaligned() for these stores.
Signed-off-by: suryasaimadhu <suryasaimadhu369@gmail.com>
---
drivers/staging/fbtft/fb_ra8875.c | 3 ++-
drivers/staging/fbtft/fbtft-bus.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/fbtft/fb_ra8875.c b/drivers/staging/fbtft/fb_ra8875.c
index 0ab1de664..5b95b0095 100644
--- a/drivers/staging/fbtft/fb_ra8875.c
+++ b/drivers/staging/fbtft/fb_ra8875.c
@@ -10,6 +10,7 @@
#include <linux/delay.h>
#include <linux/gpio/consumer.h>
+#include <linux/unaligned.h>
#include "fbtft.h"
#define DRVNAME "fb_ra8875"
@@ -262,7 +263,7 @@ static int write_vmem16_bus8(struct fbtft_par *par, size_t offset, size_t len)
to_copy, remain - to_copy);
for (i = 0; i < to_copy; i++)
- txbuf16[i] = cpu_to_be16(vmem16[i]);
+ put_unaligned(cpu_to_be16(vmem16[i]), &txbuf16[i]);
vmem16 = vmem16 + to_copy;
ret = par->fbtftops.write(par, par->txbuf.buf,
diff --git a/drivers/staging/fbtft/fbtft-bus.c b/drivers/staging/fbtft/fbtft-bus.c
index cfcf4d7e7..fc3faab7d 100644
--- a/drivers/staging/fbtft/fbtft-bus.c
+++ b/drivers/staging/fbtft/fbtft-bus.c
@@ -158,7 +158,7 @@ int fbtft_write_vmem16_bus8(struct fbtft_par *par, size_t offset, size_t len)
to_copy, remain - to_copy);
for (i = 0; i < to_copy; i++)
- txbuf16[i] = cpu_to_be16(vmem16[i]);
+ put_unaligned(cpu_to_be16(vmem16[i]), &txbuf16[i]);
vmem16 = vmem16 + to_copy;
ret = par->fbtftops.write(par, par->txbuf.buf,
--
2.47.3
^ permalink raw reply related
* [PATCH] staging: fbtft: fix unaligned access and buffer size when startbyte is used
From: suryasaimadhu @ 2026-06-25 10:30 UTC (permalink / raw)
To: andy
Cc: gregkh, dri-devel, linux-fbdev, linux-staging, linux-kernel,
suryasaimadhu
When par->startbyte is non-zero, buf is advanced by one byte creating
an unaligned pointer for 16-bit types (u16, __be16). Dereferencing this
unaligned pointer can cause a kernel panic on strict-alignment
architectures.
Fix by using put_unaligned() instead of direct pointer dereference.
Also fix incorrect buffer size calculation in fbtft_write_buf_dc() call:
len * (sizeof(data_type) + offset) /* wrong: multiplies offset by len */
len * sizeof(data_type) + offset /* correct: one startbyte +
len items */
Signed-off-by: suryasaimadhu <suryasaimadhu369@gmail.com>
---
drivers/staging/fbtft/fbtft-bus.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-bus.c b/drivers/staging/fbtft/fbtft-bus.c
index 2169f8d1d..cfcf4d7e7 100644
--- a/drivers/staging/fbtft/fbtft-bus.c
+++ b/drivers/staging/fbtft/fbtft-bus.c
@@ -4,6 +4,7 @@
#include <linux/gpio/consumer.h>
#include <linux/spi/spi.h>
#include "fbtft.h"
+#include <linux/unaligned.h>
/*****************************************************************************
*
@@ -40,7 +41,7 @@ void func(struct fbtft_par *par, int len, ...) \
offset = 1; \
} \
\
- *buf = modifier((data_type)va_arg(args, unsigned int)); \
+ put_unaligned(modifier((data_type)va_arg(args, unsigned int)), buf); \
ret = fbtft_write_buf_dc(par, par->buf, sizeof(data_type) + offset, \
0); \
if (ret < 0) \
@@ -52,11 +53,13 @@ void func(struct fbtft_par *par, int len, ...) \
\
if (len) { \
i = len; \
- while (i--) \
- *buf++ = modifier((data_type)va_arg(args, \
- unsigned int)); \
+ while (i--) { \
+ put_unaligned(modifier((data_type)va_arg(args, \
+ unsigned int)), buf); \
+ buf++; \
+ } \
fbtft_write_buf_dc(par, par->buf, \
- len * (sizeof(data_type) + offset), 1); \
+ len * sizeof(data_type) + offset, 1); \
} \
out: \
va_end(args); \
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] staging: fbtft: replace empty modifier argument with no-op macro
From: Sai Madhu @ 2026-06-25 10:30 UTC (permalink / raw)
To: Dan Carpenter
Cc: andy, gregkh, dri-devel, linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <aj0Cv0Wzb3rieNqW@stanley.mountain>
Hi Dan,
Thank you for the feedback. I understand and will drop this patch.
I have also noticed two pre-existing bugs in the same file
(unaligned access and buffer size calculation when startbyte is used)
and have sent a separate patch to fix those.
Regards,
suryasaimadhu
On Thu, 25 Jun 2026 at 15:58, Dan Carpenter <error27@gmail.com> wrote:
>
> On Thu, Jun 25, 2026 at 05:27:21PM +0800, suryasaimadhu wrote:
> > Define fbtft_write_reg_no_modifier() as an identity function and
> > use it in place of empty modifier arguments in define_fbtft_write_reg()
> > calls to fix checkpatch errors.
> >
> > Signed-off-by: suryasaimadhu <suryasaimadhu369@gmail.com>
> > ---
>
> I don't hate this patch, but I think we've decided to leave this
> as-is.
>
> regards,
> dan carpenter
>
^ permalink raw reply
* Re: [PATCH] staging: fbtft: replace empty modifier argument with no-op macro
From: Dan Carpenter @ 2026-06-25 10:28 UTC (permalink / raw)
To: suryasaimadhu
Cc: andy, gregkh, dri-devel, linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <20260625092721.238366-1-suryasaimadhu369@gmail.com>
On Thu, Jun 25, 2026 at 05:27:21PM +0800, suryasaimadhu wrote:
> Define fbtft_write_reg_no_modifier() as an identity function and
> use it in place of empty modifier arguments in define_fbtft_write_reg()
> calls to fix checkpatch errors.
>
> Signed-off-by: suryasaimadhu <suryasaimadhu369@gmail.com>
> ---
I don't hate this patch, but I think we've decided to leave this
as-is.
regards,
dan carpenter
^ permalink raw reply
* [PATCH] staging: fbtft: replace empty modifier argument with no-op macro
From: suryasaimadhu @ 2026-06-25 9:27 UTC (permalink / raw)
To: andy
Cc: gregkh, dri-devel, linux-fbdev, linux-staging, linux-kernel,
suryasaimadhu
Define fbtft_write_reg_no_modifier() as an identity function and
use it in place of empty modifier arguments in define_fbtft_write_reg()
calls to fix checkpatch errors.
Signed-off-by: suryasaimadhu <suryasaimadhu369@gmail.com>
---
drivers/staging/fbtft/fbtft-bus.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-bus.c b/drivers/staging/fbtft/fbtft-bus.c
index 30e436ff1..2169f8d1d 100644
--- a/drivers/staging/fbtft/fbtft-bus.c
+++ b/drivers/staging/fbtft/fbtft-bus.c
@@ -11,6 +11,7 @@
*
*****************************************************************************/
+#define fbtft_write_reg_no_modifier(x) (x)
#define define_fbtft_write_reg(func, buffer_type, data_type, modifier) \
void func(struct fbtft_par *par, int len, ...) \
{ \
@@ -62,9 +63,9 @@ out: \
} \
EXPORT_SYMBOL(func);
-define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8, )
+define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8, fbtft_write_reg_no_modifier)
define_fbtft_write_reg(fbtft_write_reg16_bus8, __be16, u16, cpu_to_be16)
-define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16, )
+define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16, fbtft_write_reg_no_modifier)
void fbtft_write_reg8_bus9(struct fbtft_par *par, int len, ...)
{
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] staging: sm750fb: fix const pointer declaration
From: Sai Madhu @ 2026-06-25 9:03 UTC (permalink / raw)
To: ahmet
Cc: sudipm.mukherjee, teddy.wang, gregkh, linux-fbdev, linux-staging,
linux-kernel
In-Reply-To: <f5be5a78-a649-447c-8145-b32a530194c2@sezginduran.net>
Hi Ahmet,
Thank you for the review.
I compiled the patch with CONFIG_FB_SM750 enabled and it fails
with the following errors:
sm750.c:773: error: assignment of read-only location 'g_fbmode[index]'
sm750.c:775: error: assignment of read-only location 'g_fbmode[index]'
sm750.c:884: error: assignment of read-only location 'g_fbmode[0]'
sm750.c:888: error: assignment of read-only location 'g_fbmode[1]'
The array elements are assigned at runtime in lynxfb_set_fbinfo()
and sm750fb_setup(), so making them const is incorrect.
The checkpatch warning is a false positive in this case.
I will drop this patch.
Regards,
suryasaimadhu
On Thu, 25 Jun 2026 at 12:58, Ahmet Sezgin Duran <ahmet@sezginduran.net> wrote:
>
> On 6/25/26 10:13 AM, suryasaimadhu wrote:
> > Make g_fbmode a constant pointer array by adding const qualifier
> > after the asterisk, as recommended by checkpatch.
> >
> > Signed-off-by: suryasaimadhu <suryasaimadhu369@gmail.com>
> > ---
> > drivers/staging/sm750fb/sm750.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
> > index 89c811e08..8f533f3b1 100644
> > --- a/drivers/staging/sm750fb/sm750.c
> > +++ b/drivers/staging/sm750fb/sm750.c
> > @@ -21,7 +21,7 @@
> > static int g_hwcursor = 1;
> > static int g_noaccel __ro_after_init;
> > static int g_nomtrr __ro_after_init;
> > -static const char *g_fbmode[] = {NULL, NULL};
> > +static const char * const g_fbmode[] = {NULL, NULL};
> > static const char *g_def_fbmode = "1024x768-32@60";
> > static char *g_settings;
> > static int g_dualview __ro_after_init;
>
> Did you compile this patch while sm750fb module is enabled?
>
> Regards,
> Ahmet Sezgin Duran
^ permalink raw reply
* Re: [PATCH] staging: sm750fb: make g_fbmode array const pointer const
From: Ahmet Sezgin Duran @ 2026-06-25 7:28 UTC (permalink / raw)
To: Shravya, sudipm.mukherjee, teddy.wang, gregkh
Cc: linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <20260624233907.67886-1-shravy112@gmail.com>
On 6/25/26 2:39 AM, Shravya wrote:
> Add the const qualifier to the g_fbmode array pointers to make
> the entire structure read-only. This resolves a checkpatch warning
> and allows the compiler to put the data into the read-only segment.
>
> Signed-off-by: Shravya <shravy112@gmail.com>
> ---
> drivers/staging/sm750fb/sm750.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
> index 89c811e0806c..8f533f3b1b42 100644
> --- a/drivers/staging/sm750fb/sm750.c
> +++ b/drivers/staging/sm750fb/sm750.c
> @@ -21,7 +21,7 @@
> static int g_hwcursor = 1;
> static int g_noaccel __ro_after_init;
> static int g_nomtrr __ro_after_init;
> -static const char *g_fbmode[] = {NULL, NULL};
> +static const char * const g_fbmode[] = {NULL, NULL};
> static const char *g_def_fbmode = "1024x768-32@60";
> static char *g_settings;
> static int g_dualview __ro_after_init;
Did you compile this patch while sm750fb module is enabled?
Regards,
Ahmet Sezgin Duran
^ permalink raw reply
* Re: [PATCH] staging: sm750fb: fix const pointer declaration
From: Ahmet Sezgin Duran @ 2026-06-25 7:27 UTC (permalink / raw)
To: suryasaimadhu, sudipm.mukherjee, teddy.wang
Cc: gregkh, linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <20260625071348.132880-1-suryasaimadhu369@gmail.com>
On 6/25/26 10:13 AM, suryasaimadhu wrote:
> Make g_fbmode a constant pointer array by adding const qualifier
> after the asterisk, as recommended by checkpatch.
>
> Signed-off-by: suryasaimadhu <suryasaimadhu369@gmail.com>
> ---
> drivers/staging/sm750fb/sm750.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
> index 89c811e08..8f533f3b1 100644
> --- a/drivers/staging/sm750fb/sm750.c
> +++ b/drivers/staging/sm750fb/sm750.c
> @@ -21,7 +21,7 @@
> static int g_hwcursor = 1;
> static int g_noaccel __ro_after_init;
> static int g_nomtrr __ro_after_init;
> -static const char *g_fbmode[] = {NULL, NULL};
> +static const char * const g_fbmode[] = {NULL, NULL};
> static const char *g_def_fbmode = "1024x768-32@60";
> static char *g_settings;
> static int g_dualview __ro_after_init;
Did you compile this patch while sm750fb module is enabled?
Regards,
Ahmet Sezgin Duran
^ permalink raw reply
* Re: [PATCH v5 07/14] mfd: lm3533: Use dev_groups in struct device_driver
From: Andy Shevchenko @ 2026-06-25 7:26 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <ajzXidQCd8pe-L5b@ashevche-desk.local>
On Thu, Jun 25, 2026 at 10:24:00AM +0300, Andy Shevchenko wrote:
> On Wed, Jun 17, 2026 at 11:00:24AM +0300, Svyatoslav Ryhel wrote:
...
> > .attrs = lm3533_attributes
> > };
> >
> > +static const struct attribute_group *lm3533_attribute_groups[] = {
> > + &lm3533_attribute_group,
> > + NULL,
> > +};
>
> We have ATTRIBUTE_GROUPS() macro.
Okay, it uses is_visible, so __ATTRIBUTE_GROUPS() that we can still use.
...
> > +++ b/drivers/video/backlight/lm3533_bl.c
>
> Same as per above.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v5 07/14] mfd: lm3533: Use dev_groups in struct device_driver
From: Andy Shevchenko @ 2026-06-25 7:23 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <20260617080031.99156-8-clamor95@gmail.com>
On Wed, Jun 17, 2026 at 11:00:24AM +0300, Svyatoslav Ryhel wrote:
> Instead of creating and removing the device sysfs attributes directly
> during probe and remove of the driver, respectively, use dev_groups in
> struct device_driver to point to the attribute definitions and let the
> core take care of creating and removing them.
>
> No intentional functional impact.
Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
And thanks for doing that!
...
> .attrs = lm3533_attributes
> };
>
> +static const struct attribute_group *lm3533_attribute_groups[] = {
> + &lm3533_attribute_group,
> + NULL,
> +};
We have ATTRIBUTE_GROUPS() macro.
...
> +++ b/drivers/video/backlight/lm3533_bl.c
Same as per above.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] staging: sm750fb: fix const pointer declaration
From: suryasaimadhu @ 2026-06-25 7:13 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang
Cc: gregkh, linux-fbdev, linux-staging, linux-kernel, suryasaimadhu
Make g_fbmode a constant pointer array by adding const qualifier
after the asterisk, as recommended by checkpatch.
Signed-off-by: suryasaimadhu <suryasaimadhu369@gmail.com>
---
drivers/staging/sm750fb/sm750.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 89c811e08..8f533f3b1 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -21,7 +21,7 @@
static int g_hwcursor = 1;
static int g_noaccel __ro_after_init;
static int g_nomtrr __ro_after_init;
-static const char *g_fbmode[] = {NULL, NULL};
+static const char * const g_fbmode[] = {NULL, NULL};
static const char *g_def_fbmode = "1024x768-32@60";
static char *g_settings;
static int g_dualview __ro_after_init;
--
2.47.3
^ permalink raw reply related
* [PATCH v2] firmware: sysfb: Mark CONFIG_SYSFB_SIMPLEFB as deprecated
From: Thomas Zimmermann @ 2026-06-25 6:57 UTC (permalink / raw)
To: javierm, julianbraha, sima, airlied
Cc: dri-devel, linux-fbdev, linux-kernel, sashiko-reviews,
Thomas Zimmermann
Mark CONFIG_SYSFB_SIMPLEFB as deprecated. Enabling it allows to
run simpledrm and simplefb on EFI/VESA framebuffers. Doing this
is discouraged in favor of using efidrm and vesadrm.
v2:
- resolve conflicting help texts (Sashiko)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
---
drivers/firmware/Kconfig | 32 ++++++++++----------------------
drivers/gpu/drm/sysfb/Kconfig | 7 ++-----
2 files changed, 12 insertions(+), 27 deletions(-)
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index bbd2155d8483..637e3bb5549e 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -184,32 +184,20 @@ config SYSFB
select SCREEN_INFO
config SYSFB_SIMPLEFB
- bool "Mark VGA/VBE/EFI FB as generic system framebuffer"
+ bool "Mark VGA/VBE/EFI FB as generic system framebuffer (deprecated)"
depends on X86 || EFI
select SYSFB
help
- Firmwares often provide initial graphics framebuffers so the BIOS,
+ Firmware often provides initial graphics framebuffers so the BIOS,
bootloader or kernel can show basic video-output during boot for
- user-guidance and debugging. Historically, x86 used the VESA BIOS
- Extensions and EFI-framebuffers for this, which are mostly limited
- to x86 BIOS or EFI systems.
- This option, if enabled, marks VGA/VBE/EFI framebuffers as generic
- framebuffers so the new generic system-framebuffer drivers can be
- used instead. If the framebuffer is not compatible with the generic
- modes, it is advertised as fallback platform framebuffer so legacy
- drivers like efifb, vesafb and uvesafb can pick it up.
- If this option is not selected, all system framebuffers are always
- marked as fallback platform framebuffers as usual.
-
- Note: Legacy fbdev drivers, including vesafb, efifb, uvesafb, will
- not be able to pick up generic system framebuffers if this option
- is selected. You are highly encouraged to enable simplefb as
- replacement if you select this option. simplefb can correctly deal
- with generic system framebuffers. But you should still keep vesafb
- and others enabled as fallback if a system framebuffer is
- incompatible with simplefb.
-
- If unsure, say Y.
+ user-guidance and debugging.
+
+ This option, if enabled, marks VBE/EFI framebuffers as system
+ framebuffers so the generic simpledrm driver can be used.
+
+ This option is deprecated and will be removed in the near future. If
+ unsure, say N and select efidrm, vesadrm instead. The dedicated DRM
+ drivers provide the same functionality plus additional features.
config TH1520_AON_PROTOCOL
tristate "Always-On firmware protocol"
diff --git a/drivers/gpu/drm/sysfb/Kconfig b/drivers/gpu/drm/sysfb/Kconfig
index 2559ead6cf1f..f7e48178885e 100644
--- a/drivers/gpu/drm/sysfb/Kconfig
+++ b/drivers/gpu/drm/sysfb/Kconfig
@@ -67,11 +67,8 @@ config DRM_SIMPLEDRM
This driver assumes that the display hardware has been initialized
by the firmware or bootloader before the kernel boots. Scanout
- buffer, size, and display format must be provided via device tree,
- UEFI, VESA, etc.
-
- On x86 BIOS or UEFI systems, you should also select SYSFB_SIMPLEFB
- to use UEFI and VESA framebuffers.
+ buffer, size, and display format must be provided via device tree's
+ simple-framebuffer node.
config DRM_VESADRM
tristate "VESA framebuffer driver"
--
2.54.0
^ permalink raw reply related
* [PATCH] fbdev: Fix fb_new_modelist to prevent null-ptr-deref in fb_videomode_to_var
From: Ian Bridges @ 2026-06-25 4:13 UTC (permalink / raw)
To: Simona Vetter, Helge Deller, linux-fbdev, dri-devel, linux-kernel
info->var, a framebuffer's current mode, is expected to have a matching
entry in info->modelist. var_to_display() relies on this and treats a
failed fb_match_mode() as "This should not happen". fb_set_var() keeps it
true by adding the mode to the list on every change, and
do_register_framebuffer() does the same at registration.
store_modes() replaces the modelist from userspace. fb_new_modelist()
validates the new modes but does not check that info->var still has a
match. It relies on fbcon_new_modelist() to re-point consoles, but that
only handles consoles mapped to the framebuffer. With fbcon unbound there
are none, so info->var is left describing a mode that is no longer in the
list.
A later console takeover runs var_to_display(), where fb_match_mode()
returns NULL and leaves fb_display[i].mode NULL. fbcon_switch() passes it
to display_to_var(), and fb_videomode_to_var() dereferences the NULL mode.
Keep the current mode in the list in fb_new_modelist(), the same way
fb_set_var() does.
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Ian Bridges <icb@fastmail.org>
---
This patch fixes a NULL pointer dereference in fb_videomode_to_var(), reached
through the framebuffer console. The fix is in fb_new_modelist(). Sashiko
flagged this dereference while reviewing the fix for a separate NULL pointer
dereference in fbcon_new_modelist() [1].
The dereference happens when a framebuffer's current mode is dropped from its
modelist while fbcon is unbound, and a console is then taken over onto it, as
follows.
1. With fbcon unbound, a write to the modes attribute calls store_modes()
(fbsysfs.c:91), which replaces the modelist and calls fb_new_modelist()
(fbsysfs.c:108). fb_new_modelist() (fbmem.c:746) validates the new modes but
does not keep info->var in the list, and the fbcon_new_modelist() it calls
(fbmem.c:770) only re-points consoles mapped to the framebuffer. With fbcon
unbound there are none, so info->var is left describing a mode no longer in
the list.
2. Mapping a console with FBIOPUT_CON2FBMAP takes the framebuffer over,
set_con2fb_map() -> do_fbcon_takeover() (fbcon.c:930).
3. The takeover initialises the console, fbcon_init() -> var_to_display()
(fbcon.c:1113). fb_match_mode() finds no entry for info->var, so
var_to_display() leaves fb_display[i].mode NULL (fbcon.c:988).
4. The takeover switches to the console, fbcon_switch() -> display_to_var()
(fbcon.c:2181), and fb_videomode_to_var() reads the NULL mode
(modedb.c:905). This is a NULL pointer dereference.
The faulting line is not touched by this patch:
var->xres = mode->xres;
mode is the fb_display[i].mode passed by display_to_var(). Instead of guarding
this read, the patch keeps info->var in the modelist in fb_new_modelist(),
so the mode is never NULL here.
The same dereference, fb_videomode_to_var() on a NULL mode, was fixed twice
before, by CVE-2025-38214 in fb_set_var() and CVE-2025-38215 in
do_register_framebuffer(). Both keep info->var in the modelist, and both are
already in this base. This bug reaches the same line through a different
path, a modelist replacement, and this fix keeps info->var in the list
the same way.
It reproduces on a KASAN kernel with two framebuffers:
1. Unbind fbcon, so the store in step 3 does not re-sync the mode.
2. Set a video mode on fb0 with FBIOPUT_VSCREENINFO.
3. Write a different modelist to /sys/class/graphics/fb0/modes, so the mode
from step 2 is no longer in the modelist.
4. Map a console to fb0 with FBIOPUT_CON2FBMAP. With fbcon unbound this takes
fb0 over, sets the console mode to NULL (the mode is not in the modelist),
and switches to the console.
The reproducer was written with the help of a coding agent (Claude Code). The
patch is against commit 3726ce7f6cef on the for-next branch of
git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git. The
file offsets above are from that commit. The defect is present in the initial
2.6.12-rc2 import, so there is no Fixes tag.
[1] https://lore.kernel.org/all/20260624213027.6C1E01F000E9@smtp.kernel.org/
drivers/video/fbdev/core/fbmem.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index e5221653ec2b..2f1c56e5a7a2 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -767,6 +767,18 @@ int fb_new_modelist(struct fb_info *info)
if (list_empty(&info->modelist))
return 1;
+ /*
+ * The new modelist may not contain the current mode (info->var), and
+ * fbcon_new_modelist() below only re-points consoles mapped to this
+ * framebuffer. Add the current mode here so info->var keeps a match
+ * even when fbcon is unbound.
+ */
+ if (!fb_match_mode(&info->var, &info->modelist)) {
+ fb_var_to_videomode(&mode, &info->var);
+ if (fb_add_videomode(&mode, &info->modelist))
+ return 1;
+ }
+
fbcon_new_modelist(info);
return 0;
--
2.47.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox