kernel/git/stable/linux.git/drivers/misc/ibmasm, branch master

misc: ibmasm: Remove obsolete IBM Remote Supervisor Adapter driver

2026-08-06T09:12:07+00:00

The IBM Remote Supervisor Adapter (RSA) and RSA II were out-of-band management PCI/ISA cards introduced in the early 2000s for ancient IBM eServer xSeries machines. IBM deprecated the RSA family and replaced it with the Integrated Management Module (IMM) around 2008. IBM subsequently sold its x86 server business to Lenovo in 2014, and modern systems use entirely different BMC architectures. This hardware has been completely obsolete and out of production for over 15 years. Surviving physical servers using this specific hardware would be running ancient 32-bit processors vastly unsuited for modern kernels. A review of the recent git history shows that aside from mechanical treewide VFS API updates, the only recent activities are out-of-bounds fixes in command_file_write and MFA handling. These fixes address userspace-triggered security vulnerabilities and fuzzer-discovered MMIO bugs rather than functional issues reported by active hardware users. Keeping this obsolete driver in the tree leaves an unnecessary attack surface and acts as a "fuzzing honeypot", forcing core maintainers to endlessly review CVEs and OOB fixes for dead hardware, while also paying a maintenance tax to drag it through modern API refactorings. Remove the driver entirely. Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn> Acked-by: Arnd Bergmann Link: https://patch.msgid.link/20260801070756.161698-1-25181214217@stu.xidian.edu.cn Signed-off-by: Greg Kroah-Hartman

misc: Unify code style for various *_device_id arrays

2026-07-31T12:20:50+00:00

- Add a trailing comma for initializers unless the closing brace is on the same line and for the list terminator; - Use a single space in the list terminator; - A space after an opening { and before a closing }; - Use the PCI_DEVICE* macro in two drivers for pci_device_id entry which is usual for these arrays - No explicit zeros in the list terminator; None of these changes introduces changes to the compiled result. Signed-off-by: Uwe Kleine-König (The Capable Hub) Acked-by: Michał Mirosław Link: https://patch.msgid.link/583653bc7b9ae19707bc28be69a20e66b8c3720a.1784299069.git.u.kleine-koenig@baylibre.com Signed-off-by: Greg Kroah-Hartman

misc: ibmasm: add parentheses around sizeof operand

2026-07-17T13:49:48+00:00

sizeof used without parentheses around its operand on two occasions in r_heartbeat.c. Add them to comply with the kernel coding style. Signed-off-by: Batu Ada Tutkun Link: https://patch.msgid.link/20260622201633.2577-1-batuadatutkun@gmail.com Signed-off-by: Greg Kroah-Hartman

ibmasm: fix heap over-read in ibmasm_send_i2o_message()

2026-04-02T14:31:02+00:00

The ibmasm_send_i2o_message() function uses get_dot_command_size() to compute the byte count for memcpy_toio(), but this value is derived from user-controlled fields in the dot_command_header (command_size: u8, data_size: u16) and is never validated against the actual allocation size. A root user can write a small buffer with inflated header fields, causing memcpy_toio() to read up to ~65 KB past the end of the allocation into adjacent kernel heap, which is then forwarded to the service processor over MMIO. Silently clamping the copy size is not sufficient: if the header fields claim a larger size than the buffer, the SP receives a dot command whose own header is inconsistent with the I2O message length, which can cause the SP to desynchronize. Reject such commands outright by returning failure. Validate command_size before calling get_mfa_inbound() to avoid leaking an I2O message frame: reading INBOUND_QUEUE_PORT dequeues a hardware frame from the controller's free pool, and returning without a corresponding set_mfa_inbound() call would permanently exhaust it. Additionally, clamp command_size to I2O_COMMAND_SIZE before the memcpy_toio() so the MMIO write stays within the I2O message frame, consistent with the clamping already performed by outgoing_message_size() for the header field. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Yuhao Jiang Cc: stable@vger.kernel.org Signed-off-by: Tyllis Xu Link: https://patch.msgid.link/20260314165805.548293-1-LivelyCarpet87@gmail.com Signed-off-by: Greg Kroah-Hartman

ibmasm: fix OOB reads in command_file_write due to missing size checks

2026-04-02T14:30:53+00:00

The command_file_write() handler allocates a kernel buffer of exactly count bytes and copies user data into it, but does not validate the buffer against the dot command protocol before passing it to get_dot_command_size() and get_dot_command_timeout(). Since both the allocation size (count) and the header fields (command_size, data_size) are independently user-controlled, an attacker can cause get_dot_command_size() to return a value exceeding the allocation, triggering OOB reads in get_dot_command_timeout() and an out-of-bounds memcpy_toio() that leaks kernel heap memory to the service processor. Fix with two guards: reject writes smaller than sizeof(struct dot_command_header) before allocation, then after copying user data reject commands where the buffer is smaller than the total size declared by the header (sizeof(header) + command_size + data_size). This ensures all subsequent header and payload field accesses stay within the buffer. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Yuhao Jiang Cc: stable@vger.kernel.org Signed-off-by: Tyllis Xu Link: https://patch.msgid.link/20260314165355.548119-1-LivelyCarpet87@gmail.com Signed-off-by: Greg Kroah-Hartman

misc: ibmasm: fix OOB MMIO read in ibmasm_handle_mouse_interrupt()

2026-04-02T14:30:42+00:00

ibmasm_handle_mouse_interrupt() performs an out-of-bounds MMIO read when the queue reader or writer index from hardware exceeds REMOTE_QUEUE_SIZE (60). A compromised service processor can trigger this by writing an out-of-range value to the reader or writer MMIO register before asserting an interrupt. Since writer is re-read from hardware on every loop iteration, it can also be set to an out-of-range value after the loop has already started. The root cause is that get_queue_reader() and get_queue_writer() return raw readl() values that are passed directly into get_queue_entry(), which computes: queue_begin + reader * sizeof(struct remote_input) with no bounds check. This unchecked MMIO address is then passed to memcpy_fromio(), reading 8 bytes from unintended device registers. For sufficiently large values the address falls outside the PCI BAR mapping entirely, triggering a machine check exception. Fix by checking both indices against REMOTE_QUEUE_SIZE at the top of the loop body, before any call to get_queue_entry(). On an out-of-range value, reset the reader register to 0 via set_queue_reader() before breaking, so that normal queue operation can resume if the corrupted hardware state is transient. Reported-by: Yuhao Jiang Fixes: 278d72ae8803 ("[PATCH] ibmasm driver: redesign handling of remote control events") Cc: stable@vger.kernel.org Cc: ychen@northwestern.edu Signed-off-by: Tyllis Xu Link: https://patch.msgid.link/20260308062108.258940-1-LivelyCarpet87@gmail.com Signed-off-by: Greg Kroah-Hartman

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

ibmasmfs: get rid of ibmasmfs_dir_ops

2025-11-16T06:35:04+00:00

it is always equal (and always had been equal) to &simple_dir_operations Signed-off-by: Al Viro

convert ibmasmfs

2025-11-16T06:35:04+00:00

static contents for each "service processor", whatever the fuck it is. Congruent subdirectories of root, created at mount time, taken out by kill_litter_super(). All dentries created with d_alloc_name() and are left pinned. The odd part is that the list of service providers is assumed to be unchanging - no locking, nothing to handle removals or extra elements added later on. ... and it's a PCI device. If you ever tell it to remove an instance, you are fucked - it doesn't bother with removing its directory from filesystem, it has a strange check that presumably wanted to be a check for removed devices, but it had never been fleshed out. Anyway, d_add() -> d_make_persistent()+dput() in ibmasmfs_create_dir() and ibmasmfs_create_file(), and make the latter return int - no need to even borrow that dentry, callers completely ignore it. Signed-off-by: Al Viro