From a5f7a5bb3b7f28ba7e4fa246775b29a0e5537255 Mon Sep 17 00:00:00 2001 From: Jinke Han Date: Tue, 8 Sep 2026 15:37:42 +0800 Subject: x86/kprobes: Fix crash when probing CS CALL instructions When using eBPF to probe CS CALL instructions within a function, a crash can be triggered. The eBPF tool probes offset 257 of the __hrtimer_run_queues() function: <__hrtimer_run_queues+249>: nopl 0x0(%rax,%rax,1) <__hrtimer_run_queues+254>: mov %r14,%rdi <__hrtimer_run_queues+257>: cs call <__x86_indirect_thunk_r12> <__hrtimer_run_queues+263>: mov %eax,%r12d <__hrtimer_run_queues+266>: xchg %ax,%ax <__hrtimer_run_queues+268>: mov %r13,%rdi Which triggers this crash: BUG: unable to handle page fault for address: 00000000000f41c9 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: P RIP: 0010:__hrtimer_run_queues+0x106/0x230 Note that __hrtimer_run_queues+0x106 is __hrtimer_run_queues+262, which is at the 6th byte of the above CS CALL instruction. Since the CS CALL instruction occupies 6 bytes, the exception occurred in the middle of that call instruction. The root cause is that when using eBPF tools to probe in the middle of a function, a kprobe with INT3 is used as the underlying implementation. During single-step emulation of the original CALL instruction, int3_emulate_call() assumes that the probed CALL instruction is 5 bytes long. However, the actual CS-prefixed CALL instruction occupies 6 bytes, so it constructs an incorrect exception return address. When the CPU returns from the kprobe handler, the next instruction to be executed is at the address of the last byte of that CS CALL instruction. Coincidentally, starting from that address, the CPU fetches and decodes a completely different instruction, which ultimately triggers a kernel crash. Fix the issue by using the actual instruction length obtained from the instruction decoder when constructing the exception return address, rather than relying on the hardcoded CALL_INSN_SIZE macro. [ mingo: Refined the changelog ] Fixes: 6256e668b7af ("x86/kprobes: Use int3 instead of debug trap for single-step") Suggested-by: Masami Hiramatsu (Google) Signed-off-by: Jinke Han Signed-off-by: Ingo Molnar Reviewed-by: Masami Hiramatsu (Google) Acked-by: Yafang Shao Acked-by: Borislav Petkov Cc: Peter Zijlstra Link: https://patch.msgid.link/20260908073742.GA10517@didi-ThinkCentre-M920t-N000 --- drivers/video/fbdev/sa1100fb.c | 1226 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1226 insertions(+) create mode 100644 drivers/video/fbdev/sa1100fb.c (limited to 'drivers/video/fbdev/sa1100fb.c') diff --git a/drivers/video/fbdev/sa1100fb.c b/drivers/video/fbdev/sa1100fb.c new file mode 100644 index 000000000..fea0172c4 --- /dev/null +++ b/drivers/video/fbdev/sa1100fb.c @@ -0,0 +1,1226 @@ +/* + * linux/drivers/video/sa1100fb.c + * + * Copyright (C) 1999 Eric A. Thomas + * Based on acornfb.c Copyright (C) Russell King. + * + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file COPYING in the main directory of this archive for + * more details. + * + * StrongARM 1100 LCD Controller Frame Buffer Driver + * + * Please direct your questions and comments on this driver to the following + * email address: + * + * linux-arm-kernel@lists.arm.linux.org.uk + * + * Clean patches should be sent to the ARM Linux Patch System. Please see the + * following web page for more information: + * + * https://www.arm.linux.org.uk/developer/patches/info.shtml + * + * Thank you. + * + * Known problems: + * - With the Neponset plugged into an Assabet, LCD powerdown + * doesn't work (LCD stays powered up). Therefore we shouldn't + * blank the screen. + * - We don't limit the CPU clock rate nor the mode selection + * according to the available SDRAM bandwidth. + * + * Other notes: + * - Linear grayscale palettes and the kernel. + * Such code does not belong in the kernel. The kernel frame buffer + * drivers do not expect a linear colourmap, but a colourmap based on + * the VT100 standard mapping. + * + * If your _userspace_ requires a linear colourmap, then the setup of + * such a colourmap belongs _in userspace_, not in the kernel. Code + * to set the colourmap correctly from user space has been sent to + * David Neuer. It's around 8 lines of C code, plus another 4 to + * detect if we are using grayscale. + * + * - The following must never be specified in a panel definition: + * LCCR0_LtlEnd, LCCR3_PixClkDiv, LCCR3_VrtSnchL, LCCR3_HorSnchL + * + * - The following should be specified: + * either LCCR0_Color or LCCR0_Mono + * either LCCR0_Sngl or LCCR0_Dual + * either LCCR0_Act or LCCR0_Pas + * either LCCR3_OutEnH or LCCD3_OutEnL + * either LCCR3_PixRsEdg or LCCR3_PixFlEdg + * either LCCR3_ACBsDiv or LCCR3_ACBsCntOff + * + * Code Status: + * 1999/04/01: + * - Driver appears to be working for Brutus 320x200x8bpp mode. Other + * resolutions are working, but only the 8bpp mode is supported. + * Changes need to be made to the palette encode and decode routines + * to support 4 and 16 bpp modes. + * Driver is not designed to be a module. The FrameBuffer is statically + * allocated since dynamic allocation of a 300k buffer cannot be + * guaranteed. + * + * 1999/06/17: + * - FrameBuffer memory is now allocated at run-time when the + * driver is initialized. + * + * 2000/04/10: Nicolas Pitre + * - Big cleanup for dynamic selection of machine type at run time. + * + * 2000/07/19: Jamey Hicks + * - Support for Bitsy aka Compaq iPAQ H3600 added. + * + * 2000/08/07: Tak-Shing Chan + * Jeff Sutherland + * - Resolved an issue caused by a change made to the Assabet's PLD + * earlier this year which broke the framebuffer driver for newer + * Phase 4 Assabets. Some other parameters were changed to optimize + * for the Sharp display. + * + * 2000/08/09: Kunihiko IMAI + * - XP860 support added + * + * 2000/08/19: Mark Huang + * - Allows standard options to be passed on the kernel command line + * for most common passive displays. + * + * 2000/08/29: + * - s/save_flags_cli/local_irq_save/ + * - remove unneeded extra save_flags_cli in sa1100fb_enable_lcd_controller + * + * 2000/10/10: Erik Mouw + * - Updated LART stuff. Fixed some minor bugs. + * + * 2000/10/30: Murphy Chen + * - Pangolin support added + * + * 2000/10/31: Roman Jordan + * - Huw Webpanel support added + * + * 2000/11/23: Eric Peng + * - Freebird add + * + * 2001/02/07: Jamey Hicks + * Cliff Brake + * - Added PM callback + * + * 2001/05/26: + * - Fix 16bpp so that (a) we use the right colours rather than some + * totally random colour depending on what was in page 0, and (b) + * we don't de-reference a NULL pointer. + * - remove duplicated implementation of consistent_alloc() + * - convert dma address types to dma_addr_t + * - remove unused 'montype' stuff + * - remove redundant zero inits of init_var after the initial + * memset. + * - remove allow_modeset (acornfb idea does not belong here) + * + * 2001/05/28: + * - massive cleanup - move machine dependent data into structures + * - I've left various #warnings in - if you see one, and know + * the hardware concerned, please get in contact with me. + * + * 2001/05/31: + * - Fix LCCR1 HSW value, fix all machine type specifications to + * keep values in line. (Please check your machine type specs) + * + * 2001/06/10: + * - Fiddle with the LCD controller from task context only; mainly + * so that we can run with interrupts on, and sleep. + * - Convert #warnings into #errors. No pain, no gain. ;) + * + * 2001/06/14: + * - Make the palette BPS value for 12bpp come out correctly. + * - Take notice of "greyscale" on any colour depth. + * - Make truecolor visuals use the RGB channel encoding information. + * + * 2001/07/02: + * - Fix colourmap problems. + * + * 2001/07/13: + * - Added support for the ICP LCD-Kit01 on LART. This LCD is + * manufactured by Prime View, model no V16C6448AB + * + * 2001/07/23: + * - Hand merge version from handhelds.org CVS tree. See patch + * notes for 595/1 for more information. + * - Drop 12bpp (it's 16bpp with different colour register mappings). + * - This hardware can not do direct colour. Therefore we don't + * support it. + * + * 2001/07/27: + * - Halve YRES on dual scan LCDs. + * + * 2001/08/22: + * - Add b/w iPAQ pixclock value. + * + * 2001/10/12: + * - Add patch 681/1 and clean up stork definitions. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include