Review Results

Comment

The change only updates a sha256 checksum in .SRCINFO for one source entry. This is metadata-only and does not introduce new sources, commands, privilege changes, or packaging behavior. I did not see any indication from the provided hunk of malicious intent or integrity weakening beyond the expected checksum refresh, so the risk is minimal.

@@ -38,7 +38,7 @@ pkgbase = linux-mainline
 	validpgpkeys = 647F28654894E3BD457199BE38DBBDC86092693E
 	validpgpkeys = 83BC8889351B5DEBBB68416EB8AC08600F108CDF
 	sha256sums = 39d89488855de6428f01fd77746ff0568706da996e348583823d0e988cd15f61
-	sha256sums = 09d57e32920139bc7275b8e0bccfb3bea2fe1d68655f1978ac89f2ce240f2dd2
+	sha256sums = 9f6e1be50d2ebb69a23b14799ccf23462c80e29f284ce3b205186921c5c3bf3d
 
 pkgname = linux-mainline
 	pkgdesc = The Linux Mainline kernel and modules

Comment

The change is low risk. It only updates the SHA-256 checksum for the existing upstream kernel source tarball/tag and makes a few packaging/build-order tweaks: running htmldocs in parallel with the main build, moving a log message inside a conditional, and pruning __pycache__ in the docs packaging step. I did not find any new network fetches, privilege escalation, persistence mechanisms, or suspicious install-time behavior. The source remains pinned to an official kernel.org git tag over HTTPS, and the rest of the PKGBUILD logic is unchanged.

@@ -57,7 +57,7 @@ validpgpkeys=(
   83BC8889351B5DEBBB68416EB8AC08600F108CDF  # Jan Alexander Steffens (heftig)
 )
 sha256sums=('39d89488855de6428f01fd77746ff0568706da996e348583823d0e988cd15f61'
-            '09d57e32920139bc7275b8e0bccfb3bea2fe1d68655f1978ac89f2ce240f2dd2')
+            '9f6e1be50d2ebb69a23b14799ccf23462c80e29f284ce3b205186921c5c3bf3d')
 
 export KBUILD_BUILD_HOST=archlinux
 export KBUILD_BUILD_USER=$pkgbase

Comment

The change is low risk. It only runs the existing kernel documentation build in parallel with the main build and waits for it to finish, which is a build-time performance tweak rather than a functional or security change. The other edits are harmless packaging hygiene adjustments (moving a log line under the Rust conditional and pruning __pycache__ during docs packaging). I do not see any new network access, privilege escalation, persistence, or integrity issues introduced by this diff.

@@ -91,9 +91,13 @@ prepare() {
 
 build() {
   cd $_srcname
+
+  make htmldocs SPHINXOPTS=-QT &
+  local pid_docs=$!
+
   make all
   make -C tools/bpf/bpftool vmlinux.h feature-clang-bpf-co-re=1
-  make htmldocs SPHINXOPTS=-QT
+  wait $pid_docs
 }
 
 _package() {

Comment

The change only moves the "Installing Rust files..." log message inside the existing CONFIG_RUST conditional. It does not alter what gets installed, where files are written, or introduce any new execution, network, privilege, or persistence behavior. No security impact is apparent from this diff hunk alone.

@@ -201,8 +205,8 @@ _package-headers() {
   echo "Installing KConfig files..."
   find . -name 'Kconfig*' -exec install -Dm644 {} "$builddir/{}" \;
 
-  echo "Installing Rust files..."
   if [[ $(scripts/config -s CONFIG_RUST) = y ]]; then
+    echo "Installing Rust files..."
     install -Dt "$builddir/rust" -m644 rust/*.rmeta
     install -Dt "$builddir/rust" rust/*.so
   fi

Comment

The change is low risk. It only adjusts the documentation packaging file filter to also prune __pycache__ directories, which prevents accidental inclusion of Python bytecode caches in the docs package. No new network access, privilege changes, persistence mechanisms, or executable content are introduced. The rest of the diff shown in PKGBUILD is unrelated to this hunk, and this specific change is a benign packaging hygiene fix.

@@ -263,7 +267,10 @@ _package-docs() {
     dst="${src#Documentation/}"
     dst="$builddir/Documentation/${dst#output/}"
     install -Dm644 "$src" "$dst"
-  done < <(find Documentation -name '.*' -prune -o ! -type d -print0)
+  done < <(
+    find Documentation \( -name '.*' -o -name __pycache__ \) -prune \
+      -o \! -type d -print0
+  )
 
   echo "Adding symlink..."
   mkdir -p "$pkgdir/usr/share/doc"

Comment

The change is a kernel config refresh with many option flips, but nothing in the diff suggests a supply-chain or packaging attack. I do see a few potentially risky kernel feature changes (e.g. enabling additional debug/telemetry and driver modules, changing some features from module to built-in), but these are normal config churn in a mainline kernel package and do not affect the PKGBUILD/build/install attack surface directly. No suspicious sources, scripts, or privilege-escalation mechanisms are present in this file change.

@@ -1,19 +1,19 @@
 #
 # Automatically generated file; DO NOT EDIT.
-# Linux/x86 7.1.2-arch1 Kernel Configuration
+# Linux/x86 7.2.2-arch1 Kernel Configuration
 #
-CONFIG_CC_VERSION_TEXT="gcc (GCC) 16.1.1 20260625"
+CONFIG_CC_VERSION_TEXT="gcc (GCC) 16.2.1 20260810"
 CONFIG_CC_IS_GCC=y
-CONFIG_GCC_VERSION=160101
+CONFIG_GCC_VERSION=160201
 CONFIG_CLANG_VERSION=0
 CONFIG_AS_IS_GNU=y
-CONFIG_AS_VERSION=24601
+CONFIG_AS_VERSION=24700
 CONFIG_LD_IS_BFD=y
-CONFIG_LD_VERSION=24601
+CONFIG_LD_VERSION=24700
 CONFIG_LLD_VERSION=0
-CONFIG_RUSTC_VERSION=109600
+CONFIG_RUSTC_VERSION=109800
 CONFIG_RUST_IS_AVAILABLE=y
-CONFIG_RUSTC_LLVM_VERSION=220106
+CONFIG_RUSTC_LLVM_VERSION=220108
 CONFIG_RUSTC_LLVM_MAJOR_VERSION=22
 CONFIG_CC_CAN_LINK=y
 CONFIG_CC_HAS_ASM_GOTO_OUTPUT=y

Comment

The change only adds a single kernel config symbol in config.x86_64. There is no evidence here of source tampering, network access, privilege escalation, persistence, or packaging logic changes. The added option name is unusual, but within the scope of this review it is just a configuration flag in a kernel config file and does not by itself introduce executable behavior or a supply-chain risk. Based on the provided diff hunk alone, this appears low risk.

@@ -30,6 +30,7 @@ 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_RUSTC_HAS_SUSPICIOUS_RUNTIME_SYMBOL_DEFINITIONS=y
 CONFIG_PAHOLE_VERSION=131
 CONFIG_IRQ_WORK=y
 CONFIG_BUILDTIME_TABLE_SORT=y

Comment

The change only removes CONFIG_GENERIC_TIME_VSYSCALL from the kernel config. This disables the legacy vsyscall time interface, which is a hardening-oriented change rather than a security regression. No added sources, scripts, privileges, or persistence mechanisms are involved in this hunk.

@@ -97,7 +98,6 @@ CONFIG_SPARSE_IRQ=y
 CONFIG_CLOCKSOURCE_WATCHDOG=y
 CONFIG_ARCH_CLOCKSOURCE_INIT=y
 CONFIG_ARCH_WANTS_CLOCKSOURCE_READ_INLINE=y
-CONFIG_GENERIC_TIME_VSYSCALL=y
 CONFIG_GENERIC_CLOCKEVENTS=y
 CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
 CONFIG_GENERIC_CLOCKEVENTS_BROADCAST_IDLE=y

Comment

The change only enables CONFIG_SCHED_CACHE in the kernel config. This is a normal kernel feature toggle and does not introduce any obvious supply-chain, persistence, privilege-escalation, or build-time execution risk. No sources, scripts, units, or packaging logic are affected by this diff hunk.

@@ -229,6 +229,7 @@ CONFIG_GCC_NO_STRINGOP_OVERFLOW=y
 CONFIG_CC_NO_STRINGOP_OVERFLOW=y
 CONFIG_ARCH_SUPPORTS_INT128=y
 CONFIG_NUMA_BALANCING=y
+CONFIG_SCHED_CACHE=y
 CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y
 CONFIG_SLAB_OBJ_EXT=y
 CONFIG_CGROUPS=y

Comment

The change only enables two kernel config options related to futex robust unlock support. This is a normal kernel feature toggle with no evidence of network access, privilege escalation, persistence, or packaging abuse. I did not see any suspicious build/install behavior in this diff.

@@ -310,6 +311,8 @@ CONFIG_FUTEX=y
 CONFIG_FUTEX_PI=y
 CONFIG_FUTEX_PRIVATE_HASH=y
 CONFIG_FUTEX_MPOL=y
+CONFIG_HAVE_FUTEX_ROBUST_UNLOCK=y
+CONFIG_FUTEX_ROBUST_UNLOCK=y
 CONFIG_EPOLL=y
 CONFIG_SIGNALFD=y
 CONFIG_TIMERFD=y

Comment

This is a low-risk metadata-only change in the kernel config, updating the embedded Rust compiler version string from 1.96.0 to 1.98.0. It does not alter build logic, sources, install scripts, permissions, or introduce any execution paths. The only effect is the expected version text used for kernel build/config consistency checks, so there is no evident security impact in this diff.

@@ -342,7 +345,7 @@ CONFIG_PERF_EVENTS=y
 CONFIG_SYSTEM_DATA_VERIFICATION=y
 CONFIG_PROFILING=y
 CONFIG_RUST=y
-CONFIG_RUSTC_VERSION_TEXT="rustc 1.96.0 (ac68faa20 2026-05-25) (Arch Linux rust 1:1.96.0-1)"
+CONFIG_RUSTC_VERSION_TEXT="rustc 1.98.0 (88d9e12ae 2026-08-18) (Arch Linux rust 1:1.98.0-1)"
 CONFIG_BINDGEN_VERSION_TEXT="bindgen 0.72.1"
 CONFIG_TRACEPOINTS=y
 

Comment

The change only removes a disabled kernel config line for CONFIG_XEN_DEBUG_FS from the shipped config. This does not enable any new functionality, does not add code execution, network access, privilege changes, or packaging/install-time behavior, and has no supply-chain or persistence implications on its own. It is a negligible configuration cleanup with no security impact in the reviewed hunk.

@@ -434,7 +437,6 @@ CONFIG_XEN_PV_DOM0=y
 CONFIG_XEN_PVHVM=y
 CONFIG_XEN_PVHVM_SMP=y
 CONFIG_XEN_PVHVM_GUEST=y
-# CONFIG_XEN_DEBUG_FS is not set
 CONFIG_XEN_PVH=y
 CONFIG_XEN_DOM0=y
 CONFIG_XEN_PV_MSR_SAFE=y

Comment

The diff is a no-op reordering of a kernel config option: CONFIG_BROADCAST_TLB_FLUSH is moved a few lines later with no value change. This does not alter build inputs, package contents, privileges, network behavior, or runtime behavior in any meaningful way. No security impact identified from the provided hunk.

@@ -459,12 +461,12 @@ CONFIG_X86_MINIMUM_CPU_FAMILY=64
 CONFIG_X86_DEBUGCTLMSR=y
 CONFIG_IA32_FEAT_CTL=y
 CONFIG_X86_VMX_FEATURE_NAMES=y
-CONFIG_BROADCAST_TLB_FLUSH=y
 CONFIG_CPU_SUP_INTEL=y
 CONFIG_CPU_SUP_AMD=y
 CONFIG_CPU_SUP_HYGON=y
 CONFIG_CPU_SUP_CENTAUR=y
 CONFIG_CPU_SUP_ZHAOXIN=y
+CONFIG_BROADCAST_TLB_FLUSH=y
 CONFIG_HPET_TIMER=y
 CONFIG_HPET_EMULATE_RTC=y
 CONFIG_DMI=y

Comment

The change removes CONFIG_PREFIX_SYMBOLS from the kernel config. This is a build/configuration change only and does not introduce code execution, network access, privilege escalation, persistence, or packaging integrity issues. I don't see a security problem in the diff itself; at most it changes symbol prefixing behavior in the built kernel, which is not an obvious supply-chain or runtime backdoor risk from this isolated modification.

@@ -596,7 +598,6 @@ CONFIG_FUNCTION_PADDING_BYTES=16
 CONFIG_CALL_PADDING=y
 CONFIG_HAVE_CALL_THUNKS=y
 CONFIG_CALL_THUNKS=y
-CONFIG_PREFIX_SYMBOLS=y
 CONFIG_CPU_MITIGATIONS=y
 CONFIG_MITIGATION_PAGE_TABLE_ISOLATION=y
 CONFIG_MITIGATION_RETPOLINE=y

Comment

The change only enables CONFIG_ARCH_MEMORY_ORDER_TSO in the kernel config. This is a build-time kernel configuration toggle, not a packaging script or install-time action, and it does not introduce network access, privilege escalation, persistence, or other supply-chain red flags. I did not find any security-relevant behavior in this diff hunk itself.

@@ -927,6 +928,7 @@ CONFIG_ARCH_HAS_CPU_PASID=y
 CONFIG_HAVE_ARCH_THREAD_STRUCT_WHITELIST=y
 CONFIG_ARCH_WANTS_DYNAMIC_TASK_STRUCT=y
 CONFIG_ARCH_WANTS_NO_INSTR=y
+CONFIG_ARCH_MEMORY_ORDER_TSO=y
 CONFIG_HAVE_ASM_MODVERSIONS=y
 CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
 CONFIG_HAVE_RSEQ=y

Comment

The change only removes two kernel config capability flags: CONFIG_ARCH_SUPPORTS_AUTOFDO_CLANG and CONFIG_ARCH_SUPPORTS_PROPELLER_CLANG. This does not introduce code execution, privilege escalation, persistence, network access, or packaging integrity issues. It merely disables support for two Clang optimization features in the built kernel configuration. No security concern is evident from this diff alone.

@@ -968,8 +970,6 @@ CONFIG_STACKPROTECTOR_STRONG=y
 CONFIG_ARCH_SUPPORTS_LTO_CLANG=y
 CONFIG_ARCH_SUPPORTS_LTO_CLANG_THIN=y
 CONFIG_LTO_NONE=y
-CONFIG_ARCH_SUPPORTS_AUTOFDO_CLANG=y
-CONFIG_ARCH_SUPPORTS_PROPELLER_CLANG=y
 CONFIG_ARCH_SUPPORTS_CFI=y
 CONFIG_HAVE_ARCH_WITHIN_STACK_FRAMES=y
 CONFIG_HAVE_CONTEXT_TRACKING_USER=y

Comment

The change only enables CONFIG_BLK_ERROR_INJECTION in the kernel config. This is a standard kernel testing/debug feature that allows block-layer error injection; it does not introduce a build-time download, privilege escalation, persistence mechanism, or packaging integrity issue by itself. In the context of an Arch kernel package, this is a low-risk configuration change, though it could be used for fault-injection testing on a built kernel. No malicious behavior is evident in the diff provided.

@@ -1149,6 +1149,7 @@ CONFIG_EFI_PARTITION=y
 CONFIG_BLK_PM=y
 CONFIG_BLOCK_HOLDER_DEPRECATED=y
 CONFIG_BLK_MQ_STACKING=y
+CONFIG_BLK_ERROR_INJECTION=y
 
 #
 # IO Schedulers

Comment

The change is a kernel config tweak only and does not introduce any obvious supply-chain, privilege-escalation, persistence, or build-time execution risk. The specific hunk replaces one disabled slab allocator option with another disabled option (`RANDOM_KMALLOC_CACHES` -> `KMALLOC_PARTITION_CACHES`), so it does not enable new code paths by itself. No scripts, sources, or install hooks are affected in this diff.

@@ -1226,7 +1227,7 @@ CONFIG_SLAB_FREELIST_RANDOM=y
 CONFIG_SLAB_FREELIST_HARDENED=y
 CONFIG_SLAB_BUCKETS=y
 # CONFIG_SLUB_STATS is not set
-# CONFIG_RANDOM_KMALLOC_CACHES is not set
+# CONFIG_KMALLOC_PARTITION_CACHES is not set
 # end of Slab allocator options
 
 CONFIG_SHUFFLE_PAGE_ALLOCATOR=y

Comment

The change only removes CONFIG_READ_ONLY_THP_FOR_FS from the kernel config. This disables a read-only transparent hugepage feature for filesystems, which is a functional/kernel-tuning change rather than a supply-chain or privilege/security backdoor concern. I don't see any added code execution, persistence, network access, or packaging integrity issue in this diff hunk.

@@ -1294,7 +1295,6 @@ CONFIG_TRANSPARENT_HUGEPAGE_SHMEM_HUGE_ADVISE=y
 # CONFIG_TRANSPARENT_HUGEPAGE_TMPFS_HUGE_WITHIN_SIZE is not set
 CONFIG_TRANSPARENT_HUGEPAGE_TMPFS_HUGE_ADVISE=y
 CONFIG_THP_SWAP=y
-CONFIG_READ_ONLY_THP_FOR_FS=y
 # CONFIG_NO_PAGE_MAPCOUNT is not set
 CONFIG_PAGE_MAPCOUNT=y
 CONFIG_PGTABLE_HAS_HUGE_LEAVES=y

Comment

The change only removes the explicit 'CONFIG_TLS_TOE is not set' line from the kernel config. That does not introduce a new build-time or runtime security risk by itself; it merely stops pinning that option in the config fragment. There are no added sources, scripts, privilege changes, or packaging/install-time behaviors in this diff hunk. At most, the resulting kernel configuration could differ if the option's default changes upstream, but this single-line deletion is not a direct security issue in the package metadata/artifacts reviewed here.

@@ -1396,7 +1396,6 @@ CONFIG_AF_UNIX_OOB=y
 CONFIG_UNIX_DIAG=m
 CONFIG_TLS=m
 CONFIG_TLS_DEVICE=y
-# CONFIG_TLS_TOE is not set
 CONFIG_XFRM=y
 CONFIG_XFRM_OFFLOAD=y
 CONFIG_XFRM_ALGO=m

Comment

The change only removes CONFIG_TCP_SIGPOOL from the kernel config. This is a kernel feature toggle, not a packaging or build-script change, and there are no signs of added code execution, network access, privilege escalation, or persistence mechanisms. Based on the provided hunk alone, this appears low risk and likely just a configuration adjustment.

@@ -1478,7 +1477,6 @@ CONFIG_TCP_CONG_BBR=m
 CONFIG_DEFAULT_CUBIC=y
 # CONFIG_DEFAULT_RENO is not set
 CONFIG_DEFAULT_TCP_CONG="cubic"
-CONFIG_TCP_SIGPOOL=y
 CONFIG_TCP_AO=y
 CONFIG_TCP_MD5SIG=y
 CONFIG_IPV6=y

Comment

The change only switches CONFIG_NETFILTER_NETLINK from a module to built-in. This is a kernel configuration adjustment with no evidence of added code execution, network fetching, privilege escalation, or packaging integrity issues. It may affect runtime behavior and attack surface slightly by making netfilter netlink available earlier in boot, but that is not inherently malicious and is common in kernel configs. No other suspicious artifacts are present in the reviewed hunk.

@@ -1529,7 +1527,7 @@ CONFIG_BRIDGE_NETFILTER=m
 CONFIG_NETFILTER_INGRESS=y
 CONFIG_NETFILTER_EGRESS=y
 CONFIG_NETFILTER_SKIP_EGRESS=y
-CONFIG_NETFILTER_NETLINK=m
+CONFIG_NETFILTER_NETLINK=y
 CONFIG_NETFILTER_FAMILY_BRIDGE=y
 CONFIG_NETFILTER_FAMILY_ARP=y
 CONFIG_NETFILTER_BPF_LINK=y

Comment

The change only enables the upstream Linux kernel config option CONFIG_NET_DSA_TAG_NETC as a module in the shipped kernel configuration. This is a normal feature toggle for a kernel subsystem (DSA tagging) and does not introduce any build-time downloads, scripts, privilege changes, persistence mechanisms, or packaging integrity issues. No suspicious sources or executable artifacts are involved in this hunk.

@@ -1925,6 +1923,7 @@ CONFIG_NET_DSA_TAG_MTK=m
 CONFIG_NET_DSA_TAG_MXL_862XX=m
 CONFIG_NET_DSA_TAG_MXL_GSW1XX=m
 CONFIG_NET_DSA_TAG_KSZ=m
+CONFIG_NET_DSA_TAG_NETC=m
 CONFIG_NET_DSA_TAG_OCELOT=m
 CONFIG_NET_DSA_TAG_OCELOT_8021Q=m
 CONFIG_NET_DSA_TAG_QCA=m

Comment

The change only removes CONFIG_ATALK=m from the kernel config. This disables AppleTalk support in the built kernel and does not introduce any new code execution, privilege escalation, persistence, network fetching, or packaging integrity concerns. It is a straightforward hardening/reduction of attack surface, with no suspicious side effects in the provided diff.

@@ -1942,7 +1941,6 @@ CONFIG_VLAN_8021Q_GVRP=y
 CONFIG_VLAN_8021Q_MVRP=y
 CONFIG_LLC=m
 CONFIG_LLC2=m
-CONFIG_ATALK=m
 # CONFIG_X25 is not set
 # CONFIG_LAPB is not set
 CONFIG_PHONET=m

Comment

The diff only removes three Bluetooth HCI driver modules from the kernel config: BT_HCIDTL1, BT_HCIBT3C, and BT_HCIBLUECARD. This is a reduction in enabled functionality, not an addition of code, privilege, persistence, or network behavior. I see no supply-chain or packaging integrity concern in this hunk alone.

@@ -2178,9 +2176,6 @@ CONFIG_BT_HCIBCM203X=m
 CONFIG_BT_HCIBCM4377=m
 CONFIG_BT_HCIBPA10X=m
 CONFIG_BT_HCIBFUSB=m
-CONFIG_BT_HCIDTL1=m
-CONFIG_BT_HCIBT3C=m
-CONFIG_BT_HCIBLUECARD=m
 CONFIG_BT_HCIVHCI=m
 CONFIG_BT_MRVL=m
 CONFIG_BT_MRVL_SDIO=m

Comment

The change only removes one kernel module option from the shipped kernel config: CONFIG_SENSORS_APDS990X=m. This is a straightforward configuration reduction with no evidence of added code execution, network access, privilege changes, or packaging/install-script behavior. It may reduce hardware support for APDS990X ambient light/proximity sensors, but that is not a security concern in itself.

@@ -2846,7 +2841,6 @@ CONFIG_ISL29003=m
 CONFIG_ISL29020=m
 CONFIG_SENSORS_TSL2550=m
 CONFIG_SENSORS_BH1770=m
-CONFIG_SENSORS_APDS990X=m
 CONFIG_HMC6352=m
 CONFIG_DS1682=m
 CONFIG_VMWARE_BALLOON=m

Comment

The change only enables CONFIG_DM_INLINECRYPT as a loadable kernel module in the kernel config. This is a normal upstream kernel feature toggle and does not introduce any packaging-time code execution, network access, privilege escalation, persistence mechanism, or integrity issue in the AUR metadata/artifacts reviewed. No suspicious sources or scripts are involved in this hunk.

@@ -3201,6 +3195,7 @@ CONFIG_DM_BIO_PRISON=m
 CONFIG_DM_PERSISTENT_DATA=m
 CONFIG_DM_UNSTRIPED=m
 CONFIG_DM_CRYPT=m
+CONFIG_DM_INLINECRYPT=m
 CONFIG_DM_SNAPSHOT=m
 CONFIG_DM_THIN_PROVISIONING=m
 CONFIG_DM_CACHE=m

Comment

The change only enables an additional in-tree kernel driver option (Alibaba Ethernet EEA) in the shipped kernel config. This is a normal hardware-support toggle, not a build-time code execution path, install script, or external source change. I do not see any supply-chain, privilege-escalation, or persistence risk introduced by this config delta alone.

@@ -3379,6 +3374,8 @@ CONFIG_NET_VENDOR_AGERE=y
 CONFIG_ET131X=m
 CONFIG_NET_VENDOR_ALACRITECH=y
 CONFIG_SLICOSS=m
+CONFIG_NET_VENDOR_ALIBABA=y
+CONFIG_ALIBABA_EEA=m
 CONFIG_ALTERA_TSE=m
 CONFIG_NET_VENDOR_AMAZON=y
 CONFIG_ENA_ETHERNET=m

Comment

The change only removes several Wiznet network driver options from the kernel config (WIZNET_W5300, bus selection, and W5100_SPI). This is a reduction in enabled functionality, not an addition of code, persistence, privilege escalation, or build-time network behavior. No suspicious sources or packaging scripts are involved in this hunk. Security impact appears negligible.

@@ -3719,11 +3716,6 @@ CONFIG_TXGBEVF=m
 CONFIG_NGBEVF=m
 CONFIG_NET_VENDOR_WIZNET=y
 CONFIG_WIZNET_W5100=m
-CONFIG_WIZNET_W5300=m
-# CONFIG_WIZNET_BUS_DIRECT is not set
-# CONFIG_WIZNET_BUS_INDIRECT is not set
-CONFIG_WIZNET_BUS_ANY=y
-CONFIG_WIZNET_W5100_SPI=m
 CONFIG_NET_VENDOR_XILINX=y
 CONFIG_XILINX_EMACLITE=m
 CONFIG_XILINX_AXI_EMAC=m

Comment

The only substantive change in the reviewed hunk is enabling two additional PHY drivers (CONFIG_AIR_AN8801_PHY and CONFIG_AIR_NET_PHYLIB) in the kernel config. This is a normal feature expansion for a mainline kernel config and does not introduce obvious supply-chain, persistence, privilege-escalation, or build-time execution risks. No scripts, downloads, or packaging logic are affected by this diff.

@@ -3746,7 +3738,9 @@ CONFIG_SFP=m
 # MII PHY device drivers
 #
 CONFIG_AS21XXX_PHY=m
+CONFIG_AIR_AN8801_PHY=m
 CONFIG_AIR_EN8811H_PHY=m
+CONFIG_AIR_NET_PHYLIB=m
 CONFIG_AMD_PHY=m
 CONFIG_ADIN_PHY=m
 CONFIG_ADIN1100_PHY=m

Comment

The change only enables the in-tree CAN virtio driver as a module in the kernel config. This is a normal feature toggle, with no evidence of added network fetches, scripts, privilege escalation, persistence, or packaging integrity issues in the provided hunk. I found no security red flags in this diff alone.

@@ -3824,6 +3818,7 @@ CONFIG_CAN_CAN327=m
 CONFIG_CAN_JANZ_ICAN3=m
 CONFIG_CAN_KVASER_PCIEFD=m
 CONFIG_CAN_SLCAN=m
+CONFIG_CAN_VIRTIO_CAN=m
 CONFIG_CAN_C_CAN=m
 CONFIG_CAN_C_CAN_PLATFORM=m
 CONFIG_CAN_C_CAN_PCI=m

Comment

The change only enables CONFIG_PPPOX as a loadable kernel module in the shipped kernel config. This is a normal networking feature toggle (used by PPPoX/PPPoE-related protocols) and does not introduce build-time downloads, privilege escalation, persistence, or packaging integrity issues. No suspicious scripts, sources, or install-time behavior are involved in this diff hunk.

@@ -3920,6 +3915,7 @@ CONFIG_PPP_FILTER=y
 CONFIG_PPP_MPPE=m
 CONFIG_PPP_MULTILINK=y
 CONFIG_PPPOATM=m
+CONFIG_PPPOX=m
 CONFIG_PPPOE=m
 # CONFIG_PPPOE_HASH_BITS_1 is not set
 # CONFIG_PPPOE_HASH_BITS_2 is not set

Comment

The change is a one-line kernel config addition enabling the rtw89 8922AU wireless driver as a module. This is a normal upstream-style hardware support toggle, with no evidence of network access, privilege escalation, persistence, or packaging integrity issues. It does not alter build scripts, install scripts, or introduce external sources/binaries.

@@ -4303,6 +4299,7 @@ CONFIG_RTW89_8852BTE=m
 CONFIG_RTW89_8852CE=m
 CONFIG_RTW89_8852CU=m
 CONFIG_RTW89_8922AE=m
+CONFIG_RTW89_8922AU=m
 CONFIG_RTW89_DEBUG=y
 CONFIG_RTW89_DEBUGMSG=y
 CONFIG_RTW89_DEBUGFS=y

Comment

The change is a single kernel config addition enabling the Wacom W9000 touchscreen driver as a module. This does not introduce build-time downloads, scripts, privilege changes, persistence, or packaging/install-script behavior. It is a normal hardware-support configuration change with no evident security impact from the diff provided.

@@ -4546,6 +4543,7 @@ CONFIG_TOUCHSCREEN_ELAN=m
 CONFIG_TOUCHSCREEN_ELO=m
 CONFIG_TOUCHSCREEN_WACOM_W8001=m
 CONFIG_TOUCHSCREEN_WACOM_I2C=m
+CONFIG_TOUCHSCREEN_WACOM_W9000=m
 CONFIG_TOUCHSCREEN_MAX11801=m
 CONFIG_TOUCHSCREEN_MMS114=m
 CONFIG_TOUCHSCREEN_MELFAS_MIP4=m

Comment

The change only removes CONFIG_TOUCHSCREEN_PCAP from the kernel config. This disables one touchscreen driver module and does not introduce any new code execution, privilege changes, network access, persistence, or packaging integrity issues. No security concern is evident from this diff hunk alone.

@@ -4592,7 +4590,6 @@ CONFIG_TOUCHSCREEN_TSC2004=m
 CONFIG_TOUCHSCREEN_TSC2005=m
 CONFIG_TOUCHSCREEN_TSC2007=m
 CONFIG_TOUCHSCREEN_TSC2007_IIO=y
-CONFIG_TOUCHSCREEN_PCAP=m
 CONFIG_TOUCHSCREEN_RM_TS=m
 CONFIG_TOUCHSCREEN_SILEAD=m
 CONFIG_TOUCHSCREEN_SIS_I2C=m

Comment

The change is a single kernel config toggle removing CONFIG_INPUT_PCAP from the x86_64 config. This disables building the PCAP input driver as a module, which is a straightforward reduction in included functionality and does not introduce any new code execution, privilege, network, persistence, or packaging risks. No suspicious build-time behavior or artifact changes are present in the provided diff hunk.

@@ -4658,7 +4655,6 @@ CONFIG_INPUT_DA9052_ONKEY=m
 CONFIG_INPUT_DA9055_ONKEY=m
 CONFIG_INPUT_DA9063_ONKEY=m
 CONFIG_INPUT_WM831X_ON=m
-CONFIG_INPUT_PCAP=m
 CONFIG_INPUT_ADXL34X=m
 CONFIG_INPUT_ADXL34X_I2C=m
 CONFIG_INPUT_ADXL34X_SPI=m

Comment

The change removes CONFIG_APPLICOM from the kernel config. This is a benign reduction in enabled hardware support and does not introduce code execution, privilege escalation, persistence, network access, or packaging integrity issues. No suspicious build/install behavior is present in the provided diff hunk.

@@ -4834,7 +4830,6 @@ CONFIG_HW_RANDOM_BA431=m
 CONFIG_HW_RANDOM_VIA=m
 CONFIG_HW_RANDOM_VIRTIO=m
 CONFIG_HW_RANDOM_XIPHERA=m
-CONFIG_APPLICOM=m
 CONFIG_DEVMEM=y
 CONFIG_NVRAM=y
 CONFIG_DEVPORT=y

Comment

The change only removes CONFIG_PINCTRL_STMFX from the kernel config, disabling one optional pinctrl driver. This is a straightforward feature reduction with no evidence of malicious behavior, privilege escalation, persistence, or integrity issues in the provided diff. No build-time execution, source changes, or install-time scripts are involved.

@@ -5113,7 +5108,6 @@ CONFIG_PINCTRL_MAX7360=m
 CONFIG_PINCTRL_MCP23S08_I2C=m
 CONFIG_PINCTRL_MCP23S08_SPI=m
 CONFIG_PINCTRL_MCP23S08=m
-CONFIG_PINCTRL_STMFX=m
 CONFIG_PINCTRL_SX150X=y
 CONFIG_PINCTRL_UPBOARD=m
 CONFIG_PINCTRL_CS42L43=m

Comment

The change only enables CONFIG_GPIO_WAVESHARE_DSI_TOUCH as a loadable kernel module in the shipped kernel config. This is a normal driver toggle with no evidence of malicious build steps, persistence mechanisms, privilege escalation, or integrity issues in the diff. I did not see any suspicious source fetching, install scripts, or unit files associated with this change.

@@ -5185,6 +5179,7 @@ CONFIG_GPIO_MENZ127=m
 # CONFIG_GPIO_POLARFIRE_SOC is not set
 CONFIG_GPIO_SIOX=m
 CONFIG_GPIO_TANGIER=m
+CONFIG_GPIO_WAVESHARE_DSI_TOUCH=m
 CONFIG_GPIO_WCD934X=m
 CONFIG_GPIO_XILINX=m
 CONFIG_GPIO_AMD_FCH=m

Comment

The change only enables CONFIG_GPIO_LTC4283 as a loadable kernel module in the kernel config. This is a normal upstream driver selection change with no evidence of network access, install-script behavior, privilege escalation, or packaging integrity issues. I don't see any security-relevant red flags in this hunk alone.

@@ -5256,6 +5251,12 @@ CONFIG_GPIO_WM8994=m
 # end of MFD GPIO expanders
 
 #
+# Auxiliary Bus GPIO drivers
+#
+CONFIG_GPIO_LTC4283=m
+# end of Auxiliary Bus GPIO drivers
+
+#
 # PCI GPIO expanders
 #
 CONFIG_GPIO_AMD8111=m

Comment

The change only enables the Surface RT battery charger driver as a loadable kernel 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 in the provided hunk.

@@ -5439,6 +5440,7 @@ CONFIG_CHARGER_WILCO=m
 CONFIG_BATTERY_SURFACE=m
 CONFIG_CHARGER_SURFACE=m
 CONFIG_BATTERY_UG3105=m
+CONFIG_BATTERY_CHARGER_SURFACE_RT=m
 CONFIG_FUEL_GAUGE_MM8013=m
 CONFIG_HWMON=y
 CONFIG_HWMON_VID=m

Comment

The change only enables an additional kernel hardware-monitoring driver (CONFIG_SENSORS_ARCTIC_FAN_CONTROLLER=m) in the shipped kernel config. This is a normal feature toggle, does not introduce build-time downloads, privilege escalation, persistence, or packaging-script behavior, and it remains a loadable module rather than built-in. No security red flags are apparent from this diff alone.

@@ -5478,6 +5480,7 @@ CONFIG_SENSORS_KBATT=m
 CONFIG_SENSORS_KFAN=m
 CONFIG_SENSORS_FAM15H_POWER=m
 CONFIG_SENSORS_APPLESMC=m
+CONFIG_SENSORS_ARCTIC_FAN_CONTROLLER=m
 CONFIG_SENSORS_ASB100=m
 CONFIG_SENSORS_ATXP1=m
 CONFIG_SENSORS_CGBC=m

Comment

The change only enables an additional kernel module option in the shipped kernel config: CONFIG_SENSORS_PROM21_XHCI=m. This is a normal kernel configuration toggle, not a build-time download, script, privilege change, or packaging/persistence mechanism. I found no evidence in the provided hunk of malicious behavior or integrity risk.

@@ -5519,6 +5522,7 @@ CONFIG_SENSORS_IT87=m
 CONFIG_SENSORS_JC42=m
 CONFIG_SENSORS_POWERZ=m
 CONFIG_SENSORS_POWR1220=m
+CONFIG_SENSORS_PROM21_XHCI=m
 CONFIG_SENSORS_LATTEPANDA_SIGMA_EC=m
 CONFIG_SENSORS_LENOVO_EC=m
 CONFIG_SENSORS_LINEAGE=m

Comment

The change is a one-line kernel config addition enabling the LTC4283 hardware monitoring driver as a module. This does not introduce build-time downloads, scripts, privilege changes, persistence, or packaging integrity issues. It only expands kernel module availability for a specific sensor device and is low risk from a supply-chain/security perspective.

@@ -5536,6 +5540,7 @@ CONFIG_SENSORS_LTC4245=m
 CONFIG_SENSORS_LTC4260=m
 CONFIG_SENSORS_LTC4261=m
 CONFIG_SENSORS_LTC4282=m
+CONFIG_SENSORS_LTC4283=m
 CONFIG_SENSORS_MAX1111=m
 CONFIG_SENSORS_MAX127=m
 CONFIG_SENSORS_MAX16065=m

Comment

The change only enables two additional Linux kernel hardware-monitoring drivers (CONFIG_SENSORS_D1U74T and CONFIG_SENSORS_E50SN12051) as modules in the shipped kernel config. This does not introduce build-time network access, privilege escalation, persistence, or packaging-script behavior, and it does not alter source integrity or install scripts. The risk is minimal and limited to expanded kernel functionality for additional power-supply sensors.

@@ -5607,11 +5612,13 @@ CONFIG_SENSORS_APS_379=m
 CONFIG_SENSORS_BEL_PFE=m
 CONFIG_SENSORS_BPA_RS600=m
 CONFIG_SENSORS_CRPS=m
+CONFIG_SENSORS_D1U74T=m
 CONFIG_SENSORS_DELTA_AHE50DC_FAN=m
 CONFIG_SENSORS_FSP_3Y=m
 CONFIG_SENSORS_HAC300S=m
 CONFIG_SENSORS_IBM_CFFPS=m
 CONFIG_SENSORS_DPS920AB=m
+CONFIG_SENSORS_E50SN12051=m
 CONFIG_SENSORS_INA233=m
 CONFIG_SENSORS_INSPUR_IPSPS=m
 CONFIG_SENSORS_IR35221=m

Comment

This change only enables additional Linux kernel hardware-monitoring drivers in the kernel config: LX1308, MAX20830, and MAX20860A (plus the MAX20860A regulator option). There are no new sources, scripts, install hooks, privilege changes, or build-time network fetches. The diff is limited to config flags and does not introduce obvious supply-chain or persistence risk.

@@ -5629,12 +5636,16 @@ CONFIG_SENSORS_LTC2978=m
 # CONFIG_SENSORS_LTC2978_REGULATOR is not set
 CONFIG_SENSORS_LTC3815=m
 CONFIG_SENSORS_LTC4286=y
+CONFIG_SENSORS_LX1308=m
 CONFIG_SENSORS_MAX15301=m
 CONFIG_SENSORS_MAX16064=m
 CONFIG_SENSORS_MAX16601=m
 CONFIG_SENSORS_MAX17616=m
 CONFIG_SENSORS_MAX20730=m
 CONFIG_SENSORS_MAX20751=m
+CONFIG_SENSORS_MAX20830=m
+CONFIG_SENSORS_MAX20860A=m
+CONFIG_SENSORS_MAX20860A_REGULATOR=y
 CONFIG_SENSORS_MAX31785=m
 CONFIG_SENSORS_MAX34440=m
 CONFIG_SENSORS_MAX8688=m

Comment

The change only enables an additional kernel hardware monitoring driver (CONFIG_SENSORS_MP2985=m) in the shipped kernel config. This is a normal upstream-style config adjustment, does not introduce build-time downloads, scripts, privilege changes, persistence, or packaging behavior changes, and the module is built as a loadable kernel module rather than being forced in. No security concerns are evident from this diff alone.

@@ -5645,6 +5656,7 @@ CONFIG_SENSORS_MP2891=m
 CONFIG_SENSORS_MP2925=m
 CONFIG_SENSORS_MP29502=m
 CONFIG_SENSORS_MP2975=m
+CONFIG_SENSORS_MP2985=m
 CONFIG_SENSORS_MP2993=m
 CONFIG_SENSORS_MP2975_REGULATOR=y
 CONFIG_SENSORS_MP5023=m

Comment

The change is a single kernel config addition enabling the EMC1812 hardware monitoring driver as a module. This is a normal upstream kernel feature toggle, does not introduce build-time downloads, scripts, privilege changes, or packaging/install-time behavior, and it only broadens supported hardware. No security red flags are apparent from this diff alone.

@@ -5693,6 +5705,7 @@ CONFIG_SENSORS_SIS5595=m
 CONFIG_SENSORS_SY7636A=m
 CONFIG_SENSORS_DME1737=m
 CONFIG_SENSORS_EMC1403=m
+CONFIG_SENSORS_EMC1812=m
 CONFIG_SENSORS_EMC2103=m
 CONFIG_SENSORS_EMC2305=m
 CONFIG_SENSORS_EMC6W201=m

Comment

The change only enables the GPIO watchdog kernel driver as a module in the kernel config. This is a normal upstream-style configuration toggle with no evidence of added code, network access, privilege escalation, persistence, or packaging-time execution. I found no security-relevant concerns in this hunk.

@@ -5829,6 +5842,7 @@ CONFIG_DA9052_WATCHDOG=m
 CONFIG_DA9055_WATCHDOG=m
 CONFIG_DA9063_WATCHDOG=m
 CONFIG_DA9062_WATCHDOG=m
+CONFIG_GPIO_WATCHDOG=m
 CONFIG_LENOVO_SE10_WDT=m
 CONFIG_LENOVO_SE30_WDT=m
 CONFIG_MENF21BMC_WATCHDOG=m

Comment

The change only removes CONFIG_MACHZ_WDT from the kernel config. This disables one watchdog driver module and does not introduce new code execution, persistence, privilege escalation, network access, or packaging integrity issues. No suspicious build/install behavior is present in the provided hunk.

@@ -5881,7 +5895,6 @@ CONFIG_VIA_WDT=m
 CONFIG_W83627HF_WDT=m
 CONFIG_W83877F_WDT=m
 CONFIG_W83977F_WDT=m
-CONFIG_MACHZ_WDT=m
 CONFIG_SBC_EPX_C3_WATCHDOG=m
 CONFIG_INTEL_MEI_WDT=m
 CONFIG_NI903X_WDT=m

Comment

The change only disables CONFIG_EZX_PCAP in the kernel config, removing a built-in driver option. This is a narrow configuration change with no evidence of added code execution, persistence, privilege escalation, network access, or packaging integrity issues. It reduces functionality rather than introducing risk.

@@ -6000,7 +6013,6 @@ CONFIG_MFD_MT6397=m
 CONFIG_MFD_MENF21BMC=m
 CONFIG_MFD_NCT6694=m
 CONFIG_MFD_OCELOT=m
-CONFIG_EZX_PCAP=y
 CONFIG_MFD_VIPERBOARD=m
 CONFIG_MFD_RETU=m
 CONFIG_MFD_SY7636A=m

Comment

The change only removes one kernel config option, CONFIG_MFD_STMFX, from the shipped kernel configuration. This is a build-time feature toggle, not an install script, source change, or privilege/persistence mechanism. I see no security-sensitive behavior introduced by this diff; at most it disables support for a specific MFD driver, which is a functional regression risk rather than a security issue.

@@ -6055,7 +6067,6 @@ CONFIG_MFD_WM831X_SPI=y
 CONFIG_MFD_WM8350=y
 CONFIG_MFD_WM8350_I2C=y
 CONFIG_MFD_WM8994=m
-CONFIG_MFD_STMFX=m
 CONFIG_MFD_WCD934X=m
 CONFIG_MFD_ATC260X=m
 CONFIG_MFD_ATC260X_I2C=m

Comment

The change only removes CONFIG_REGULATOR_PCAP from the kernel config. This is a straightforward feature disablement in a mainline kernel package and does not introduce code execution, privilege escalation, network access, or packaging integrity issues. No suspicious build/install behavior is present in the provided diff hunk.

@@ -6144,7 +6155,6 @@ CONFIG_REGULATOR_MT6397=m
 CONFIG_REGULATOR_PALMAS=m
 CONFIG_REGULATOR_PCA9450=m
 CONFIG_REGULATOR_PF9453=m
-CONFIG_REGULATOR_PCAP=m
 CONFIG_REGULATOR_PF0900=m
 CONFIG_REGULATOR_PV88060=m
 CONFIG_REGULATOR_PV88080=m

Comment

The change only enables an additional kernel module option, CONFIG_VIDEO_HWS=m, in the kernel config. This is a straightforward feature toggle in a local config file and does not introduce any build-time downloads, privilege changes, install-script behavior, or other supply-chain/security red flags. I did not see evidence that this option alters packaging integrity or adds persistence/privilege escalation mechanisms by itself.

@@ -6464,6 +6474,7 @@ CONFIG_MEDIA_PCI_SUPPORT=y
 #
 # Media capture support
 #
+CONFIG_VIDEO_HWS=m
 CONFIG_VIDEO_MGB4=m
 CONFIG_VIDEO_SOLO6X10=m
 CONFIG_VIDEO_TW5864=m

Comment

The change only enables the AMD ISP4 capture driver as a loadable kernel module in the kernel config. This is a normal upstream feature toggle, with no added sources, scripts, install hooks, privilege changes, or packaging behavior. I don't see any supply-chain or persistence risk in this diff hunk itself.

@@ -6562,6 +6573,7 @@ CONFIG_VIDEO_MEM2MEM_DEINTERLACE=m
 #
 # Allegro DVT media platform drivers
 #
+CONFIG_VIDEO_AMD_ISP4_CAPTURE=m
 
 #
 # Amlogic media platform drivers

Comment

The change only removes two kernel config options from the shipped config: CONFIG_DRM_ANALOGIX_ANX78XX and CONFIG_DRM_ANALOGIX_DP. This is a reduction in enabled functionality, not an addition of code, build-time fetching, privilege escalation, persistence, or other security-sensitive behavior. No suspicious sources, scripts, or packaging changes are involved in this hunk.

@@ -7203,8 +7215,6 @@ CONFIG_DRM_PANEL_BRIDGE=y
 # Display Interface Bridges
 #
 CONFIG_DRM_I2C_NXP_TDA998X=m
-CONFIG_DRM_ANALOGIX_ANX78XX=m
-CONFIG_DRM_ANALOGIX_DP=m
 # end of Display Interface Bridges
 
 # CONFIG_DRM_ETNAVIV is not set

Comment

The change only enables CONFIG_DRM_PANEL_FOCALTECH_OTA7290B in the kernel config. This is a normal kernel driver toggle for a display panel, with no evidence of network access, privilege escalation, persistence, or packaging-time execution. I did not see any accompanying scripts or patches introducing suspicious behavior in this change scope.

@@ -7247,6 +7257,7 @@ CONFIG_DRM_PANEL=y
 # Display Panels
 #
 CONFIG_DRM_PANEL_AUO_A030JTN01=m
+CONFIG_DRM_PANEL_FOCALTECH_OTA7290B=m
 CONFIG_DRM_PANEL_ILITEK_ILI9341=m
 CONFIG_DRM_PANEL_ORISETECH_OTA5601A=m
 CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN=m

Comment

The change only removes a single kernel config line disabling CONFIG_FB_HGA. This is a minor kernel feature toggle in a shipped config file, with no evidence of added code execution, persistence, privilege escalation, network access, or packaging integrity issues. I did not see any suspicious source, install script, or build-time behavior associated with this diff hunk.

@@ -7329,7 +7340,6 @@ CONFIG_FB=y
 CONFIG_FB_VESA=y
 CONFIG_FB_EFI=y
 # CONFIG_FB_N411 is not set
-# CONFIG_FB_HGA is not set
 # CONFIG_FB_OPENCORES is not set
 # CONFIG_FB_S1D13XXX is not set
 # CONFIG_FB_NVIDIA is not set

Comment

The change only enables the MAX25014 backlight driver 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 or install behavior is introduced by this config-only change.

@@ -7405,6 +7415,7 @@ CONFIG_BACKLIGHT_PWM=m
 CONFIG_BACKLIGHT_CGBC=m
 CONFIG_BACKLIGHT_DA903X=m
 CONFIG_BACKLIGHT_DA9052=m
+CONFIG_BACKLIGHT_MAX25014=m
 CONFIG_BACKLIGHT_MAX8925=m
 CONFIG_BACKLIGHT_MT6370=m
 CONFIG_BACKLIGHT_APPLE=m

Comment

This change only flips CONFIG_SND_SOC_ACPI_AMD_SDCA_QUIRKS from module to built-in in the kernel config. It does not introduce new code, network access, privilege escalation, persistence, or packaging/install-script behavior. The option is a kernel quirk setting for AMD audio hardware and is a normal build-time configuration change with no obvious security impact in the package context.

@@ -7752,7 +7763,7 @@ CONFIG_SND_SOC_AMD_YC_MACH=m
 CONFIG_SND_AMD_ACP_CONFIG=m
 CONFIG_SND_SOC_AMD_ACP_COMMON=m
 CONFIG_SND_SOC_ACPI_AMD_MATCH=m
-CONFIG_SND_SOC_ACPI_AMD_SDCA_QUIRKS=m
+CONFIG_SND_SOC_ACPI_AMD_SDCA_QUIRKS=y
 CONFIG_SND_SOC_AMD_ACP_PDM=m
 CONFIG_SND_SOC_AMD_ACP_LEGACY_COMMON=m
 CONFIG_SND_SOC_AMD_ACP_I2S=m

Comment

The change only enables an additional Linux kernel sound driver option (CONFIG_SND_SOC_AMD_ACP7X=m) in the shipped kernel config. This is a normal feature toggle, does not introduce build-time downloads, scripts, privilege changes, or packaging/install-time behavior, and there is no evidence of malicious persistence or integrity impact in this diff. Risk is minimal.

@@ -7775,6 +7786,7 @@ CONFIG_SND_SOC_AMD_SOUNDWIRE_LINK_BASELINE=m
 CONFIG_SND_SOC_AMD_SOUNDWIRE=m
 CONFIG_SND_SOC_AMD_PS=m
 CONFIG_SND_SOC_AMD_PS_MACH=m
+CONFIG_SND_SOC_AMD_ACP7X=m
 # end of AMD
 
 #

Comment

This change only enables an additional Linux kernel sound driver option (CONFIG_SND_SOC_CS42XX8_SPI) in the package config. It does not introduce new sources, scripts, install hooks, privilege changes, network access, or packaging behavior. The added option is a normal kernel module setting and is consistent with the surrounding audio codec driver configuration. No security concerns are evident from this diff alone.

@@ -8152,6 +8164,7 @@ CONFIG_SND_SOC_CS4271=m
 CONFIG_SND_SOC_CS4271_I2C=m
 CONFIG_SND_SOC_CS4271_SPI=m
 CONFIG_SND_SOC_CS42XX8=m
+CONFIG_SND_SOC_CS42XX8_SPI=m
 CONFIG_SND_SOC_CS42XX8_I2C=m
 CONFIG_SND_SOC_CS43130=m
 CONFIG_SND_SOC_CS4341=m

Comment

The change only enables an additional Linux kernel sound codec driver (ES9356) as a module in the shipped kernel config. This is a normal feature toggle in a kernel package, with no evidence of network access, privilege escalation, persistence, or packaging integrity issues. I did not see any suspicious build-time behavior in the provided diff hunk.

@@ -8178,6 +8191,7 @@ CONFIG_SND_SOC_ES8328_I2C=m
 CONFIG_SND_SOC_ES8328_SPI=m
 CONFIG_SND_SOC_ES8375=m
 CONFIG_SND_SOC_ES8389=m
+CONFIG_SND_SOC_ES9356=m
 CONFIG_SND_SOC_FS_AMP_LIB=m
 CONFIG_SND_SOC_FS210X=m
 CONFIG_SND_SOC_GTM601=m

Comment

The change only enables one additional kernel config option, CONFIG_SND_SOC_TAC5XX2_SDW=m, in an Arch kernel config. This is a normal upstream driver toggle with no evidence of malicious build logic, no network access, no install-script changes, and no privilege/persistence mechanisms. The surrounding diff is a broad kernel config refresh, but this specific hunk is a straightforward module enablement for an audio codec driver.

@@ -8298,6 +8312,7 @@ CONFIG_SND_SOC_SSM4567=m
 CONFIG_SND_SOC_STA32X=m
 CONFIG_SND_SOC_STA350=m
 CONFIG_SND_SOC_STI_SAS=m
+CONFIG_SND_SOC_TAC5XX2_SDW=m
 CONFIG_SND_SOC_TAS2552=m
 CONFIG_SND_SOC_TAS2562=m
 CONFIG_SND_SOC_TAS2764=m

Comment

The change only enables an additional Linux kernel sound codec driver (CONFIG_SND_SOC_TAS675X=m) in the kernel config. This is a normal feature addition, not a build-time code execution path, privilege change, or packaging integrity issue. No suspicious sources, scripts, or install-time behavior are involved in this diff hunk.

@@ -8313,6 +8328,7 @@ CONFIG_SND_SOC_TAS571X=m
 CONFIG_SND_SOC_TAS5720=m
 CONFIG_SND_SOC_TAS5805M=m
 CONFIG_SND_SOC_TAS6424=m
+CONFIG_SND_SOC_TAS675X=m
 CONFIG_SND_SOC_TDA7419=m
 CONFIG_SND_SOC_TFA9879=m
 CONFIG_SND_SOC_TFA989X=m

Comment

The only reviewed change adds CONFIG_HID_RAKK=m to the kernel config. This is a normal kernel driver enablement for a HID device and does not introduce any obvious supply-chain, persistence, privilege-escalation, or build-time execution risk. No suspicious sources, scripts, or packaging behavior are involved in this hunk.

@@ -8503,6 +8519,7 @@ CONFIG_HID_MAGICMOUSE=m
 CONFIG_HID_MALTRON=m
 CONFIG_HID_MAYFLASH=m
 CONFIG_HID_MEGAWORLD_FF=m
+CONFIG_HID_RAKK=m
 CONFIG_HID_REDRAGON=m
 CONFIG_HID_MICROSOFT=m
 CONFIG_HID_MONTEREY=m

Comment

The change only enables the HID_OXP kernel module in the shipped kernel config. This is a normal driver configuration change with no evidence of network access, privilege escalation, persistence, or packaging integrity issues. I did not find any suspicious build-time behavior or install-script impact in the provided hunk.

@@ -8514,6 +8531,7 @@ CONFIG_HID_NTRIG=m
 CONFIG_HID_NVIDIA_SHIELD=m
 CONFIG_NVIDIA_SHIELD_FF=y
 CONFIG_HID_ORTEK=m
+CONFIG_HID_OXP=m
 CONFIG_HID_PANTHERLORD=m
 CONFIG_PANTHERLORD_FF=y
 CONFIG_HID_PENMOUNT=m

Comment

The change only enables CONFIG_USB_XHCI_PCI_PROM21 in the kernel config. This is a normal kernel driver/configuration toggle, with no evidence of added build-time code execution, network access, privilege escalation, install-script behavior, or suspicious packaging metadata. I did not find any security-relevant red flags in this hunk.

@@ -8655,6 +8673,7 @@ CONFIG_USB_C67X00_HCD=m
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DBGCAP=y
 CONFIG_USB_XHCI_PCI=y
+CONFIG_USB_XHCI_PCI_PROM21=y
 CONFIG_USB_XHCI_PCI_RENESAS=m
 CONFIG_USB_XHCI_PLATFORM=m
 CONFIG_USB_XHCI_SIDEBAND=y

Comment

The change only reorders/adjusts kernel config options for USB dual-mode controller support: it removes CONFIG_USB_CDNS_HOST and CONFIG_USB_CDNS3_GADGET from one position, then re-enables CONFIG_USB_CDNS3_GADGET and adds a comment block for platform glue driver support. No new sources, scripts, install actions, privilege changes, or network-fetching behavior are introduced. This appears to be a benign kernel configuration tweak with no obvious security impact in the package build artifacts reviewed.

@@ -8726,14 +8745,15 @@ CONFIG_USBIP_VUDC=m
 # USB dual-mode controller drivers
 #
 CONFIG_USB_CDNS_SUPPORT=m
-CONFIG_USB_CDNS_HOST=y
 CONFIG_USB_CDNS3=m
-CONFIG_USB_CDNS3_GADGET=y
 CONFIG_USB_CDNS3_HOST=y
+CONFIG_USB_CDNS3_GADGET=y
+
+#
+# Platform glue driver support
+#
 CONFIG_USB_CDNS3_PCI_WRAP=m
 CONFIG_USB_CDNSP_PCI=m
-CONFIG_USB_CDNSP_GADGET=y
-CONFIG_USB_CDNSP_HOST=y
 CONFIG_USB_MUSB_HDRC=m
 # CONFIG_USB_MUSB_HOST is not set
 # CONFIG_USB_MUSB_GADGET is not set

Comment

The change only enables CONFIG_INFINIBAND_USER_ACCESS_CORE built into the kernel, alongside existing Infiniband user-access options. This is a normal kernel configuration adjustment with no evidence of network fetches, scripts, privilege escalation, persistence, or packaging integrity issues. I don't see any security red flags in this single-line config change.

@@ -9251,6 +9271,7 @@ CONFIG_SPEAKUP_SYNTH_DUMMY=m
 CONFIG_INFINIBAND=m
 CONFIG_INFINIBAND_USER_MAD=m
 CONFIG_INFINIBAND_USER_ACCESS=m
+CONFIG_INFINIBAND_USER_ACCESS_CORE=y
 CONFIG_INFINIBAND_USER_MEM=y
 CONFIG_INFINIBAND_ON_DEMAND_PAGING=y
 CONFIG_INFINIBAND_ADDR_TRANS=y

Comment

The change is a one-line kernel config adjustment that removes CONFIG_RTC_DRV_PCAP from the built modules list. This does not introduce code execution, privilege changes, network access, or packaging/install-script behavior. It only reduces included functionality for a specific RTC driver, so there is no security concern evident in this diff.

@@ -9446,7 +9467,6 @@ CONFIG_RTC_DRV_CROS_EC=m
 # on-CPU RTC drivers
 #
 CONFIG_RTC_DRV_FTRTC010=m
-CONFIG_RTC_DRV_PCAP=m
 CONFIG_RTC_DRV_MC13XXX=m
 CONFIG_RTC_DRV_MT6397=m
 CONFIG_RTC_DRV_GOLDFISH=m

Comment

The change only enables a kernel config option, CONFIG_DMABUF_HEAPS_SYSTEM_CC_SHARED, and removes the explicit comment disabling DMABUF selftests. There are no package build scripts, install hooks, network fetches, privilege changes, or shipped binaries involved in this hunk. From a supply-chain/security-review perspective this is a low-risk kernel configuration tweak; the main effect is functional behavior of the kernel's dmabuf heap sharing, not an obvious persistence or escalation mechanism. I don't see evidence in this diff of malicious intent or a packaging integrity issue.

@@ -9505,9 +9525,9 @@ CONFIG_SYNC_FILE=y
 # CONFIG_SW_SYNC is not set
 CONFIG_UDMABUF=y
 # CONFIG_DMABUF_DEBUG is not set
-# CONFIG_DMABUF_SELFTESTS is not set
 CONFIG_DMABUF_HEAPS=y
 CONFIG_DMABUF_HEAPS_SYSTEM=y
+CONFIG_DMABUF_HEAPS_SYSTEM_CC_SHARED=y
 CONFIG_DMABUF_HEAPS_CMA=y
 # end of DMABUF options
 

Comment

The change only enables CONFIG_TDX_HOST_SERVICES as a module in the kernel config. This is a normal upstream kernel feature toggle, with no evidence of added build-time downloads, scripts, privilege escalation, persistence, or suspicious packaging behavior in the provided diff. I did not see any integrity or supply-chain red flags in this single-line config change.

@@ -9563,6 +9583,7 @@ CONFIG_TDX_GUEST_DRIVER=m
 CONFIG_TSM_GUEST=y
 CONFIG_TSM_REPORTS=m
 CONFIG_TSM_MEASUREMENTS=y
+CONFIG_TDX_HOST_SERVICES=m
 CONFIG_TSM=y
 CONFIG_VIRTIO_ANCHOR=y
 CONFIG_VIRTIO=y

Comment

The change only enables the upstream kernel driver CONFIG_VIDEO_MAX96712 as a module in the shipped kernel config. This is a normal feature toggle in a kernel package, with no evidence of added network access, post-install actions, privilege escalation, or suspicious packaging behavior in the provided hunk. I see no security concern from this diff alone.

@@ -9727,6 +9748,7 @@ CONFIG_DVB_AV7110_OSD=y
 CONFIG_DVB_SP8870=m
 CONFIG_VIDEO_IPU3_IMGU=m
 CONFIG_VIDEO_INTEL_IPU7=m
+CONFIG_VIDEO_MAX96712=m
 # CONFIG_STAGING_MEDIA_DEPRECATED is not set
 # CONFIG_FB_TFT is not set
 CONFIG_MOST_COMPONENTS=m

Comment

The change only enables a single additional kernel module, CONFIG_DELL_DW5826E_RESET=m, in the shipped kernel config. This is a normal upstream kernel feature toggle, not a packaging script, install hook, or external source change. I see no evidence of network access, privilege escalation, persistence, or integrity issues introduced by this diff hunk.

@@ -9851,6 +9873,7 @@ CONFIG_DELL_WMI_DESCRIPTOR=m
 CONFIG_DELL_WMI_DDV=m
 CONFIG_DELL_WMI_LED=m
 CONFIG_DELL_WMI_SYSMAN=m
+CONFIG_DELL_DW5826E_RESET=m
 CONFIG_AMILO_RFKILL=m
 CONFIG_FUJITSU_LAPTOP=m
 CONFIG_FUJITSU_TABLET=m

Comment

The change only enables an additional upstream Linux kernel telemetry driver (CONFIG_INTEL_PMC_PWRM_TELEMETRY=m) in the shipped kernel config. This is a normal feature toggle in a kernel package, with no evidence of added build-time downloads, scripts, privilege escalation, persistence, or other supply-chain red flags in the provided hunk. Risk is minimal.

@@ -9870,6 +9893,7 @@ CONFIG_INTEL_SAR_INT1092=m
 CONFIG_INTEL_SKL_INT3472=m
 CONFIG_INTEL_PMC_CORE=m
 CONFIG_INTEL_PMC_SSRAM_TELEMETRY=m
+CONFIG_INTEL_PMC_PWRM_TELEMETRY=m
 CONFIG_INTEL_PMT_CLASS=m
 CONFIG_INTEL_PMT_TELEMETRY=m
 CONFIG_INTEL_PMT_CRASHLOG=m

Comment

The change removes CONFIG_HYPERV_IOMMU from the kernel config. This is a security-relevant feature toggle, but the diff only disables Hyper-V IOMMU support and does not introduce any new code execution, persistence, privilege escalation, network access, or packaging integrity issues. It may reduce functionality for Hyper-V guests, but there is no evidence of malicious behavior or a direct security regression from the change alone.

@@ -10041,7 +10065,6 @@ CONFIG_INTEL_IOMMU_PERF_EVENTS=y
 CONFIG_IOMMUFD_DRIVER_CORE=y
 CONFIG_IOMMUFD=m
 CONFIG_IRQ_REMAP=y
-CONFIG_HYPERV_IOMMU=y
 CONFIG_VIRTIO_IOMMU=m
 CONFIG_GENERIC_PT=y
 # CONFIG_DEBUG_GENERIC_PT is not set

Comment

The change only enables the CONFIG_AD4691 kernel driver in the shipped kernel config. This is a normal device-driver addition with no evidence of malicious behavior, privilege escalation, persistence, network access, or packaging integrity issues. I found no suspicious build/install scripts or source changes associated with this hunk.

@@ -10302,6 +10325,7 @@ CONFIG_AD4080=m
 CONFIG_AD4130=m
 CONFIG_AD4134=m
 CONFIG_AD4170_4=m
+CONFIG_AD4691=m
 CONFIG_AD4695=m
 CONFIG_AD4851=m
 CONFIG_AD7091R=m

Comment

The change only enables the AD5706R kernel driver as a loadable module in the kernel config. This is a normal upstream configuration adjustment with no evidence of malicious behavior, privilege escalation, network access, persistence, or packaging integrity issues in the provided hunk.

@@ -10523,6 +10547,7 @@ CONFIG_AD5592R=m
 CONFIG_AD5593R=m
 CONFIG_AD5504=m
 CONFIG_AD5624R_SPI=m
+CONFIG_AD5706R=m
 CONFIG_AD9739A=m
 CONFIG_LTC2688=m
 CONFIG_AD5686=m

Comment

The change is a single kernel config toggle enabling CONFIG_APDS9999=m. This is a normal in-tree driver option in a large kernel config update, with no evidence of network fetches, install-script behavior, privilege escalation, or suspicious packaging logic. The surrounding diff is broad but this specific hunk only adds a module for an upstream kernel driver, so I see no security concern in this change itself.

@@ -10715,6 +10740,7 @@ CONFIG_APDS9160=m
 CONFIG_APDS9300=m
 CONFIG_APDS9306=m
 CONFIG_APDS9960=m
+CONFIG_APDS9999=m
 CONFIG_AS73211=m
 CONFIG_BH1745=m
 CONFIG_BH1750=m

Comment

The change is a one-line kernel config addition enabling the VEML3328 ambient light sensor driver as a module. This is a normal upstream kernel feature toggle, with no evidence of network access, script execution, privilege escalation, persistence, or packaging integrity issues in the provided diff. No suspicious sources or install-time behavior are introduced by this change.

@@ -10766,6 +10792,7 @@ CONFIG_US5182D=m
 CONFIG_VCNL4000=m
 CONFIG_VCNL4035=m
 CONFIG_VEML3235=m
+CONFIG_VEML3328=m
 CONFIG_VEML6030=m
 CONFIG_VEML6040=m
 CONFIG_VEML6046X00=m

Comment

The reviewed hunk only adds `CONFIG_MMC5983=m` to the kernel config. This enables an additional magnetometer driver as a loadable module; it does not introduce build-time network access, privilege escalation, persistence, or packaging changes. No suspicious source/integrity issues are present in this diff hunk itself.

@@ -10789,6 +10816,7 @@ CONFIG_MAG3110=m
 CONFIG_HID_SENSOR_MAGNETOMETER_3D=m
 CONFIG_MMC35240=m
 CONFIG_MMC5633=m
+CONFIG_MMC5983=m
 CONFIG_IIO_ST_MAGN_3AXIS=m
 CONFIG_IIO_ST_MAGN_I2C_3AXIS=m
 CONFIG_IIO_ST_MAGN_SPI_3AXIS=m

Comment

The change only removes CONFIG_IIO_INTERRUPT_TRIGGER from the kernel config. This is a build-time feature toggle in a shipped config file, with no added code, scripts, sources, or privilege-related behavior. I don't see any supply-chain, persistence, or integrity risk introduced by this diff alone.

@@ -10821,7 +10849,6 @@ CONFIG_HID_SENSOR_DEVICE_ROTATION=m
 # Triggers - standalone
 #
 CONFIG_IIO_HRTIMER_TRIGGER=m
-CONFIG_IIO_INTERRUPT_TRIGGER=m
 CONFIG_IIO_TIGHTLOOP_TRIGGER=m
 CONFIG_IIO_SYSFS_TRIGGER=m
 # end of Triggers - standalone

Comment

The change only enables the NXP TJA1145 PHY driver as a loadable kernel module in the kernel config. This is a normal upstream kernel configuration toggle, with no evidence of added code, scripts, network access, privilege escalation, or packaging-time execution. I did not see any integrity or persistence concerns in this diff hunk.

@@ -11014,6 +11041,7 @@ CONFIG_GENERIC_PHY_MIPI_DPHY=y
 CONFIG_PHY_CAN_TRANSCEIVER=m
 CONFIG_PHY_GOOGLE_USB=m
 CONFIG_USB_LGM_PHY=m
+CONFIG_PHY_NXP_TJA1145=m
 
 #
 # PHY drivers for Broadcom platforms

Comment

The change only enables two additional kernel modules in the shipped kernel config: CONFIG_USB4_CONFIGFS and CONFIG_USB4_STREAM. This is a normal feature toggle in a kernel package, with no evidence of network access, privilege escalation, persistence, or packaging integrity issues. I did not see any suspicious scripts or external downloads associated with this diff hunk.

@@ -11054,8 +11082,10 @@ CONFIG_AMD_ATL=m
 CONFIG_AMD_ATL_PRM=y
 CONFIG_RAS_FMPM=m
 CONFIG_USB4=m
+CONFIG_USB4_CONFIGFS=m
 # CONFIG_USB4_DEBUGFS_WRITE is not set
 # CONFIG_USB4_DMA_TEST is not set
+CONFIG_USB4_STREAM=m
 
 #
 # Android

Comment

The change only enables the in-tree kernel config option CONFIG_FPGA_MGR_EFINIX_SPI as a module. This is a normal kernel feature toggle, with no added sources, scripts, install hooks, privilege changes, or build-time network activity. I see no security-relevant red flags in this diff hunk.

@@ -11135,6 +11165,7 @@ CONFIG_FPGA_M10_BMC_SEC_UPDATE=m
 CONFIG_FPGA_MGR_MICROCHIP_SPI=m
 CONFIG_FPGA_MGR_LATTICE_SYSCONFIG=m
 CONFIG_FPGA_MGR_LATTICE_SYSCONFIG_SPI=m
+CONFIG_FPGA_MGR_EFINIX_SPI=m
 CONFIG_TEE=m
 CONFIG_TEE_DMABUF_HEAPS=y
 CONFIG_OPTEE_STATIC_PROTMEM_POOL=y

Comment

The change only adjusts Linux kernel EROFS filesystem configuration: it adds a default max streams setting for LZMA compression, removes CONFIG_EROFS_FS_ONDEMAND, and explicitly disables page cache sharing. This is a normal feature-tuning change with no evidence of supply-chain risk, privilege escalation, persistence, network access, or packaging-time code execution. No suspicious sources, scripts, or install-time behavior are involved in this hunk.

@@ -11435,12 +11466,13 @@ CONFIG_EROFS_FS_SECURITY=y
 CONFIG_EROFS_FS_BACKED_BY_FILE=y
 CONFIG_EROFS_FS_ZIP=y
 CONFIG_EROFS_FS_ZIP_LZMA=y
+CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=16
 CONFIG_EROFS_FS_ZIP_DEFLATE=y
 CONFIG_EROFS_FS_ZIP_ZSTD=y
 CONFIG_EROFS_FS_ZIP_ACCEL=y
-CONFIG_EROFS_FS_ONDEMAND=y
 CONFIG_EROFS_FS_PCPU_KTHREAD=y
 CONFIG_EROFS_FS_PCPU_KTHREAD_HIPRI=y
+# CONFIG_EROFS_FS_PAGE_CACHE_SHARE is not set
 CONFIG_VBOXSF_FS=m
 CONFIG_NETWORK_FILESYSTEMS=y
 CONFIG_NFS_FS=m

Comment

The change only removes three kernel config options enabling additional Kerberos encryption types for RPCSEC_GSS (AES-SHA1, Camellia, AES-SHA2). This is a functional reduction, not a security backdoor or privilege escalation. It may reduce compatibility with some NFS/RPCSEC_GSS deployments that rely on those enctypes, but it does not introduce suspicious build-time behavior, network access, or packaging risks.

@@ -11488,9 +11520,6 @@ CONFIG_SUNRPC_GSS=m
 CONFIG_SUNRPC_BACKCHANNEL=y
 CONFIG_SUNRPC_SWAP=y
 CONFIG_RPCSEC_GSS_KRB5=m
-CONFIG_RPCSEC_GSS_KRB5_ENCTYPES_AES_SHA1=y
-CONFIG_RPCSEC_GSS_KRB5_ENCTYPES_CAMELLIA=y
-CONFIG_RPCSEC_GSS_KRB5_ENCTYPES_AES_SHA2=y
 CONFIG_SUNRPC_DEBUG=y
 # CONFIG_SUNRPC_DEBUG_TRACE is not set
 CONFIG_SUNRPC_XPRT_RDMA=m

Comment

The change only enables CONFIG_HAVE_TRUSTED_KEYS_DEBUG in the kernel config and explicitly leaves CONFIG_TRUSTED_KEYS_DEBUG disabled. This is a build-time kernel configuration flag, not a runtime persistence or privilege-escalation mechanism by itself. I do not see any added sources, scripts, install hooks, or packaging behavior changes in the provided hunk. On its face this is low risk and appears to be a harmless config adjustment.

@@ -11594,6 +11623,8 @@ CONFIG_PERSISTENT_KEYRINGS=y
 CONFIG_BIG_KEYS=y
 CONFIG_TRUSTED_KEYS=m
 CONFIG_HAVE_TRUSTED_KEYS=y
+CONFIG_HAVE_TRUSTED_KEYS_DEBUG=y
+# CONFIG_TRUSTED_KEYS_DEBUG is not set
 CONFIG_TRUSTED_KEYS_TPM=y
 CONFIG_TRUSTED_KEYS_TEE=y
 CONFIG_ENCRYPTED_KEYS=m

Comment

The change only removes CONFIG_CRYPTO_FCRYPT from the kernel config. This disables building the FCRYPT crypto module, which is a straightforward feature reduction and does not introduce any new code execution, persistence, privilege escalation, or integrity risks. No suspicious build-time behavior or packaging changes are present in the reviewed hunk.

@@ -11787,7 +11818,6 @@ CONFIG_CRYPTO_CAST_COMMON=m
 CONFIG_CRYPTO_CAST5=m
 CONFIG_CRYPTO_CAST6=m
 CONFIG_CRYPTO_DES=m
-CONFIG_CRYPTO_FCRYPT=m
 CONFIG_CRYPTO_SERPENT=m
 CONFIG_CRYPTO_SM4=m
 CONFIG_CRYPTO_SM4_GENERIC=m

Comment

The change only removes CONFIG_CRYPTO_PCBC from the kernel config. This disables one optional block cipher mode and does not introduce any new code execution, privilege escalation, persistence, network access, or packaging integrity concerns. No suspicious sources or install-time behavior are implicated by this diff hunk.

@@ -11806,7 +11836,6 @@ CONFIG_CRYPTO_CTS=y
 CONFIG_CRYPTO_ECB=y
 CONFIG_CRYPTO_HCTR2=m
 CONFIG_CRYPTO_LRW=m
-CONFIG_CRYPTO_PCBC=m
 CONFIG_CRYPTO_XCTR=m
 CONFIG_CRYPTO_XTS=y
 # end of Length-preserving ciphers and modes

Comment

The change only switches CONFIG_CRYPTO_LZ4 from a loadable module to built-in support in the kernel config. This does not introduce new code, network access, privilege escalation, persistence, or packaging integrity issues. It slightly changes kernel composition/boot behavior but is not a security concern by itself.

@@ -11857,7 +11886,7 @@ CONFIG_CRYPTO_CRC32=m
 CONFIG_CRYPTO_DEFLATE=m
 CONFIG_CRYPTO_LZO=y
 CONFIG_CRYPTO_842=m
-CONFIG_CRYPTO_LZ4=m
+CONFIG_CRYPTO_LZ4=y
 CONFIG_CRYPTO_LZ4HC=m
 CONFIG_CRYPTO_ZSTD=y
 # end of Compression

Comment

The change is limited to kernel config toggles in the crypto RNG section and a comment update. It removes several DRBG sub-options and one KDF option while keeping CONFIG_CRYPTO_DRBG enabled, and marks the userspace crypto API section as deprecated. There are no signs of supply-chain risk, privilege escalation, persistence, or build-time code execution in this diff. The only potential concern is a functional/regression change in kernel crypto capabilities, not a security issue in the package metadata or build process.

@@ -11865,21 +11894,16 @@ CONFIG_CRYPTO_ZSTD=y
 #
 # Random number generation
 #
-CONFIG_CRYPTO_DRBG_MENU=y
-CONFIG_CRYPTO_DRBG_HMAC=y
-CONFIG_CRYPTO_DRBG_HASH=y
-CONFIG_CRYPTO_DRBG_CTR=y
 CONFIG_CRYPTO_DRBG=y
 CONFIG_CRYPTO_JITTERENTROPY=y
 CONFIG_CRYPTO_JITTERENTROPY_MEMORY_BLOCKS=64
 CONFIG_CRYPTO_JITTERENTROPY_MEMORY_BLOCKSIZE=32
 CONFIG_CRYPTO_JITTERENTROPY_OSR=1
 CONFIG_CRYPTO_KDF800108_CTR=y
-CONFIG_CRYPTO_DF80090A=y
 # end of Random number generation
 
 #
-# Userspace interface
+# Userspace interface (deprecated)
 #
 CONFIG_CRYPTO_USER_API=m
 CONFIG_CRYPTO_USER_API_HASH=m

Comment

This change only updates a comment in the kernel config from '# end of Userspace interface' to '# end of Userspace interface (deprecated)'. It does not alter any enabled kernel options, build inputs, scripts, sources, permissions, or packaging behavior. No security impact is evident from this diff hunk alone.

@@ -11888,7 +11912,7 @@ CONFIG_CRYPTO_USER_API_RNG=m
 # CONFIG_CRYPTO_USER_API_RNG_CAVP is not set
 CONFIG_CRYPTO_USER_API_AEAD=m
 # CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set
-# end of Userspace interface
+# end of Userspace interface (deprecated)
 
 #
 # Accelerated Cryptographic Algorithms for CPU (x86)

Comment

The change is a kernel config refresh with many feature toggles, but nothing in the reviewed hunk suggests a supply-chain or privilege-escalation issue. The notable edits are enabling/disabling kernel subsystems (e.g. RAID6_PQ moved later with ARCH variant, bitreverse, crypto/compression options), which affect kernel functionality but are not inherently malicious. No build-time downloads, install scripts, or external sources are involved in this diff, and there are no obvious persistence or privilege changes. Overall this looks like routine config churn with low security risk.

@@ -11986,11 +12010,10 @@ CONFIG_BINARY_PRINTF=y
 #
 # Library routines
 #
-CONFIG_RAID6_PQ=y
-# CONFIG_RAID6_PQ_BENCHMARK is not set
 CONFIG_LINEAR_RANGES=y
 CONFIG_PACKING=y
 CONFIG_BITREVERSE=y
+CONFIG_GENERIC_BITREVERSE=y
 CONFIG_GENERIC_STRNCPY_FROM_USER=y
 CONFIG_GENERIC_STRNLEN_USER=y
 CONFIG_GENERIC_NET_UTILS=y

Comment

The change only flips CONFIG_CRYPTO_LIB_AES_CBC_MACS from a loadable module to built-in. This is a kernel config adjustment with no added code, no new sources, no build-time downloads, and no privilege/persistence mechanism. I don't see a security issue in this diff hunk by itself; at most it changes when the crypto helper is available during boot.

@@ -12019,7 +12042,7 @@ 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_MACS=m
+CONFIG_CRYPTO_LIB_AES_CBC_MACS=y
 CONFIG_CRYPTO_LIB_AESGCM=y
 CONFIG_CRYPTO_LIB_ARC4=m
 CONFIG_CRYPTO_LIB_GF128MUL=m

Comment

The change only enables the kernel RAID6 parity library and its arch-specific implementation, plus leaves the benchmark option disabled. This is a normal kernel configuration adjustment with no evidence of network access, privilege escalation, persistence, or other supply-chain risk in the diff provided. No suspicious packaging behavior is introduced by this hunk.

@@ -12053,6 +12076,9 @@ CONFIG_CRYPTO_LIB_SM3=m
 CONFIG_CRYPTO_LIB_SM3_ARCH=y
 CONFIG_XOR_BLOCKS=y
 CONFIG_XOR_BLOCKS_ARCH=y
+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

Comment

The change only switches CONFIG_LZ4_COMPRESS from a loadable module to built-in. This does not introduce new code, network access, privilege escalation, persistence, or packaging integrity issues; it only changes when existing kernel compression support is available. No suspicious build-time behavior or install-script impact is present in the provided diff.

@@ -12061,7 +12087,7 @@ CONFIG_ZLIB_INFLATE=y
 CONFIG_ZLIB_DEFLATE=y
 CONFIG_LZO_COMPRESS=y
 CONFIG_LZO_DECOMPRESS=y
-CONFIG_LZ4_COMPRESS=m
+CONFIG_LZ4_COMPRESS=y
 CONFIG_LZ4HC_COMPRESS=m
 CONFIG_LZ4_DECOMPRESS=y
 CONFIG_ZSTD_COMMON=y

Comment

The change only adds an explicit disabled kernel config option: CONFIG_RING_BUFFER_PERSISTENT_INJECT is not set. This is a benign config-file update with no code execution, packaging, privilege, or persistence implications. No suspicious sources, scripts, or install-time behavior are introduced by this hunk.

@@ -12497,6 +12523,7 @@ CONFIG_HIST_TRIGGERS=y
 # CONFIG_FTRACE_SORT_STARTUP_TEST is not set
 # CONFIG_RING_BUFFER_STARTUP_TEST is not set
 # CONFIG_RING_BUFFER_VALIDATE_TIME_DELTAS is not set
+# CONFIG_RING_BUFFER_PERSISTENT_INJECT is not set
 # CONFIG_MMIOTRACE_TEST is not set
 # CONFIG_PREEMPTIRQ_DELAY_TEST is not set
 # CONFIG_SYNTH_EVENT_GEN_TEST is not set