[LTS 9.2] CVE-2023-5633 #211
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Closed
github-actions bot
pushed a commit
that referenced
this pull request
Sep 7, 2025
JIRA: https://issues.redhat.com/browse/RHEL-102691 commit 0370fb1 Author: Sudeep Holla <[email protected]> Date: Thu, 18 Apr 2024 11:29:32 +0100 If the firmware returns incorrect SRI/NRI number, we fail to set it up in the kernel which is absolutely fine. However, we don't reset the stashed value of sched_recv or notif_pend IRQs. When we call ffa_notifications_cleanup() in case of failures to setup the notifications, we end up calling free_percpu_irq() from ffa_uninit_pcpu_irq() which results in the following warning: | genirq: Flags mismatch irq 6. 00004401 (ARM-FFA-NPI) vs. 00004400 (IPI) | ARM FF-A: Error registering percpu NPI nIRQ 6 : -16 | ARM FF-A: Notification setup failed -16, not enabled | ------------[ cut here ]------------ | Trying to free already-free IRQ 6 | WARNING: CPU: 2 PID: 1 at kernel/irq/manage.c:2476 __free_percpu_irq+0x6c/0x138 | Modules linked in: | CPU: 2 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc3 #211 | Hardware name: FVP Base RevC (DT) | pstate: 614000c9 (nZCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--) | pc : __free_percpu_irq+0x6c/0x138 | lr : __free_percpu_irq+0x6c/0x138 | Call trace: | __free_percpu_irq+0x6c/0x138 | free_percpu_irq+0x48/0x84 | ffa_notifications_cleanup+0x78/0x164 | ffa_notifications_setup+0x368/0x3c0 | ffa_init+0x2b4/0x36c | do_one_initcall+0xe0/0x258 | do_initcall_level+0x8c/0xac | do_initcalls+0x54/0x94 | do_basic_setup+0x1c/0x28 | kernel_init_freeable+0x108/0x174 | kernel_init+0x20/0x1a4 | ret_from_fork+0x10/0x20 Fix the same by resetting the stashed copy of IRQ values to 0 in case of any failure to set them up properly. Cc: Jens Wiklander <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sudeep Holla <[email protected]> Signed-off-by: Marcin Juszkiewicz <[email protected]>
github-actions bot
pushed a commit
that referenced
this pull request
Oct 12, 2025
The way tracing_mark_raw_write() records its data is that it has the
following structure:
struct {
struct trace_entry;
int id;
char buf[];
};
But memcpy(&entry->id, buf, size) triggers the following warning when the
size is greater than the id:
------------[ cut here ]------------
memcpy: detected field-spanning write (size 6) of single field "&entry->id" at kernel/trace/trace.c:7458 (size 4)
WARNING: CPU: 7 PID: 995 at kernel/trace/trace.c:7458 write_raw_marker_to_buffer.isra.0+0x1f9/0x2e0
Modules linked in:
CPU: 7 UID: 0 PID: 995 Comm: bash Not tainted 6.17.0-test-00007-g60b82183e78a-dirty #211 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014
RIP: 0010:write_raw_marker_to_buffer.isra.0+0x1f9/0x2e0
Code: 04 00 75 a7 b9 04 00 00 00 48 89 de 48 89 04 24 48 c7 c2 e0 b1 d1 b2 48 c7 c7 40 b2 d1 b2 c6 05 2d 88 6a 04 01 e8 f7 e8 bd ff <0f> 0b 48 8b 04 24 e9 76 ff ff ff 49 8d 7c 24 04 49 8d 5c 24 08 48
RSP: 0018:ffff888104c3fc78 EFLAGS: 00010292
RAX: 0000000000000000 RBX: 0000000000000006 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 1ffffffff6b363b4 RDI: 0000000000000001
RBP: ffff888100058a00 R08: ffffffffb041d459 R09: ffffed1020987f40
R10: 0000000000000007 R11: 0000000000000001 R12: ffff888100bb9010
R13: 0000000000000000 R14: 00000000000003e3 R15: ffff888134800000
FS: 00007fa61d286740(0000) GS:ffff888286cad000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000560d28d509f1 CR3: 00000001047a4006 CR4: 0000000000172ef0
Call Trace:
<TASK>
tracing_mark_raw_write+0x1fe/0x290
? __pfx_tracing_mark_raw_write+0x10/0x10
? security_file_permission+0x50/0xf0
? rw_verify_area+0x6f/0x4b0
vfs_write+0x1d8/0xdd0
? __pfx_vfs_write+0x10/0x10
? __pfx_css_rstat_updated+0x10/0x10
? count_memcg_events+0xd9/0x410
? fdget_pos+0x53/0x5e0
ksys_write+0x182/0x200
? __pfx_ksys_write+0x10/0x10
? do_user_addr_fault+0x4af/0xa30
do_syscall_64+0x63/0x350
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7fa61d318687
Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff
RSP: 002b:00007ffd87fe0120 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007fa61d286740 RCX: 00007fa61d318687
RDX: 0000000000000006 RSI: 0000560d28d509f0 RDI: 0000000000000001
RBP: 0000560d28d509f0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000006
R13: 00007fa61d4715c0 R14: 00007fa61d46ee80 R15: 0000000000000000
</TASK>
---[ end trace 0000000000000000 ]---
This is because fortify string sees that the size of entry->id is only 4
bytes, but it is writing more than that. But this is OK as the
dynamic_array is allocated to handle that copy.
The size allocated on the ring buffer was actually a bit too big:
size = sizeof(*entry) + cnt;
But cnt includes the 'id' and the buffer data, so adding cnt to the size
of *entry actually allocates too much on the ring buffer.
Change the allocation to:
size = struct_size(entry, buf, cnt - sizeof(entry->id));
and the memcpy() to unsafe_memcpy() with an added justification.
Cc: [email protected]
Cc: Masami Hiramatsu <[email protected]>
Cc: Mathieu Desnoyers <[email protected]>
Cc: Andrew Morton <[email protected]>
Link: https://lore.kernel.org/[email protected]
Fixes: 64cf7d0 ("tracing: Have trace_marker use per-cpu data to read user space")
Reported-by: [email protected]
Closes: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Steven Rostedt (Google) <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
[LTS 9.2]
CVE-2023-5633
VULN-8161
Problem
https://www.cve.org/CVERecord?id=CVE-2023-5633
Analysis and solution
Official fix
Following https://bugzilla.redhat.com/show_bug.cgi?id=2245663
the official solution for mainline kernel is contained in the 91398b4 commit.
Applicability analysis
The buggy commit 9ef8d83 being the source of CVE-2023-5633, fixed by 91398b4, was itself a fix of a buggy commit 8afa13a with associated additional CVE-2023-33951 and CVE-2023-33952. The following table summarizes the relations between all commits involved in the problem, hopefully clarifying the issue
The files associated with each of these commits, as would be listed by
can be gathered in the following table, defining the changes domain.
The recent history of the changes to these files is
Consider the history of the same files in the
ciqlts9_4versionThe chronology of
ciqlts9_4fully contains that ofciqlts9_2, at the same time containing all three of the commits in the problem chain (or their backport equivalents):Summary and discussion
The fix for CVE-2023-5633 is contained in the commit which is not even present in the Rocky version 9.2. This may or may not mean that the vulnerability doesn't apply.
At the same time the investigation found CVE-2023-33951 and CVE-2023-33952 which definitely are applicable to Rocky 9.2, and the potential fix for CVE-2023-5633 would have to include the fix for them anyway, suggesting the broadening of scope for the vulnerability remedition. On the other hand the amount of changes is high and the commits don't seem to isolate specific problems well, risking the broadening of scope even further, to the point of equalizing the drivers/gpu/drm/vmwgfx driver's version with that contained in Rocky 9.4. The difficulty of testing changes in this driver should also be considered.