[rocky10_2] History Rebuild through kernel-6.12.0-211.43.1.el10_2 - #1509
Merged
Conversation
jira KERNEL-1416 cve CVE-2026-31676 Rebuild_History Non-Buildable kernel-6.12.0-211.40.1.el10_2 commit-author Wang Jie <jiewang2024@lzu.edu.cn> commit c43ffdc Only process RESPONSE packets while the service connection is still in RXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock before running response verification and security initialization, then use a local secured flag to decide whether to queue the secured-connection work after the state transition. This keeps duplicate or late RESPONSE packets from re-running the setup path and removes the unlocked post-transition state test. Fixes: 17926a7 ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both") Reported-by: Yifan Wu <yifanwucs@gmail.com> Reported-by: Juefei Pu <tomapufckgml@gmail.com> Co-developed-by: Yuan Tan <yuantan098@gmail.com> Signed-off-by: Yuan Tan <yuantan098@gmail.com> Suggested-by: Xin Liu <bird@lzu.edu.cn> Signed-off-by: Jie Wang <jiewang2024@lzu.edu.cn> Signed-off-by: Yang Yang <n05ec@lzu.edu.cn> Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: Jeffrey Altman <jaltman@auristor.com> cc: Simon Horman <horms@kernel.org> cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260408121252.2249051-21-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit c43ffdc) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.40.1.el10_2 commit-author David Howells <dhowells@redhat.com> commit 24481a7 The security operations that verify the RESPONSE packets decrypt bits of it in place - however, the sk_buff may be shared with a packet sniffer, which would lead to the sniffer seeing an apparently corrupt packet (actually decrypted). Fix this by handing a copy of the packet off to the specific security handler if the packet was cloned. Fixes: 17926a7 ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both") Closes: https://sashiko.dev/#/patchset/20260408121252.2249051-1-dhowells%40redhat.com Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: Jeffrey Altman <jaltman@auristor.com> cc: Simon Horman <horms@kernel.org> cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260422161438.2593376-5-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 24481a7) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 cve CVE-2026-43500 Rebuild_History Non-Buildable kernel-6.12.0-211.40.1.el10_2 commit-author Hyunwoo Kim <imv4bel@gmail.com> commit aa54b1d The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE handler in rxrpc_verify_response() copy the skb to a linear one before calling into the security ops only when skb_cloned() is true. An skb that is not cloned but still carries externally-owned paged fragments (e.g. SKBFL_SHARED_FRAG set by splice() into a UDP socket via __ip_append_data, or a chained skb_has_frag_list()) falls through to the in-place decryption path, which binds the frag pages directly into the AEAD/skcipher SGL via skb_to_sgvec(). Extend the gate to also unshare when skb_has_frag_list() or skb_has_shared_frag() is true. This catches the splice-loopback vector and other externally-shared frag sources while preserving the zero-copy fast path for skbs whose frags are kernel-private (e.g. NIC page_pool RX, GRO). The OOM/trace handling already in place is reused. Fixes: d0d5c0c ("rxrpc: Use skb_unshare() rather than skb_cow_data()") Cc: stable@vger.kernel.org Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com> Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev> Acked-by: David Howells <dhowells@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit aa54b1d) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.40.1.el10_2 commit-author David Howells <dhowells@redhat.com> commit f93af41 Add error checking for failure of crypto_skcipher_en/decrypt() to various rxkad function as the crypto functions can fail with ENOMEM at least. Fixes: 17926a7 ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both") Closes: https://sashiko.dev/#/patchset/20260401105614.1696001-10-dhowells@redhat.com Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: Jeffrey Altman <jaltman@auristor.com> cc: Simon Horman <horms@kernel.org> cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260408121252.2249051-17-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit f93af41) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.40.1.el10_2 commit-author David Howells <dhowells@redhat.com> commit 34f61a0 Fix rxkad_verify_response() to free the ticket and the server key under all circumstances by initialising the ticket pointer to NULL and then making all paths through the function after the first allocation has been done go through a single common epilogue that just releases everything - where all the releases skip on a NULL pointer. Fixes: 57af281 ("rxrpc: Tidy up abort generation infrastructure") Fixes: ec832bd ("rxrpc: Don't retain the server key in the connection") Closes: https://sashiko.dev/#/patchset/20260408121252.2249051-1-dhowells%40redhat.com Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: Jeffrey Altman <jaltman@auristor.com> cc: Simon Horman <horms@kernel.org> cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260422161438.2593376-2-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 34f61a0) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.40.1.el10_2 commit-author David Howells <dhowells@redhat.com> commit def304a Fix handling of a packet with a misaligned crypto length. Also handle non-ENOMEM errors from decryption by aborting. Further, remove the WARN_ON_ONCE() so that it can't be remotely triggered (a trace line can still be emitted). Fixes: f93af41 ("rxrpc: Fix missing error checks for rxkad encryption/decryption failure") Closes: https://sashiko.dev/#/patchset/20260408121252.2249051-1-dhowells%40redhat.com Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: Jeffrey Altman <jaltman@auristor.com> cc: Simon Horman <horms@kernel.org> cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260422161438.2593376-3-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit def304a) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.40.1.el10_2 commit-author David Howells <dhowells@redhat.com> commit 6929350 Fix potential integer overflow in rxgk_extract_token() when checking the length of the ticket. Rather than rounding up the value to be tested (which might overflow), round down the size of the available data. Fixes: 2429a19 ("rxrpc: Fix untrusted unsigned subtract") Closes: https://sashiko.dev/#/patchset/20260408121252.2249051-1-dhowells%40redhat.com Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: Jeffrey Altman <jaltman@auristor.com> cc: Simon Horman <horms@kernel.org> cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260422161438.2593376-6-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 6929350) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 cve CVE-2026-31631 Rebuild_History Non-Buildable kernel-6.12.0-211.40.1.el10_2 commit-author David Howells <dhowells@redhat.com> commit f564af3 Fix rxgk_do_verify_authenticator() to check the buffer size before checking the nonce. Fixes: 9d1d2b5 ("rxrpc: rxgk: Implement the yfs-rxgk security class (GSSAPI)") Closes: https://sashiko.dev/#/patchset/20260401105614.1696001-10-dhowells@redhat.com Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: Jeffrey Altman <jaltman@auristor.com> cc: Simon Horman <horms@kernel.org> cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260408121252.2249051-20-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit f564af3) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 cve CVE-2026-31632 Rebuild_History Non-Buildable kernel-6.12.0-211.40.1.el10_2 commit-author David Howells <dhowells@redhat.com> commit 7e1876c Fix rxgk_verify_response() to clean up the rxgk context it creates. Fixes: 9d1d2b5 ("rxrpc: rxgk: Implement the yfs-rxgk security class (GSSAPI)") Closes: https://sashiko.dev/#/patchset/20260401105614.1696001-10-dhowells@redhat.com Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: Jeffrey Altman <jaltman@auristor.com> cc: Simon Horman <horms@kernel.org> cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260408121252.2249051-19-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 7e1876c) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 cve CVE-2026-31633 Rebuild_History Non-Buildable kernel-6.12.0-211.40.1.el10_2 commit-author David Howells <dhowells@redhat.com> commit 699e521 In rxgk_verify_response(), there's a potential integer overflow due to rounding up token_len before checking it, thereby allowing the length check to be bypassed. Fix this by checking the unrounded value against len too (len is limited as the response must fit in a single UDP packet). Fixes: 9d1d2b5 ("rxrpc: rxgk: Implement the yfs-rxgk security class (GSSAPI)") Closes: https://sashiko.dev/#/patchset/20260401105614.1696001-10-dhowells@redhat.com Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: Jeffrey Altman <jaltman@auristor.com> cc: Simon Horman <horms@kernel.org> cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260408121252.2249051-18-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 699e521) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 cve CVE-2026-31635 Rebuild_History Non-Buildable kernel-6.12.0-211.40.1.el10_2 commit-author Keenan Dong <keenanat2000@gmail.com> commit a256721 rxgk_verify_response() decodes auth_len from the packet and is supposed to verify that it fits in the remaining bytes. The existing check is inverted, so oversized RESPONSE authenticators are accepted and passed to rxgk_decrypt_skb(), which can later reach skb_to_sgvec() with an impossible length and hit BUG_ON(len). Decoded from the original latest-net reproduction logs with scripts/decode_stacktrace.sh: RIP: __skb_to_sgvec() [net/core/skbuff.c:5285 (discriminator 1)] Call Trace: skb_to_sgvec() [net/core/skbuff.c:5305] rxgk_decrypt_skb() [net/rxrpc/rxgk_common.h:81] rxgk_verify_response() [net/rxrpc/rxgk.c:1268] rxrpc_process_connection() [net/rxrpc/conn_event.c:266 net/rxrpc/conn_event.c:364 net/rxrpc/conn_event.c:386] process_one_work() [kernel/workqueue.c:3281] worker_thread() [kernel/workqueue.c:3353 kernel/workqueue.c:3440] kthread() [kernel/kthread.c:436] ret_from_fork() [arch/x86/kernel/process.c:164] Reject authenticator lengths that exceed the remaining packet payload. Fixes: 9d1d2b5 ("rxrpc: rxgk: Implement the yfs-rxgk security class (GSSAPI)") Signed-off-by: Keenan Dong <keenanat2000@gmail.com> Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: Simon Horman <horms@kernel.org> cc: Willy Tarreau <w@1wt.eu> cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260408121252.2249051-14-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit a256721) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.40.1.el10_2 commit-author David Howells <dhowells@redhat.com> commit 2b50ace Empty-Commit: Cherry-Pick Conflicts during history rebuild. Will be included in final tarball splat. Ref for failed cherry-pick at: ciq/ciq_backports/kernel-6.12.0-211.40.1.el10_2/2b50acea.failed Change the krb5 crypto library to provide facilities to precheck the length of the message about to be decrypted or verified. Fix AF_RXRPC to make use of this to validate DATA packets secured with RxGK. Fixes: 9d1d2b5 ("rxrpc: rxgk: Implement the yfs-rxgk security class (GSSAPI)") Closes: https://sashiko.dev/#/patchset/20260511160753.607296-1-dhowells%40redhat.com Signed-off-by: David Howells <dhowells@redhat.com> cc: Herbert Xu <herbert@gondor.apana.org.au> cc: Simon Horman <horms@kernel.org> cc: Chuck Lever <chuck.lever@oracle.com> cc: linux-afs@lists.infradead.org Reviewed-by: Jeffrey Altman <jaltman@auristor.com> Tested-by: Marc Dionne <marc.dionne@auristor.com> Link: https://patch.msgid.link/20260515230516.2718212-2-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 2b50ace) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # Documentation/crypto/krb5.rst
jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.40.1.el10_2 commit-author David Howells <dhowells@redhat.com> commit d2bc90c Empty-Commit: Cherry-Pick Conflicts during history rebuild. Will be included in final tarball splat. Ref for failed cherry-pick at: ciq/ciq_backports/kernel-6.12.0-211.40.1.el10_2/d2bc90cf.failed This improves the fix for CVE-2026-43500. Fix the pagecache corruption from in-place decryption of a DATA packet transmitted locally by splice() by getting rid of the packet sharing in the I/O thread and unconditionally extracting the packet content into a bounce buffer in which the buffer is decrypted. recvmsg() (or the kernel equivalent) then copies the data from the bounce buffer to the destination buffer. The sk_buff then remains unmodified. This has an additional advantage in that the packet is then arranged in the buffer with the correct alignment required for the crypto algorithms to process directly. The performance of the crypto does seem to be a little faster and, surprisingly, the unencrypted performance doesn't seem to change much - possibly due to removing complexity from the I/O thread. Yet another advantage is that the I/O thread doesn't have to copy packets which would slow down packet distribution, ACK generation, etc.. The buffer belongs to the call and is allocated initially at 2K, sufficiently large to hold a whole jumbo subpacket, but the buffer will be increased in size if needed. However, to take this work, MSG_PEEK may cause a later packet to be decrypted into the buffer, in which case the earlier one will need re-decrypting for a subsequent recvmsg(). Note that rx_pkt_offset may legitimately see 0 as a valid offset now, so switch to using USHRT_MAX to indicate an invalid offset. Note also that I would generally prefer to replace the buffers of the current sk_buff with a new kmalloc'd buffer of the right size, ditching the old data and frags as this makes the handling of MSG_PEEK easier and removes the re-decryption issue, but this looks like quite a complicated thing to achieve. skb_morph() looks half way to what I want, but I don't want to have to allocate a new sk_buff. Fixes: d0d5c0c ("rxrpc: Use skb_unshare() rather than skb_cow_data()") Reported-by: Hyunwoo Kim <imv4bel@gmail.com> Closes: https://lore.kernel.org/r/afKV2zGR6rrelPC7@v4bel/ Signed-off-by: David Howells <dhowells@redhat.com> cc: Simon Horman <horms@kernel.org> cc: Jiayuan Chen <jiayuan.chen@linux.dev> cc: linux-afs@lists.infradead.org Reviewed-by: Jeffrey Altman <jaltman@auristor.com> Tested-by: Marc Dionne <marc.dionne@auristor.com> Link: https://patch.msgid.link/20260515230516.2718212-3-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit d2bc90c) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # net/rxrpc/rxgk.c # net/rxrpc/rxkad.c
…ffer jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.40.1.el10_2 commit-author David Howells <dhowells@redhat.com> commit 8bfab4b Empty-Commit: Cherry-Pick Conflicts during history rebuild. Will be included in final tarball splat. Ref for failed cherry-pick at: ciq/ciq_backports/kernel-6.12.0-211.40.1.el10_2/8bfab4b6.failed This improves the fix for CVE-2026-43500. Fix the verification of RESPONSE packets to avoid the problem of overwriting a RESPONSE packet sent via splice to a local address by extracting the contents of the UDP packet into a kmalloc'd linear buffer rather than decrypting the data in place in the sk_buff (which may corrupt the original buffer). Fixes: 24481a7 ("rxrpc: Fix conn-level packet handling to unshare RESPONSE packets") Reported-by: Hyunwoo Kim <imv4bel@gmail.com> Closes: https://lore.kernel.org/r/afKV2zGR6rrelPC7@v4bel/ Signed-off-by: David Howells <dhowells@redhat.com> cc: Simon Horman <horms@kernel.org> cc: Jiayuan Chen <jiayuan.chen@linux.dev> cc: linux-afs@lists.infradead.org cc: stable@kernel.org Reviewed-by: Jeffrey Altman <jaltman@auristor.com> Tested-by: Marc Dionne <marc.dionne@auristor.com> Link: https://patch.msgid.link/20260515230516.2718212-4-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 8bfab4b) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # net/rxrpc/rxgk_common.h # net/rxrpc/rxkad.c
jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.40.1.el10_2 commit-author David Howells <dhowells@redhat.com> commit 333b6d5 Fix modification of the received skbuff in rxrpc_input_soft_acks() and a potential incorrect access of the buffer in a fragmented UDP packet (the packet would probably have to be deliberately pre-generated as fragmented) when AF_RXRPC tries to extract the contents of the SACK table by copying out the contents of the SACK table into a buffer before attempting to parse AF_RXRPC assumes that it can just call skb_condense() and then validly access the SACK table from skb->data and that it will be a flat buffer - but skb_condense() can silently fail to do anything under some circumstances. Note that whilst rxrpc_input_soft_acks() should be able to parse extended ACKs, the rest of AF_RXRPC doesn't currently support that. Further, there's then no need to call skb_condense() in rxrpc_input_ack(), so don't. Fixes: d57a3a1 ("rxrpc: Save last ACK's SACK table rather than marking txbufs") Reported-by: Michael Bommarito <michael.bommarito@gmail.com> Link: https://lore.kernel.org/r/20260513180907.2061972-1-michael.bommarito@gmail.com Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: Jeffrey Altman <jaltman@auristor.com> cc: Eric Dumazet <edumazet@google.com> cc: "David S. Miller" <davem@davemloft.net> cc: Jakub Kicinski <kuba@kernel.org> cc: Paolo Abeni <pabeni@redhat.com> cc: Simon Horman <horms@kernel.org> cc: linux-afs@lists.infradead.org cc: netdev@vger.kernel.org cc: stable@kernel.org Link: https://patch.msgid.link/105362.1780573560@warthog.procyon.org.uk Signed-off-by: Paolo Abeni <pabeni@redhat.com> (cherry picked from commit 333b6d5) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.40.1.el10_2 commit-author Jeffrey Altman <jaltman@auristor.com> commit 16c8ae9 Empty-Commit: Cherry-Pick Conflicts during history rebuild. Will be included in final tarball splat. Ref for failed cherry-pick at: ciq/ciq_backports/kernel-6.12.0-211.40.1.el10_2/16c8ae97.failed rxrpc_recvmsg_data() calls rxrpc_verify_data() whenever the rxrpc_call.rx_dec_buffer is unallocated and assumes that upon successful return that rx_dec_buffer must be allocated. However, rxrpc_verify_data() does not request an allocation if the rxrpc_skb_priv.len is zero. In addition, failure to allocate rx_dec_buffer will result in a call to skb_copy_bits() with a NULL destination which can trigger a NULL pointer dereference. To prevent these issues rxrpc_verify_data() is modified to always attempt to allocate the rxrpc_call.rx_dec_buffer if it is NULL. This issue was identified with assistance of a private sashiko instance. Fixes: d2bc90c ("rxrpc: Fix DATA decrypt vs splice() by copying data to buffer in recvmsg") Reported-by: Simon Horman <simon.horman@redhat.com> Signed-off-by: Jeffrey Altman <jaltman@auristor.com> Signed-off-by: David Howells <dhowells@redhat.com> cc: Jiayuan Chen <jiayuan.chen@linux.dev> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260609140911.838677-2-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 16c8ae9) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # net/rxrpc/recvmsg.c
jira KERNEL-1416 cve CVE-2026-46086 Rebuild_History Non-Buildable kernel-6.12.0-211.40.1.el10_2 commit-author Zhengchuan Liang <zcliangcn@gmail.com> commit df46016 Empty-Commit: Cherry-Pick Conflicts during history rebuild. Will be included in final tarball splat. Ref for failed cherry-pick at: ciq/ciq_backports/kernel-6.12.0-211.40.1.el10_2/df460165.failed Local FDB entries can be rewritten in place by `fdb_delete_local()`, which updates `f->dst` to another port or to `NULL` while keeping the entry alive. Several bridge RCU readers inspect `f->dst`, including `br_fdb_fillbuf()` through the `brforward_read()` sysfs path. These readers currently load `f->dst` multiple times and can therefore observe inconsistent values across the check and later dereference. In `br_fdb_fillbuf()`, this means a concurrent local-FDB update can change `f->dst` after the NULL check and before the `port_no` dereference, leading to a NULL-ptr-deref. Fix this by taking a single `READ_ONCE()` snapshot of `f->dst` in each affected RCU reader and using that snapshot for the rest of the access sequence. Also publish the in-place `f->dst` updates in `fdb_delete_local()` with `WRITE_ONCE()` so the readers and writer use matching access patterns. Fixes: 960b589 ("bridge: Properly check if local fdb entry can be deleted in br_fdb_change_mac_address") Cc: stable@kernel.org Reported-by: Yifan Wu <yifanwucs@gmail.com> Reported-by: Juefei Pu <tomapufckgml@gmail.com> Co-developed-by: Yuan Tan <yuantan098@gmail.com> Signed-off-by: Yuan Tan <yuantan098@gmail.com> Suggested-by: Xin Liu <bird@lzu.edu.cn> Tested-by: Ren Wei <enjou1224z@gmail.com> Signed-off-by: Zhengchuan Liang <zcliangcn@gmail.com> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Link: https://patch.msgid.link/6570fabb85ecadb8baaf019efe856f407711c7b9.1776043229.git.zcliangcn@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> (cherry picked from commit df46016) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # net/bridge/br_fdb.c
jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.40.1.el10_2 commit-author Zhenzhong Duan <zhenzhong.duan@intel.com> commit a6dea58 Below oops triggers when kill QEMU process: Oops: general protection fault, probably for non-canonical address 0x7fffffff844eaaa7: 0000 [#1] SMP NOPTI Call Trace: <TASK> do_raw_spin_lock+0xaa/0xc0 _raw_spin_lock_irqsave+0x21/0x40 domain_remove_dev_pasid+0x52/0x160 intel_nested_set_dev_pasid+0x1b9/0x1e0 __iommu_set_group_pasid+0x56/0x120 pci_dev_reset_iommu_done+0xe3/0x180 pcie_flr+0x65/0x160 __pci_reset_function_locked+0x5b/0x120 vfio_pci_core_close_device+0x63/0xe0 [vfio_pci_core] vfio_df_close+0x4f/0xa0 vfio_df_unbind_iommufd+0x2d/0x60 vfio_device_fops_release+0x3e/0x40 __fput+0xe5/0x2c0 task_work_run+0x58/0xa0 do_exit+0x2c8/0x600 do_group_exit+0x2f/0xa0 get_signal+0x863/0x8c0 arch_do_signal_or_restart+0x24/0x100 exit_to_user_mode_loop+0x87/0x380 do_syscall_64+0x2ff/0x11e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The global static blocked domain is a dummy domain without corresponding dmar_domain structure, accessing beyond iommu_domain structure triggers oops easily. Fix it by return early in domain_remove_dev_pasid() like identity domain. Fixes: 7d0c9da ("iommu/vt-d: Add set_dev_pasid callback for dma domain") Cc: stable@vger.kernel.org Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Link: https://lore.kernel.org/r/20260421031347.1408890-1-zhenzhong.duan@intel.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> (cherry picked from commit a6dea58) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 cve CVE-2026-53281 Rebuild_History Non-Buildable kernel-6.12.0-211.40.1.el10_2 commit-author Zhenzhong Duan <zhenzhong.duan@intel.com> commit 79ea2fe Commit 60f030f ("iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE") fixed a NULL pointer dereference in an unlikely situation partly. If dev_pasid is not found in the dev_pasids list, it remains NULL. However, the teardown operations are executed unconditionally, this lead to a NULL pointer dereference or refcount corruption. If the domain was never attached to this IOMMU, info will be NULL, which would cause an immediate dereference when checking --info->refcnt. Even if info is not NULL, decrementing the refcount without having removed a valid PASID might unbalance the count. This could lead to premature dropping of the refcount to 0, potentially causing a use-after-free for the remaining active devices sharing the domain. Fix it by returning early if dev_pasid is NULL, before executing the teardown operations. Issue found by AI review and suggested by Kevin Tian. https://sashiko.dev/#/patchset/20260421031347.1408890-1-zhenzhong.duan%40intel.com Fixes: 60f030f ("iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE") Cc: stable@vger.kernel.org Suggested-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Link: https://lore.kernel.org/r/20260422033538.95000-1-zhenzhong.duan@intel.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> (cherry picked from commit 79ea2fe) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 cve CVE-2026-52993 Rebuild_History Non-Buildable kernel-6.12.0-211.40.1.el10_2 commit-author Lee Jones <lee@kernel.org> commit d293ca7 tipc_msg_validate() can potentially reallocate the skb it is validating, freeing the old one. In tipc_buf_append(), it was being called with a pointer to a local variable which was a copy of the caller's skb pointer. If the skb was reallocated and validation subsequently failed, the error handling path would free the original skb pointer, which had already been freed, leading to double-free. Fix this by checking if head now points to a newly allocated reassembled skb. If it does, reassign *headbuf for later freeing operations. Fixes: d618d09 ("tipc: enforce valid ratio between skb truesize and contents") Suggested-by: Tung Nguyen <tung.quang.nguyen@est.tech> Signed-off-by: Lee Jones <lee@kernel.org> Reviewed-by: Tung Nguyen <tung.quang.nguyen@est.tech> Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit d293ca7) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 cve CVE-2026-53006 Rebuild_History Non-Buildable kernel-6.12.0-211.40.1.el10_2 commit-author Eric Dumazet <edumazet@google.com> commit f996edd Caching saddr and daddr before pskb_pull() is problematic since skb->head can change. Remove these temporary variables: - We only access &ipv6_hdr(skb)->saddr and &ipv6_hdr(skb)->daddr when net_dbg_ratelimited() is called in the slow path. - Avoid potential future misuse after pskb_pull() call. Fixes: 4b3418f ("ipv6: icmp: include addresses in debug messages") Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de> Reviewed-by: Joe Damato <joe@dama.to> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260416103505.2380753-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit f996edd) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
Rebuild_History BUILDABLE Rebuilding Kernel from rpm changelog with Fuzz Limit: 87.50% Number of commits in upstream range v6.12~1..kernel-mainline: 138299 Number of commits in rpm: 23 Number of commits matched with upstream: 21 (91.30%) Number of commits in upstream but not in rpm: 138278 Number of commits NOT found in upstream: 2 (8.70%) Rebuilding Kernel on Branch rocky10_2_rebuild_kernel-6.12.0-211.40.1.el10_2 for kernel-6.12.0-211.40.1.el10_2 Clean Cherry Picks: 16 (76.19%) Empty Cherry Picks: 5 (23.81%) _______________________________ Full Details Located here: ciq/ciq_backports/kernel-6.12.0-211.40.1.el10_2/rebuild.details.txt Includes: * git commit header above * Empty Commits with upstream SHA * RPM ChangeLog Entries that could not be matched Individual Empty Commit failures contained in the same containing directory. The git message for empty commits will have the path for the failed commit. File names are the first 8 characters of the upstream SHA
jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.42.1.el10_2 commit-author Bard Liao <yung-chuan.liao@linux.intel.com> commit c84179a The dai_type is used to select function topologies. Since the topology stream name and DAI link name use partial matching, unconditionally appending the dai_type provides necessary selection metadata without breaking existing topologies. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Link: https://patch.msgid.link/20260515083043.1864426-1-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> (cherry picked from commit c84179a) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 cve CVE-2026-46303 Rebuild_History Non-Buildable kernel-6.12.0-211.42.1.el10_2 commit-author Michael Bommarito <michael.bommarito@gmail.com> commit a36d990 rock_continue() reads rs->cont_extent verbatim from the Rock Ridge CE record and passes it to sb_bread() without checking that the block number is within the mounted ISO 9660 volume. commit e595447 ("[PATCH] rock.c: handle corrupted directories") added cont_offset and cont_size rejection for the CE continuation but did not validate the extent block number itself. commit f54e18f ("isofs: Fix infinite looping over CE entries") later capped the CE chain length at RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked. With a crafted ISO mounted via udisks2 (desktop optical auto-mount) or via CAP_SYS_ADMIN mount, rs->cont_extent can therefore point at an out-of-range block or at blocks belonging to an adjacent filesystem on the same block device. sb_bread() on an out-of-range block returns NULL cleanly via the block layer EIO path, so there is no memory-safety violation. For in-range reads of adjacent- filesystem data, the CE buffer is parsed as Rock Ridge records and only the text of SL sub-records reaches userspace through readlink(), which makes the info-leak channel narrow and difficult to exploit; still, rejecting the malformed CE outright matches the rejection shape already present in the same function for cont_offset and cont_size. Add an ISOFS_SB(sb)->s_nzones bounds check to rock_continue() next to the existing offset/size rejection, printing the same corrupted-directory-entry notice. Fixes: f54e18f ("isofs: Fix infinite looping over CE entries") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Link: https://patch.msgid.link/20260419212155.2169382-2-michael.bommarito@gmail.com Signed-off-by: Jan Kara <jack@suse.cz> (cherry picked from commit a36d990) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
…_item jira KERNEL-1416 cve CVE-2025-68211 Rebuild_History Non-Buildable kernel-6.12.0-211.42.1.el10_2 commit-author Pedro Demarchi Gomes <pedrodemargomes@gmail.com> commit f5548c3 Currently, scan_get_next_rmap_item() walks every page address in a VMA to locate mergeable pages. This becomes highly inefficient when scanning large virtual memory areas that contain mostly unmapped regions, causing ksmd to use large amount of cpu without deduplicating much pages. This patch replaces the per-address lookup with a range walk using walk_page_range(). The range walker allows KSM to skip over entire unmapped holes in a VMA, avoiding unnecessary lookups. This problem was previously discussed in [1]. Consider the following test program which creates a 32 TiB mapping in the virtual address space but only populates a single page: #include <unistd.h> #include <stdio.h> #include <sys/mman.h> /* 32 TiB */ const size_t size = 32ul * 1024 * 1024 * 1024 * 1024; int main() { char *area = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_NORESERVE | MAP_PRIVATE | MAP_ANON, -1, 0); if (area == MAP_FAILED) { perror("mmap() failed\n"); return -1; } /* Populate a single page such that we get an anon_vma. */ *area = 0; /* Enable KSM. */ madvise(area, size, MADV_MERGEABLE); pause(); return 0; } $ ./ksm-sparse & $ echo 1 > /sys/kernel/mm/ksm/run Without this patch ksmd uses 100% of the cpu for a long time (more then 1 hour in my test machine) scanning all the 32 TiB virtual address space that contain only one mapped page. This makes ksmd essentially deadlocked not able to deduplicate anything of value. With this patch ksmd walks only the one mapped page and skips the rest of the 32 TiB virtual address space, making the scan fast using little cpu. Link: https://lkml.kernel.org/r/20251023035841.41406-1-pedrodemargomes@gmail.com Link: https://lkml.kernel.org/r/20251022153059.22763-1-pedrodemargomes@gmail.com Link: https://lore.kernel.org/linux-mm/423de7a3-1c62-4e72-8e79-19a6413e420c@redhat.com/ [1] Fixes: 31dbd01 ("ksm: Kernel SamePage Merging") Signed-off-by: Pedro Demarchi Gomes <pedrodemargomes@gmail.com> Co-developed-by: David Hildenbrand <david@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Reported-by: craftfever <craftfever@airmail.cc> Closes: https://lkml.kernel.org/r/020cf8de6e773bb78ba7614ef250129f11a63781@murena.io Suggested-by: David Hildenbrand <david@redhat.com> Acked-by: David Hildenbrand <david@redhat.com> Cc: Chengming Zhou <chengming.zhou@linux.dev> Cc: xu xin <xu.xin16@zte.com.cn> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> (cherry picked from commit f5548c3) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 cve CVE-2026-64530 Rebuild_History Non-Buildable kernel-6.12.0-211.42.1.el10_2 commit-author Jamal Hadi Salim <jhs@mojatatu.com> commit a8a0289 tcf_classify() can return TC_ACT_CONSUMED while the skb is held by the defragmentation engine (e.g. act_ct on out-of-order fragments). When that happens the skb is no longer owned by the caller and must not be touched again. tcf_qevent_handle() did not handle TC_ACT_CONSUMED: it fell through the switch and returned the skb to the caller as if classification had passed. The only qdisc that wires up qevents today is RED, via three call sites (qe_mark on RED_PROB_MARK/HARD_MARK, qe_early_drop on congestion_drop) red_enqueue() was continuing to operate on an skb it no longer owns in this case -- enqueueing it, dropping it, or updating statistics. Resulting in a UAF. tc qdisc add dev eth0 root handle 1: red ... qevent early_drop block 10 tc filter add block 10 ... action ct (with ct defrag enabled and traffic that produces out-of-order fragments, e.g. a fragmented UDP stream) Handle TC_ACT_CONSUMED in tcf_qevent_handle() the same way the ingress and egress fast paths do: treat it as stolen and return NULL without touching the skb. Unlike the TC_ACT_STOLEN case, the skb must not be dropped/freed here, as it is no longer owned by us. Fixes: 3f14b37 ("net/sched: act_ct: fix skb leak and crash on ooo frags") Reported-by: Zero Day Initiative <zdi-disclosures@trendmicro.com> Tested-by: Victor Nogueira <victor@mojatatu.com> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com> Link: https://patch.msgid.link/20260620130749.226642-1-jhs@mojatatu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit a8a0289) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
Rebuild_History BUILDABLE Rebuilding Kernel from rpm changelog with Fuzz Limit: 87.50% Number of commits in upstream range v6.12~1..kernel-mainline: 138299 Number of commits in rpm: 7 Number of commits matched with upstream: 4 (57.14%) Number of commits in upstream but not in rpm: 138295 Number of commits NOT found in upstream: 3 (42.86%) Rebuilding Kernel on Branch rocky10_2_rebuild_kernel-6.12.0-211.42.1.el10_2 for kernel-6.12.0-211.42.1.el10_2 Clean Cherry Picks: 4 (100.00%) Empty Cherry Picks: 0 (0.00%) _______________________________ Full Details Located here: ciq/ciq_backports/kernel-6.12.0-211.42.1.el10_2/rebuild.details.txt Includes: * git commit header above * Empty Commits with upstream SHA * RPM ChangeLog Entries that could not be matched Individual Empty Commit failures contained in the same containing directory. The git message for empty commits will have the path for the failed commit. File names are the first 8 characters of the upstream SHA
jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.43.1.el10_2 commit-author Jose Ignacio Tornos Martinez <jtornosm@redhat.com> commit ae73379 SAP (Service Access Point) suspend occasionally times out with error -110 (ETIMEDOUT), followed by modem port errors and complete modem failure requiring a system reboot to recover. Error symptoms: mtk_t7xx 0000:72:00.0: [PM] SAP suspend error: -110 mtk_t7xx 0000:72:00.0: can't suspend (...returned -110) mtk_t7xx 0000:07:00.0: Failed to send skb: -22 mtk_t7xx 0000:07:00.0: Write error on MBIM port, -22 The modem firmware needs time after receiving the MD (modem) suspend request to complete internal operations before it is ready to accept the SAP suspend request. Without this delay, if runtime PM attempts to suspend while the firmware is busy, the SAP suspend command times out, leaving the modem in an unrecoverable state. Root cause and userspace interaction: ModemManager 1.24+ includes changes that reduce the likelihood of this issue by ensuring the modem is in a low-power state before the kernel attempts runtime suspend. However, the kernel driver should not depend on specific userspace behavior or ModemManager versions. Older versions (1.20-1.22) are still widely deployed, and the kernel should be robust regardless of userspace implementation details. There appears to be no hardware status register or other mechanism available to query whether the firmware is ready for SAP suspend. A delay between the two suspend requests is the most reliable solution found through testing. Add a 50ms delay between MD suspend and SAP suspend. This gives the firmware adequate time to complete internal operations without adding significant latency to the suspend path. This makes the driver robust across all ModemManager versions and system conditions. Testing: 96+ hours of continuous operation with ModemManager 1.20.2 and Fibocom FM350-GL modem. Zero SAP suspend timeouts observed across 2000+ successful suspend/resume cycles. Previously failed within 24 hours with 100% reproducibility. Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com> Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Link: https://patch.msgid.link/20260527061451.12710-1-jtornosm@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit ae73379) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 cve CVE-2025-68214 Rebuild_History Non-Buildable kernel-6.12.0-211.43.1.el10_2 commit-author Yipeng Zou <zouyipeng@huawei.com> commit 20739af There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0 CPU1 <SOFTIRQ> lock_timer_base() expire_timers() base->running_timer = timer; unlock_timer_base() [call_timer_fn enter] mod_timer() ... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) ret = detach_if_pending(timer, base, true); if (shutdown) timer->function = NULL; unlock_timer_base() [call_timer_fn exit] lock_timer_base() base->running_timer = NULL; unlock_timer_base() ... // Now timer is pending while its function set to NULL. // next timer trigger <SOFTIRQ> expire_timers() WARN_ON_ONCE(!fn) // hit ... lock_timer_base() // Now timer will detach if (base->running_timer != timer) ret = detach_if_pending(timer, base, true); if (shutdown) timer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running. Fixes: 0cc04e8 ("timers: Add shutdown mechanism to the internal functions") Signed-off-by: Yipeng Zou <zouyipeng@huawei.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251122093942.301559-1-zouyipeng@huawei.com (cherry picked from commit 20739af) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 cve CVE-2026-23199 Rebuild_History Non-Buildable kernel-6.12.0-211.43.1.el10_2 commit-author Andrii Nakryiko <andrii@kernel.org> commit b5cbacd Empty-Commit: Cherry-Pick Conflicts during history rebuild. Will be included in final tarball splat. Ref for failed cherry-pick at: ciq/ciq_backports/kernel-6.12.0-211.43.1.el10_2/b5cbacd7.failed Fix PROCMAP_QUERY to fetch optional build ID only after dropping mmap_lock or per-VMA lock, whichever was used to lock VMA under question, to avoid deadlock reported by syzbot: -> #1 (&mm->mmap_lock){++++}-{4:4}: __might_fault+0xed/0x170 _copy_to_iter+0x118/0x1720 copy_page_to_iter+0x12d/0x1e0 filemap_read+0x720/0x10a0 blkdev_read_iter+0x2b5/0x4e0 vfs_read+0x7f4/0xae0 ksys_read+0x12a/0x250 do_syscall_64+0xcb/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (&sb->s_type->i_mutex_key#8){++++}-{4:4}: __lock_acquire+0x1509/0x26d0 lock_acquire+0x185/0x340 down_read+0x98/0x490 blkdev_read_iter+0x2a7/0x4e0 __kernel_read+0x39a/0xa90 freader_fetch+0x1d5/0xa80 __build_id_parse.isra.0+0xea/0x6a0 do_procmap_query+0xd75/0x1050 procfs_procmap_ioctl+0x7a/0xb0 __x64_sys_ioctl+0x18e/0x210 do_syscall_64+0xcb/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- rlock(&mm->mmap_lock); lock(&sb->s_type->i_mutex_key#8); lock(&mm->mmap_lock); rlock(&sb->s_type->i_mutex_key#8); *** DEADLOCK *** This seems to be exacerbated (as we haven't seen these syzbot reports before that) by the recent: 777a856 ("lib/buildid: use __kernel_read() for sleepable context") To make this safe, we need to grab file refcount while VMA is still locked, but other than that everything is pretty straightforward. Internal build_id_parse() API assumes VMA is passed, but it only needs the underlying file reference, so just add another variant build_id_parse_file() that expects file passed directly. [akpm@linux-foundation.org: fix up kerneldoc] Link: https://lkml.kernel.org/r/20260129215340.3742283-1-andrii@kernel.org Fixes: ed5d583 ("fs/procfs: implement efficient VMA querying API for /proc/<pid>/maps") Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Reported-by: <syzbot+4e70c8e0a2017b432f7a@syzkaller.appspotmail.com> Reviewed-by: Suren Baghdasaryan <surenb@google.com> Tested-by: Suren Baghdasaryan <surenb@google.com> Reviewed-by: Shakeel Butt <shakeel.butt@linux.dev> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Eduard Zingerman <eddyz87@gmail.com> Cc: Hao Luo <haoluo@google.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: John Fastabend <john.fastabend@gmail.com> Cc: KP Singh <kpsingh@kernel.org> Cc: Martin KaFai Lau <martin.lau@linux.dev> Cc: Song Liu <song@kernel.org> Cc: Stanislav Fomichev <sdf@fomichev.me> Cc: Yonghong Song <yonghong.song@linux.dev> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> (cherry picked from commit b5cbacd) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/proc/task_mmu.c
jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.43.1.el10_2 commit-author Jouni Högander <jouni.hogander@intel.com> commit 008304c PORT_ALPM_CTL is supposed to be written only before link training. Remove writing it from ALPM disable. Also clearing ALPM_CTL_ALPM_AUX_LESS_ENABLE and is not about disabling ALPM but switching to AUX-Wake ALPM. Stop touching this bit on ALPM disable. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7153 Fixes: 1ccbf13 ("drm/i915/psr: Enable ALPM on source side for eDP Panel replay") Cc: Animesh Manna <animesh.manna@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: <stable@vger.kernel.org> # v6.10+ Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/20260212062731.397801-1-jouni.hogander@intel.com (cherry picked from commit 008304c) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.43.1.el10_2 commit-author Jouni Högander <jouni.hogander@intel.com> commit c5a52cd With some panels informing support for Panel Replay we are observing problems if having Panel Replay enable bit set on sink when forced to use PSR instead of Panel Replay. Avoid these problems by not setting Panel Replay enable bit in sink when Panel Replay is globally disabled during link training. I.e. disabled by module parameter. The enable bit is still set when disabling Panel Replay via debugfs interface. Added note comment about this. Fixes: 68f3a50 ("drm/i915/psr: Enable Panel Replay on sink always when it's supported") Cc: Mika Kahola <mika.kahola@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: <stable@vger.kernel.org> # v6.15+ Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patch.msgid.link/20260115070039.368965-1-jouni.hogander@intel.com (cherry picked from commit c5a52cd) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
…orted jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.43.1.el10_2 commit-author Jouni Högander <jouni.hogander@intel.com> commit eb5911f Currently we are blocking DC states only when Panel Replay is enabled on vblank enable. It may happen that Panel Replay is getting enabled when vblank is already enabled. Fix this by blocking DC states always if Panel Replay is supported. While at it take care of possible dual eDP case by looping all encoders supporting PSR. Fixes: 0c427ac ("drm/i915/psr: Add interface to notify PSR of vblank enable/disable") Cc: <stable@vger.kernel.org> # v6.16+ Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/20260520104944.239797-1-jouni.hogander@intel.com (cherry picked from commit eb5911f) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.43.1.el10_2 commit-author Jouni Högander <jouni.hogander@intel.com> commit 35485ac Empty-Commit: Cherry-Pick Conflicts during history rebuild. Will be included in final tarball splat. Ref for failed cherry-pick at: ciq/ciq_backports/kernel-6.12.0-211.43.1.el10_2/35485ac5.failed We are observing following warnings: *ERROR* power well DC_off state mismatch (refcount 0/enabled 1) gen9_dc_off_power_well_enabled is considering target state DC_STATE_DISABLE as DC_OFF power well being enabled. Fix this by using wakeref for the purpose. To achieve this we need to modify notification code as well. Currently it is possible that PSR gets notified vblank enable/disable twice on same status. This is currently not a problem as it is just triggering call to intel_display_power_set_target_dc_state with same target state as a parameter. When using wakeref this becomes a problem due to reference counting. Fix this storing vbank status on last notification and use that to ensure there are no more than one notification with same vblank status. v2: ensure there is no subsequent notifications with same status Fixes: aa451ab ("drm/i915/display: Prevent DC6 while vblank is enabled for Panel Replay") Cc: <stable@vger.kernel.org> # v6.13+ Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/20260520104944.239797-2-jouni.hogander@intel.com (cherry picked from commit 35485ac) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # drivers/gpu/drm/i915/display/intel_display_types.h
jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.43.1.el10_2 commit-author Ivan Vecera <ivecera@redhat.com> commit 620055c Export __dpll_pin_change_ntf() so that drivers can send pin change notifications from within pin callbacks, which are already called under dpll_lock. Using dpll_pin_change_ntf() in that context would deadlock. Add lockdep_assert_held() to catch misuse without the lock held. Acked-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Signed-off-by: Ivan Vecera <ivecera@redhat.com> Signed-off-by: Petr Oros <poros@redhat.com> Tested-by: Alexander Nowlin <alexander.nowlin@intel.com> Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260427-jk-iwl-net-petr-oros-fixes-v1-9-cdcb48303fd8@intel.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> (cherry picked from commit 620055c) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.43.1.el10_2 commit-author Ivan Vecera <ivecera@redhat.com> commit f3ddbaa Modify the internal registration helpers dpll_xa_ref_{dpll,pin}_add() to reject duplicate registration attempts. Previously, if a caller attempted to register the same pin multiple times (with the same ops, priv, and cookie) on the same device, the core silently increments the reference count and return success. This behavior is incorrect because if the caller makes these duplicate registrations then for the first one dpll_pin_registration is allocated and for others the associated dpll_pin_ref.refcount is incremented. During the first unregistration the associated dpll_pin_registration is freed and for others WARN is fired. Fix this by updating the logic to return `-EEXIST` if a matching registration is found to enforce a strict "register once" policy. Fixes: 9431063 ("dpll: core: Add DPLL framework base functions") Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20260121130012.112606-1-ivecera@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit f3ddbaa) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.43.1.el10_2 commit-author Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> commit a09dfac While being less compact, using named initializers allows to more easily see which members of the structs are assigned which value without having to lookup the declaration of the struct. And it's also more robust against changes to the struct definition. This patch doesn't modify the compiled arrays, only their representation in source form benefits. The former was confirmed with x86 and arm64 builds. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Reviewed-by: Ivan Vecera <ivecera@redhat.com> Link: https://patch.msgid.link/20260519142710.1587324-2-u.kleine-koenig@baylibre.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit a09dfac) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.43.1.el10_2 commit-author Ivan Vecera <ivecera@redhat.com> commit fa997dd If zl3073x_dpll_pin_register() fails, the allocated pin is not yet added to zldpll->pins list. The error path calls zl3073x_dpll_pins_unregister() which only iterates pins on the list, so the current pin is leaked. Free the pin before jumping to the error label. Additionally move the pin->dpll_pin = NULL assignment in zl3073x_dpll_pin_register() from err_register to the common err_pin_get path. When dpll_pin_get() fails, pin->dpll_pin holds an ERR_PTR value. Without this fix the subsequent zl3073x_dpll_pin_free() would trigger a spurious WARN because it checks pin->dpll_pin for non-NULL. Fixes: 75a71ec ("dpll: zl3073x: Register DPLL devices and pins") Reviewed-by: Petr Oros <poros@redhat.com> Signed-off-by: Ivan Vecera <ivecera@redhat.com> Link: https://patch.msgid.link/20260519132205.161847-1-ivecera@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit fa997dd) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
…ll be used jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.43.1.el10_2 commit-author Eric Dumazet <edumazet@google.com> commit 7409fad We plan to no longer hold RTNL in "ip link show", and use RCU instead. Assume rtnl_fill_dpll_pin() will have to fill DPLL_A_PIN_ID. It is fine to over-estimate skb size (by 8 bytes) in if_nlmsg_size(). Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20260521171440.114956-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 7409fad) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.43.1.el10_2 commit-author Ivan Vecera <ivecera@redhat.com> commit 20040b2 Export __dpll_device_change_ntf() so that drivers can send device change notifications from within device callbacks, which are already called under dpll_lock. Using dpll_device_change_ntf() in that context would deadlock. Add lockdep_assert_held() to catch misuse without the lock held. Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://patch.msgid.link/20260526074525.1451008-2-ivecera@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> (cherry picked from commit 20040b2) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.43.1.el10_2 commit-author Ivan Vecera <ivecera@redhat.com> commit d733f51 The change_work was introduced to send device change notifications from DPLL device callbacks without deadlocking on dpll_lock, since the callbacks are already invoked under that lock. Now that __dpll_device_change_ntf() is exported for callers that already hold dpll_lock, use it directly and remove the change_work infrastructure entirely. This eliminates a race condition where change_work could be re-scheduled after cancel_work_sync() during device teardown, potentially causing the handler to dereference a freed or NULL dpll_dev pointer. Fixes: 9363b48 ("dpll: zl3073x: Allow to configure phase offset averaging factor") Signed-off-by: Ivan Vecera <ivecera@redhat.com> Link: https://patch.msgid.link/20260526074525.1451008-3-ivecera@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> (cherry picked from commit d733f51) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.43.1.el10_2 commit-author Ivan Vecera <ivecera@redhat.com> commit c122456 The frequency monitoring feature uses shared hardware registers that measure input reference frequencies independently of individual DPLL channels. However, the freq_monitor flag was incorrectly placed in the per-DPLL structure, causing each channel to track its own enable/disable state independently. Since the DPLL core calls measured_freq_get() only for the first pin registration, the measured_freq_check() in the periodic worker was gated by the per-DPLL freq_monitor flag of whichever channel happens to be checked. If the first DPLL channel had frequency monitoring disabled while another had it enabled, measurements were never reported. Move freq_monitor from struct zl3073x_dpll to struct zl3073x_dev so all DPLL channels share a single flag, matching the hardware behavior. Update freq_monitor_set() to notify other DPLL devices about the change (like phase_offset_avg_factor_set() already does) and remove the mode-dependent guard in zl3073x_dpll_changes_check() since all input pin monitoring (pin state, phase offset, FFO, and measured frequency) works correctly in all DPLL modes. Fixes: bfc923b ("dpll: zl3073x: implement frequency monitoring") Signed-off-by: Ivan Vecera <ivecera@redhat.com> Link: https://patch.msgid.link/20260526074525.1451008-4-ivecera@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> (cherry picked from commit c122456) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.43.1.el10_2 commit-author Grzegorz Nitka <grzegorz.nitka@intel.com> commit 9375487 Add DPLL_TYPE_GENERIC to represent DPLL devices which do not fit the existing PPS or EEC classes. The UAPI type is intentionally generic. During netdev discussion, maintainers pointed out that introducing identifiers tied to a specific placement or single design does not scale across ASICs and vendors. The role of a DPLL is already inferable from the spawning driver, bus device, and pin topology, without encoding additional purpose-specific taxonomy in the type name. Using a generic type keeps the UAPI extensible and avoids premature naming that may become incorrect as new hardware topologies are exposed through the DPLL subsystem. Expose the new type through UAPI and netlink specification as "generic". Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com> Link: https://patch.msgid.link/20260607183045.1213735-2-grzegorz.nitka@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 9375487) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.43.1.el10_2 commit-author Grzegorz Nitka <grzegorz.nitka@intel.com> commit c191b31 Relax the (module, clock_id) equality requirement when registering a pin identified by firmware (pin->fwnode). Some platforms associate a FW-described pin with a DPLL instance that differs from the pin's (module, clock_id) tuple. For such pins, permit registration without requiring the strict match. Non-FW pins still require equality. Keep netlink pin module reporting/filtering safe for this relaxed registration model by caching the module name in the pin object at allocation time and using the cached string in netlink paths. This avoids dereferencing pin->module after provider module teardown. Reviewed-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com> Link: https://patch.msgid.link/20260607183045.1213735-3-grzegorz.nitka@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit c191b31) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.43.1.el10_2 commit-author Grzegorz Nitka <grzegorz.nitka@intel.com> commit 32239d6 Neither parent->dpll_refs nor pin->dpll_refs on its own is a correct iteration target at unregister time: - pin->dpll_refs includes DPLLs the child was registered against via a different parent or directly; blind unregister WARNs on the cookie miss in dpll_xa_ref_pin_del(). - parent->dpll_refs reflects the parent's current attachments, not those at child-register time. Another driver may have (un)reg'd the parent against additional DPLLs in the meantime, so we miss registrations that exist and visit DPLLs that have none. Walk pin->dpll_refs and use dpll_pin_registration_find() to filter to entries whose cookie is this parent. Symmetric with dpll_pin_on_pin_register(), correct under any subsequent change to parent->dpll_refs. Fixes: 9431063 ("dpll: core: Add DPLL framework base functions") Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com> Link: https://patch.msgid.link/20260607183045.1213735-4-grzegorz.nitka@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 32239d6) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.43.1.el10_2 commit-author Grzegorz Nitka <grzegorz.nitka@intel.com> commit e83b403 The rollback path in dpll_pin_on_pin_register() called __dpll_pin_unregister() before dpll_pin_delete_ntf(). When the unregister dropped the pin's last DPLL reference it cleared the DPLL_REGISTERED mark in dpll_pin_xa, so the subsequent dpll_pin_event_send() failed dpll_pin_available() and aborted with -ENODEV. As a result userspace was never notified of the rollback deletion and remained out of sync with the kernel. Send the delete notification first, matching the order used by dpll_pin_unregister() and dpll_pin_on_pin_unregister(). Fixes: 9d71b54 ("dpll: netlink: Add DPLL framework base functions") Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com> Link: https://patch.msgid.link/20260607183045.1213735-5-grzegorz.nitka@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit e83b403) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.43.1.el10_2 commit-author Grzegorz Nitka <grzegorz.nitka@intel.com> commit df0ba51 dpll_pin_on_pin_register() emits a creation notification for every parent->dpll_refs entry, but dpll_pin_on_pin_unregister() emitted only one deletion notification outside the loop. When a pin is registered against multiple parent dplls, userspace sees N creates but a single delete and leaks per-dpll state. Move dpll_pin_delete_ntf() into the loop and call it before __dpll_pin_unregister() so the DPLL_REGISTERED mark is still set when dpll_pin_available() is consulted. Fixes: 9d71b54 ("dpll: netlink: Add DPLL framework base functions") Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com> Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Link: https://patch.msgid.link/20260607183045.1213735-6-grzegorz.nitka@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit df0ba51) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.43.1.el10_2 commit-author Grzegorz Nitka <grzegorz.nitka@intel.com> commit 0a5c720 __dpll_pin_unregister() wiped the global sync-pair state on every (dpll, ops, priv, cookie) tuple removed from a pin. When a pin is registered multiple times and only one registration is being torn down, this dropped sync-pair pairings still in use by the surviving registrations. Move dpll_pin_ref_sync_pair_del() inside the xa_empty(&pin->dpll_refs) branch so it only runs when the last registration is gone, alongside clearing the DPLL_REGISTERED mark. Fixes: 58256a2 ("dpll: add reference sync get/set") Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com> Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Link: https://patch.msgid.link/20260607183045.1213735-7-grzegorz.nitka@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 0a5c720) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.43.1.el10_2 commit-author Grzegorz Nitka <grzegorz.nitka@intel.com> commit 1a22921 __dpll_pin_register() emits dpll_pin_create_ntf() internally, but __dpll_pin_unregister() left the matching delete to its callers. The counts then diverge on dpll_pin_on_pin_register() rollback and on dpll_pin_on_pin_unregister(), leaking stale notifications. Emit dpll_pin_delete_ntf() inside __dpll_pin_unregister() and drop the now-redundant call in dpll_pin_unregister(). Fixes: 9431063 ("dpll: core: Add DPLL framework base functions") Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com> Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Link: https://patch.msgid.link/20260607183045.1213735-8-grzegorz.nitka@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 1a22921) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.43.1.el10_2 commit-author Grzegorz Nitka <grzegorz.nitka@intel.com> commit 0bf47f7 Extend the DPLL pin notification API to include a source identifier indicating where the notification originates. This allows notifier consumers to distinguish between notifications coming from an associated DPLL instance, a parent pin, or the pin itself. A new field, src_clock_id, is added to struct dpll_pin_notifier_info and is passed through all pin-related notification paths. Callers of dpll_pin_notify() are updated to provide a meaningful source identifier based on their context: - pin registration/unregistration uses the DPLL's clock_id, - pin-on-pin operations use the parent pin's clock_id, - pin changes use the pin's own clock_id. As introduced in the commit ("dpll: allow registering FW-identified pin with a different DPLL"), it is possible to share the same physical pin via firmware description (fwnode) with DPLL objects from different kernel modules. This means that a given pin can be registered multiple times. Driver such as ICE (E825 devices) rely on this mechanism when listening for the event where a shared-fwnode pin appears, while avoiding reacting to events triggered by their own registration logic. This change only extends the notification metadata and does not alter existing semantics for drivers that do not use the new field. Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com> Link: https://patch.msgid.link/20260607183045.1213735-9-grzegorz.nitka@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 0bf47f7) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1416 Rebuild_History Non-Buildable kernel-6.12.0-211.43.1.el10_2 commit-author Grzegorz Nitka <grzegorz.nitka@intel.com> commit 521b6d5 Pins registered with an fwnode may have .state_on_dpll_set implemented without advertising DPLL_PIN_CAPABILITIES_STATE_CAN_CHANGE upfront. Requiring the bit for fwnode pins ties firmware description to driver implementation details unnecessarily. Relax the capability check in dpll_pin_state_set() and dpll_pin_on_pin_state_set(): when a pin has an associated fwnode, bypass the capability gate and let the ops layer decide, returning -EOPNOTSUPP if .state_on_dpll_set is absent. Non-fwnode pins retain the original strict behavior. This is used later in the series by the SyncE_Ref output pin, which relies on the fwnode path for state control. Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com> Link: https://patch.msgid.link/20260607183045.1213735-10-grzegorz.nitka@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 521b6d5) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
Rebuild_History BUILDABLE Rebuilding Kernel from rpm changelog with Fuzz Limit: 87.50% Number of commits in upstream range v6.12~1..kernel-mainline: 138299 Number of commits in rpm: 28 Number of commits matched with upstream: 25 (89.29%) Number of commits in upstream but not in rpm: 138274 Number of commits NOT found in upstream: 3 (10.71%) Rebuilding Kernel on Branch rocky10_2_rebuild_kernel-6.12.0-211.43.1.el10_2 for kernel-6.12.0-211.43.1.el10_2 Clean Cherry Picks: 22 (88.00%) Empty Cherry Picks: 3 (12.00%) _______________________________ Full Details Located here: ciq/ciq_backports/kernel-6.12.0-211.43.1.el10_2/rebuild.details.txt Includes: * git commit header above * Empty Commits with upstream SHA * RPM ChangeLog Entries that could not be matched Individual Empty Commit failures contained in the same containing directory. The git message for empty commits will have the path for the failed commit. File names are the first 8 characters of the upstream SHA
shreeya-patel98
approved these changes
Aug 4, 2026
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
This is an automated kernel history rebuild using cron and internal tooling. It follows the same process used for previous history rebuilds:
src.rpmpackagessrc.rpm:6.12.0-211)git cherry-pickrpmbuild -bpfor the correspondingsrc.rpmRebuild Splat Inspection
kernel-6.12.0-211.43.1.el10_2
BUILD
KSelfTests