The PKG_CPE_ID links to NIST CPE version 2.2.
Assign PKG_CPE_ID to all remaining tools which have a CPE ID.
Not every tool has CPE id.
Related: https://github.com/openwrt/packages/issues/8534
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
The PKG_CPE_ID links to NIST CPE version 2.2.
Assign PKG_CPE_ID to all remaining package which have a CPE ID.
Not every package has CPE id.
Related: https://github.com/openwrt/packages/issues/8534
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
When the membase and pci_dev pointer were moved to a new struct in priv,
the actual membase users were left untouched, and they started reading
out arbitrary memory behind the struct instead of registers. This
unfortunately turned the RNG into a constant number generator, depending
on the content of what was at that offset.
To fix this, update geode_rng_data_{read,present}() to also get the
membase via amd_geode_priv, and properly read from the right addresses
again.
Closes#13417.
Reported-by: Timur I. Davletshin <timur.davletshin@gmail.com>
Tested-by: Timur I. Davletshin <timur.davletshin@gmail.com>
Suggested-by: Jo-Philipp Wich <jo@mein.io>
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
(cherry picked from commit 09d13cd8d8)
7aefb47 jitterentropy-rngd: update to the v1.2.0
What's interesting about jitterentropy-rngd v1.2.0 release is that it
bumps its copy of jitterentropy-library from v2.2.0 to the v3.0.0. That
bump includes a relevant commit 3130cd9 ("replace LSFR with SHA-3 256").
When initializing entropy jent calculates time delta. Time values are
obtained using clock_gettime() + CLOCK_REALTIME. There is no guarantee
from CLOCK_REALTIME of unique values and slow devices often return
duplicated ones.
A switch from jent_lfsr_time() to jent_hash_time() resulted in many less
cases of zero delta and avoids ECOARSETIME.
Long story short: on some system this fixes:
[ 6.722725] urngd: jent-rng init failed, err: 2
This is important change for BCM53573 which doesn't include hwrng and
seems to have arch_timer running at 36,8 Hz.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit c74b5e09e6)
It seems that DSA-based b53 driver never worked with BCM53573 SoCs and
BCM53125.
In case of swconfig-based b53 this fixes a regression. Switching bgmac
from using mdiobus_register() to of_mdiobus_register() resulted in MDIO
device (BCM53125) having of_node set (see of_mdiobus_register_phy()).
That made downstream b53 driver read invalid data from DT and broke
Ethernet support.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit 79fd3e62b4)
'help' target fails not finding a file, so follow up on a change[2] made
as a fix for main README[1].
1. d0113711a3 ("README: port to 21st century")
2. 751486b31f ("build: fix README.md reference after rename")
Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
(cherry picked from commit 2d5f7035cf)
(cherry picked from commit e9911f10e4)
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Some device recipes remove default target packages. If user tries to add
them back they will be ignored, since packages list is processed in one
go. Process the device recipe packages first and do user ones later, so
additions won't get filtered out.
Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
(cherry picked from commit e40b9a7fa0)
The DGND3700v2 renames the cferam bootloader from cferam to cfeXXX, where XXX
is the number of firmware upgrades performed by the bootloader. Other bcm63xx
devices rename cferam.000 to cferam.XXX, but this device is special because
the cferam name isn't changed on the first firmware flashing but it's changed
on the subsequent ones.
Therefore, we need to look for "cfe" instead of "cferam" to properly detect
the cferam partition and fix the bootlop.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
(cherry picked from commit cdfcac6e24)
Some devices rename cferam bootloader using specific patterns and don't follow
broadcom standards for renaming cferam files. This requires supporting
different cferam file names.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
(cherry picked from commit 8813edd8d9)
The index.json file lies next to Packages index files and contains a
json dict with the package architecture and a dict of package names and
versions.
This can be used for downstream project to know what packages in which
versions are available.
Signed-off-by: Paul Spooren <mail@aparcar.org>
(cherry picked from commit 218ce40cd7)
Apply two patches fixing low-severity vulnerabilities related to
certificate policies validation:
- Excessive Resource Usage Verifying X.509 Policy Constraints
(CVE-2023-0464)
Severity: Low
A security vulnerability has been identified in all supported versions
of OpenSSL related to the verification of X.509 certificate chains
that include policy constraints. Attackers may be able to exploit
this vulnerability by creating a malicious certificate chain that
triggers exponential use of computational resources, leading to a
denial-of-service (DoS) attack on affected systems.
Policy processing is disabled by default but can be enabled by passing
the `-policy' argument to the command line utilities or by calling the
`X509_VERIFY_PARAM_set1_policies()' function.
- Invalid certificate policies in leaf certificates are silently ignored
(CVE-2023-0465)
Severity: Low
Applications that use a non-default option when verifying certificates
may be vulnerable to an attack from a malicious CA to circumvent
certain checks.
Invalid certificate policies in leaf certificates are silently ignored
by OpenSSL and other certificate policy checks are skipped for that
certificate. A malicious CA could use this to deliberately assert
invalid certificate policies in order to circumvent policy checking on
the certificate altogether.
Policy processing is disabled by default but can be enabled by passing
the `-policy' argument to the command line utilities or by calling the
`X509_VERIFY_PARAM_set1_policies()' function.
Note: OpenSSL also released a fix for low-severity security advisory
CVE-2023-466. It is not included here because the fix only changes the
documentation, which is not built nor included in any OpenWrt package.
Due to the low-severity of these issues, there will be not be an
immediate new release of OpenSSL.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Import commit "ubi: Fix failure attaching when vid_hdr offset equals to
(sub)page size" which did not yet make it to stable upstream Linux trees.
Fixes: #12232Fixes: #12339
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
(cherry picked from commit aad34818b5)
Setting this options modifies the rootfs size of created images. When
installing a large number of packages it may become necessary to
increase the size to have enough storage.
This option is only useful for supported devices, i.e. with an attached
SD Card or installed on a hard drive.
Signed-off-by: Paul Spooren <mail@aparcar.org>
(cherry picked from commit 7b7edd25a5)
On any currently supported hardware, the performance impact should not
matter anymore.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
(cherry picked from commit 75e78bcaab)
The USB port on the MR8300 randomly fails to feed bus-powered devices.
This is caused by a misconfigured pinmux. The GPIO68 should be used to
enable the USB power (active low), but it's inside the NAND pinmux.
This GPIO pin was found in the original firmware at a startup script in
both MR8300 and EA8300. Therefore apply the fix for both boards.
Signed-off-by: Daniel González Cabanelas <dgcbueu@gmail.com>
Reviewed-by: Robert Marko <robimarko@gmail.com>
(cherry picked from commit ed64c33235)
Signed-off-by: Steffen Scheib <steffen@scheib.me>
Due to SCHED_FIFO being a broken scheduler model, all users of
sched_setscheduler() are converted to sched_set_fifo_low() upstream and
sched_setscheduler() is no longer exported.
The callback handling of the tasklet API was redesigned and the macros
using the old syntax renamed to _OLD.
Signed-off-by: Mathias Kresin <dev@kresin.me>
(cherry picked from commit 31f3f79700)
[Add DECLARE_TASKLET handling for kernel 5.4.235 too]
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The callback handling of the tasklet API was redesigned and the macros
using the old syntax renamed to _OLD.
The stuck queue is now passed to ndo_tx_timeout callback but not used so
far.
Signed-off-by: Mathias Kresin <dev@kresin.me>
(cherry picked from commit 804c541446)
[Add DECLARE_TASKLET handling for kernel 5.4.235 too]
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This patch is a revert of the upstream patch to Debian's ca-certificate
commit 033d52259172 ("mozilla/certdata2pem.py: print a warning for expired certificates.")
The reason is, that this change broke builds with the popular
Ubuntu 20.04 LTS (focal) releases which are shipping with an
older version of the python3-cryptography package that is not
compatible.
|Traceback (most recent call last):
| File "certdata2pem.py", line 125, in <module>
| cert = x509.load_der_x509_certificate(obj['CKA_VALUE'])
|TypeError: load_der_x509_certificate() missing 1 required positional argument: 'backend'
|make[5]: *** [Makefile:6: all] Error 1
...or if the python3-cryptography was missing all together:
|Traceback (most recent call last):
| File "/certdata2pem.py", line 31, in <module>
| from cryptography import x509
|ModuleNotFoundError: No module named 'cryptography'
More concerns were raised by Jo-Philipp Wich:
"We don't want the build to depend on the local system time anyway.
Right now it seems to be just a warning but I could imagine that
eventually certs are simply omitted of found to be expired at
build time which would break reproducibility."
Link: <https://github.com/openwrt/openwrt/commit/7c99085bd697>
Reported-by: Chen Minqiang <ptpt52@gmail.com>
Reported-by: Shane Synan <digitalcircuit36939@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
(cherry picked from commit 25bc66eb40)
This driver is backported from the v6.0 which deals with
"linux,default-trigger" in leds core. For kernel 5.4 we need
leds-bcm63138 to read trigger on its own.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
This update mac80211 to version 5.10.168-1. This includes multiple
bugfixes. Some of these bugfixes are fixing security relevant bugs.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Changes between 1.1.1s and 1.1.1t [7 Feb 2023]
*) Fixed X.400 address type confusion in X.509 GeneralName.
There is a type confusion vulnerability relating to X.400 address processing
inside an X.509 GeneralName. X.400 addresses were parsed as an ASN1_STRING
but subsequently interpreted by GENERAL_NAME_cmp as an ASN1_TYPE. This
vulnerability may allow an attacker who can provide a certificate chain and
CRL (neither of which need have a valid signature) to pass arbitrary
pointers to a memcmp call, creating a possible read primitive, subject to
some constraints. Refer to the advisory for more information. Thanks to
David Benjamin for discovering this issue. (CVE-2023-0286)
This issue has been fixed by changing the public header file definition of
GENERAL_NAME so that x400Address reflects the implementation. It was not
possible for any existing application to successfully use the existing
definition; however, if any application references the x400Address field
(e.g. in dead code), note that the type of this field has changed. There is
no ABI change.
[Hugo Landau]
*) Fixed Use-after-free following BIO_new_NDEF.
The public API function BIO_new_NDEF is a helper function used for
streaming ASN.1 data via a BIO. It is primarily used internally to OpenSSL
to support the SMIME, CMS and PKCS7 streaming capabilities, but may also
be called directly by end user applications.
The function receives a BIO from the caller, prepends a new BIO_f_asn1
filter BIO onto the front of it to form a BIO chain, and then returns
the new head of the BIO chain to the caller. Under certain conditions,
for example if a CMS recipient public key is invalid, the new filter BIO
is freed and the function returns a NULL result indicating a failure.
However, in this case, the BIO chain is not properly cleaned up and the
BIO passed by the caller still retains internal pointers to the previously
freed filter BIO. If the caller then goes on to call BIO_pop() on the BIO
then a use-after-free will occur. This will most likely result in a crash.
(CVE-2023-0215)
[Viktor Dukhovni, Matt Caswell]
*) Fixed Double free after calling PEM_read_bio_ex.
The function PEM_read_bio_ex() reads a PEM file from a BIO and parses and
decodes the "name" (e.g. "CERTIFICATE"), any header data and the payload
data. If the function succeeds then the "name_out", "header" and "data"
arguments are populated with pointers to buffers containing the relevant
decoded data. The caller is responsible for freeing those buffers. It is
possible to construct a PEM file that results in 0 bytes of payload data.
In this case PEM_read_bio_ex() will return a failure code but will populate
the header argument with a pointer to a buffer that has already been freed.
If the caller also frees this buffer then a double free will occur. This
will most likely lead to a crash.
The functions PEM_read_bio() and PEM_read() are simple wrappers around
PEM_read_bio_ex() and therefore these functions are also directly affected.
These functions are also called indirectly by a number of other OpenSSL
functions including PEM_X509_INFO_read_bio_ex() and
SSL_CTX_use_serverinfo_file() which are also vulnerable. Some OpenSSL
internal uses of these functions are not vulnerable because the caller does
not free the header argument if PEM_read_bio_ex() returns a failure code.
(CVE-2022-4450)
[Kurt Roeckx, Matt Caswell]
*) Fixed Timing Oracle in RSA Decryption.
A timing based side channel exists in the OpenSSL RSA Decryption
implementation which could be sufficient to recover a plaintext across
a network in a Bleichenbacher style attack. To achieve a successful
decryption an attacker would have to be able to send a very large number
of trial messages for decryption. The vulnerability affects all RSA padding
modes: PKCS#1 v1.5, RSA-OEAP and RSASVE.
(CVE-2022-4304)
[Dmitry Belyavsky, Hubert Kario]
Signed-off-by: John Audia <therealgraysky@proton.me>
(cherry picked from commit 4ae86b3358)
The original commit removed the upstreamed patch 010-padlock.patch, but
it's not on OpenWrt 21.02, so it doesn't have to be removed.
Signed-off-by: Michal Vasilek <michal.vasilek@nic.cz>
fixes the problem that the banana pi m2 berry cannot connect to wifi and cannot be used as an access point
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
(cherry picked from commit ff2bb16730)
Signed-off-by: LizenzFass78851 <82592556+LizenzFass78851@users.noreply.github.com>
As of upstream Linux commit 0fe1e96fef0a ("powerpc/pci: Prefer PCI
domain assignment via DT 'linux,pci-domain' and alias"), the PCIe
domain address is no longer numbered by the lowest 16 bits of the PCI
register address after a fallthrough. Instead of the fallthrough, the
enumeration process accepts the alias ID (as determined by
`of_alias_scan()`). This causes e.g.:
9000:00:00.0 PCI bridge: Freescale Semiconductor Inc P1020E (rev 11)
9000:01:00.0 Network controller: Qualcomm Atheros AR958x 802.11abgn ...
to become
0000:00:00.0 PCI bridge: Freescale Semiconductor Inc P1020E (rev 11)
0000:01:00.0 Network controller: Qualcomm Atheros AR958x 802.11abgn ...
... which then causes the sysfs path of the netdev to change,
invalidating the `wifi_device.path`s enumerated in
`/etc/config/wireless`.
One other solution might be to migrate the uci configuration, as was
done for mvebu in commit 0bd5aa89fc ("mvebu: Migrate uci config to
new PCIe path"). However, there are concerns that the sysfs path will
change once again once some upstream patches[^2][^3] are merged and
backported (and `CONFIG_PPC_PCI_BUS_NUM_DOMAIN_DEPENDENT` is enabled).
Instead, remove the aliases and allow the fallthrough to continue for
now. We will provide a migration in a later release.
This was first reported as a Github issue[^1].
[^1]: https://github.com/openwrt/openwrt/issues/10530
[^2]: https://lore.kernel.org/linuxppc-dev/20220706104308.5390-1-pali@kernel.org/t/#u
[^3]: https://lore.kernel.org/linuxppc-dev/20220706101043.4867-1-pali@kernel.org/Fixes: #10530
Tested-by: Martin Kennedy <hurricos@gmail.com>
[Tested on the Aerohive HiveAP 330 and Extreme Networks WS-AP3825i]
Signed-off-by: Martin Kennedy <hurricos@gmail.com>
(cherry picked from commit 7f4b4c29f3)
Signed-off-by: Fabian Bläse <fabian@blaese.de>
This was done by running these commands:
./scripts/kconfig.pl '+' target/linux/generic/config-5.4 /dev/null > target/linux/generic/config-5.4-new
mv target/linux/generic/config-5.4-new target/linux/generic/config-5.4
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
OpenWrt provides kmod-asn1-decoder for CONFIG_ASN1 but selecting it
doesn't really work as expected. Kernel symbol is hidden and can be
actually selected only as a dependency. That works well for in-kernel
stuff but fails for external modules requiring ASN1 like ksmbd.
Modify kernel Kconfig to make CONFIG_ASN1 always selectable. It's
required to satisfy ksmbd dependencies cleanly (without hack like
selecting unrelated modules).
Link: http://lists.openwrt.org/pipermail/openwrt-devel/2023-January/040298.html
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Allign dl_github_archieve.py to 8252511dc0
change. On supported system the sigid bit is applied to files and tar
archieve that on tar creation. This cause unreproducible tar for these
system and these bit should be dropped to produce reproducible tar.
Add the missing option following the command options used in other
scripts.
Fixes: 75ab064d2b ("build: download code from github using archive API")
Suggested-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Tested-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
(cherry picked from commit 5f1758ef14)
Add driver for NVM Express block devices, ie. PCIe connected SSDs.
Targets which allow booting from NVMe (x86, maybe some mvebu boards come
to mind) should have it built-in, so rootfs can be mounted from there.
For targets without NVMe support in bootloader or BIOS/firmware it's
sufficient to provide the kernel module package.
On targets having the NVMe driver built-in the resulting kmod package
is an empty dummy. In any case, depending on or installing kmod-nvme
results in driver support being available (either because it was already
built-in or because the relevant kernel modules are added and loaded).
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
(cherry picked from commit dbe53352e3)
These have long been obsolete. For reference, here's the Linux version where
each symbol has been dropped:
CONFIG_IP6_NF_QUEUE - 3.5
CONFIG_IP6_NF_TARGET_LOG - 3.4
CONFIG_IP_NF_MATCH_DSCP - 2.6.19
CONFIG_NF_CONNTRACK_IPV4 - 4.19
CONFIG_NF_CONNTRACK_IPV6 - 4.19
CONFIG_NF_CONNTRACK_RTCACHE - out-of-tree, superseded by flow offloading
Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
(cherry picked from commit d7956c5728)
