| Age | Commit message (Collapse) | Author |
|---|
|
This is the 4.19.303 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmWC/FIACgkQONu9yGCS
# aT4PGBAAmX42BpkC8qqWMrV0bmHf7KtjUyPBeMybVKBXaFkhUSbtwraAI0QWkIUM
# mEqzUehaTxFhy+QFGRvA9982ChamygDZsWK+2EOigqTXFmVWrIESC5GJAHrCdc06
# /b+6oNoTFuRcbVIAxyEL9S+K1pJ11/6Da6tvUKiWizczpZnA3IXLT4nbTFr3Q7cS
# wPv6ggk6rdyXlmMSiYrRJA4HjN/0akrUNcwoW00LCgKc8892Y7Q1YfnFiJVC75Fa
# U2+97SSvboM6pJ28mvm3yR4dV02Q8Cs9hI9M1rzIV6ftU8KzEUP3ZCZGaUh4Bwqi
# MOH8T5DaE+Velbp7ECyzQRHOzhu1dGjFOda1ZR9YpbcE/PBzZ4fOSIUf1glP3K6o
# U9FpIJHMn+MQk1j4AA+GYJfhOAeaiBjs5y7z3hhNLV1lvshuZGxRKONUtBtOMhwS
# HfYBW3/7Af7a2q2ITS27RRBCFv6Gqkza0vLzte0Om0XvCn6JFzzIsymFa0cjjg2B
# G++HZDBQqHWF8EEYRA1XsoJQDEk9o2F7IaX+hOar24mAEsqXBYNzOFvqn2uf/a5c
# 9mGBpbDGrq0P5EkwIQjgSovbvmplmmAGB74fBrCSrQVKuXjzloAjUbHQqFVVu49q
# lAMTCtfLxQyioSlTXrYKX1ANKjlR1kqBIF2GP2oHE74MwR3hYSo=
# =V5/I
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 20 Dec 2023 09:38:10 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.302 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmV53vEACgkQONu9yGCS
# aT4wng/9ECVr1tNbX+0oo5p4GFnY2wR3I39TslGkS048Yo1UiW/m7WX2nDJPhJXO
# YLLiSsm0xOKZEn1xDh99L5kIWZHeHywajMdrIDZwRhOtBj8RHX0NyWQQzxg2ftxs
# 7IrgXyt/38b6kcQ2or8rqPqINGeZWAErukMfGMQZIMkp48D68cyfPDk0xfFwryAL
# mfn1tQOe6OgPFSbNR7MiV1mWzC6f06J6ZOx3kUvS6tqu0ZF61yhE8QkB/U2dQb/z
# S7VTM4BQ5NuW9BiGfLF39OAppEZ7jB/JZjCzh5h2ZUWpKhxl09u5FFqT81fOqtBN
# b/rhPnNnG1gFarGChrRbdvU4YnomBce7f7knpe0/vUiZW+UBxIW5yagUoXz7Eo0X
# Lyowuj5bXhDAJ1T/G/AV8Fv0eIunBRUyXcdeF6qeHWV2NzDmcYbswY6gh5eWDZL3
# ST83NvEq+p5uGzZHEbjbP3AX0P5wHDPAkhLXKLCwTsylHKrfL12e1+FWY2Jv40PA
# Ze+8SNCZrdHIYXZWSczrGZJM+GJh1KCkOQt/wSkGzPPAmoqcOTyMqD7Tj7o8qUER
# lQGDYzEO7+ZGMQ3QtSqQ//3Mlaeh4JYjzEYgpuXA7bFeepn/9FVDUurKZW39A/o5
# 0TTWsgwRlt2j92Jfi8ajbT5aAVJ0+o6KFqElUhc2onMMEWngUXs=
# =Ryx9
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 13 Dec 2023 11:42:25 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.300 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmVmGaYACgkQONu9yGCS
# aT6nzRAApEttSs9XhWbu1hXqfcOUKBsq2BLss2+9zfp2jwhCVQFQOApU5xggjpww
# 5ATVq2FQGEk1kMRpESeDdkW7fnFevwEgyZafYrBbbBk6/9bbWMyqMBhlGP7RWNY9
# KoEhpMOejOYfCc+Z/II+BDf3KK2roXnrO8L5rFnyOTeJxgmofAqWYe5WWtHlcDtK
# z5KceJiXy0ddjgm6+nvpHrfStu9uDs+O63nf0XG6gmgFeRa/tI7hQg1mSUlpR8X3
# Ip5kk5pYjZ+T3gwepDJmhpOLW+xHeXKrbAb3nN38lPrRnnM/7lxp6FJkhkts6FqF
# r/8MgWcKe2XpnxwiLvIFGV4jIG1GNC8ZYdVWYVNZxi+SdD6Jz9qLraAoTQDR6zSR
# R60pond+MdjBzFeKsFvV6F5a4cDTY+REaVK92YV7y1U70IRR9UrsZipxmqcD0dxa
# eRgLxM663DF0b1hjiP2WL4IxQSlVTPMJMj8U6eXtfdHebDOb+J/Qoq7mlQHd9ExL
# S3snvJhAco0+SopK4v4GN1a5SHKx7a2Ua2OOG3CfHTRK3yoH5F/qE/cLpRR6vxxl
# NVyB5N2s9zkgX4p+2rFi8XR2/DsBReTu2C8hzXQ6AGYLZ15qIvRIkXCSUBNZO3tt
# r7h3+oUwmNQ478y7NWpAVGcczZQBel3NjHDZMIdWZJPLVffLP+A=
# =B47s
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 28 Nov 2023 11:47:34 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.296 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmUlqccACgkQONu9yGCS
# aT4gqQ/+MgTjBf9wQ4KfZI5RZaQJhRVuubL58TmHD0HMkGhaQhPgsswQ7Sil5nQ2
# 889+PhxTJ6p9tNFYdYz/urv0qM197vWFOpWvkKqBlLLkHEIU14e7OiLdZuydYPVV
# iyFXNrEr5xVerYo7tTsmuOYNzgArwVxmEa/GNlpy/AJl7uP/wxt5g8sbChziM1k2
# erSmRrBp0tCG2xVjLWx1LEIWqmB11rTuP0Kl5j86THnS5czzCmdQyvWypMDB+M1o
# UX6SF1bFMdvh59ultJQN+SYfq+HSo66xxKNDCRRiqvBi2BvBOYKwnDZYwLuf9H8/
# ELOQ//RbWv42wrhosoj637748CwWlgJQCNYR1RiV09CA/bHqlKDwfZM7sUbzeebM
# 5/Z+ODM/WtJ1/jdbvu1KkkurVLFaKGOmDKefiosZt+4KMXPbyy6jg6J6/moLZqJ8
# hbym4x8n6KWYMBrvxQt9Ukyo/SBkcoFAJfCdks1hqtkEL7L+VAxaC1mfUqcNzhlY
# RXopvFhEoMlBQ2pOQzK1lDy2m3rZS+md5UUO8G+DZ0keerK7oKVLKVstBTBzx++k
# d2SZ7ijRHqqvSfCYbtNrzgBdc06Ou9zT5vOK9KuWR5CQxIwW3NTu23umg7AmMcdT
# WkdxqcpO1YZCCbH9oK40ynbP4Ap0fYzZ0SGIoNuclknGX+NJ1E0=
# =LBDu
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 10 Oct 2023 03:45:11 PM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.295 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmUOpmEACgkQONu9yGCS
# aT6vSQ/8D3yjJUYiUnHkiSzTMZHAtwR5qk0jCsqw1Xlr+XVouGCG/wpk8z7ckT6W
# 4gsG5+QvuB4SfWXmbIn/rPApqQdQSiTicOfHrev705v0U+ib+kw1vgBKv38qkOlI
# EZKuo7Ir1vZUnqghw9uIGperU3kEAt2EvWK37EBryukDoxbzDGIctOvAN7KMMbAJ
# jPQciVOOAJrNNdgPOSrxs1OCdAkEYlDaNuBZ+9j/HjNQLB9KtdtsJ50gerCPA4rS
# oKpZhnx9VJYXI9szor3T7q71iNfpJeL+mOrnpCSFVAFCPkesXQ+MG/GdgJJQDCMJ
# 9VF12W6rpqVcKfYFdPX9WevkqMfHRpE4brotDQx36rpUwVFcP7HClJ2zE3p36QWV
# Mfu4O31ZNkLUF8SmFXc3JXVyrwe/ARiha9nLH9VKZ7cSHoYUKlO4NeSGyHjz5J99
# RErBGpea7SgHTSLk30+sHaB3zhdUZyv8ej++zjTG9QA8bRbMp97I9psQ7FWhWDng
# l6f87mdta1X76OJJPkL3yZfbiB/M58e514ptbDNhu4cnH/S6aB6I3K5IYVtfZI/9
# zESuavKEUks+Ng1vBUGsPGN/eHDaPWUkl7HewP7WXRDOQUjaIX/0saeaSiUFYNI7
# UYa72hD9fKMblkwxIl75ybI/WZRgw9fyrQeGG0DfX3t6kt6BhHM=
# =bQT4
# -----END PGP SIGNATURE-----
# gpg: Signature made Sat 23 Sep 2023 04:48:33 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.291 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmTWBMYACgkQONu9yGCS
# aT5fcw//f8IqgXhnM1RmdENWcj8Yttld1jY0L8+z2fRvkzmuqFJAnOuTEP/BV9Zk
# iMNH6Hg5iZh/ajGyW4OxsWHvaDNyZtpPOgNtQkhHPPDq5tqAgg+8ZgPlZkmbvnGd
# askxaSJE7OuJOfG193o/Uf0CR/boSIN1ioIu0vumqhrP2NUbe44/PLeSB239ZdGy
# nIaBo1JXffOH8P7kSS4E9NSrfoA9MQEuJgcYPkc1c08W2FWO8MftM/hdQtXGwbNC
# LCy4yGc3PN40MT7tOsXE0w3P+ZUXfP6g8NgHooRKuLimSiAYodLgCwnvELZ/Nsg+
# w1TPDxbLD99te5J16GzlzhN4+9BUtf2qq9ZgiJQ8lmKaGc+hAMRKF2h2E5Qhla8R
# TJubYFjD5yilANlRumVHMzNJZntROw0hG0ZIX6An/1QM5JAy7B736jI6jt+RZFSx
# r08xhBXcO+m3s2Vc2OojJFKLot9i0ugiKkTuQBZsBFDfcOtSrUUarB6Vz6wZvCY8
# sojQOS0eoYb+2GlKJ0UzTPLEHrCpusRkEnv3QMAPfTkw6vqvkrYACfOEbBujfT8e
# TtC7wuS3beULYPKpObe9HrpCooOXX8YQFXyld5e5iBINXwt/UT4daDL85BbMsPEu
# MPaSKrTMGXUsRoOWHiuPumT/MDE5LBSCqhyi41k90R9qRW6M+Wk=
# =KuAb
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 11 Aug 2023 05:52:06 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.284 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmR14SUACgkQONu9yGCS
# aT5twA/9FzPtWeYCa9WdaW3YrlwXAwUSX+Q749XupcGbrXS1cljiB7XzvSQ48Ce9
# FrI+b4UNRmq1sjBq39GMVTCpVcis1PhI5uthvP/eNIazFvAb8Ksidsv10cGKtmi6
# dhe8+z6InAut46npKt+YHLTrgu+rkQ7nWk5thT52JLD2VsTf/AwNvy2wDVrtpwND
# XldYW/jP6GErmPXVdy2nBzP5kFKWpd6DIVrnKrP0g+G1UF6mV1mg2Bt9aoMyWenK
# TU9cv+FwAr40EmPSn6ooJbo0oOgJrkOidaoJEIgzOw4MWv/lNd6dijuKlkfKg56s
# elIa+TAlQBkkfXWNDSg8RCT0Im6iw+qVMmuIUvn4Y6zyFhQS2kBPZHavOHrIdYK3
# HKkEjl1l24z/k7HSkPVS+FR7YxF9EeQunJBJjA3NGLx4woFVoqCgCp5C5cAyC1D1
# lVE8lAPq/R5oIPgsL7WwYCdwvlnoA4R8HFmS/53ySRxQ839A0Ea1vQB96ISPdoGk
# AxU1DarM+BxLQbYVaW+HmDctox0wlhV9pmlSmRNzGDno0OsME9e7grUSxBC96ogf
# GFFYs2zTKE8y9/1LzBQSrJdXHjofOrupIEVHHcb8Bit6tuQ/hAIYl4erzIrJUc1e
# c0OuIcevfYbyUFYzYnWFkPWo0akRWcAIUKba5rzQV4lPpCGOfJc=
# =0ViV
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 30 May 2023 07:42:29 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.282 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmRI7ToACgkQONu9yGCS
# aT4xng//dh2IM5JCSF05cmbZuG081/1dgxJgsfY47AsQQJMbpw0To3goh+RhshCR
# UhpLZvStn/ZnxZ1XxV97+X+DfLy51wucsRWPObASserscDyD2jPaqe9kMPQxT/Ry
# TwxzQd2AjLmhsI1ej2bwTx4bL7I5t7J6Kr+kwFOxaajPUTPMzwHifbBw4b3sT+Fr
# YT18jthD1drK35sfWncre5ZBa1UTB00Vq0fK6o9yJ7oKPaJkouUnMDgVaIAitC0N
# pheoG4QifnlIDaBqzFxRppn/ekYjuzPaynBd/bkEjivk5lESYk4RRGWSABkV/zpe
# QcfTF3E1Eb5Qy/IkgvQfdGk57PBa4yet6KzrM71ml51VTmHTO+CLCjVxdH1EZ2CJ
# 4IcIScnVsOPrOH+C3R1JyP12dB+DP9x5aLiqo6JUPAnfniisDieU/ho4izOfqaZm
# eXtAMOEImhbac/s/6s0uJVUlx9jaqoh28GkuIQWaXPsAO9tUrlcAzK3iLtu218Jn
# ynV4atSYm3RTj1c3ijzAaYr+zirHwD0E04PSTRpfCmX39Xznn2KfUgTtCBj3fm/O
# yvivLfA4CI9z8cewi+3V706dufvO70g9tRaowfyP1hMHYfFvr+rU7O/3HQcbii0J
# vccbacf54j4Y2raAF32Jv+1VvqmGZZAR1NpGYlc/4LxVlZ54p8k=
# =kncc
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 26 Apr 2023 05:22:02 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.278 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmQUF3AACgkQONu9yGCS
# aT4OSxAAswpeK9OJvLyqcaC/ee6e1twIqffN670U8TEIn7Ys4BnCuD4v7hPOOAOh
# 1VUFFFAi614G6D3Em4DZGZaTudPklIaHY+iIYVSUMM6N974CM+wMPgMpQzYeSCqt
# Jie/thl4ZVL14NE3tqIFwICEyxicU/1+YwykLmMOI1c+jEGR0aPSiBeuyie3Bg/3
# NAOm1DRgv0XRtJWg9APMUC85qbhQrO+Z9irfWNlq2NUwj8H9vJSZFGVL2qINGyMU
# F5l+hGjVJkXBO5y7ov380EdsXKLijubGUQMYOwHk6xK5DF8zXtD4e8l0tnvyQHtb
# Sf0/7tIW2w0chVHJodvmcpdGzIU7XJwPlexxAyiaDsh5CA2zzaqEZwcT+wFXx5cd
# iF516IuR64wDfYz5MhoFeK4J2H5qodQgtQY90PChy4+aw5ITIjZEGM8AtaeyHKQs
# y8uDx7O+RIzZLGsBLZSuMilsWlicko4eBeUDhzoIt8SOGcBojZ1b55DeAOnSw5rN
# yKRk3Am/m9utPQKpBWJkUk4ou5Hr02vMYo8IFOGoYUOzV8ZX4/vtEnSJLBwMtMUu
# DQ8PD6VcUS/2dbMgd8cGxPJ8DCN5g4BWEQnFRDg7MfHrNW6r7l256uxkC13s89cF
# UpUczRNwKF2ZkJ8bnQ7YD0Xa94tWtcKY/Ckebz0JnP8VgwgCaSQ=
# =0HUJ
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 17 Mar 2023 03:32:00 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.268 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmORulwACgkQONu9yGCS
# aT7rlxAAqr6GK3Ei3JnP+/bWtrZxOZaMJ3v4d+o0x680B0MYPiCl8O2MGLOTFh5S
# TLhYsYEddu+xAmLBLDFJzylIPr6EDKXBDS8i4w6/WWJA2Wqvk2vp2Mculm6OeIly
# Np7NycSvqpxxfWCxqzilUqdu5pcTGbUB6fM+iCXIeDxLhFN+q4gztIBSBUwr2fHI
# Okek8QOPHQGT2dQQvQLSo/41MQYm0g6d5U2/mvkRysz9esUKB5TqYBxBkla6hb8s
# A83fZ/TGZwulwyJUhJVbEGsQ0Jbr/uzRS6LrRkAFYMp+FQN194w+2Xb/AN6xiKij
# miVZxUgS+tLbuL2CZ+AjEVlkOdtQMLvzn3GNX+iYAMPnXvPiLq6cVhCvm77EM6Xs
# gQ1fc42REvnLl03lIvYcIBNG6ESXCBzLaX+qHPqPzl3OPcOv9VYVMEzQ0DVXXp+I
# +3fzLoQNLbtV7OSQ17d+Uxijw0U2aXMemoPlGGAxhntIs/Pn/NGhGSKmYed9aImp
# 328YgGIBvaqINrAuenaXLckzEcxXRzfb+iM+V7yJ1gE5pam0eppbbuH2hTQTIzqS
# PPqWdq6fPSjgB/RvRURj36bGgUIMdei8Jt0/GXDWgIe4qgstDJKAQ2fQuiVVOfI0
# arMRtQSW8wTB/gOTOSgGpNiEywqK8mj7EtutOFUdGa5IAdloMZY=
# =+EDx
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 08 Dec 2022 05:20:12 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.267 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmOA8CAACgkQONu9yGCS
# aT6V4BAAxRZAMCEAeeruu1tUNaZHWVmZkpsawlC9c4+lavSkniYbcXenkmgYBBcs
# 4GCklhZawUnDFl9VqC9xrn39aRdLX8jTL5tFSNlN+qbQyZ1SkEgvM2eeXHBzBfWP
# SALX15eLoCe4p4RzhwL5nlZZ9Z1siSnPUKO8og+j81X65DpYrIWRmimZthOY733a
# u6emEYrC7wcpuO9DyEU6ZhkHrvrBRSeaSELeUcShwfK4vlAV5FKSRUgmcIDT7mTe
# gtLSh/qlsEO3t0UxPckqG6tsgDofuK7o04YkLzV6y2TMgRoLSJdzn9bid65e3h2R
# jT8FcnBBxJgA42i/0e1UIbYgIisnt2NG1Tq8OrrVXe6N5eF7KhoFOZXiZ+Qq0xam
# WbxPe6jZu1cgrSh9tV1xOX09By31uzc3C6zAMwz/KQbXYcaDQeL/krl+IolDxab7
# 4fIHDGpmIS26aSr2GMWs9z+UDgIH5KOXEweLCsCquRIEwLcpvsPMnq7fnHlAspMX
# O393TY53BtpGIHYGhHJuWuLFIH11Rb3RiTJxU2lsZzHrETR/THirf6T8a6yYWwCo
# lY8tk1XuHQ89X2e+TAsQJ6LJqz2tnHPo01zqhsH7wJKCmnBE3VMzg1NeNxhW3q/i
# CEpoZYF3NhHSRvg0Jcj/DyGI7zuMGRyxprzhtso348+rQ+lYhVQ=
# =Ufv3
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 25 Nov 2022 11:41:04 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.262 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmNZGCIACgkQONu9yGCS
# aT5dEQ//Q2YBvqn1WGhMJRRtIYeczfwvLh3b5duyt1nbf7KOA7yrjpmaQvszunLj
# FanBKsf9QrekTxMUJ9++RlFQy/pxkexy39P3ddlE+QQnKeY+lBr5fc/XSBOmmvm+
# f1CInT4C6nRRn/r/vCumGfuhZ6o+BLwPPgkTCOs9ima6iaq7nLqgFquznVQ2XFJG
# SCtS+OPjnoH7HMOw9vXefd53KJJj5kpE+2fMnEBjdW7x4mPM6nwY3ZxB8sIUdLXe
# dtfDku6W1I8qnGSnI0B+I8/4psNYr/7j4UVTgEKSGmlKKzc78qypdX8YiOGExa84
# MWQrEcIGBOzOaMt5F5RWbGbQmwDtlZC2yuTc5YeJ1eSZ6WfZ42rRu+SkMgloRpjO
# bCzKI8bZ6jmRFNeAPSuR9sF/fRrXlgPsszWYALwy9TTPMvG33jrJaiGwYCOuRxP/
# Fn9C1AshGI+Yy7pX5PR+yOWeII4fgwFBo3Oxritm0RG31KZoXKsrVdyb5CwAD0Sf
# VMb4SNapWwjWKOqi39jAzxgmvkFAwv99HC77dLZhTzwsW+c0+8CH0ccpX/V9997v
# i2IfCLEoOODlpjjoEgeoZ1lwOSX4/cSrlO4L7qcw+vkmXplEkOnD5Lj5Sdw+m9Hp
# 1uwQGVZyngK/eMxInDLlrOFY9SOASCIs+XjJpzqimXp1cTLLEHM=
# =2I2l
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 26 Oct 2022 07:21:06 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.260 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmM0DccACgkQONu9yGCS
# aT7rLA/+Kht2QUTuMXaoGnhRnCICOgQC4RykQgrdLNlp7rmcwh43I8dIwWIGuUKP
# LHB1PQQTKrpAXwkksXUteB0oOwnXoodIwsQX4u21RBySPll1Fs2l1TyyP2hph8nw
# tDEXDcLrd5GdHhS/zR+skKkfyy+gMDEmM5ArDhrQeVjGArRytB5TcXPOUlfhdER+
# C1g1JG0nAG4jM5x7Nq08XTSzn5zucL0R9mOx+2vO0yTjAmghsdu5oHBBifcbBmuH
# DS1ZmKg5u8XxjCYQlkTNoyoh0CcLckZyEKn/f2uQvnMvhinfXz9+qn+jpbL1YrV+
# vAGpQOmLBoX8HSMktwjQGATDygeFi26+JF/cTFpTuL0knbiC4VvmK4V+Wkjpjge1
# piUYv1p9g4+/ZpIQ9OtDpEoCFCJeFGJo1u1fttyNvBw/WXZo0Y4EgDWGNlcPJC7e
# FDL63CQ/VHfoE15yR63z9LzJD7LOiifCLBZvM0mjb+0KSgPRbexCTcyylh28QgHR
# bLU8L0Vs5t7NGOWxWjK/FPLl8eaj+F1jn9N7f5Y6oWvwE/qXtNyZS3b2Vw2WeRVn
# J4U484N3aZl60qbVYArFaEcRmvlASIOKdGk15G2jfwaBcdc4fcajt37ZlHSHXVph
# EDm96/ejTD+H8gHw18TgGtp8aOmovKiK4hHY3GK9/uOitWQG4aE=
# =aRqh
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 28 Sep 2022 05:03:03 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
[ Upstream commit 829649443e78d85db0cff0c37cadb28fbb1a5f6f ]
There are some wrong return values check in sign-file when call OpenSSL
API. The ERR() check cond is wrong because of the program only check the
return value is < 0 which ignored the return val is 0. For example:
1. CMS_final() return 1 for success or 0 for failure.
2. i2d_CMS_bio_stream() returns 1 for success or 0 for failure.
3. i2d_TYPEbio() return 1 for success and 0 for failure.
4. BIO_free() return 1 for success and 0 for failure.
Link: https://www.openssl.org/docs/manmaster/man3/
Fixes: e5a2e3c84782 ("scripts/sign-file.c: Add support for signing with a raw signature")
Signed-off-by: Yusong Gao <a869920004@gmail.com>
Reviewed-by: Juerg Haefliger <juerg.haefliger@canonical.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://lore.kernel.org/r/20231213024405.624692-1-a869920004@gmail.com/ # v5
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit ae1eff0349f2e908fc083630e8441ea6dc434dc0 ]
Currently, sym_validate_range() duplicates the range string using
xstrdup(), which is overwritten by a subsequent sym_calc_value() call.
It results in a memory leak.
Instead, only the pointer should be copied.
Below is a test case, with a summary from Valgrind.
[Test Kconfig]
config FOO
int "foo"
range 10 20
[Test .config]
CONFIG_FOO=0
[Before]
LEAK SUMMARY:
definitely lost: 3 bytes in 1 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
still reachable: 17,465 bytes in 21 blocks
suppressed: 0 bytes in 0 blocks
[After]
LEAK SUMMARY:
definitely lost: 0 bytes in 0 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
still reachable: 17,462 bytes in 20 blocks
suppressed: 0 bytes in 0 blocks
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit 381fdb73d1e2a48244de7260550e453d1003bb8e upstream.
The performance mode of the gcc-plugin randstruct was shuffling struct
members outside of the cache-line groups. Limit the range to the
specified group indexes.
Cc: linux-hardening@vger.kernel.org
Cc: stable@vger.kernel.org
Reported-by: Lukas Loidolt <e1634039@student.tuwien.ac.at>
Closes: https://lore.kernel.org/all/f3ca77f0-e414-4065-83a5-ae4c4d25545d@student.tuwien.ac.at
Fixes: 313dd1b62921 ("gcc-plugins: Add the randstruct plugin")
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit cbc3d00cf88fda95dbcafee3b38655b7a8f2650a ]
Without this 'else' statement, an "usb" name goes into two handlers:
the first/previous 'if' statement _AND_ the for-loop over 'devtable',
but the latter is useless as it has no 'usb' device_id entry anyway.
Tested with allmodconfig before/after patch; no changes to *.mod.c:
git checkout v6.6-rc3
make -j$(nproc) allmodconfig
make -j$(nproc) olddefconfig
make -j$(nproc)
find . -name '*.mod.c' | cpio -pd /tmp/before
# apply patch
make -j$(nproc)
find . -name '*.mod.c' | cpio -pd /tmp/after
diff -r /tmp/before/ /tmp/after/
# no difference
Fixes: acbef7b76629 ("modpost: fix module autoloading for OF devices with generic compatible property")
Signed-off-by: Mauricio Faria de Oliveira <mfo@canonical.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit a3b7039bb2b22fcd2ad20d59c00ed4e606ce3754 ]
Buffer 'new_argv' is accessed without bound check after accessing with
bound check via 'new_argc' index.
Fixes: e298f3b49def ("kconfig: add built-in function support")
Co-developed-by: Ivanov Mikhail <ivanov.mikhail1@huawei-partners.com>
Signed-off-by: Konstantin Meskhidze <konstantin.meskhidze@huawei.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 56a24b8ce6a7f9c4a21b2276a8644f6f3d8fc14d ]
addend_arm_rel() processes R_ARM_PC24, R_ARM_CALL, R_ARM_JUMP24 in a
wrong way.
Here, test code.
[test code for R_ARM_JUMP24]
.section .init.text,"ax"
bar:
bx lr
.section .text,"ax"
.globl foo
foo:
b bar
[test code for R_ARM_CALL]
.section .init.text,"ax"
bar:
bx lr
.section .text,"ax"
.globl foo
foo:
push {lr}
bl bar
pop {pc}
If you compile it with ARM multi_v7_defconfig, modpost will show the
symbol name, (unknown).
WARNING: modpost: vmlinux.o: section mismatch in reference: foo (section: .text) -> (unknown) (section: .init.text)
(You need to use GNU linker instead of LLD to reproduce it.)
Fix the code to make modpost show the correct symbol name.
I imported (with adjustment) sign_extend32() from include/linux/bitops.h.
The '+8' is the compensation for pc-relative instruction. It is
documented in "ELF for the Arm Architecture" [1].
"If the relocation is pc-relative then compensation for the PC bias
(the PC value is 8 bytes ahead of the executing instruction in Arm
state and 4 bytes in Thumb state) must be encoded in the relocation
by the object producer."
[1]: https://github.com/ARM-software/abi-aa/blob/main/aaelf32/aaelf32.rst
Fixes: 56a974fa2d59 ("kbuild: make better section mismatch reports on arm")
Fixes: 6e2e340b59d2 ("ARM: 7324/1: modpost: Fix section warnings for ARM for many compilers")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit b7c63520f6703a25eebb4f8138fed764fcae1c6f ]
addend_arm_rel() processes R_ARM_ABS32 in a wrong way.
Here, test code.
[test code 1]
#include <linux/init.h>
int __initdata foo;
int get_foo(void) { return foo; }
If you compile it with ARM versatile_defconfig, modpost will show the
symbol name, (unknown).
WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> (unknown) (section: .init.data)
(You need to use GNU linker instead of LLD to reproduce it.)
If you compile it for other architectures, modpost will show the correct
symbol name.
WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> foo (section: .init.data)
For R_ARM_ABS32, addend_arm_rel() sets r->r_addend to a wrong value.
I just mimicked the code in arch/arm/kernel/module.c.
However, there is more difficulty for ARM.
Here, test code.
[test code 2]
#include <linux/init.h>
int __initdata foo;
int get_foo(void) { return foo; }
int __initdata bar;
int get_bar(void) { return bar; }
With this commit applied, modpost will show the following messages
for ARM versatile_defconfig:
WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> foo (section: .init.data)
WARNING: modpost: vmlinux.o: section mismatch in reference: get_bar (section: .text) -> foo (section: .init.data)
The reference from 'get_bar' to 'foo' seems wrong.
I have no solution for this because it is true in assembly level.
In the following output, relocation at 0x1c is no longer associated
with 'bar'. The two relocation entries point to the same symbol, and
the offset to 'bar' is encoded in the instruction 'r0, [r3, #4]'.
Disassembly of section .text:
00000000 <get_foo>:
0: e59f3004 ldr r3, [pc, #4] @ c <get_foo+0xc>
4: e5930000 ldr r0, [r3]
8: e12fff1e bx lr
c: 00000000 .word 0x00000000
00000010 <get_bar>:
10: e59f3004 ldr r3, [pc, #4] @ 1c <get_bar+0xc>
14: e5930004 ldr r0, [r3, #4]
18: e12fff1e bx lr
1c: 00000000 .word 0x00000000
Relocation section '.rel.text' at offset 0x244 contains 2 entries:
Offset Info Type Sym.Value Sym. Name
0000000c 00000c02 R_ARM_ABS32 00000000 .init.data
0000001c 00000c02 R_ARM_ABS32 00000000 .init.data
When find_elf_symbol() gets into a situation where relsym->st_name is
zero, there is no guarantee to get the symbol name as written in C.
I am keeping the current logic because it is useful in many architectures,
but the symbol name is not always correct depending on the optimization.
I left some comments in find_tosym().
Fixes: 56a974fa2d59 ("kbuild: make better section mismatch reports on arm")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit e1b37563caffc410bb4b55f153ccb14dede66815 upstream.
gtags considers any file outside of its current working directory
"outside the source tree" and refuses to index it. For O= kernel builds,
or when "make" is invoked from a directory other then the kernel source
tree, gtags ignores the entire kernel source and generates an empty
index.
Force-set gtags current working directory to the kernel source tree.
Due to commit 9da0763bdd82 ("kbuild: Use relative path when building in
a subdir of the source tree"), if the kernel build is done in a
sub-directory of the kernel source tree, the kernel Makefile will set
the kernel's $srctree to ".." for shorter compile-time and run-time
warnings. Consequently, the list of files to be indexed will be in the
"../*" form, rendering all such paths invalid once gtags switches to the
kernel source tree as its current working directory.
If gtags indexing is requested and the build directory is not the kernel
source tree, index all files in absolute-path form.
Note, indexing in absolute-path form will not affect the generated
index, as paths in gtags indices are always relative to the gtags "root
directory" anyway (as evidenced by "gtags --dump").
Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit fa359d068574d29e7d2f0fdd0ebe4c6a12b5cfb9 ]
Common realloc mistake: 'file_append' nulled but not freed upon failure
Link: https://lkml.kernel.org/r/20230426010527.703093-1-zenghao@kylinos.cn
Signed-off-by: Hao Zeng <zenghao@kylinos.cn>
Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit 5a43001c01691dcbd396541e6faa2c0077378f48 upstream.
It seems there is a misprint in the check of strdup() return code that
can lead to NULL pointer dereference.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 4520c6a49af8 ("X.509: Add simple ASN.1 grammar compiler")
Signed-off-by: Ekaterina Orlova <vorobushek.ok@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jarkko Sakkinen <jarkko@kernel.org>
Cc: keyrings@vger.kernel.org
Cc: linux-kbuild@vger.kernel.org
Link: https://lore.kernel.org/r/20230315172130.140-1-vorobushek.ok@gmail.com/
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit 4f2c8f3089f538f556c86f26603a062865e4aa94 ]
The modules.order files in directories visited by the chain of obj-y
or obj-m are merged to the upper-level ones, and become parts of the
top-level modules.order. On the other hand, there is no need to
generate modules.order in directories visited by subdir-y or subdir-m
since they would become orphan anyway.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Stable-dep-of: 2e3d0e20d845 ("ARM: dts: exynos: correct TMU phandle in Odroid HC1")
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit d9f78edfd81b9e484423534360350ef7253cc888 ]
The current implementation of need-builtin is false-positive,
for example, in the following Makefile:
obj-m := foo/
obj-y := foo/bar/
..., where foo/built-in.a is not required.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Stable-dep-of: 2e3d0e20d845 ("ARM: dts: exynos: correct TMU phandle in Odroid HC1")
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 2d77de1581bb5b470486edaf17a7d70151131afd ]
Commit 1d1a0e7c5100 ("scripts/faddr2line: Fix overlapping text section
failures") can cause faddr2line to fail on ppc64le on some
distributions, while it works fine on other distributions. The failure
can be attributed to differences in the readelf output.
$ ./scripts/faddr2line vmlinux find_busiest_group+0x00
no match for find_busiest_group+0x00
On ppc64le, readelf adds the localentry tag before the symbol name on
some distributions, and adds the localentry tag after the symbol name on
other distributions. This problem has been discussed previously:
https://lore.kernel.org/bpf/20191211160133.GB4580@calabresa/
This problem can be overcome by filtering out the localentry tags in the
readelf output. Similar fixes are already present in the kernel by way
of the following commits:
1fd6cee127e2 ("libbpf: Fix VERSIONED_SYM_COUNT number parsing")
aa915931ac3e ("libbpf: Fix readelf output parsing for Fedora")
[jpoimboe: rework commit log]
Fixes: 1d1a0e7c5100 ("scripts/faddr2line: Fix overlapping text section failures")
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Acked-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Reviewed-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Link: https://lore.kernel.org/r/20220927075211.897152-1-srikar@linux.vnet.ibm.com
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit 6bfb56e93bcef41859c2d5ab234ffd80b691be35 upstream.
OpenSSL 3.0 deprecated the OpenSSL's ENGINE API. That is as may be, but
the kernel build host tools still use it. Disable the warning about
deprecated declarations until somebody who cares fixes it.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit c969bb8dbaf2f3628927eae73e7c579a74cf1b6e upstream.
The latest version of grep claims that egrep is now obsolete so the build
now contains warnings that look like:
egrep: warning: egrep is obsolescent; using grep -E
fix this by using "grep -E" instead.
Cc: Paul Moore <paul@paul-moore.com>
Cc: Stephen Smalley <stephen.smalley.work@gmail.com>
Cc: Eric Paris <eparis@parisplace.org>
Cc: selinux@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[PM: tweak to remove vdso reference, cleanup subj line]
Signed-off-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 2120635108b35ecad9c59c8b44f6cbdf4f98214e upstream.
We enable -Wcast-function-type globally in the kernel to warn about
mismatching types in function pointer casts. Compilers currently
warn only about ABI incompability with this flag, but Clang 16 will
enable a stricter version of the check by default that checks for an
exact type match. This will be very noisy in the kernel, so disable
-Wcast-function-type-strict without W=1 until the new warnings have
been addressed.
Cc: stable@vger.kernel.org
Link: https://reviews.llvm.org/D134831
Link: https://github.com/ClangBuiltLinux/linux/issues/1724
Suggested-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20220930203310.4010564-1-samitolvanen@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit c17a2538704f926ee4d167ba625e09b1040d8439 ]
When System.map was generated, the kernel used mksysmap to filter the
kernel symbols, we need to filter "L0" symbols in LoongArch architecture.
$ cat System.map | grep L0
9000000000221540 t L0
The L0 symbol exists in System.map, but not in .tmp_System.map. When
"cmp -s System.map .tmp_System.map" will show "Inconsistent kallsyms
data" error message in link-vmlinux.sh script.
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
This is the 4.19.257 stable release
# gpg: Signature made Mon 05 Sep 2022 04:26:42 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.256 stable release
# gpg: Signature made Thu 25 Aug 2022 05:15:59 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.250 stable release
# gpg: Signature made Sat 02 Jul 2022 10:27:48 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.249 stable release
# gpg: Signature made Sat 25 Jun 2022 05:49:23 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.247 stable release
# gpg: Signature made Tue 14 Jun 2022 11:01:13 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.239 stable release
# gpg: Signature made Wed 20 Apr 2022 03:12:54 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.231 stable release
# gpg: Signature made Wed 23 Feb 2022 05:58:46 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.226 stable release
# gpg: Signature made Thu 27 Jan 2022 03:04:40 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
commit 23a0cb8e3225122496bfa79172005c587c2d64bf upstream.
When building an external module, if users don't need to separate the
compilation output and source code, they run the following command:
"make -C $(LINUX_SRC_DIR) M=$(PWD)". At this point, "$(KBUILD_EXTMOD)"
and "$(src)" are the same.
If they need to separate them, they run "make -C $(KERNEL_SRC_DIR)
O=$(KERNEL_OUT_DIR) M=$(OUT_DIR) src=$(PWD)". Before running the
command, they need to copy "Kbuild" or "Makefile" to "$(OUT_DIR)" to
prevent compilation failure.
So the kernel should change the included path to avoid the copy operation.
Signed-off-by: Jing Leng <jleng@ambarella.com>
[masahiro: I do not think "M=$(OUT_DIR) src=$(PWD)" is the official way,
but this patch is a nice clean up anyway.]
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
[nsc: updated context for v4.19]
Signed-off-by: Nicolas Schier <n.schier@avm.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 012e8d2034f1bda8863435cd589636e618d6a659 upstream.
Commit 36d4b36b6959 ("lib/nodemask: inline next_node_in() and
node_random()") refactored some code by moving node_random() from
lib/nodemask.c to include/linux/nodemask.h, thus requiring nodemask.h to
include random.h, which conditionally defines add_latent_entropy()
depending on whether the macro LATENT_ENTROPY_PLUGIN is defined.
This broke the build on powerpc, where nodemask.h is indirectly included
in arch/powerpc/kernel/prom_init.c, part of the early boot machinery that
is excluded from the latent entropy plugin using
DISABLE_LATENT_ENTROPY_PLUGIN. It turns out that while we add a gcc flag
to disable the actual plugin, we don't undefine LATENT_ENTROPY_PLUGIN.
This leads to the following:
CC arch/powerpc/kernel/prom_init.o
In file included from ./include/linux/nodemask.h:97,
from ./include/linux/mmzone.h:17,
from ./include/linux/gfp.h:7,
from ./include/linux/xarray.h:15,
from ./include/linux/radix-tree.h:21,
from ./include/linux/idr.h:15,
from ./include/linux/kernfs.h:12,
from ./include/linux/sysfs.h:16,
from ./include/linux/kobject.h:20,
from ./include/linux/pci.h:35,
from arch/powerpc/kernel/prom_init.c:24:
./include/linux/random.h: In function 'add_latent_entropy':
./include/linux/random.h:25:46: error: 'latent_entropy' undeclared (first use in this function); did you mean 'add_latent_entropy'?
25 | add_device_randomness((const void *)&latent_entropy, sizeof(latent_entropy));
| ^~~~~~~~~~~~~~
| add_latent_entropy
./include/linux/random.h:25:46: note: each undeclared identifier is reported only once for each function it appears in
make[2]: *** [scripts/Makefile.build:249: arch/powerpc/kernel/prom_init.o] Fehler 1
make[1]: *** [scripts/Makefile.build:465: arch/powerpc/kernel] Fehler 2
make: *** [Makefile:1855: arch/powerpc] Error 2
Change the DISABLE_LATENT_ENTROPY_PLUGIN flags to undefine
LATENT_ENTROPY_PLUGIN for files where the plugin is disabled.
Cc: Yury Norov <yury.norov@gmail.com>
Fixes: 38addce8b600 ("gcc-plugins: Add latent_entropy plugin")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216367
Link: https://lore.kernel.org/linuxppc-dev/alpine.DEB.2.22.394.2208152006320.289321@ramsan.of.borg/
Reported-by: Erhard Furtner <erhard_f@mailbox.org>
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
Reviewed-by: Yury Norov <yury.norov@gmail.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20220816051720.44108-1-ajd@linux.ibm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit b6a5068854cfe372da7dee3224dcf023ed5b00cb ]
Since commit dcea997beed6 ("faddr2line: Fix overlapping text section
failures, the sequel"), faddr2line is completely broken on arm64.
For some reason, on arm64, the vmlinux ELF object file type is ET_DYN
rather than ET_EXEC. Check for both when determining whether the object
is vmlinux.
Modules and vmlinux.o have type ET_REL on all arches.
Fixes: dcea997beed6 ("faddr2line: Fix overlapping text section failures, the sequel")
Reported-by: John Garry <john.garry@huawei.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Tested-by: John Garry <john.garry@huawei.com>
Link: https://lore.kernel.org/r/dad1999737471b06d6188ce4cdb11329aa41682c.1658426357.git.jpoimboe@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit 28438794aba47a27e922857d27b31b74e8559143 upstream.
Since commit f02e8a6596b7 ("module: Sort exported symbols"),
EXPORT_SYMBOL* is placed in the individual section ___ksymtab(_gpl)+<sym>
(3 leading underscores instead of 2).
Since then, modpost cannot detect the bad combination of EXPORT_SYMBOL
and __init/__exit.
Fix the .fromsec field.
Fixes: f02e8a6596b7 ("module: Sort exported symbols")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit dcea997beed694cbd8705100ca1a6eb0d886de69 ]
If a function lives in a section other than .text, but .text also exists
in the object, faddr2line may wrongly assume .text. This can result in
comically wrong output. For example:
$ scripts/faddr2line vmlinux.o enter_from_user_mode+0x1c
enter_from_user_mode+0x1c/0x30:
find_next_bit at /home/jpoimboe/git/linux/./include/linux/find.h:40
(inlined by) perf_clear_dirty_counters at /home/jpoimboe/git/linux/arch/x86/events/core.c:2504
Fix it by passing the section name to addr2line, unless the object file
is vmlinux, in which case the symbol table uses absolute addresses.
Fixes: 1d1a0e7c5100 ("scripts/faddr2line: Fix overlapping text section failures")
Reported-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Link: https://lore.kernel.org/r/7d25bc1408bd3a750ac26e60d2f2815a5f4a8363.1654130536.git.jpoimboe@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit d6b732666a1bae0df3c3ae06925043bba34502b1 ]
The return value of is_arm_mapping_symbol() is unpredictable when "$"
is passed in.
strchr(3) says:
The strchr() and strrchr() functions return a pointer to the matched
character or NULL if the character is not found. The terminating null
byte is considered part of the string, so that if c is specified as
'\0', these functions return a pointer to the terminator.
When str[1] is '\0', strchr("axtd", str[1]) is not NULL, and str[2] is
referenced (i.e. buffer overrun).
Test code
---------
char str1[] = "abc";
char str2[] = "ab";
strcpy(str1, "$");
strcpy(str2, "$");
printf("test1: %d\n", is_arm_mapping_symbol(str1));
printf("test2: %d\n", is_arm_mapping_symbol(str2));
Result
------
test1: 0
test2: 1
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit b5beffa20d83c4e15306c991ffd00de0d8628338 ]
With the `-z unique-symbol` linker flag or any similar mechanism,
it is possible to trigger the following:
ERROR: modpost: "param_set_uint.0" [vmlinux] is a static EXPORT_SYMBOL
The reason is that for now the condition from remove_dot():
if (m && (s[n + m] == '.' || s[n + m] == 0))
which was designed to test if it's a dot or a '\0' after the suffix
is never satisfied.
This is due to that `s[n + m]` always points to the last digit of a
numeric suffix, not on the symbol next to it (from a custom debug
print added to modpost):
param_set_uint.0, s[n + m] is '0', s[n + m + 1] is '\0'
So it's off-by-one and was like that since 2014.
Fix this for the sake of any potential upcoming features, but don't
bother stable-backporting, as it's well hidden -- apart from that
LD flag, it can be triggered only with GCC LTO which never landed
upstream.
Fixes: fcd38ed0ff26 ("scripts: modpost: fix compilation warning")
Signed-off-by: Alexander Lobakin <alexandr.lobakin@intel.com>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 1d1a0e7c5100d332583e20b40aa8c0a8ed3d7849 ]
There have been some recent reports of faddr2line failures:
$ scripts/faddr2line sound/soundcore.ko sound_devnode+0x5/0x35
bad symbol size: base: 0x0000000000000000 end: 0x0000000000000000
$ ./scripts/faddr2line vmlinux.o enter_from_user_mode+0x24
bad symbol size: base: 0x0000000000005fe0 end: 0x0000000000005fe0
The problem is that faddr2line is based on 'nm', which has a major
limitation: it doesn't know how to distinguish between different text
sections. So if an offset exists in multiple text sections in the
object, it may fail.
Rewrite faddr2line to be section-aware, by basing it on readelf.
Fixes: 67326666e2d4 ("scripts: add script for translating stack dump function offsets")
Reported-by: Kaiwan N Billimoria <kaiwan.billimoria@gmail.com>
Reported-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Link: https://lore.kernel.org/r/29ff99f86e3da965b6e46c1cc2d72ce6528c17c3.1652382321.git.jpoimboe@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit c40160f2998c897231f8454bf797558d30a20375 upstream.
While the latent entropy plugin mostly doesn't derive entropy from
get_random_const() for measuring the call graph, when __latent_entropy is
applied to a constant, then it's initialized statically to output from
get_random_const(). In that case, this data is derived from a 64-bit
seed, which means a buffer of 512 bits doesn't really have that amount
of compile-time entropy.
This patch fixes that shortcoming by just buffering chunks of
/dev/urandom output and doling it out as requested.
At the same time, it's important that we don't break the use of
-frandom-seed, for people who want the runtime benefits of the latent
entropy plugin, while still having compile-time determinism. In that
case, we detect whether gcc's set_random_seed() has been called by
making a call to get_random_seed(noinit=true) in the plugin init
function, which is called after set_random_seed() is called but before
anything that calls get_random_seed(noinit=false), and seeing if it's
zero or not. If it's not zero, we're in deterministic mode, and so we
just generate numbers with a basic xorshift prng.
Note that we don't detect if -frandom-seed is being used using the
documented local_tick variable, because it's assigned via:
local_tick = (unsigned) tv.tv_sec * 1000 + tv.tv_usec / 1000;
which may well overflow and become -1 on its own, and so isn't
reliable: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105171
[kees: The 256 byte rnd_buf size was chosen based on average (250),
median (64), and std deviation (575) bytes of used entropy for a
defconfig x86_64 build]
Fixes: 38addce8b600 ("gcc-plugins: Add latent_entropy plugin")
Cc: stable@vger.kernel.org
Cc: PaX Team <pageexec@freemail.hu>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20220405222815.21155-1-Jason@zx2c4.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit 8a4c5b2a6d8ea079fa36034e8167de87ab6f8880 ]
The 'shell' built-in only returns the first 256 bytes of the command's
output. In some cases, 'shell' is used to return a path; by bumping up
the buffer size to 4096 this lets us capture up to PATH_MAX.
The specific case where I ran into this was due to commit 1e860048c53e
("gcc-plugins: simplify GCC plugin-dev capability test"). After this
change, we now use `$(shell,$(CC) -print-file-name=plugin)` to return
a path; if the gcc path is particularly long, then the path ends up
truncated at the 256 byte mark, which makes the HAVE_GCC_PLUGINS
depends test always fail.
Signed-off-by: Brenda Streiff <brenda.streiff@ni.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit 1cf5f151d25fcca94689efd91afa0253621fb33a upstream.
-Wunaligned-access is a new warning in clang that is default enabled for
arm and arm64 under certain circumstances within the clang frontend (see
LLVM commit below). On v5.17-rc2, an ARCH=arm allmodconfig build shows
1284 total/70 unique instances of this warning (most of the instances
are in header files), which is quite noisy.
To keep a normal build green through CONFIG_WERROR, only show this
warning with W=1, which will allow automated build systems to catch new
instances of the warning so that the total number can be driven down to
zero eventually since catching unaligned accesses at compile time would
be generally useful.
Cc: stable@vger.kernel.org
Link: https://github.com/llvm/llvm-project/commit/35737df4dcd28534bd3090157c224c19b501278a
Link: https://github.com/ClangBuiltLinux/linux/issues/1569
Link: https://github.com/ClangBuiltLinux/linux/issues/1576
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
[nathan: Fix conflict due to lack of afe956c577b2d]
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit d8adf5b92a9d2205620874d498c39923ecea8749 upstream.
dtx_diff suggests to use <(...) syntax to pipe two inputs into it, but
this has never worked: The /proc/self/fds/... paths passed by the shell
will fail the `[ -f "${dtx}" ] && [ -r "${dtx}" ]` check in compile_to_dts,
but even with this check removed, the function cannot work: hexdump will
eat up the DTB magic, making the subsequent dtc call fail, as a pipe
cannot be rewound.
Simply remove this broken example, as there is already an alternative one
that works fine.
Fixes: 10eadc253ddf ("dtc: create tool to diff device trees")
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Reviewed-by: Frank Rowand <frank.rowand@sony.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220113081918.10387-1-matthias.schiffer@ew.tq-group.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
Bruce Ashfield
Yusong Gao
Masahiro Yamada
Kees Cook
Mauricio Faria de Oliveira
Konstantin Meskhidze
Ahmed S. Darwish
Hao Zeng
Ekaterina Orlova
Masahiro Yamada
Srikar Dronamraju
Linus Torvalds
Greg Kroah-Hartman
Sami Tolvanen
Youling Tang
Jing Leng
Andrew Donnellan
Josh Poimboeuf
Alexander Lobakin
Jason A. Donenfeld
Brenda Streiff
Nathan Chancellor
Matthias Schiffer