Review Results

Comment

The change only bumps pkgver in .SRCINFO from 7.2.pf6 to 7.3.pf1. No sources, checksums, build steps, install scripts, or permissions are altered in this diff, so there is no new security concern visible in the reviewed hunk. This appears to be a routine version metadata update.

@@ -1,6 +1,6 @@
 pkgbase = linux-pf
 	pkgdesc = pf-kernel
-	pkgver = 7.2.pf6
+	pkgver = 7.3.pf1
 	pkgrel = 1
 	url = https://pfkernel.natalenko.name
 	arch = x86_64

Comment

The change only updates the pinned upstream tarball commit and its corresponding B2 checksum in .SRCINFO. The source remains an HTTPS Codeberg archive from the project’s upstream repository, with no new build-time commands, scripts, or packaging behavior introduced. This is a routine version bump with integrity metadata updated accordingly, so I see no security concern in the diff itself.

@@ -26,10 +26,10 @@ pkgbase = linux-pf
 	makedepends = zstd
 	options = !debug
 	options = !strip
-	source = https://codeberg.org/pf-kernel/linux/archive/21fd5a3cfe1c05f54a18bb24e557300638833634.tar.gz
+	source = https://codeberg.org/pf-kernel/linux/archive/90ca6ced047fbab83d9f9f1c5d83b23f7f60734d.tar.gz
 	source = config
 	b2sums = SKIP
-	b2sums = b5656a9f5d33440be055c38ccb75e26e2ed64b199c5d9d180024ba3396081b8d232f6f2b93aa24c9f78c568fe5717b1820678ac2100faef386845cbdd17ebc13
+	b2sums = 216a9ea28f2ddd3595fe52aeebd315298f7e6723d6a72808cafd747e3040fbfdda8786c5a1ae79872bb43b7f86bca9c6f9fe4a2519696f5af60c33c5a914250b
 
 pkgname = linux-pf
 	pkgdesc = The pf-kernel and modules

Comment

The change is a routine upstream kernel version bump: it updates the pinned commit hash, pkgver, and matching b2 checksum for the source tarball. The source remains an HTTPS Codeberg archive, there are no new build-time downloads, scripts, privilege changes, or packaging logic changes. No security red flags are introduced by this diff alone.

@@ -3,8 +3,8 @@
 pkgbase="linux-pf"
 _suffix=""
 pkgname=(${pkgbase}${_suffix} ${pkgbase}-headers${_suffix})
-_rev=21fd5a3cfe1c05f54a18bb24e557300638833634
-pkgver=7.2.pf6
+_rev=90ca6ced047fbab83d9f9f1c5d83b23f7f60734d
+pkgver=7.3.pf1
 pkgrel=1
 pkgdesc="pf-kernel"
 arch=(x86_64)

Comment

The change only updates the pinned upstream revision and the corresponding b2 checksum in PKGBUILD. The source remains an HTTPS Codeberg archive, there are no new build-time commands, no added scripts, and no packaging/persistence changes. This looks like a routine upstream version bump with integrity metadata refresh, so I see no security issue in the diff itself.

@@ -15,7 +15,7 @@ options=(!debug !strip)
 source=(https://codeberg.org/pf-kernel/linux/archive/${_rev}.tar.gz
 		config)
 b2sums=(SKIP
-		'b5656a9f5d33440be055c38ccb75e26e2ed64b199c5d9d180024ba3396081b8d232f6f2b93aa24c9f78c568fe5717b1820678ac2100faef386845cbdd17ebc13')
+		'216a9ea28f2ddd3595fe52aeebd315298f7e6723d6a72808cafd747e3040fbfdda8786c5a1ae79872bb43b7f86bca9c6f9fe4a2519696f5af60c33c5a914250b')
 
 export KBUILD_BUILD_HOST=archlinux
 export KBUILD_BUILD_USER=${pkgbase}

Comment

The change is a one-line version string update in the kernel config header, from 7.2.0-pf6 to 7.3.0-pf1. No build logic, source URLs, install scripts, permissions, or runtime behavior are affected. Based on the provided diff hunk, there are no security-relevant changes.

@@ -1,6 +1,6 @@
 #
 # Automatically generated file; DO NOT EDIT.
-# Linux/x86 7.2.0-pf6 Kernel Configuration
+# Linux/x86 7.3.0-pf1 Kernel Configuration
 #
 CONFIG_CC_VERSION_TEXT="gcc (GCC) 16.2.1 20260810"
 CONFIG_CC_IS_GCC=y

Comment

The change is a one-line bump of CONFIG_RUSTC_VERSION in the kernel config from 109701 to 109801. This is a build-time version pin for the Rust compiler expected by the kernel, not an execution path, dependency fetch, or packaging/persistence mechanism. No suspicious sources, scripts, permissions, or install-time behavior are introduced by this diff. Based on the provided hunk alone, this appears low risk and consistent with a routine version update.

@@ -11,7 +11,7 @@ CONFIG_AS_VERSION=24700
 CONFIG_LD_IS_BFD=y
 CONFIG_LD_VERSION=24700
 CONFIG_LLD_VERSION=0
-CONFIG_RUSTC_VERSION=109701
+CONFIG_RUSTC_VERSION=109801
 CONFIG_RUST_IS_AVAILABLE=y
 CONFIG_RUSTC_LLVM_VERSION=220108
 CONFIG_RUSTC_LLVM_MAJOR_VERSION=22

Comment

The change only bumps CONFIG_PAHOLE_VERSION from 131 to 132 and adds a new kernel config symbol, CONFIG_RUSTC_HAS_SUSPICIOUS_RUNTIME_SYMBOL_DEFINITIONS=y. In the provided diff there is no executable code, no build-time network access, no install script, and no packaging/persistence behavior. The new config symbol name is unusual, but as a kernel config entry in this package context it does not by itself introduce a supply-chain or privilege-escalation risk in the reviewed hunk. Based on this diff alone, I do not see a security issue.

@@ -30,7 +30,8 @@ CONFIG_RUSTC_HAS_SPAN_FILE=y
 CONFIG_RUSTC_HAS_UNNECESSARY_TRANSMUTES=y
 CONFIG_RUSTC_HAS_FILE_WITH_NUL=y
 CONFIG_RUSTC_HAS_FILE_AS_C_STR=y
-CONFIG_PAHOLE_VERSION=131
+CONFIG_RUSTC_HAS_SUSPICIOUS_RUNTIME_SYMBOL_DEFINITIONS=y
+CONFIG_PAHOLE_VERSION=132
 CONFIG_IRQ_WORK=y
 CONFIG_BUILDTIME_TABLE_SORT=y
 CONFIG_THREAD_INFO_IN_TASK=y

Comment

The change only enables a kernel configuration option, CONFIG_HAS_SEPARATE_PREEMPT_RESCHED_BITS, in the shipped config. This is a normal kernel build-time setting and does not introduce any new source, scripts, network access, privilege escalation, persistence, or packaging behavior. No security-relevant red flags are present in this diff hunk.

@@ -146,6 +147,7 @@ CONFIG_ARCH_HAS_PREEMPT_LAZY=y
 CONFIG_PREEMPT=y
 # CONFIG_PREEMPT_LAZY is not set
 CONFIG_PREEMPT_COUNT=y
+CONFIG_HAS_SEPARATE_PREEMPT_RESCHED_BITS=y
 CONFIG_PREEMPTION=y
 CONFIG_PREEMPT_DYNAMIC=y
 CONFIG_SCHED_CORE=y

Comment

The change only enables CONFIG_ARCH_HAS_PTE_PROTNONE in the kernel config. This is a normal kernel feature flag related to page table/protection-none support and does not introduce code execution, persistence, privilege escalation, network access, or packaging integrity issues. No suspicious sources, scripts, or install-time behavior are involved in this diff hunk.

@@ -217,6 +219,7 @@ CONFIG_UCLAMP_TASK=y
 CONFIG_UCLAMP_BUCKETS_COUNT=5
 # end of Scheduler features
 
+CONFIG_ARCH_HAS_PTE_PROTNONE=y
 CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
 CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
 CONFIG_CC_HAS_INT128=y

Comment

The change only updates the kernel config by adding CONFIG_ARCH_SUPPORTS_CMDLINE_FROM_BOOTCONFIG=y and removing CONFIG_SYSCTL=y. There are no source downloads, scripts, install hooks, or privilege-related artifacts involved in this hunk. The added option is a standard kernel capability flag, and the removed SYSCTL setting does not by itself indicate a backdoor or persistence mechanism in this diff. Based on the provided change alone, I see no security issue.

@@ -285,13 +288,13 @@ CONFIG_RD_ZSTD=y
 CONFIG_BOOT_CONFIG=y
 # CONFIG_BOOT_CONFIG_FORCE is not set
 # CONFIG_BOOT_CONFIG_EMBED is not set
+CONFIG_ARCH_SUPPORTS_CMDLINE_FROM_BOOTCONFIG=y
 CONFIG_CMDLINE_LOG_WRAP_IDEAL_LEN=1021
 CONFIG_INITRAMFS_PRESERVE_MTIME=y
 CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
 # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
 CONFIG_LD_ORPHAN_WARN=y
 CONFIG_LD_ORPHAN_WARN_LEVEL="warn"
-CONFIG_SYSCTL=y
 CONFIG_HAVE_UID16=y
 CONFIG_SYSCTL_EXCEPTION_TRACE=y
 # CONFIG_SYSFS_SYSCALL is not set

Comment

The change only updates two kernel config metadata strings for the recorded Rust and bindgen versions. It does not alter build commands, source URLs, install scripts, permissions, or any executable code path. No security-relevant behavior is introduced by this diff hunk alone.

@@ -344,8 +347,8 @@ CONFIG_PERF_EVENTS=y
 CONFIG_SYSTEM_DATA_VERIFICATION=y
 CONFIG_PROFILING=y
 CONFIG_RUST=y
-CONFIG_RUSTC_VERSION_TEXT="rustc 1.97.1 (8bab26f4f 2026-07-14) (Arch Linux rust 1:1.97.1-1)"
-CONFIG_BINDGEN_VERSION_TEXT="bindgen 0.72.1"
+CONFIG_RUSTC_VERSION_TEXT="rustc 1.98.1 (48a229cea 2026-09-01) (Arch Linux rust 1:1.98.1-1)"
+CONFIG_BINDGEN_VERSION_TEXT="bindgen 0.73.2"
 CONFIG_TRACEPOINTS=y
 
 #

Comment

The change only disables two Xen PVHVM kernel config options (CONFIG_XEN_PVHVM and CONFIG_XEN_PVHVM_SMP) while leaving related Xen guest/dom0 options enabled. This is a narrow functional configuration change with no evidence of malicious behavior, privilege escalation, persistence, network access, or integrity compromise. It may affect virtualization support for some Xen PVHVM setups, but that is a compatibility/regression concern rather than a security issue.

@@ -433,8 +436,6 @@ CONFIG_XEN_PV=y
 CONFIG_XEN_512GB=y
 CONFIG_XEN_PV_SMP=y
 CONFIG_XEN_PV_DOM0=y
-CONFIG_XEN_PVHVM=y
-CONFIG_XEN_PVHVM_SMP=y
 CONFIG_XEN_PVHVM_GUEST=y
 CONFIG_XEN_PVH=y
 CONFIG_XEN_DOM0=y

Comment

The reviewed hunk only swaps KVM guest memory capability flags in the kernel config: it replaces HAVE_KVM_ARCH_GMEM_PREPARE with HAVE_KVM_ARCH_GMEM_CONVERT and HAVE_KVM_ARCH_GMEM_RECLAIM. This is a normal kernel feature/configuration update with no evidence of code execution, persistence, privilege escalation, network access, or packaging integrity issues. No suspicious install scripts or external sources are implicated by this change.

@@ -839,7 +840,8 @@ CONFIG_KVM_ELIDE_TLB_FLUSH_IF_YOUNG=y
 CONFIG_KVM_MMU_LOCKLESS_AGING=y
 CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES=y
 CONFIG_KVM_GUEST_MEMFD=y
-CONFIG_HAVE_KVM_ARCH_GMEM_PREPARE=y
+CONFIG_HAVE_KVM_ARCH_GMEM_CONVERT=y
+CONFIG_HAVE_KVM_ARCH_GMEM_RECLAIM=y
 CONFIG_HAVE_KVM_ARCH_GMEM_INVALIDATE=y
 CONFIG_HAVE_KVM_ARCH_GMEM_POPULATE=y
 CONFIG_VIRTUALIZATION=y

Comment

The change only enables CONFIG_SYSCALL_USER_DISPATCH and its architecture support in the kernel config. This is a standard upstream kernel feature that lets a process selectively trap syscalls for user-space dispatch; it does not introduce build-time network access, privilege escalation, persistence, or packaging integrity issues by itself. No suspicious sources, scripts, or install-time behavior are involved in this hunk.

@@ -895,6 +897,8 @@ CONFIG_HOTPLUG_PARALLEL=y
 CONFIG_GENERIC_IRQ_ENTRY=y
 CONFIG_GENERIC_SYSCALL=y
 CONFIG_GENERIC_ENTRY=y
+CONFIG_ARCH_SUPPORTS_SYSCALL_USER_DISPATCH=y
+CONFIG_SYSCALL_USER_DISPATCH=y
 CONFIG_KPROBES=y
 CONFIG_JUMP_LABEL=y
 # CONFIG_STATIC_KEYS_SELFTEST is not set

Comment

The change is a one-line kernel config addition enabling CONFIG_ARCH_HAS_DELAY_TIMER. This is a build-time kernel feature flag, not a runtime script, package install hook, or source fetch change. I see no evidence of network access, privilege escalation, persistence, or integrity issues in this diff hunk. Risk is minimal.

@@ -924,6 +928,7 @@ CONFIG_ARCH_HAS_FORTIFY_SOURCE=y
 CONFIG_ARCH_HAS_SET_MEMORY=y
 CONFIG_ARCH_HAS_SET_DIRECT_MAP=y
 CONFIG_ARCH_HAS_CPU_FINALIZE_INIT=y
+CONFIG_ARCH_HAS_DELAY_TIMER=y
 CONFIG_ARCH_HAS_CPU_PASID=y
 CONFIG_HAVE_ARCH_THREAD_STRUCT_WHITELIST=y
 CONFIG_ARCH_WANTS_DYNAMIC_TASK_STRUCT=y

Comment

The only change in the provided hunk enables CONFIG_BLK_ERROR_INJECTION in the kernel config. This is a debug/testing feature that allows fault injection in block-layer paths; it does not introduce a build-time code execution path, persistence mechanism, privilege escalation, or packaging integrity issue by itself. While it can be used to simulate I/O failures and may be undesirable in a production kernel, the change is limited to a kernel configuration toggle and does not appear malicious or high risk from a supply-chain perspective.

@@ -1149,7 +1154,7 @@ CONFIG_EFI_PARTITION=y
 CONFIG_BLK_PM=y
 CONFIG_BLOCK_HOLDER_DEPRECATED=y
 CONFIG_BLK_MQ_STACKING=y
-# CONFIG_BLK_ERROR_INJECTION is not set
+CONFIG_BLK_ERROR_INJECTION=y
 
 #
 # IO Schedulers

Comment

The change only adds a commented-out kernel config option: `CONFIG_QUEUED_SPINLOCKS_TRACE_CONTENDED_RELEASE is not set`. This does not introduce code execution, network access, privilege escalation, persistence, or packaging integrity issues. It appears to be a benign configuration adjustment with no security impact visible in the diff.

@@ -1171,6 +1176,7 @@ CONFIG_RWSEM_SPIN_ON_OWNER=y
 CONFIG_LOCK_SPIN_ON_OWNER=y
 CONFIG_ARCH_USE_QUEUED_SPINLOCKS=y
 CONFIG_QUEUED_SPINLOCKS=y
+# CONFIG_QUEUED_SPINLOCKS_TRACE_CONTENDED_RELEASE is not set
 CONFIG_ARCH_USE_QUEUED_RWLOCKS=y
 CONFIG_QUEUED_RWLOCKS=y
 CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE=y

Comment

The only change in scope is enabling CONFIG_BINFMT_MISC_BPF in the kernel config. This is a kernel feature toggle, not a packaging/script change, and it does not introduce any new build-time downloads, privilege escalation, install hooks, or shipped binaries. While it expands kernel functionality by allowing BPF-backed binfmt_misc handlers, that is an upstream kernel capability rather than a packaging integrity issue. No direct security red flags are present in this diff hunk alone.

@@ -1187,6 +1193,7 @@ CONFIG_ELFCORE=y
 CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
 CONFIG_BINFMT_SCRIPT=y
 CONFIG_BINFMT_MISC=y
+CONFIG_BINFMT_MISC_BPF=y
 CONFIG_COREDUMP=y
 # end of Executable file formats
 

Comment

The change only removes CONFIG_HAVE_BOOTMEM_INFO_NODE from the kernel config. This is a build-time kernel configuration adjustment with no evidence of added code execution, persistence, privilege escalation, network access, or packaging integrity issues. I did not find any security-relevant behavior in this single-line config change.

@@ -1246,7 +1253,6 @@ CONFIG_ARCH_KEEP_MEMBLOCK=y
 CONFIG_NUMA_KEEP_MEMINFO=y
 CONFIG_MEMORY_ISOLATION=y
 CONFIG_EXCLUSIVE_SYSTEM_RAM=y
-CONFIG_HAVE_BOOTMEM_INFO_NODE=y
 CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
 CONFIG_MEMORY_HOTPLUG=y
 # CONFIG_MHP_DEFAULT_ONLINE_TYPE_OFFLINE is not set

Comment

The only reviewed change replaces CONFIG_ARCH_ENABLE_THP_MIGRATION with CONFIG_ARCH_HAS_PMD_SOFTLEAVES in the kernel config. This is a normal kernel configuration symbol change with no evidence of malicious build logic, network access, privilege escalation, persistence, or packaging integrity issues. It affects runtime kernel behavior only and does not introduce an obvious supply-chain or install-script risk in the package artifacts reviewed.

@@ -1268,7 +1274,7 @@ CONFIG_NUMA_MIGRATION=y
 CONFIG_MIGRATION=y
 CONFIG_DEVICE_MIGRATION=y
 CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION=y
-CONFIG_ARCH_ENABLE_THP_MIGRATION=y
+CONFIG_ARCH_HAS_PMD_SOFTLEAVES=y
 CONFIG_CONTIG_ALLOC=y
 CONFIG_PCP_BATCH_SCALE_MAX=5
 CONFIG_PHYS_ADDR_T_64BIT=y

Comment

The change only enables CONFIG_USERFAULTFD_RWP in the kernel config. This is a kernel feature toggle, not a packaging or build-time execution change, and it does not introduce new sources, scripts, privileges, persistence, or network activity. I found no security red flags in this diff hunk alone.

@@ -1340,6 +1346,7 @@ CONFIG_SECRETMEM=y
 CONFIG_ANON_VMA_NAME=y
 CONFIG_HAVE_ARCH_USERFAULTFD_WP=y
 CONFIG_HAVE_ARCH_USERFAULTFD_MINOR=y
+CONFIG_USERFAULTFD_RWP=y
 CONFIG_USERFAULTFD=y
 CONFIG_PTE_MARKER_UFFD_WP=y
 CONFIG_LRU_GEN=y

Comment

The change only enables an additional Linux kernel configuration option, CONFIG_NET_DSA_TAG_MT7628=m, in the package config. This is a standard kernel module selection for MediaTek MT7628 DSA tagging support and does not introduce build-time downloads, scripts, privilege changes, persistence mechanisms, or packaging integrity issues. No suspicious sources or post-install behavior are involved in this diff hunk.

@@ -1919,6 +1926,7 @@ CONFIG_NET_DSA_TAG_GSWIP=m
 CONFIG_NET_DSA_TAG_DSA_COMMON=m
 CONFIG_NET_DSA_TAG_DSA=m
 CONFIG_NET_DSA_TAG_EDSA=m
+CONFIG_NET_DSA_TAG_MT7628=m
 CONFIG_NET_DSA_TAG_MTK=m
 CONFIG_NET_DSA_TAG_MXL_862XX=m
 CONFIG_NET_DSA_TAG_MXL_GSW1XX=m

Comment

The change only removes three Open vSwitch tunnel module options (GRE, VXLAN, GENEVE) from the kernel config. This is a reduction in functionality, not an integrity or privilege/security concern. No build-time execution, packaging script, or persistence mechanism is introduced. The remaining config still enables Open vSwitch as a module, but the removed options do not create a security issue by themselves.

@@ -2072,9 +2080,6 @@ CONFIG_BATMAN_ADV_MCAST=y
 # CONFIG_BATMAN_ADV_DEBUG is not set
 # CONFIG_BATMAN_ADV_TRACING is not set
 CONFIG_OPENVSWITCH=m
-CONFIG_OPENVSWITCH_GRE=m
-CONFIG_OPENVSWITCH_VXLAN=m
-CONFIG_OPENVSWITCH_GENEVE=m
 CONFIG_VSOCKETS=m
 CONFIG_VSOCKETS_DIAG=m
 CONFIG_VSOCKETS_LOOPBACK=m

Comment

The change only removes an explicit kernel config disable for CONFIG_DMA_FENCE_TRACE. This does not introduce code execution, persistence, privilege escalation, network access, or packaging integrity issues. At most it allows the option to follow the kernel's default/Kconfig selection, which is a low-risk functional change rather than a security concern.

@@ -2490,7 +2495,6 @@ CONFIG_REGMAP_SOUNDWIRE_MBQ=m
 CONFIG_REGMAP_SCCB=m
 CONFIG_REGMAP_SPI_AVMM=m
 CONFIG_DMA_SHARED_BUFFER=y
-# CONFIG_DMA_FENCE_TRACE is not set
 # CONFIG_FW_DEVLINK_SYNC_STATE_TIMEOUT is not set
 # end of Generic Driver Options
 

Comment

The change only enables two additional Qualcomm firmware driver modules in the kernel config (QCOM_PAS and QCOM_PAS_TEE). These are standard in-tree kernel drivers, added as loadable modules, and the diff does not introduce any new sources, build-time downloads, install scripts, privilege changes, or persistence mechanisms. No security-relevant packaging behavior changes are present in this hunk.

@@ -2571,6 +2575,8 @@ CONFIG_UEFI_CPER_X86=y
 #
 # Qualcomm firmware drivers
 #
+CONFIG_QCOM_PAS=m
+CONFIG_QCOM_PAS_TEE=m
 CONFIG_QCOM_SCM=m
 CONFIG_QCOM_TZMEM=m
 CONFIG_QCOM_TZMEM_MODE_GENERIC=y

Comment

The change only removes CONFIG_IBM_ASM from the kernel config, which disables building that optional module. This is a reduction in functionality, not an added execution path, persistence mechanism, or integrity risk. I found no evidence of suspicious sources, build-time downloads, privilege escalation, or packaging-script changes in this hunk.

@@ -2825,7 +2831,6 @@ CONFIG_AD525X_DPOT=m
 CONFIG_AD525X_DPOT_I2C=m
 CONFIG_AD525X_DPOT_SPI=m
 # CONFIG_DUMMY_IRQ is not set
-CONFIG_IBM_ASM=m
 CONFIG_PHANTOM=m
 CONFIG_RPMB=m
 CONFIG_TI_FPC202=m

Comment

The change only toggles a few kernel config options in the shipped Arch kernel config, and the specific hunk under review removes several EEPROM-related modules while leaving other EEPROM support enabled. I do not see any supply-chain, persistence, privilege-escalation, or build-time execution risk in this diff. At worst it changes hardware support coverage, not security posture.

@@ -2860,14 +2865,9 @@ CONFIG_C2PORT_DURAMAR_2150=m
 #
 # EEPROM support
 #
-CONFIG_EEPROM_AT24=m
-# CONFIG_EEPROM_AT25 is not set
 CONFIG_EEPROM_MAX6875=m
 CONFIG_EEPROM_93CX6=m
-# CONFIG_EEPROM_93XX46 is not set
 CONFIG_EEPROM_IDT_89HPESX=m
-CONFIG_EEPROM_EE1004=m
-CONFIG_EEPROM_M24LR=m
 # end of EEPROM support
 
 CONFIG_CB710_CORE=m

Comment

The only change in scope adds two kernel config options: CONFIG_INTEL_SSEI and CONFIG_INTEL_SSEI_HW_HECI as modules. These are standard in-tree kernel drivers, not build-time scripts or packaging logic, and the diff does not introduce any network fetches, privilege escalation, persistence mechanisms, or suspicious install/unit artifacts. No security-relevant red flags are evident from this hunk alone.

@@ -2901,6 +2901,8 @@ CONFIG_PVPANIC_PCI=m
 CONFIG_GP_PCI1XXXX=m
 CONFIG_KEBA_CP500=m
 CONFIG_KEBA_LAN9252=m
+CONFIG_INTEL_SSEI=m
+CONFIG_INTEL_SSEI_HW_HECI=m
 # end of Misc devices
 
 #

Comment

The change only enables an additional kernel driver, CONFIG_SCSI_LEAPRAID=m, in the shipped kernel config. This is a normal kernel feature toggle with no evidence of malicious behavior, privilege escalation, persistence, network access, or packaging hygiene issues. I did not see any accompanying build scripts, install hooks, or source changes that would raise supply-chain concerns in this diff.

@@ -2986,6 +2988,7 @@ CONFIG_SCSI_MPT2SAS_MAX_SGE=128
 CONFIG_SCSI_MPT3SAS_MAX_SGE=128
 CONFIG_SCSI_MPT2SAS=m
 CONFIG_SCSI_MPI3MR=m
+CONFIG_SCSI_LEAPRAID=m
 CONFIG_SCSI_SMARTPQI=m
 CONFIG_SCSI_HPTIOP=m
 CONFIG_SCSI_BUSLOGIC=m

Comment

The change only removes CONFIG_PCMCIA_XIRCOM from the kernel config. This is a benign feature toggle in a kernel package configuration and does not introduce code execution, privilege escalation, network fetching, or packaging integrity issues. No suspicious build/install behavior is present in the provided diff hunk.

@@ -3460,7 +3463,6 @@ CONFIG_TULIP_NAPI_HW_MITIGATION=y
 CONFIG_WINBOND_840=m
 CONFIG_DM9102=m
 CONFIG_ULI526X=m
-CONFIG_PCMCIA_XIRCOM=m
 CONFIG_NET_VENDOR_DLINK=y
 CONFIG_DL2K=m
 CONFIG_SUNDANCE=m

Comment

The change only enables two additional kernel config options, CONFIG_LIBIE_CP and CONFIG_LIBIE_PCI, in an existing Linux kernel configuration. There is no evidence of added scripts, downloads, privilege changes, persistence mechanisms, or other packaging-time execution. This is a routine feature toggle in a kernel config file and does not by itself introduce a supply-chain or post-install risk.

@@ -3492,7 +3494,9 @@ CONFIG_LIBETH=m
 CONFIG_LIBETH_XDP=m
 CONFIG_LIBIE=m
 CONFIG_LIBIE_ADMINQ=m
+CONFIG_LIBIE_CP=m
 CONFIG_LIBIE_FWLOG=m
+CONFIG_LIBIE_PCI=m
 CONFIG_E100=m
 CONFIG_E1000=m
 CONFIG_E1000E=m

Comment

The change only enables two additional kernel config options in an Arch kernel config: CONFIG_IXD=m and CONFIG_ADIN1140=m. These are ordinary driver/module additions for network hardware support and do not introduce build-time code execution, persistence, privilege escalation, or packaging-integrity issues. No suspicious sources, scripts, or install-time behavior are involved in this diff hunk.

@@ -3521,9 +3525,11 @@ CONFIG_IGC=m
 CONFIG_IGC_LEDS=y
 CONFIG_IDPF=m
 # CONFIG_IDPF_SINGLEQ is not set
+CONFIG_IXD=m
 CONFIG_JME=m
 CONFIG_NET_VENDOR_ADI=y
 CONFIG_ADIN1110=m
+CONFIG_ADIN1140=m
 CONFIG_NET_VENDOR_LITEX=y
 CONFIG_NET_VENDOR_MARVELL=y
 CONFIG_MVMDIO=m

Comment

The change only enables CONFIG_SFC_CXL in the kernel config. This is a normal feature toggle for the SFC network driver stack and does not introduce any build-time downloads, scripts, privilege changes, persistence mechanisms, or packaging integrity issues. No suspicious sources or post-install behavior are involved in this hunk.

@@ -3667,6 +3673,7 @@ CONFIG_SFC_MTD=y
 CONFIG_SFC_MCDI_MON=y
 CONFIG_SFC_SRIOV=y
 CONFIG_SFC_MCDI_LOGGING=y
+CONFIG_SFC_CXL=y
 CONFIG_SFC_FALCON=m
 CONFIG_SFC_FALCON_MTD=y
 CONFIG_SFC_SIENA=m

Comment

The change only enables additional kernel network driver options in the shipped config: ZTE and Dinghai/PF support. This is a configuration expansion, not executable build logic, and there are no signs of network fetches, privilege escalation, persistence, or packaging-script abuse in the provided hunk. The main risk is limited to broadening the set of compiled-in modules, which is normal for a kernel package and not inherently malicious.

@@ -3722,6 +3729,9 @@ CONFIG_XILINX_AXI_EMAC=m
 CONFIG_XILINX_LL_TEMAC=m
 CONFIG_NET_VENDOR_XIRCOM=y
 CONFIG_PCMCIA_XIRC2PS=m
+CONFIG_NET_VENDOR_ZTE=y
+CONFIG_DINGHAI=y
+CONFIG_DINGHAI_PF=m
 CONFIG_FDDI=m
 CONFIG_DEFXX=m
 CONFIG_SKFP=m

Comment

The change only enables an additional kernel PHY driver (CONFIG_ADIN1140_PHY=m) in the kernel config. This is a normal feature toggle, does not introduce build-time downloads, privilege escalation, install-script behavior, or suspicious packaging changes. No security concerns are evident from this diff hunk alone.

@@ -3744,6 +3754,7 @@ CONFIG_AIR_NET_PHYLIB=m
 CONFIG_AMD_PHY=m
 CONFIG_ADIN_PHY=m
 CONFIG_ADIN1100_PHY=m
+CONFIG_ADIN1140_PHY=m
 CONFIG_AQUANTIA_PHY=m
 CONFIG_AX88796B_PHY=m
 CONFIG_BROADCOM_PHY=m

Comment

The reviewed hunk only enables three additional kernel config options for Realtek PSE MCU support (I2C/UART variants) as loadable modules. This is a normal feature expansion in a kernel config and does not introduce any obvious supply-chain, persistence, privilege-escalation, or build-time execution risk by itself. No suspicious sources, install scripts, or external downloads are involved in this change. Risk is low.

@@ -3803,6 +3814,9 @@ CONFIG_DP83TG720_PHY=m
 CONFIG_VITESSE_PHY=m
 CONFIG_XILINX_GMII2RGMII=m
 CONFIG_PSE_CONTROLLER=y
+CONFIG_PSE_REALTEK_MCU=m
+CONFIG_PSE_REALTEK_MCU_I2C=m
+CONFIG_PSE_REALTEK_MCU_UART=m
 CONFIG_PSE_REGULATOR=m
 CONFIG_PSE_PD692X0=m
 CONFIG_PSE_SI3474=m

Comment

The change only enables an additional kernel config option, CONFIG_MCTP_TRANSPORT_USBLIB=m, and adds a comment header for MDIO controller drivers. This is a routine feature toggle in a kernel config file with no evidence of malicious build logic, persistence, privilege escalation, network fetches, or packaging-script changes. I do not see any security-relevant risk introduced by this hunk itself.

@@ -3880,9 +3894,13 @@ CONFIG_CAN_UCAN=m
 #
 CONFIG_MCTP_SERIAL=m
 CONFIG_MCTP_TRANSPORT_I2C=m
+CONFIG_MCTP_TRANSPORT_USBLIB=m
 CONFIG_MCTP_TRANSPORT_USB=m
 # end of MCTP Device Drivers
 
+#
+# MDIO controller drivers
+#
 CONFIG_FWNODE_MDIO=m
 CONFIG_ACPI_MDIO=m
 CONFIG_MDIO_BITBANG=m

Comment

The change only adds two comment lines to the kernel config file, with no effect on build behavior, runtime behavior, sources, scripts, permissions, or package metadata. There are no security-relevant changes in this hunk.

@@ -3898,6 +3916,8 @@ CONFIG_MDIO_THUNDER=m
 #
 # MDIO Multiplexers
 #
+# end of MDIO Multiplexers
+# end of MDIO controller drivers
 
 #
 # PCS device drivers

Comment

The reviewed hunk only enables additional Wi‑Fi vendor drivers (Morse Micro and NXP) and their module options. This is a normal kernel configuration expansion, with no evidence of network fetches, install-script behavior, privilege escalation, or other supply-chain red flags in the change itself. The added options are kernel modules built from in-tree sources, not external binaries or scripts. Risk is low.

@@ -4186,6 +4206,13 @@ CONFIG_WILC1000=m
 CONFIG_WILC1000_SDIO=m
 CONFIG_WILC1000_SPI=m
 # CONFIG_WILC1000_HW_OOB_INTR is not set
+CONFIG_WLAN_VENDOR_MORSEMICRO=y
+CONFIG_MM81X=m
+CONFIG_MM81X_USB=m
+CONFIG_MM81X_SDIO=m
+CONFIG_WLAN_VENDOR_NXP=y
+CONFIG_NXPWIFI=m
+CONFIG_NXPWIFI_SDIO=m
 CONFIG_WLAN_VENDOR_PURELIFI=y
 CONFIG_PLFXLC=m
 CONFIG_WLAN_VENDOR_RALINK=y

Comment

The change only enables an additional Realtek Wi‑Fi driver module (CONFIG_RTW89_8922D=m) in the kernel config. This is a normal kernel feature toggle, with no evidence of network fetches, privilege escalation, persistence, or packaging hygiene issues in the provided hunk. It does expand the set of included kernel modules, but that is expected for a kernel package and not inherently suspicious.

@@ -4289,6 +4316,7 @@ CONFIG_RTW89_8852B=m
 CONFIG_RTW89_8852BT=m
 CONFIG_RTW89_8852C=m
 CONFIG_RTW89_8922A=m
+CONFIG_RTW89_8922D=m
 CONFIG_RTW89_8851BE=m
 CONFIG_RTW89_8851BU=m
 CONFIG_RTW89_8852AE=m

Comment

The change only enables additional Realtek rtw89 kernel config options: support for the 8922DE device and LED integration (RTW89_LEDS/RTW89_LEDS_MC). This is a straightforward feature expansion in a kernel config, with no evidence of network access, privilege escalation, persistence, or packaging-time code execution. I did not see any suspicious source, script, or install-time behavior in the provided hunk.

@@ -4300,9 +4328,12 @@ CONFIG_RTW89_8852CE=m
 CONFIG_RTW89_8852CU=m
 CONFIG_RTW89_8922AE=m
 CONFIG_RTW89_8922AU=m
+CONFIG_RTW89_8922DE=m
 CONFIG_RTW89_DEBUG=y
 CONFIG_RTW89_DEBUGMSG=y
 CONFIG_RTW89_DEBUGFS=y
+CONFIG_RTW89_LEDS=y
+CONFIG_RTW89_LEDS_MC=y
 CONFIG_WLAN_VENDOR_RSI=y
 CONFIG_RSI_91X=m
 CONFIG_RSI_DEBUGFS=y

Comment

The change only enables two additional kernel config options: CONFIG_INPUT_ISA1200_HAPTIC and CONFIG_INPUT_AMD_SFH_TABLETMODE. Both are ordinary input-device drivers, with no evidence of network access, privilege escalation, persistence, or packaging hygiene issues. In the context of this diff, this is a low-risk feature enablement rather than a security-sensitive change.

@@ -4663,11 +4694,13 @@ CONFIG_INPUT_IMS_PCU=m
 CONFIG_INPUT_IQS269A=m
 CONFIG_INPUT_IQS626A=m
 CONFIG_INPUT_IQS7222=m
+CONFIG_INPUT_ISA1200_HAPTIC=m
 CONFIG_INPUT_CMA3000=m
 CONFIG_INPUT_CMA3000_I2C=m
 CONFIG_INPUT_XEN_KBDDEV_FRONTEND=m
 CONFIG_INPUT_IDEAPAD_SLIDEBAR=m
 CONFIG_INPUT_SOC_BUTTON_ARRAY=m
+CONFIG_INPUT_AMD_SFH_TABLETMODE=m
 CONFIG_INPUT_DRV260X_HAPTICS=m
 CONFIG_INPUT_DRV2665_HAPTICS=m
 CONFIG_INPUT_DRV2667_HAPTICS=m

Comment

The change only enables an additional kernel driver module, CONFIG_SERIAL_8250_MOXA_PCIE=m, in the shipped kernel config. This is a normal hardware-support addition with no evidence of network access, privilege escalation, persistence, or packaging integrity issues. I did not see any suspicious build-time execution or install-script behavior in the provided diff hunk.

@@ -4741,6 +4774,7 @@ CONFIG_SERIAL_8250_DMA=y
 CONFIG_SERIAL_8250_PCILIB=y
 CONFIG_SERIAL_8250_PCI=y
 CONFIG_SERIAL_8250_EXAR=m
+CONFIG_SERIAL_8250_MOXA_PCIE=m
 CONFIG_SERIAL_8250_CS=m
 CONFIG_SERIAL_8250_MEN_MCB=m
 CONFIG_SERIAL_8250_NR_UARTS=32

Comment

The change only removes CONFIG_IPWIRELESS=m from the kernel config. This disables building the ipwireless driver as a module; it does not add code execution, persistence, privilege escalation, network fetches, or packaging/install-script behavior. I see no security concern in this diff hunk by itself.

@@ -4795,7 +4829,6 @@ CONFIG_SERIAL_NONSTANDARD=y
 CONFIG_MOXA_INTELLIO=m
 CONFIG_MOXA_SMARTIO=m
 CONFIG_N_HDLC=m
-CONFIG_IPWIRELESS=m
 # CONFIG_N_GSM is not set
 CONFIG_NOZOMI=m
 CONFIG_NULL_TTY=m

Comment

The change only enables CONFIG_RUST_SERIAL_DEV_BUS_ABSTRACTIONS in the kernel config. This is a build-time feature toggle for an in-tree kernel subsystem, with no added scripts, downloads, privilege changes, or packaging/install-time behavior. I don't see any security-relevant red flags in this isolated config change.

@@ -4805,6 +4838,7 @@ CONFIG_HVC_XEN=y
 CONFIG_HVC_XEN_FRONTEND=y
 CONFIG_RPMSG_TTY=m
 CONFIG_SERIAL_DEV_BUS=y
+CONFIG_RUST_SERIAL_DEV_BUS_ABSTRACTIONS=y
 CONFIG_SERIAL_DEV_CTRL_TTYPORT=y
 CONFIG_PRINTER=m
 CONFIG_LP_CONSOLE=y

Comment

The change only enables CONFIG_IPMI_SI_ASYNC_INIT in the kernel config. This is a kernel build-time option affecting IPMI System Interface initialization behavior; it does not introduce new sources, scripts, network access, privilege escalation, persistence, or packaging-time execution. I see no security red flags in this isolated config toggle.

@@ -4816,6 +4850,7 @@ CONFIG_IPMI_PLAT_DATA=y
 # CONFIG_IPMI_PANIC_EVENT is not set
 CONFIG_IPMI_DEVICE_INTERFACE=m
 CONFIG_IPMI_SI=m
+CONFIG_IPMI_SI_ASYNC_INIT=y
 CONFIG_IPMI_SSIF=m
 CONFIG_IPMI_IPMB=m
 CONFIG_IPMI_WATCHDOG=m

Comment

The change only enables two additional kernel charger driver modules in the shipped kernel config: CONFIG_CHARGER_BQ25630 and CONFIG_CHARGER_SGM41542. This is a routine hardware-support update with no evidence of network access, privilege escalation, persistence, or packaging integrity issues. No suspicious sources, scripts, or install-time behavior are involved in this diff.

@@ -5420,7 +5455,9 @@ CONFIG_CHARGER_BQ2515X=m
 CONFIG_CHARGER_BQ257XX=m
 CONFIG_CHARGER_BQ25890=m
 CONFIG_CHARGER_BQ25980=m
+CONFIG_CHARGER_BQ25630=m
 CONFIG_CHARGER_BQ256XX=m
+CONFIG_CHARGER_SGM41542=m
 CONFIG_CHARGER_SMB347=m
 CONFIG_CHARGER_TPS65090=m
 CONFIG_BATTERY_GAUGE_LTC2941=m

Comment

The change only enables the kernel config option CONFIG_SENSORS_KB9002 as a loadable module. This is a standard hardware-monitoring driver toggle in the kernel config and does not introduce any packaging-time code execution, network access, privilege escalation, persistence mechanism, or suspicious source/integrity change. No security concerns are evident from this diff alone.

@@ -5476,6 +5513,7 @@ CONFIG_SENSORS_ASUS_ROG_RYUJIN=m
 CONFIG_SENSORS_AXI_FAN_CONTROL=m
 CONFIG_SENSORS_K8TEMP=m
 CONFIG_SENSORS_K10TEMP=m
+CONFIG_SENSORS_KB9002=m
 CONFIG_SENSORS_KBATT=m
 CONFIG_SENSORS_KFAN=m
 CONFIG_SENSORS_FAM15H_POWER=m

Comment

The change only enables two additional Linux kernel hardware-monitoring drivers as modules and explicitly leaves the MPQ8646 debug/unsafe option disabled. There are no signs of network access, script execution, privilege escalation, persistence, or packaging integrity issues in this hunk. This is a low-risk kernel config expansion for additional device support.

@@ -5667,7 +5705,10 @@ CONFIG_SENSORS_MP9941=m
 CONFIG_SENSORS_MP9945=m
 CONFIG_SENSORS_MPQ7932_REGULATOR=y
 CONFIG_SENSORS_MPQ7932=m
+CONFIG_SENSORS_MPQ82D00=m
 CONFIG_SENSORS_MPQ8785=m
+CONFIG_SENSORS_MPQ8646=m
+# CONFIG_SENSORS_MPQ8646_DEBUG_UNSAFE is not set
 CONFIG_SENSORS_PIM4328=m
 CONFIG_SENSORS_PLI1209BC=m
 CONFIG_SENSORS_PLI1209BC_REGULATOR=y

Comment

The change only enables two additional kernel configuration options for the SQ24860 sensor driver and its regulator support. This is a normal hardware-support addition in a kernel package config, with no evidence of network access, post-install actions, privilege escalation, or suspicious packaging behavior. I did not see any red flags in the provided hunk.

@@ -5675,6 +5716,8 @@ CONFIG_SENSORS_PM6764TR=m
 CONFIG_SENSORS_PXE1610=m
 CONFIG_SENSORS_Q54SJ108A2=m
 CONFIG_SENSORS_STEF48H28=m
+CONFIG_SENSORS_SQ24860=m
+CONFIG_SENSORS_SQ24860_REGULATOR=y
 CONFIG_SENSORS_STPDDC60=m
 CONFIG_SENSORS_TDA38640=m
 CONFIG_SENSORS_TDA38640_REGULATOR=y

Comment

The change only enables two additional kernel hwmon options in the shipped kernel config: VT7505 sensor support and the XDPE1A2G7B regulator helper, while removing SBTSI. This is a normal feature/configuration adjustment with no evidence of malicious build steps, persistence, privilege escalation, network access, or packaging integrity issues in the diff shown. Risk is low.

@@ -5685,17 +5728,18 @@ CONFIG_SENSORS_TPS53679=m
 CONFIG_SENSORS_TPS546D24=m
 CONFIG_SENSORS_UCD9000=m
 CONFIG_SENSORS_UCD9200=m
+CONFIG_SENSORS_VT7505=m
 CONFIG_SENSORS_XDP710=m
 CONFIG_SENSORS_XDP720=m
 CONFIG_SENSORS_XDPE152=m
 CONFIG_SENSORS_XDPE1A2G7B=m
+CONFIG_SENSORS_XDPE1A2G7B_REGULATOR=y
 CONFIG_SENSORS_XDPE122=m
 CONFIG_SENSORS_XDPE122_REGULATOR=y
 CONFIG_SENSORS_ZL6100=m
 CONFIG_SENSORS_PT5161L=m
 CONFIG_SENSORS_PWM_FAN=m
 CONFIG_SENSORS_QNAP_MCU_HWMON=m
-CONFIG_SENSORS_SBTSI=m
 CONFIG_SENSORS_SHT15=m
 CONFIG_SENSORS_SHT21=m
 CONFIG_SENSORS_SHT3x=m

Comment

The change only enables an additional kernel watchdog pretimeout governor module (CONFIG_WATCHDOG_PRETIMEOUT_GOV_DUMP) and explicitly leaves the default governor unset. This is a small kernel configuration adjustment with no evidence of network access, privilege escalation, persistence, or packaging integrity issues. It does not introduce new scripts, binaries, or install-time behavior.

@@ -5827,8 +5871,10 @@ CONFIG_WATCHDOG_SYSFS=y
 #
 CONFIG_WATCHDOG_PRETIMEOUT_GOV=y
 CONFIG_WATCHDOG_PRETIMEOUT_GOV_SEL=m
+CONFIG_WATCHDOG_PRETIMEOUT_GOV_DUMP=m
 CONFIG_WATCHDOG_PRETIMEOUT_GOV_NOOP=m
 CONFIG_WATCHDOG_PRETIMEOUT_GOV_PANIC=y
+# CONFIG_WATCHDOG_PRETIMEOUT_DEFAULT_GOV_DUMP is not set
 # CONFIG_WATCHDOG_PRETIMEOUT_DEFAULT_GOV_NOOP is not set
 CONFIG_WATCHDOG_PRETIMEOUT_DEFAULT_GOV_PANIC=y
 

Comment

The change only enables one additional Linux kernel watchdog driver option in the shipped kernel config: CONFIG_LENOVO_SE30G2_SE60_WDT=m. This is a normal hardware-support toggle, does not introduce build-time downloads, scripts, privilege changes, persistence mechanisms, or packaging hygiene issues. No suspicious sources or executable artifacts are involved in this diff hunk.

@@ -5845,6 +5891,7 @@ CONFIG_DA9062_WATCHDOG=m
 CONFIG_GPIO_WATCHDOG=m
 CONFIG_LENOVO_SE10_WDT=m
 CONFIG_LENOVO_SE30_WDT=m
+CONFIG_LENOVO_SE30G2_SE60_WDT=m
 CONFIG_MENF21BMC_WATCHDOG=m
 CONFIG_MENZ069_WATCHDOG=m
 CONFIG_WDAT_WDT=m

Comment

The change only removes CONFIG_V4L2_LOOPBACK=m from the kernel config. This disables the v4l2loopback module rather than adding code, privileges, persistence, or network behavior. I don't see any security-sensitive functionality introduced by this diff; if anything it reduces attack surface slightly by omitting a module. No red flags in the provided hunk.

@@ -6285,7 +6332,6 @@ CONFIG_VIDEO_V4L2_SUBDEV_API=y
 # CONFIG_VIDEO_ADV_DEBUG is not set
 # CONFIG_VIDEO_FIXED_MINOR_RANGES is not set
 CONFIG_VIDEO_TUNER=m
-CONFIG_V4L2_LOOPBACK=m
 CONFIG_V4L2_MEM2MEM_DEV=m
 CONFIG_V4L2_FLASH_LED_CLASS=m
 CONFIG_V4L2_FWNODE=m

Comment

The change only enables two additional Linux kernel camera sensor drivers (IMX471 and IMX678) in the kernel config. This is a straightforward feature addition with no evidence of malicious behavior: no build-time code execution, no network access, no privilege changes, and no packaging/install-script impact. The diff is limited to toggling kernel modules from disabled to module-built, which is normal for a kernel config update.

@@ -6763,6 +6809,8 @@ CONFIG_VIDEO_IMX290=m
 CONFIG_VIDEO_IMX296=m
 CONFIG_VIDEO_IMX319=m
 CONFIG_VIDEO_IMX355=m
+CONFIG_VIDEO_IMX471=m
+CONFIG_VIDEO_IMX678=m
 CONFIG_VIDEO_MAX9271_LIB=m
 CONFIG_VIDEO_MT9M001=m
 CONFIG_VIDEO_MT9M111=m

Comment

The change only enables the kernel backlight driver CONFIG_BACKLIGHT_SY7758 as a module in the shipped kernel config. This is a normal feature toggle with no evidence of malicious behavior, privilege escalation, persistence, network access, or packaging integrity issues. No suspicious build/install script changes are involved in the provided hunk.

@@ -7411,6 +7459,7 @@ CONFIG_BACKLIGHT_AW99706=m
 CONFIG_BACKLIGHT_KTD253=m
 CONFIG_BACKLIGHT_KTD2801=m
 CONFIG_BACKLIGHT_KTZ8866=m
+CONFIG_BACKLIGHT_SY7758=m
 CONFIG_BACKLIGHT_LM3533=m
 CONFIG_BACKLIGHT_PWM=m
 CONFIG_BACKLIGHT_CGBC=m

Comment

The only change in scope adds two ALSA HDA codec driver options (AW88399 and its I2C helper) to the kernel config. These are standard in-tree kernel modules, not external code or build-time downloads, and the change does not introduce privilege escalation, persistence, or packaging hygiene issues. No suspicious sources, scripts, or install-time actions are involved in this hunk.

@@ -7669,6 +7718,8 @@ CONFIG_SND_HDA_CODEC_HDMI_NVIDIA=m
 CONFIG_SND_HDA_CODEC_HDMI_NVIDIA_MCP=m
 CONFIG_SND_HDA_CODEC_HDMI_TEGRA=m
 CONFIG_SND_HDA_CIRRUS_SCODEC=m
+CONFIG_SND_HDA_SCODEC_AW88399=m
+CONFIG_SND_HDA_SCODEC_AW88399_I2C=m
 CONFIG_SND_HDA_SCODEC_CS35L41=m
 CONFIG_SND_HDA_SCODEC_COMPONENT=m
 CONFIG_SND_HDA_SCODEC_CS35L41_I2C=m

Comment

The change is a single kernel config enablement: it adds CONFIG_SND_SOC_SOF_AMD_ACP7X=m. This is a normal feature toggle for AMD audio/SoF support and does not introduce any build-time downloads, script execution, privilege changes, persistence mechanisms, or packaging integrity issues. No suspicious sources or install scripts are involved in this hunk. Risk is therefore minimal.

@@ -8029,6 +8080,7 @@ CONFIG_SND_SOC_SOF_AMD_SOUNDWIRE_LINK_BASELINE=m
 CONFIG_SND_SOC_SOF_AMD_SOUNDWIRE=m
 CONFIG_SND_SOC_SOF_AMD_ACP63=m
 CONFIG_SND_SOC_SOF_AMD_ACP70=m
+CONFIG_SND_SOC_SOF_AMD_ACP7X=m
 CONFIG_SND_SOC_SOF_INTEL_TOPLEVEL=y
 CONFIG_SND_SOC_SOF_INTEL_HIFI_EP_IPC=m
 CONFIG_SND_SOC_SOF_INTEL_ATOM_HIFI_EP=m

Comment

The change only enables an additional Linux kernel sound codec library module (CONFIG_SND_SOC_AW88399_LIB=m) alongside an existing AW88399 codec module. This is a straightforward kernel configuration adjustment with no evidence of network access, script execution, privilege escalation, persistence, or packaging integrity issues. No suspicious sources or install-time behavior are involved in this diff hunk.

@@ -8113,6 +8165,7 @@ CONFIG_SND_SOC_AW88166=m
 CONFIG_SND_SOC_AW88261=m
 CONFIG_SND_SOC_AW88081=m
 CONFIG_SND_SOC_AW87390=m
+CONFIG_SND_SOC_AW88399_LIB=m
 CONFIG_SND_SOC_AW88399=m
 CONFIG_SND_SOC_BD28623=m
 # CONFIG_SND_SOC_BT_SCO is not set

Comment

The change is a single kernel config enablement: it adds CONFIG_SND_SOC_RT766_SDCA_SDW=m, which builds the Realtek RT766 SDCA SoundWire codec driver as a module. This is a normal upstream kernel feature toggle with no evidence of malicious behavior, no build-time network access, no script execution, and no packaging/persistence changes. I see no security concern in this diff alone.

@@ -8286,6 +8339,7 @@ CONFIG_SND_SOC_RT722_SDCA_SDW=m
 CONFIG_SND_SOC_RT715=m
 CONFIG_SND_SOC_RT715_SDW=m
 CONFIG_SND_SOC_RT715_SDCA_SDW=m
+CONFIG_SND_SOC_RT766_SDCA_SDW=m
 CONFIG_SND_SOC_RT9120=m
 CONFIG_SND_SOC_RT9123=m
 CONFIG_SND_SOC_RT9123P=m

Comment

The change only enables an additional Linux kernel sound codec driver (CONFIG_SND_SOC_WSA885X=m) in the package config. This is a routine kernel configuration update with no evidence of malicious behavior: no new sources, scripts, install hooks, privilege changes, or build-time network access. The added option is consistent with nearby Qualcomm audio codec options already enabled in the config.

@@ -8395,6 +8449,7 @@ CONFIG_SND_SOC_WM8998=m
 CONFIG_SND_SOC_WSA881X=m
 CONFIG_SND_SOC_WSA883X=m
 CONFIG_SND_SOC_WSA884X=m
+CONFIG_SND_SOC_WSA885X=m
 CONFIG_SND_SOC_ZL38060=m
 CONFIG_SND_SOC_MAX9759=m
 CONFIG_SND_SOC_MT6351=m

Comment

The only reviewed change enables two additional HID kernel modules (HID_HYPERX and HID_MSI) in the kernel config. This is a routine hardware-support expansion with no evidence of network access, privilege escalation, persistence, or packaging integrity issues in the diff hunk itself. No suspicious build-time behavior is introduced by this config-only change.

@@ -8483,12 +8538,14 @@ CONFIG_HID_GFRM=m
 CONFIG_HID_GLORIOUS=m
 CONFIG_HID_HOLTEK=m
 CONFIG_HOLTEK_FF=y
+CONFIG_HID_HYPERX=m
 CONFIG_HID_VIVALDI_COMMON=m
 CONFIG_HID_GOODIX_SPI=m
 CONFIG_HID_GOOGLE_HAMMER=m
 CONFIG_HID_GOOGLE_STADIA_FF=m
 CONFIG_HID_VIVALDI=m
 CONFIG_HID_GT683R=m
+CONFIG_HID_MSI=m
 CONFIG_HID_KEYTOUCH=m
 CONFIG_HID_KYE=m
 CONFIG_HID_KYSONA=m

Comment

The change only enables the kernel LED driver CONFIG_LEDS_LTC3220 as a module in the package config. This is a normal upstream kernel configuration toggle with no evidence of added build-time execution, network access, privilege escalation, persistence, or packaging integrity issues. No suspicious sources or scripts are involved in this hunk.

@@ -9197,6 +9254,7 @@ CONFIG_LEDS_NIC78BX=m
 CONFIG_LEDS_SPI_BYTE=m
 CONFIG_LEDS_TI_LMU_COMMON=m
 CONFIG_LEDS_LM36274=m
+CONFIG_LEDS_LTC3220=m
 CONFIG_LEDS_TPS6105X=m
 
 #

Comment

The change only disables CONFIG_XEN_AUTO_XLATE in the kernel config. This is a build-time configuration adjustment, not a code or packaging execution change, and it does not introduce network access, privilege escalation, persistence, or integrity risks. I see no security concern in this diff hunk alone.

@@ -9673,7 +9731,6 @@ CONFIG_XEN_ACPI_PROCESSOR=m
 CONFIG_XEN_MCE_LOG=y
 CONFIG_XEN_HAVE_PVMMU=y
 CONFIG_XEN_EFI=y
-CONFIG_XEN_AUTO_XLATE=y
 CONFIG_XEN_ACPI=y
 CONFIG_XEN_SYMS=y
 CONFIG_XEN_HAVE_VPMU=y

Comment

The change only enables two additional kernel configuration options in the shipped config: CONFIG_AMD_PMF_UTIL_SUPPORT=y and CONFIG_AMD_HALO_LED=m. This is a kernel build-time configuration change, not a PKGBUILD/script change, and there is no evidence here of network access, privilege escalation, persistence, or other supply-chain abuse. The added options appear to be ordinary AMD platform/LED support features and do not by themselves introduce a security concern in the package metadata or build process.

@@ -9834,11 +9891,13 @@ CONFIG_AMD_HSMP_PLAT=m
 
 CONFIG_AMD_PMF=m
 # CONFIG_AMD_PMF_DEBUG is not set
+CONFIG_AMD_PMF_UTIL_SUPPORT=y
 CONFIG_AMD_PMC=m
 CONFIG_AMD_MP2_STB=y
 CONFIG_AMD_HFI=y
 CONFIG_AMD_3D_VCACHE=y
 CONFIG_AMD_WBRF=y
+CONFIG_AMD_HALO_LED=m
 CONFIG_AMD_ISP_PLATFORM=m
 CONFIG_ADV_SWBUTTON=m
 CONFIG_APPLE_GMUX=m

Comment

The only reviewed change is enabling CONFIG_LENOVO_YB9_KBDOCK=m in the kernel config. This is a normal kernel driver toggle, with no evidence of malicious build steps, external downloads, install scripts, or privilege/persistence mechanisms. It does not alter package metadata or introduce suspicious sources. Low risk.

@@ -9942,6 +10001,7 @@ CONFIG_INTEL_VSEC=m
 CONFIG_IDEAPAD_LAPTOP=m
 CONFIG_LENOVO_WMI_HOTKEY_UTILITIES=m
 CONFIG_LENOVO_WMI_CAMERA=m
+CONFIG_LENOVO_YB9_KBDOCK=m
 CONFIG_LENOVO_YMC=m
 CONFIG_THINKPAD_ACPI=m
 CONFIG_THINKPAD_ACPI_ALSA_SUPPORT=y

Comment

The only change in scope is the insertion of a comment block in the kernel config around the Cixtech Audio Subsystem Clock Driver. It does not enable any new option, alter build commands, add sources, or change packaging/install behavior. No security-relevant behavior is introduced by this hunk.

@@ -10023,6 +10083,12 @@ CONFIG_CLK_TWL=m
 CONFIG_CLK_TWL6040=m
 CONFIG_COMMON_CLK_PALMAS=m
 CONFIG_COMMON_CLK_PWM=m
+
+#
+# Cixtech Audio Subsystem Clock Driver
+#
+# end of Cixtech Audio Subsystem Clock Driver
+
 CONFIG_XILINX_VCU=m
 CONFIG_HWSPINLOCK=y
 

Comment

The only change in the provided hunk is removal of one Qualcomm kernel config option, CONFIG_QCOM_PMIC_PDCHARGER_ULOG, and some surrounding comment lines. This is a reduction in enabled functionality, not an addition of code, persistence, privilege escalation, or network behavior. No suspicious build/install artifacts are involved in this hunk. Security impact appears negligible.

@@ -10140,15 +10206,8 @@ CONFIG_SOUNDWIRE_GENERIC_ALLOCATION=m
 # end of Enable LiteX SoC Builder specific drivers
 
 CONFIG_WPCM450_SOC=m
-
-#
-# Qualcomm SoC drivers
-#
 CONFIG_QCOM_MDT_LOADER=m
-CONFIG_QCOM_PMIC_PDCHARGER_ULOG=m
 CONFIG_QCOM_QMI_HELPERS=m
-# end of Qualcomm SoC drivers
-
 CONFIG_SOC_TI=y
 
 #

Comment

The change only enables CONFIG_LTC2378 as a loadable kernel module in the kernel config. This is a normal hardware-support addition with no evidence of network access, privilege escalation, persistence, or packaging integrity issues. No suspicious build-time behavior or post-install logic is involved in this hunk.

@@ -10375,6 +10434,7 @@ CONFIG_INTEL_DC_TI_ADC=m
 CONFIG_INTEL_MRFLD_ADC=m
 CONFIG_LP8788_ADC=m
 CONFIG_LTC2309=m
+CONFIG_LTC2378=m
 CONFIG_LTC2471=m
 CONFIG_LTC2485=m
 CONFIG_LTC2496=m

Comment

The change only enables one additional Linux kernel ADC driver option in the shipped kernel config: CONFIG_MEDIATEK_MT6323_AUXADC=m. This is a normal kernel feature toggle, with no evidence of network access, script execution, privilege escalation, persistence, or packaging hygiene issues. I did not find any suspicious source, install script, or unit-file behavior associated with this hunk. Risk is therefore minimal.

@@ -10394,6 +10454,7 @@ CONFIG_MCP320X=m
 CONFIG_MCP3422=m
 CONFIG_MCP3564=m
 CONFIG_MCP3911=m
+CONFIG_MEDIATEK_MT6323_AUXADC=m
 CONFIG_MEDIATEK_MT6359_AUXADC=m
 CONFIG_MEDIATEK_MT6360_ADC=m
 CONFIG_MEDIATEK_MT6370_ADC=m

Comment

The change only enables an additional Linux kernel driver option (CONFIG_TI_ADS112C14=m) in the package config. This is a normal kernel configuration adjustment, does not introduce new build-time downloads, scripts, privilege changes, or packaging/install behavior, and the option is built as a module rather than built-in. No security concerns are evident from this diff alone.

@@ -10419,6 +10480,7 @@ CONFIG_TI_ADS1015=m
 CONFIG_TI_ADS1018=m
 CONFIG_TI_ADS1100=m
 CONFIG_TI_ADS1119=m
+CONFIG_TI_ADS112C14=m
 CONFIG_TI_ADS124S08=m
 CONFIG_TI_ADS1298=m
 CONFIG_TI_ADS131E08=m

Comment

The change only enables two additional Linux kernel driver modules in the shipped kernel config: CONFIG_VERSAL_SYSMON_CORE and CONFIG_VERSAL_SYSMON_I2C. These are standard upstream kernel options for Versal system monitoring hardware and do not introduce any build-time downloads, script execution, privilege escalation, persistence, or packaging integrity issues. No suspicious sources or install scripts are implicated by this config-only change.

@@ -10433,6 +10495,8 @@ CONFIG_TI_TLC4541=m
 CONFIG_TI_TSC2046=m
 CONFIG_TWL4030_MADC=m
 CONFIG_TWL6030_GPADC=m
+CONFIG_VERSAL_SYSMON_CORE=m
+CONFIG_VERSAL_SYSMON_I2C=m
 CONFIG_VF610_ADC=m
 CONFIG_VIPERBOARD_ADC=m
 CONFIG_XILINX_XADC=m

Comment

The change only enables the kernel driver CONFIG_MCP47A1 as a module in the shipped kernel config. This is a normal hardware-support addition with no evidence of malicious behavior, privilege escalation, persistence, network access, or packaging integrity issues. No suspicious scripts, sources, or install-time actions are involved in this hunk.

@@ -10578,6 +10642,7 @@ CONFIG_MAX5522=m
 CONFIG_MAX5821=m
 CONFIG_MCP4725=m
 CONFIG_MCP4728=m
+CONFIG_MCP47A1=m
 CONFIG_MCP47FEB02=m
 CONFIG_MCP4821=m
 CONFIG_MCP4922=m

Comment

The only change in the reviewed hunk is enabling CONFIG_SENSIRION_SLF3S as a module in the kernel config. This is a normal upstream driver toggle for a flow sensor and does not introduce any obvious supply-chain, persistence, privilege-escalation, or build-time execution risk. No suspicious sources, scripts, or packaging changes are involved in this diff.

@@ -10601,6 +10666,12 @@ CONFIG_ADMV8818=m
 # end of Filters
 
 #
+# Flow sensors
+#
+CONFIG_SENSIRION_SLF3S=m
+# end of Flow sensors
+
+#
 # Frequency Synthesizers DDS/PLL
 #
 

Comment

The change only enables one additional Linux kernel driver, CONFIG_ADF41513=m, in the kernel config. This is a normal upstream-style configuration change for a specific PLL frequency synthesizer driver and does not introduce build-time downloads, scripts, privilege changes, persistence mechanisms, or other security-relevant packaging behavior. No suspicious sources or install-time actions are involved in this diff hunk.

@@ -10613,6 +10684,7 @@ CONFIG_AD9523=m
 #
 # Phase-Locked Loop (PLL) frequency synthesizers
 #
+CONFIG_ADF41513=m
 CONFIG_ADF4350=m
 CONFIG_ADF4371=m
 CONFIG_ADF4377=m

Comment

The only change in scope adds three kernel config options for the InvenSense ICM42607 sensor (module + I2C/SPI support). This is a normal hardware enablement change in a kernel config file and does not introduce any build-time execution, network access, privilege escalation, persistence, or packaging integrity concerns. No suspicious sources or scripts are involved in this hunk.

@@ -10707,6 +10779,9 @@ CONFIG_KMX61=m
 CONFIG_INV_ICM42600=m
 CONFIG_INV_ICM42600_I2C=m
 CONFIG_INV_ICM42600_SPI=m
+CONFIG_INV_ICM42607=m
+CONFIG_INV_ICM42607_I2C=m
+CONFIG_INV_ICM42607_SPI=m
 CONFIG_INV_ICM45600=m
 CONFIG_INV_ICM45600_I2C=m
 CONFIG_INV_ICM45600_SPI=m

Comment

The only change in the reviewed hunk is enabling two additional kernel IIO magnetometer drivers (QMC5883L and QMC6308) as modules. This is a normal feature expansion in a kernel config, with no evidence of malicious behavior, privilege escalation, persistence, network access, or integrity issues in the diff itself. No suspicious packaging artifacts are involved in this specific change.

@@ -10822,6 +10897,8 @@ CONFIG_IIO_ST_MAGN_3AXIS=m
 CONFIG_IIO_ST_MAGN_I2C_3AXIS=m
 CONFIG_IIO_ST_MAGN_SPI_3AXIS=m
 CONFIG_INFINEON_TLV493D=m
+CONFIG_QMC5883L=m
+CONFIG_QMC6308=m
 CONFIG_SENSORS_HMC5843=m
 CONFIG_SENSORS_HMC5843_I2C=m
 CONFIG_SENSORS_HMC5843_SPI=m

Comment

The only change in scope is enabling a few EEPROM-related kernel modules (at24, ee1004, m24lr) and explicitly disabling two others. This is a normal kernel config expansion for hardware support and does not introduce build-time code execution, network access, privilege escalation, persistence, or packaging hygiene issues. No suspicious sources or install scripts are involved in this diff. Low risk.

@@ -11118,6 +11195,11 @@ CONFIG_DEV_DAX_KMEM=m
 CONFIG_NVMEM=y
 CONFIG_NVMEM_SYSFS=y
 # CONFIG_NVMEM_LAYOUTS is not set
+CONFIG_EEPROM_AT24=m
+# CONFIG_EEPROM_AT25 is not set
+# CONFIG_EEPROM_93XX46 is not set
+CONFIG_EEPROM_EE1004=m
+CONFIG_EEPROM_M24LR=m
 CONFIG_NVMEM_QNAP_MCU_EEPROM=m
 CONFIG_NVMEM_RAVE_SP_EEPROM=m
 CONFIG_NVMEM_RMEM=m

Comment

The change only disables CONFIG_CACHEFILES_ONDEMAND in the kernel config. This removes an optional cachefiles feature and does not introduce any new code execution, privilege escalation, persistence, network access, or packaging integrity concerns. No suspicious build/install behavior is present in the provided hunk.

@@ -11316,7 +11398,6 @@ CONFIG_FSCACHE_STATS=y
 CONFIG_CACHEFILES=m
 # CONFIG_CACHEFILES_DEBUG is not set
 # CONFIG_CACHEFILES_ERROR_INJECTION is not set
-CONFIG_CACHEFILES_ONDEMAND=y
 # end of Caches
 
 #

Comment

The change only enables CONFIG_NTFS_FS_WOF_COMPRESSION in the kernel config. This is a kernel feature toggle, not a packaging or install-script change, and it does not introduce any obvious supply-chain, persistence, privilege-escalation, or network behavior. I did not find any accompanying source, patch, or script changes in this hunk that would raise security concerns.

@@ -11340,6 +11421,7 @@ CONFIG_FAT_DEFAULT_UTF8=y
 CONFIG_EXFAT_FS=m
 CONFIG_EXFAT_DEFAULT_IOCHARSET="utf8"
 CONFIG_NTFS_FS=m
+CONFIG_NTFS_FS_WOF_COMPRESSION=y
 CONFIG_NTFS_DEBUG=y
 CONFIG_NTFS_FS_POSIX_ACL=y
 CONFIG_NTFS3_FS=m

Comment

The reviewed hunk changes `CONFIG_PROC_SYSCTL=y` to `CONFIG_SYSCTL=y`. This is a kernel configuration rename/relocation, not an obvious security regression by itself. It does not introduce new code execution, persistence, privilege escalation, network fetches, or packaging-time side effects. The surrounding diff is a broad kernel config refresh, but this specific hunk only preserves sysctl support under the new symbol name. Risk is therefore minimal.

@@ -11355,7 +11437,7 @@ CONFIG_PROC_FS=y
 CONFIG_PROC_KCORE=y
 CONFIG_PROC_VMCORE=y
 CONFIG_PROC_VMCORE_DEVICE_DUMP=y
-CONFIG_PROC_SYSCTL=y
+CONFIG_SYSCTL=y
 CONFIG_PROC_PAGE_MONITOR=y
 CONFIG_PROC_CHILDREN=y
 CONFIG_PROC_PID_ARCH_STATUS=y

Comment

The change only removes an explicit '# CONFIG_EFS_FS is not set' line from the kernel config. This does not enable EFS support or introduce any executable code, persistence mechanism, privilege escalation, or supply-chain risk. It is effectively a no-op in terms of security posture, aside from minor config normalization.

@@ -11389,7 +11471,6 @@ CONFIG_HFSPLUS_FS=m
 CONFIG_BEFS_FS=m
 # CONFIG_BEFS_DEBUG is not set
 # CONFIG_BFS_FS is not set
-# CONFIG_EFS_FS is not set
 CONFIG_JFFS2_FS=m
 CONFIG_JFFS2_FS_DEBUG=0
 CONFIG_JFFS2_FS_WRITEBUFFER=y

Comment

The change only removes an explicit disable for CONFIG_VXFS_FS from the kernel config. This does not introduce any new code execution, persistence, privilege escalation, network access, or packaging-time behavior. At most it allows the kernel build system/defaults to decide the VXFS filesystem setting, which is a functional/configuration change rather than a security issue. No malicious artifact is present in this hunk.

@@ -11431,7 +11512,6 @@ CONFIG_SQUASHFS_ZSTD=y
 # CONFIG_SQUASHFS_4K_DEVBLK_SIZE is not set
 # CONFIG_SQUASHFS_EMBEDDED is not set
 CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=3
-# CONFIG_VXFS_FS is not set
 CONFIG_MINIX_FS=m
 CONFIG_OMFS_FS=m
 # CONFIG_HPFS_FS is not set

Comment

The change only enables CONFIG_SECURITY_APPARMOR_COMPRESSED_POLICY in the kernel config. This is a build-time kernel feature toggle, not a packaging script or install-time action. It does not introduce network access, privilege escalation, persistence, or suspicious source changes. The option appears consistent with the surrounding AppArmor security settings already enabled in this config. No security red flags are evident from this single-line change.

@@ -11671,6 +11751,7 @@ CONFIG_SECURITY_APPARMOR_INTROSPECT_POLICY=y
 CONFIG_SECURITY_APPARMOR_HASH=y
 CONFIG_SECURITY_APPARMOR_HASH_DEFAULT=y
 CONFIG_SECURITY_APPARMOR_EXPORT_BINARY=y
+CONFIG_SECURITY_APPARMOR_COMPRESSED_POLICY=y
 CONFIG_SECURITY_APPARMOR_PARANOID_LOAD=y
 CONFIG_SECURITY_LOADPIN=y
 CONFIG_SECURITY_LOADPIN_ENFORCE=y

Comment

The change only enables CONFIG_SECURITY_LANDLOCK_LOG in the kernel config. This adds logging for Landlock security events and does not introduce new code execution, persistence, privilege escalation, network access, or packaging-time behavior. I found no suspicious source, install-script, or systemd-related impact in this diff hunk.

@@ -11682,6 +11763,7 @@ CONFIG_LOCK_DOWN_KERNEL_FORCE_NONE=y
 # CONFIG_LOCK_DOWN_KERNEL_FORCE_INTEGRITY is not set
 # CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY is not set
 CONFIG_SECURITY_LANDLOCK=y
+CONFIG_SECURITY_LANDLOCK_LOG=y
 CONFIG_SECURITY_IPE=y
 CONFIG_IPE_BOOT_POLICY=""
 CONFIG_IPE_POLICY_SIG_SECONDARY_KEYRING=y

Comment

The change only switches CONFIG_CRYPTO_AEAD and CONFIG_CRYPTO_AEAD2 from modules to built-in kernel features. This is a normal kernel configuration adjustment with no evidence of malicious behavior, persistence, privilege escalation, network access, or packaging integrity issues in the diff shown. It may affect boot/runtime behavior, but not in a security-adverse way by itself.

@@ -11766,8 +11848,8 @@ CONFIG_CRYPTO=y
 #
 CONFIG_CRYPTO_ALGAPI=y
 CONFIG_CRYPTO_ALGAPI2=y
-CONFIG_CRYPTO_AEAD=m
-CONFIG_CRYPTO_AEAD2=m
+CONFIG_CRYPTO_AEAD=y
+CONFIG_CRYPTO_AEAD2=y
 CONFIG_CRYPTO_SIG=y
 CONFIG_CRYPTO_SIG2=y
 CONFIG_CRYPTO_SKCIPHER=y

Comment

The change only adjusts kernel crypto configuration, replacing a single AESGCM symbol with a set of more granular AES mode symbols (CBC/CCM/CTR/ECB/GCM/XTS) and adding AES_CBC support. This is a build-time kernel feature toggle, not an install script or runtime code path, and it does not introduce network access, privilege escalation, persistence, or suspicious packaging behavior. No red flags are evident from this diff alone.

@@ -12043,8 +12125,13 @@ CONFIG_CRYPTO_LIB_UTILS=y
 CONFIG_CRYPTO_LIB_AES=y
 CONFIG_CRYPTO_LIB_AES_ARCH=y
 CONFIG_CRYPTO_LIB_AESCFB=y
+CONFIG_CRYPTO_LIB_AES_CBC=y
 CONFIG_CRYPTO_LIB_AES_CBC_MACS=y
-CONFIG_CRYPTO_LIB_AESGCM=y
+CONFIG_CRYPTO_LIB_AES_CCM=y
+CONFIG_CRYPTO_LIB_AES_CTR=y
+CONFIG_CRYPTO_LIB_AES_ECB=y
+CONFIG_CRYPTO_LIB_AES_GCM=y
+CONFIG_CRYPTO_LIB_AES_XTS=y
 CONFIG_CRYPTO_LIB_ARC4=m
 CONFIG_CRYPTO_LIB_GF128MUL=m
 CONFIG_CRYPTO_LIB_BLAKE2B=y

Comment

The change only removes the explicit disabling of CONFIG_RANDOM32_SELFTEST from the kernel config. That option is a self-test, not a security control or privilege mechanism, and leaving it unset/default does not introduce code execution, persistence, network access, or packaging integrity issues. No suspicious build or install behavior is present in this hunk.

@@ -12081,7 +12168,6 @@ CONFIG_RAID6_PQ=y
 CONFIG_RAID6_PQ_ARCH=y
 # CONFIG_RAID6_PQ_BENCHMARK is not set
 CONFIG_XXHASH=y
-# CONFIG_RANDOM32_SELFTEST is not set
 CONFIG_842_COMPRESS=m
 CONFIG_842_DECOMPRESS=m
 CONFIG_ZLIB_INFLATE=y

Comment

The change only sets the kernel config option CONFIG_SWIOTLB_DEFAULT_SIZE_MB=64, increasing the default SWIOTLB buffer size. This is a normal kernel configuration adjustment with no evidence of malicious behavior, privilege escalation, network access, persistence, or packaging integrity issues. It does not introduce executable code or alter build/install scripts.

@@ -12138,6 +12224,7 @@ CONFIG_NEED_DMA_MAP_STATE=y
 CONFIG_ARCH_DMA_ADDR_T_64BIT=y
 CONFIG_ARCH_HAS_FORCE_DMA_UNENCRYPTED=y
 CONFIG_SWIOTLB=y
+CONFIG_SWIOTLB_DEFAULT_SIZE_MB=64
 # CONFIG_SWIOTLB_DYNAMIC is not set
 CONFIG_DMA_NEED_SYNC=y
 CONFIG_DMA_COHERENT_POOL=y

Comment

The change is a single kernel config symbol swap: CONFIG_HAVE_GENERIC_VDSO=y is replaced with CONFIG_VDSO_DATASTORE=y. This is a build-time configuration adjustment only; it does not introduce new sources, scripts, network access, privilege escalation, or packaging behavior. I see no security-relevant red flags in this isolated hunk.

@@ -12171,7 +12258,7 @@ CONFIG_DIMLIB=y
 CONFIG_LIBFDT=y
 CONFIG_OID_REGISTRY=y
 CONFIG_UCS2_STRING=y
-CONFIG_HAVE_GENERIC_VDSO=y
+CONFIG_VDSO_DATASTORE=y
 CONFIG_GENERIC_GETTIMEOFDAY=y
 CONFIG_GENERIC_VDSO_OVERFLOW_PROTECT=y
 CONFIG_VDSO_GETRANDOM=y

Comment

The change only removes a single kernel config line: `# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set`. This is not a supply-chain or packaging integrity issue by itself, and it does not introduce code execution, network access, privilege escalation, or persistence mechanisms. It appears to be a benign kernel configuration adjustment with no obvious security impact from the diff shown.

@@ -12264,7 +12351,6 @@ CONFIG_STRIP_ASM_SYMS=y
 CONFIG_SECTION_MISMATCH_WARN_ONLY=y
 CONFIG_OBJTOOL=y
 # CONFIG_OBJTOOL_WERROR is not set
-# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
 # end of Compile-time checks and compiler options
 
 #

Comment

The change only adds an explicit kernel config line disabling CONFIG_MEM_ALLOC_PROFILING. This is a defensive/no-op style change in a kernel config file and does not introduce code execution, persistence, privilege escalation, network access, or packaging integrity issues. I found no suspicious sources, scripts, or shipped artifacts associated with this hunk.

@@ -12315,6 +12401,7 @@ CONFIG_PTDUMP=y
 CONFIG_HAVE_DEBUG_KMEMLEAK=y
 # CONFIG_DEBUG_KMEMLEAK is not set
 # CONFIG_PER_VMA_LOCK_STATS is not set
+# CONFIG_MEM_ALLOC_PROFILING is not set
 # CONFIG_DEBUG_OBJECTS is not set
 CONFIG_SHRINKER_DEBUG=y
 # CONFIG_DEBUG_STACK_USAGE is not set

Comment

The change only removes an explicit 'CONFIG_MEM_ALLOC_PROFILING is not set' line from the kernel config. This does not introduce any new code execution, persistence, privilege escalation, network access, or packaging integrity issues. At most it changes the kernel build configuration by omitting an explicit disable for a profiling option, which is not a security concern by itself in this context.

@@ -12327,7 +12414,6 @@ CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y
 # CONFIG_DEBUG_VIRTUAL is not set
 CONFIG_DEBUG_MEMORY_INIT=y
 # CONFIG_DEBUG_PER_CPU_MAPS is not set
-# CONFIG_MEM_ALLOC_PROFILING is not set
 CONFIG_HAVE_ARCH_KASAN=y
 CONFIG_HAVE_ARCH_KASAN_VMALLOC=y
 CONFIG_CC_HAS_KASAN_GENERIC=y

Comment

The change only disables CONFIG_PROBE_EVENTS_DUMP_FETCHARG in the kernel config. This is a build-time kernel feature toggle, not a packaging or install-script change, and it does not introduce new code execution, network access, privilege escalation, persistence, or integrity risks. Disabling a probe-events dump feature may reduce observability/debugging capability, but it is not a security concern in the context of this review.

@@ -12501,6 +12587,7 @@ CONFIG_BRANCH_PROFILE_NONE=y
 CONFIG_BLK_DEV_IO_TRACE=y
 CONFIG_FPROBE_EVENTS=y
 CONFIG_PROBE_EVENTS_BTF_ARGS=y
+# CONFIG_PROBE_EVENTS_DUMP_FETCHARG is not set
 CONFIG_KPROBE_EVENTS=y
 # CONFIG_KPROBE_EVENTS_ON_NOTRACE is not set
 CONFIG_UPROBE_EVENTS=y

Comment

The change only adds a commented-out kernel config option (`# CONFIG_REGION_ALLOC_BENCHMARK is not set`) to the shipped kernel configuration. This does not enable code execution, persistence, privilege escalation, network access, or any packaging-time behavior. It is a benign config-file update with no security impact apparent from the diff.

@@ -12602,6 +12689,7 @@ CONFIG_ASYNC_RAID6_TEST=m
 # CONFIG_TEST_WORKQUEUE is not set
 # CONFIG_TEST_BPF is not set
 # CONFIG_FIND_BIT_BENCHMARK is not set
+# CONFIG_REGION_ALLOC_BENCHMARK is not set
 # CONFIG_FIND_BIT_BENCHMARK_RUST is not set
 # CONFIG_TEST_FIRMWARE is not set
 # CONFIG_TEST_SYSCTL is not set