This is the start of the stable review cycle for the 5.10.169 release.
There are 57 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed, 22 Feb 2023 13:35:35 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.169-r…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 5.10.169-rc1
Russell King (Oracle) <rmk+kernel(a)armlinux.org.uk>
nvmem: core: fix return value
Dan Carpenter <error27(a)gmail.com>
net: sched: sch: Fix off by one in htb_activate_prios()
Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com>
ASoC: SOF: Intel: hda-dai: fix possible stream_tag leak
Thomas Gleixner <tglx(a)linutronix.de>
alarmtimer: Prevent starvation by small intervals and SIG_IGN
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
kvm: initialize all of the kvm_debugregs structure before sending it to userspace
Pedro Tammela <pctammela(a)mojatatu.com>
net/sched: tcindex: search key must be 16 bits
Natalia Petrova <n.petrova(a)fintech.ru>
i40e: Add checking for null for nlmsg_find_attr()
Pedro Tammela <pctammela(a)mojatatu.com>
net/sched: act_ctinfo: use percpu stats
Baowen Zheng <baowen.zheng(a)corigine.com>
flow_offload: fill flags to action structure
Matt Roper <matthew.d.roper(a)intel.com>
drm/i915/gen11: Wa_1408615072/Wa_1407596294 should be on GT list
Raviteja Goud Talla <ravitejax.goud.talla(a)intel.com>
drm/i915/gen11: Moving WAs to icl_gt_workarounds_init()
Ryusuke Konishi <konishi.ryusuke(a)gmail.com>
nilfs2: fix underflow in second superblock position calculations
Guillaume Nault <gnault(a)redhat.com>
ipv6: Fix tcp socket connection with DSCP.
Guillaume Nault <gnault(a)redhat.com>
ipv6: Fix datagram socket connection with DSCP.
Jason Xing <kernelxing(a)tencent.com>
ixgbe: add double of VLAN header when computing the max MTU
Jakub Kicinski <kuba(a)kernel.org>
net: mpls: fix stale pointer if allocation fails during device rename
Cristian Ciocaltea <cristian.ciocaltea(a)collabora.com>
net: stmmac: Restrict warning on disabling DMA store and fwd mode
Michael Chan <michael.chan(a)broadcom.com>
bnxt_en: Fix mqprio and XDP ring checking logic
Johannes Zink <j.zink(a)pengutronix.de>
net: stmmac: fix order of dwmac5 FlexPPS parametrization sequence
Hangyu Hua <hbh25y(a)gmail.com>
net: openvswitch: fix possible memory leak in ovs_meter_cmd_set()
Miko Larsson <mikoxyzzz(a)gmail.com>
net/usb: kalmia: Don't pass act_len in usb_bulk_msg error path
Kuniyuki Iwashima <kuniyu(a)amazon.com>
dccp/tcp: Avoid negative sk_forward_alloc by ipv6_pinfo.pktoptions.
Pedro Tammela <pctammela(a)mojatatu.com>
net/sched: tcindex: update imperfect hash filters respecting rcu
Pietro Borrello <borrello(a)diag.uniroma1.it>
sctp: sctp_sock_filter(): avoid list_entry() on possibly empty list
Rafał Miłecki <rafal(a)milecki.pl>
net: bgmac: fix BCM5358 support by setting correct flags
Jason Xing <kernelxing(a)tencent.com>
i40e: add double of VLAN header when computing the max MTU
Jason Xing <kernelxing(a)tencent.com>
ixgbe: allow to increase MTU to 3K with XDP enabled
Andrew Morton <akpm(a)linux-foundation.org>
revert "squashfs: harden sanity check in squashfs_read_xattr_id_table"
Felix Riemann <felix.riemann(a)sma.de>
net: Fix unwanted sign extension in netdev_stats_to_stats64()
Aaron Thompson <dev(a)aaront.org>
Revert "mm: Always release pages to the buddy allocator in memblock_free_late()."
Mike Kravetz <mike.kravetz(a)oracle.com>
hugetlb: check for undefined shift on 32 bit architectures
Munehisa Kamata <kamatam(a)amazon.com>
sched/psi: Fix use-after-free in ep_remove_wait_queue()
Kailang Yang <kailang(a)realtek.com>
ALSA: hda/realtek - fixed wrong gpio assigned
Bo Liu <bo.liu(a)senarytech.com>
ALSA: hda/conexant: add a new hda codec SN6180
Yang Yingliang <yangyingliang(a)huawei.com>
mmc: mmc_spi: fix error handling in mmc_spi_probe()
Yang Yingliang <yangyingliang(a)huawei.com>
mmc: sdio: fix possible resource leaks in some error paths
Paul Cercueil <paul(a)crapouillou.net>
mmc: jz4740: Work around bug on JZ4760(B)
Florian Westphal <fw(a)strlen.de>
netfilter: nft_tproxy: restrict to prerouting hook
Amir Goldstein <amir73il(a)gmail.com>
ovl: remove privs in ovl_fallocate()
Amir Goldstein <amir73il(a)gmail.com>
ovl: remove privs in ovl_copyfile()
Sumanth Korikkar <sumanthk(a)linux.ibm.com>
s390/signal: fix endless loop in do_signal
Seth Jenkins <sethjenkins(a)google.com>
aio: fix mremap after fork null-deref
Russell King (Oracle) <rmk+kernel(a)armlinux.org.uk>
nvmem: core: fix registration vs use race
Russell King (Oracle) <rmk+kernel(a)armlinux.org.uk>
nvmem: core: fix cleanup after dev_set_name()
Russell King (Oracle) <rmk+kernel(a)armlinux.org.uk>
nvmem: core: remove nvmem_config wp_gpio
Gaosheng Cui <cuigaosheng1(a)huawei.com>
nvmem: core: add error handling for dev_set_name
Hans de Goede <hdegoede(a)redhat.com>
platform/x86: touchscreen_dmi: Add Chuwi Vi8 (CWI501) DMI match
Amit Engel <Amit.Engel(a)dell.com>
nvme-fc: fix a missing queue put in nvmet_fc_ls_create_association
Vasily Gorbik <gor(a)linux.ibm.com>
s390/decompressor: specify __decompress() buf len to avoid overflow
Kees Cook <keescook(a)chromium.org>
net: sched: sch: Bounds check priority
Andrey Konovalov <andrey.konovalov(a)linaro.org>
net: stmmac: do not stop RX_CLK in Rx LPI state for qcs404 SoC
Hyunwoo Kim <v4bel(a)theori.io>
net/rose: Fix to not accept on connected socket
Shunsuke Mie <mie(a)igel.co.jp>
tools/virtio: fix the vringh test for virtio ring changes
Arnd Bergmann <arnd(a)arndb.de>
ASoC: cs42l56: fix DT probe
Cezary Rojewski <cezary.rojewski(a)intel.com>
ALSA: hda: Do not unset preset when cleaning up codec
Eduard Zingerman <eddyz87(a)gmail.com>
selftests/bpf: Verify copy_register_state() preserves parent/live fields
Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com>
ASoC: Intel: sof_rt5682: always set dpcm_capture for amplifiers
-------------
Diffstat:
Makefile | 4 +-
arch/s390/boot/compressed/decompressor.c | 2 +-
arch/s390/kernel/signal.c | 2 +-
arch/x86/kvm/x86.c | 3 +-
drivers/gpu/drm/i915/gt/intel_workarounds.c | 32 ++++++++--------
drivers/mmc/core/sdio_bus.c | 17 +++++++--
drivers/mmc/core/sdio_cis.c | 12 ------
drivers/mmc/host/jz4740_mmc.c | 10 +++++
drivers/mmc/host/mmc_spi.c | 8 ++--
drivers/net/ethernet/broadcom/bgmac-bcma.c | 6 +--
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 8 +++-
drivers/net/ethernet/intel/i40e/i40e_main.c | 4 +-
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 2 +
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 28 ++++++++------
.../ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 2 +
drivers/net/ethernet/stmicro/stmmac/dwmac5.c | 3 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 +-
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 2 +-
drivers/net/usb/kalmia.c | 8 ++--
drivers/nvme/target/fc.c | 4 +-
drivers/nvmem/core.c | 43 +++++++++++-----------
drivers/platform/x86/touchscreen_dmi.c | 9 +++++
fs/aio.c | 4 ++
fs/nilfs2/ioctl.c | 7 ++++
fs/nilfs2/super.c | 9 +++++
fs/nilfs2/the_nilfs.c | 8 +++-
fs/overlayfs/file.c | 28 ++++++++++++--
fs/squashfs/xattr_id.c | 2 +-
include/linux/hugetlb.h | 5 ++-
include/linux/nvmem-provider.h | 2 -
include/linux/stmmac.h | 1 +
include/net/sock.h | 13 +++++++
kernel/sched/psi.c | 7 ++--
kernel/time/alarmtimer.c | 33 +++++++++++++++--
mm/memblock.c | 8 +---
net/core/dev.c | 2 +-
net/dccp/ipv6.c | 7 +---
net/ipv6/datagram.c | 2 +-
net/ipv6/tcp_ipv6.c | 11 ++----
net/mpls/af_mpls.c | 4 ++
net/netfilter/nft_tproxy.c | 8 ++++
net/openvswitch/meter.c | 4 +-
net/rose/af_rose.c | 8 ++++
net/sched/act_bpf.c | 2 +-
net/sched/act_connmark.c | 2 +-
net/sched/act_ctinfo.c | 6 +--
net/sched/act_gate.c | 2 +-
net/sched/act_ife.c | 2 +-
net/sched/act_ipt.c | 2 +-
net/sched/act_mpls.c | 2 +-
net/sched/act_nat.c | 2 +-
net/sched/act_pedit.c | 2 +-
net/sched/act_police.c | 2 +-
net/sched/act_sample.c | 2 +-
net/sched/act_simple.c | 2 +-
net/sched/act_skbedit.c | 2 +-
net/sched/act_skbmod.c | 2 +-
net/sched/cls_tcindex.c | 34 +++++++++++++++--
net/sched/sch_htb.c | 5 ++-
net/sctp/diag.c | 4 +-
sound/pci/hda/hda_bind.c | 2 +
sound/pci/hda/hda_codec.c | 1 -
sound/pci/hda/patch_conexant.c | 1 +
sound/pci/hda/patch_realtek.c | 2 +-
sound/soc/codecs/cs42l56.c | 6 ---
sound/soc/intel/boards/sof_rt5682.c | 3 ++
sound/soc/sof/intel/hda-dai.c | 8 ++--
.../selftests/bpf/verifier/search_pruning.c | 36 ++++++++++++++++++
tools/virtio/linux/bug.h | 8 ++--
tools/virtio/linux/build_bug.h | 7 ++++
tools/virtio/linux/cpumask.h | 7 ++++
tools/virtio/linux/gfp.h | 7 ++++
tools/virtio/linux/kernel.h | 1 +
tools/virtio/linux/kmsan.h | 12 ++++++
tools/virtio/linux/scatterlist.h | 1 +
tools/virtio/linux/topology.h | 7 ++++
76 files changed, 404 insertions(+), 165 deletions(-)
Hi Andrew,
On Tue, 21 Feb 2023 17:03:13 +0800 Andrew Yang <andrew.yang(a)mediatek.com> wrote:
> From: "andrew.yang" <andrew.yang(a)mediatek.com>
>
> damon_get_page() would always increase page _refcount and
> isolate_lru_page() would increase page _refcount if the page's lru
> flag is set.
>
> If a unevictable page isolated successfully, there will be two more
> _refcount. The one from isolate_lru_page() will be decreased in
> putback_lru_page(), but the other one from damon_get_page() will be
> left behind. This causes a pin page.
>
> Whatever the case, the _refcount from damon_get_page() should be
> decreased.
Thank you for finding this issue! I think the David suggested subject[1] is
better, though.
I think we could add below Fixes: and Cc: tags?
Fixes: 57223ac29584 ("mm/damon/paddr: support the pageout scheme")
Cc: <stable(a)vger.kernel.org> # 5.16.x
>
> Signed-off-by: andrew.yang <andrew.yang(a)mediatek.com>
> ---
> mm/damon/paddr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/damon/paddr.c b/mm/damon/paddr.c
> index e1a4315c4be6..56d8abd08fb1 100644
> --- a/mm/damon/paddr.c
> +++ b/mm/damon/paddr.c
> @@ -223,8 +223,8 @@ static unsigned long damon_pa_pageout(struct damon_region *r)
> putback_lru_page(page);
> } else {
> list_add(&page->lru, &page_list);
> - put_page(page);
> }
> + put_page(page);
Seems your patch is not based on mm-unstable tree[2]. Could you please rebase
on it?
Also, let's remove the braces for the single statements[3].
[1] https://lore.kernel.org/damon/1b3e8e88-ed5c-7302-553f-4ddb3400d466@redhat.c…
[2] https://docs.kernel.org/next/mm/damon/maintainer-profile.html#scm-trees
[3] https://docs.kernel.org/process/coding-style.html?highlight=coding+style#pl…
Thanks,
SJ
> }
> applied = reclaim_pages(&page_list);
> cond_resched();
> --
> 2.18.0
在 2023/2/22 4:26, Seth Jenkins 写道:
> > So you are letting an opaque US government agency, and random third
> > party companies, dictate your company's internal engineering policies
> > and resource allocations? That feels very very odd and ripe for abuse.
> I wholeheartedly agree with gregkh that the CVE system is flawed in
> numerous ways and generates many false positives, however in this case,
> this issue is a real issue with real security impact that received a
> real patch upstream. The idea of backporting this to earlier kernels
> probably warrants discussion if someone is willing to bite off that
> work. But this gets into the fuzzy "backporting exploit mitigations to
> stable" conversation.
>
> > And are you sure this can really happen? Have you proven this?
> Yes this can really, provably, happen:
> https://googleprojectzero.blogspot.com/2022/12/exploiting-CVE-2022-42703-br…
> <https://googleprojectzero.blogspot.com/2022/12/exploiting-CVE-2022-42703-br…>
>
> > And why is this really an issue, KAS[L]R is a known-weak-defense and
> almost
> > useless against local attacks.
> Granted, Peter Z's fix does help to mitigate the impact from remote
> attackers but yes this fix does not resolve the security impact from
> local exploits.
Thank you seth.
Yes, for this specific CVE issue, KASLR is indeed a mitigation measure.
>
>
> On Tue, Feb 21, 2023 at 7:30 AM Tong Tiangen <tongtiangen(a)huawei.com
> <mailto:tongtiangen@huawei.com>> wrote:
>
>
>
> 在 2023/2/21 18:40, Greg KH 写道:
> > On Tue, Feb 21, 2023 at 05:19:42PM +0800, Tong Tiangen wrote:
> >>
> >>
> >> 在 2023/2/21 16:40, Greg KH 写道:
> >>> On Tue, Feb 21, 2023 at 03:46:27PM +0800, Tong Tiangen wrote:
> >>>>
> >>>>
> >>>> 在 2023/2/21 15:30, Greg KH 写道:
> >>>>> On Tue, Feb 21, 2023 at 03:19:05PM +0800, Tong Tiangen wrote:
> >>>>>> Hi peter:
> >>>>>>
> >>>>>> Do you have any plans to backport this patch[1] to the
> stable branch of the
> >>>>>> lower version, such as 4.19.y ?
> >>>>>
> >>>>> Why? That is a new feature for 6.2 why would it be needed to fix
> >>>>> anything in really old kernels?
> >>>>
> >>>> Hi Greg:
> >>>>
> >>>> This patch fix CVE-2023-0597[1],
> >>>
> >>> The kernel developers do not care about CVEs as they are almost
> always
> >>> invalid and do not mean anything,
> >>
> >> Ok, thanks.
> >>
> >>
> >>> sorry. It is well known that, companies like Red Hat use them
> to make
> >>> up for broken internal engineering policies.
> >>
> >> Yeah, For company's internal engineering policies, the CVE with
> certain
> >> impact must be repaired.
> >
> > So you are letting an opaque US government agency, and random third
> > party companies, dictate your company's internal engineering policies
> > and resource allocations? That feels very very odd and ripe for
> abuse.
> >
> > Also note that MITRE refuses to allocate CVEs for many real kernel
> > issues for unknown reasons, (i.e. they reject all of my requests), so
> > you are getting only a small subset of real issues here.
> >
> > Also, how do you handle revocation of CVEs that are obviously invalid
> > and/or don't actually do anything (like this one?)
> >
> >>> Are you sure this really is a valid problem that must be fixed
> in older
> >>> kernels?
> >>>
> >>>> this CVE report a flaw possibility of memory leak. And this is
> >>>> important for some products using this stable version.
> >>>
> >>> What exact memory leak are you referring to?
> >>
> >> Sorry for Inaccurate description, the memory leak means: a potential
> >> security risk of kernel memory information disclosure caused by no
> >> randomization of the exception stacks.
> >
> > And are you sure this can really happen? Have you proven this?
> >
> > And why is this really an issue, KASR is a known-week-defense and
> almost
> > useless against local attacks.
> >
> > Anyway, please provide working patches if you think this really is an
> > issue.
> >
> > And please revisit your company's policies, they do not seem very
> sane :)
>
> Hi Greg:
>
> Thanks for these very useful suggestions and we will revisit our
> policies :)
>
> Thanks,
> Tong
> .
>
> >
> > thanks,
> >
> > greg k-h
> > .
>
Bom dia stable(a)vger.kernel.org,
Sou o advogado Mustafa Ayvaz, advogado pessoal do falecido Sr.
Robert, que perdeu a vida devido ao coronavírus, contraído
durante sua viagem de negócios à China. Entrei em contato com
você para trabalhar comigo na transferência de um fundo:
$4,420,000.00 (quatro milhões, quatrocentos e vinte mil dólares)
legado deixado por ele.
Procurei minuciosamente o parente mais próximo de meu cliente
falecido, mas falhei porque não tenho sua residência atual e
detalhes de contato. Enquanto pesquisava, encontrei seu perfil
com o mesmo sobrenome e na mesma localidade com o parente mais
próximo. Decidi entrar em contato com você e usá-lo como parente
genuíno.
Solicito seu consentimento para apresentá-lo como parente mais
próximo de meu falecido cliente, já que ambos têm o mesmo
sobrenome. Os fundos serão então transferidos para você como
beneficiário e compartilhados de acordo com um padrão/proporção
de compartilhamento proposto de 60:40, ou seja, 60% para mim e
40% para você. Por favor, entre em contato comigo imediatamente
para obter mais informações.
Cumprimentos
Mustafá Ayvaz
The riscv defconfig and tinyconfig builds failed with clang-nightly
due to below build warnings / errors on latest stable-rc 5.10.
Regression on riscv:
- build/clang-nightly-tinyconfig - FAILED
- build/clang-nightly-defconfig - FAILED
Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org>
metadata:
-----
git_repo: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
git_sha: 7d11e4c4fc56eb25c5b41da93748dbcf21956316
git_short_log: 7d11e4c4fc56 ("Linux 5.10.169-rc1")
git_describe: v5.10.168-58-g7d11e4c4fc56
Build log:
----
make --silent --keep-going --jobs=8
O=/home/tuxbuild/.cache/tuxmake/builds/1/build ARCH=riscv
CROSS_COMPILE=riscv64-linux-gnu- HOSTCC=clang CC=clang LLVM=1
LLVM_IAS=1 LD=riscv64-linux-gnu-ld
riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_zicsr2p0_zifencei2p0:
Invalid or unknown z ISA extension: 'zifencei'
riscv64-linux-gnu-ld: failed to merge target specific data of file
init/version.o
riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_zicsr2p0_zifencei2p0:
Invalid or unknown z ISA extension: 'zifencei'
riscv64-linux-gnu-ld: failed to merge target specific data of file
init/do_mounts.o
riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_zicsr2p0_zifencei2p0:
Invalid or unknown z ISA extension: 'zifencei'
riscv64-linux-gnu-ld: failed to merge target specific data of file
init/noinitramfs.o
riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_zicsr2p0_zifencei2p0:
Invalid or unknown z ISA extension: 'zifencei'
riscv64-linux-gnu-ld: failed to merge target specific data of file
init/calibrate.o
riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_zicsr2p0_zifencei2p0:
Invalid or unknown z ISA extension: 'zifencei'
Build details,
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10…
Build history,
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10…https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10…
steps to reproduce:
-----------
# To install tuxmake on your system globally:
# sudo pip3 install -U tuxmake
#
# See https://docs.tuxmake.org/ for complete documentation.
# Original tuxmake command with fragments listed below.
# tuxmake --runtime podman --target-arch riscv --toolchain
clang-nightly --kconfig tinyconfig LLVM=1 LLVM_IAS=1
LD=riscv64-linux-gnu-ld
--
Linaro LKFT
https://lkft.linaro.org
Beste gebruiker,
Hallo mijn gelukkige vriend, ik ben Charles W. Jackson Jr., de
megawinnaar van $ 344,6 miljoen Mega Millions Jackpot, ik doneer aan 5
willekeurige individuen, als je deze e-mail ontvangt, is je e-mail
geselecteerd na een draaibal. Ik heb het grootste deel van mijn vermogen
verdeeld over een aantal goede doelen en organisaties. Ik heb vrijwillig
besloten om de som van $ 3 miljoen USD aan jou of je organisatie te
doneren als een van de geselecteerde 5, je kunt mijn winst verifiëren
via de onderstaande YouTube-pagina.
BEKIJK MIJ HIER: https://www.youtube.com/watch?v=0MUR8QEIMQI
Deze donatie van $ 3 miljoen USD is gedaan om u in staat te stellen uw
persoonlijke problemen te versterken en genereus de hand te reiken aan
de minst bevoorrechte, verweesde en liefdadigheidsorganisaties in uw
gemeenschap.
Wat voor mij het belangrijkste is, is dat u de gedoneerde fondsen op de
beste manier toewijst die u, uw familie, vrienden ten goede komt en om
de behoeftigen in uw directe gemeenschap te helpen.
DIT IS JE DONATIECODE: DON207152
Stuur uw DONATIECODE zo snel mogelijk naar onderstaand e-mailadres,
zodat we de donatieprocedure snel kunnen afronden.
E-mail contact: charlesjacksonj1(a)hotmail.com
charlesjackson06(a)bahnhof.se
Ik hoop u en uw gezin dit jaar gelukkig te maken, ik wens u het beste en
gefeliciteerd.
Groeten,
Charles W.Jackson Jr