Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

NVIDIA: SAUCE: iommu/arm-smmu-v3: Allow default substream bypass with a pasid support #8

Open
wants to merge 115 commits into
base: main
Choose a base branch
from
Open

NVIDIA: SAUCE: iommu/arm-smmu-v3: Allow default substream bypass with a pasid support #8

wants to merge 115 commits into from

Conversation

jamieNguyenNVIDIA
Copy link
Contributor

@jamieNguyenNVIDIA jamieNguyenNVIDIA commented Aug 10, 2023 •
edited
Loading 

NVIDIA: SAUCE: iommu/arm-smmu-v3: Allow default substream bypass with a pasid support

When an iommu_domain is set to IOMMU_DOMAIN_IDENTITY, the driver would
skip the allocation of a CD table and set the CONFIG field of the STE
to STRTAB_STE_0_CFG_BYPASS. This works well for devices that only have
one substream, i.e. PASID disabled.

However, there could be a use case, for a pasid capable device, that
allows bypassing the translation at the default substream while still
enabling the pasid feature, which means the driver should not skip the
allocation of a CD table nor simply bypass the CONFIG field. Instead,
the S1DSS field should be set to STRTAB_STE_1_S1DSS_BYPASS and the
SHCFG field should be set to STRTAB_STE_1_SHCFG_INCOMING.

Add s1dss in struct arm_smmu_s1_cfg, to allow a configuration in the
finalise() to support this use case.

Also, according to "13.5 Summary of attribute/permission configuration
fields" in the reference manual, the SHCFG field value is irrelevant.
So, set the SHCFG field of the STE always to STRTAB_STE_1_SHCFG_INCOMING
for simplification.

Signed-off-by: Nicolin Chen <[email protected]>
Reviewed-by: Pritesh Raithatha <[email protected]>
Acked-by: Jamie Nguyen <[email protected]>
Acked-by: Nicolin Chen <[email protected]>

torvalds and others added 30 commits July 10, 2023 17:09
@torvalds
mm: introduce new 'lock_mm_and_find_vma()' page fault helper
f474473 
commit c2508ec upstream.

.. and make x86 use it.

This basically extracts the existing x86 "find and expand faulting vma"
code, but extends it to also take the mmap lock for writing in case we
actually do need to expand the vma.

We've historically short-circuited that case, and have some rather ugly
special logic to serialize the stack segment expansion (since we only
hold the mmap lock for reading) that doesn't match the normal VM
locking.

That slight violation of locking worked well, right up until it didn't:
the maple tree code really does want proper locking even for simple
extension of an existing vma.

So extract the code for "look up the vma of the fault" from x86, fix it
up to do the necessary write locking, and make it available as a helper
function for other architectures that can use the common helper.

Note: I say "common helper", but it really only handles the normal
stack-grows-down case.  Which is all architectures except for PA-RISC
and IA64.  So some rare architectures can't use the helper, but if they
care they'll just need to open-code this logic.

It's also worth pointing out that this code really would like to have an
optimistic "mmap_upgrade_trylock()" to make it quicker to go from a
read-lock (for the common case) to taking the write lock (for having to
extend the vma) in the normal single-threaded situation where there is
no other locking activity.

But that _is_ all the very uncommon special case, so while it would be
nice to have such an operation, it probably doesn't matter in reality.
I did put in the skeleton code for such a possible future expansion,
even if it only acts as pseudo-documentation for what we're doing.

Signed-off-by: Linus Torvalds <[email protected]>
[6.1: Ignore CONFIG_PER_VMA_LOCK context]
Signed-off-by: Samuel Mendoza-Jonas <[email protected]>
Signed-off-by: David Woodhouse <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
(cherry picked from commit d6a5c7a1a6e52d4c46fe181237ca96cd46a42386 linux-6.1.y)
CVE-2023-3269
Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
Acked-by: Cengiz Can <[email protected]>
Acked-by: Tim Gardner <[email protected]>
Signed-off-by: Luke Nowakowski-Krijger <[email protected]>
@torvalds
mm: make the page fault mmap locking killable
7924413 
This is done as a separate patch from introducing the new
lock_mm_and_find_vma() helper, because while it's an obvious change,
it's not what x86 used to do in this area.

We already abort the page fault on fatal signals anyway, so why should
we wait for the mmap lock only to then abort later? With the new helper
function that returns without the lock held on failure anyway, this is
particularly easy and straightforward.

Signed-off-by: Linus Torvalds <[email protected]>
(cherry picked from commit eda0047)
CVE-2023-3269
Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
Acked-by: Cengiz Can <[email protected]>
Acked-by: Tim Gardner <[email protected]>
Signed-off-by: Luke Nowakowski-Krijger <[email protected]>
@torvalds
arm64/mm: Convert to using lock_mm_and_find_vma()
7e26ec1 
commit ae870a6 upstream.

This converts arm64 to use the new page fault helper.  It was very
straightforward, but still needed a fix for the "obvious" conversion I
initially did.  Thanks to Suren for the fix and testing.

Fixed-and-tested-by: Suren Baghdasaryan <[email protected]>
Unnecessary-code-removal-by: Liam R. Howlett <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
[6.1: Ignore CONFIG_PER_VMA_LOCK context]
Signed-off-by: Samuel Mendoza-Jonas <[email protected]>
Signed-off-by: David Woodhouse <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
(cherry picked from commit b92cd80e5f0b14760a49ff68da23959a38452cda linux-6.1.y)
CVE-2023-3269
Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
Acked-by: Cengiz Can <[email protected]>
Acked-by: Tim Gardner <[email protected]>
Signed-off-by: Luke Nowakowski-Krijger <[email protected]>
@mpe
powerpc/mm: Convert to using lock_mm_and_find_vma()
5fbb213 
Signed-off-by: Michael Ellerman <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
(cherry picked from commit e6fe228)
CVE-2023-3269
Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
Acked-by: Cengiz Can <[email protected]>
Acked-by: Tim Gardner <[email protected]>
Signed-off-by: Luke Nowakowski-Krijger <[email protected]>
@bwhacks
mips/mm: Convert to using lock_mm_and_find_vma()
3fe51b9 
Signed-off-by: Ben Hutchings <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
(cherry picked from commit 4bce37a)
CVE-2023-3269
Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
Acked-by: Cengiz Can <[email protected]>
Acked-by: Tim Gardner <[email protected]>
Signed-off-by: Luke Nowakowski-Krijger <[email protected]>
@bwhacks
riscv/mm: Convert to using lock_mm_and_find_vma()
8218035 
Signed-off-by: Ben Hutchings <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
(backported from commit 7267ef7)
[cascardo: Kconfig conflict]
CVE-2023-3269
Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
Acked-by: Cengiz Can <[email protected]>
Acked-by: Tim Gardner <[email protected]>
Signed-off-by: Luke Nowakowski-Krijger <[email protected]>
@bwhacks
arm/mm: Convert to using lock_mm_and_find_vma()
321e50a 
arm has an additional check for address < FIRST_USER_ADDRESS before
expanding the stack.  Since FIRST_USER_ADDRESS is defined everywhere
(generally as 0), move that check to the generic expand_downwards().

Signed-off-by: Ben Hutchings <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
(cherry picked from commit 8b35ca3)
CVE-2023-3269
Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
Acked-by: Cengiz Can <[email protected]>
Acked-by: Tim Gardner <[email protected]>
Signed-off-by: Luke Nowakowski-Krijger <[email protected]>
@torvalds
mm/fault: convert remaining simple cases to lock_mm_and_find_vma()
c62c554 
This does the simple pattern conversion of alpha, arc, csky, hexagon,
loongarch, nios2, sh, sparc32, and xtensa to the lock_mm_and_find_vma()
helper.  They all have the regular fault handling pattern without odd
special cases.

The remaining architectures all have something that keeps us from a
straightforward conversion: ia64 and parisc have stacks that can grow
both up as well as down (and ia64 has special address region checks).

And m68k, microblaze, openrisc, sparc64, and um end up having extra
rules about only expanding the stack down a limited amount below the
user space stack pointer.  That is something that x86 used to do too
(long long ago), and it probably could just be skipped, but it still
makes the conversion less than trivial.

Note that this conversion was done manually and with the exception of
alpha without any build testing, because I have a fairly limited cross-
building environment.  The cases are all simple, and I went through the
changes several times, but...

Signed-off-by: Linus Torvalds <[email protected]>
(cherry picked from commit a050ba1)
CVE-2023-3269
Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
Acked-by: Cengiz Can <[email protected]>
Acked-by: Tim Gardner <[email protected]>
Signed-off-by: Luke Nowakowski-Krijger <[email protected]>
@torvalds
powerpc/mm: convert coprocessor fault to lock_mm_and_find_vma()
f0dc8c1 
This is one of the simple cases, except there's no pt_regs pointer.
Which is fine, as lock_mm_and_find_vma() is set up to work fine with a
NULL pt_regs.

Powerpc already enabled LOCK_MM_AND_FIND_VMA for the main CPU faulting,
so we can just use the helper without any extra work.

Signed-off-by: Linus Torvalds <[email protected]>
(cherry picked from commit 2cd76c5)
CVE-2023-3269
Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
Acked-by: Cengiz Can <[email protected]>
Acked-by: Tim Gardner <[email protected]>
Signed-off-by: Luke Nowakowski-Krijger <[email protected]>
@howlett
mm: make find_extend_vma() fail if write lock not held
543c62e 
Make calls to extend_vma() and find_extend_vma() fail if the write lock
is required.

To avoid making this a flag-day event, this still allows the old
read-locking case for the trivial situations, and passes in a flag to
say "is it write-locked".  That way write-lockers can say "yes, I'm
being careful", and legacy users will continue to work in all the common
cases until they have been fully converted to the new world order.

Co-Developed-by: Matthew Wilcox (Oracle) <[email protected]>
Signed-off-by: Matthew Wilcox (Oracle) <[email protected]>
Signed-off-by: Liam R. Howlett <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
(cherry picked from commit f440fa1)
CVE-2023-3269
Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
Acked-by: Cengiz Can <[email protected]>
Acked-by: Tim Gardner <[email protected]>
Signed-off-by: Luke Nowakowski-Krijger <[email protected]>
@torvalds
execve: expand new process stack manually ahead of time
9dc4f0c 
This is a small step towards a model where GUP itself would not expand
the stack, and any user that needs GUP to not look up existing mappings,
but actually expand on them, would have to do so manually before-hand,
and with the mm lock held for writing.

It turns out that execve() already did almost exactly that, except it
didn't take the mm lock at all (it's single-threaded so no locking
technically needed, but it could cause lockdep errors).  And it only did
it for the CONFIG_STACK_GROWSUP case, since in that case GUP has
obviously never expanded the stack downwards.

So just make that CONFIG_STACK_GROWSUP case do the right thing with
locking, and enable it generally.  This will eventually help GUP, and in
the meantime avoids a special case and the lockdep issue.

Signed-off-by: Linus Torvalds <[email protected]>
(cherry picked from commit f313c51)
CVE-2023-3269
Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
Acked-by: Cengiz Can <[email protected]>
Acked-by: Tim Gardner <[email protected]>
Signed-off-by: Luke Nowakowski-Krijger <[email protected]>
@torvalds
mm: always expand the stack with the mmap write lock held
c31ab58 
This finishes the job of always holding the mmap write lock when
extending the user stack vma, and removes the 'write_locked' argument
from the vm helper functions again.

For some cases, we just avoid expanding the stack at all: drivers and
page pinning really shouldn't be extending any stacks.  Let's see if any
strange users really wanted that.

It's worth noting that architectures that weren't converted to the new
lock_mm_and_find_vma() helper function are left using the legacy
"expand_stack()" function, but it has been changed to drop the mmap_lock
and take it for writing while expanding the vma.  This makes it fairly
straightforward to convert the remaining architectures.

As a result of dropping and re-taking the lock, the calling conventions
for this function have also changed, since the old vma may no longer be
valid.  So it will now return the new vma if successful, and NULL - and
the lock dropped - if the area could not be extended.

Tested-by: Vegard Nossum <[email protected]>
Tested-by: John Paul Adrian Glaubitz <[email protected]> # ia64
Tested-by: Frank Scheiner <[email protected]> # ia64
Signed-off-by: Linus Torvalds <[email protected]>
(cherry picked from commit 8d7071a)
CVE-2023-3269
Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
Acked-by: Cengiz Can <[email protected]>
Acked-by: Tim Gardner <[email protected]>
Signed-off-by: Luke Nowakowski-Krijger <[email protected]>
UBUNTU: [CONFIG]: Set CONFIG_LOCK_MM_AND_FIND_VMA
8e19887 
Aside from s390x, all other supported arches define and require it now.

CVE-2023-3269
Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
Acked-by: Cengiz Can <[email protected]>
Acked-by: Tim Gardner <[email protected]>
Signed-off-by: Luke Nowakowski-Krijger <[email protected]>
ipvlan:Fix out-of-bounds caused by unclear skb->cb
82b71b5 
If skb enqueue the qdisc, fq_skb_cb(skb)->time_to_send is changed which
is actually skb->cb, and IPCB(skb_in)->opt will be used in
__ip_options_echo. It is possible that memcpy is out of bounds and lead
to stack overflow.
We should clear skb->cb before ip_local_out or ip6_local_out.

v2:
1. clean the stack info
2. use IPCB/IP6CB instead of skb->cb

crash on stable-5.10(reproduce in kasan kernel).
Stack info:
[ 2203.651571] BUG: KASAN: stack-out-of-bounds in
__ip_options_echo+0x589/0x800
[ 2203.653327] Write of size 4 at addr ffff88811a388f27 by task
swapper/3/0
[ 2203.655460] CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Not tainted
5.10.0-60.18.0.50.h856.kasan.eulerosv2r11.x86_64 NVIDIA-BaseOS-6#1
[ 2203.655466] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.10.2-0-g5f4c7b1-20181220_000000-szxrtosci10000 04/01/2014
[ 2203.655475] Call Trace:
[ 2203.655481]  <IRQ>
[ 2203.655501]  dump_stack+0x9c/0xd3
[ 2203.655514]  print_address_description.constprop.0+0x19/0x170
[ 2203.655530]  __kasan_report.cold+0x6c/0x84
[ 2203.655586]  kasan_report+0x3a/0x50
[ 2203.655594]  check_memory_region+0xfd/0x1f0
[ 2203.655601]  memcpy+0x39/0x60
[ 2203.655608]  __ip_options_echo+0x589/0x800
[ 2203.655654]  __icmp_send+0x59a/0x960
[ 2203.655755]  nf_send_unreach+0x129/0x3d0 [nf_reject_ipv4]
[ 2203.655763]  reject_tg+0x77/0x1bf [ipt_REJECT]
[ 2203.655772]  ipt_do_table+0x691/0xa40 [ip_tables]
[ 2203.655821]  nf_hook_slow+0x69/0x100
[ 2203.655828]  __ip_local_out+0x21e/0x2b0
[ 2203.655857]  ip_local_out+0x28/0x90
[ 2203.655868]  ipvlan_process_v4_outbound+0x21e/0x260 [ipvlan]
[ 2203.655931]  ipvlan_xmit_mode_l3+0x3bd/0x400 [ipvlan]
[ 2203.655967]  ipvlan_queue_xmit+0xb3/0x190 [ipvlan]
[ 2203.655977]  ipvlan_start_xmit+0x2e/0xb0 [ipvlan]
[ 2203.655984]  xmit_one.constprop.0+0xe1/0x280
[ 2203.655992]  dev_hard_start_xmit+0x62/0x100
[ 2203.656000]  sch_direct_xmit+0x215/0x640
[ 2203.656028]  __qdisc_run+0x153/0x1f0
[ 2203.656069]  __dev_queue_xmit+0x77f/0x1030
[ 2203.656173]  ip_finish_output2+0x59b/0xc20
[ 2203.656244]  __ip_finish_output.part.0+0x318/0x3d0
[ 2203.656312]  ip_finish_output+0x168/0x190
[ 2203.656320]  ip_output+0x12d/0x220
[ 2203.656357]  __ip_queue_xmit+0x392/0x880
[ 2203.656380]  __tcp_transmit_skb+0x1088/0x11c0
[ 2203.656436]  __tcp_retransmit_skb+0x475/0xa30
[ 2203.656505]  tcp_retransmit_skb+0x2d/0x190
[ 2203.656512]  tcp_retransmit_timer+0x3af/0x9a0
[ 2203.656519]  tcp_write_timer_handler+0x3ba/0x510
[ 2203.656529]  tcp_write_timer+0x55/0x180
[ 2203.656542]  call_timer_fn+0x3f/0x1d0
[ 2203.656555]  expire_timers+0x160/0x200
[ 2203.656562]  run_timer_softirq+0x1f4/0x480
[ 2203.656606]  __do_softirq+0xfd/0x402
[ 2203.656613]  asm_call_irq_on_stack+0x12/0x20
[ 2203.656617]  </IRQ>
[ 2203.656623]  do_softirq_own_stack+0x37/0x50
[ 2203.656631]  irq_exit_rcu+0x134/0x1a0
[ 2203.656639]  sysvec_apic_timer_interrupt+0x36/0x80
[ 2203.656646]  asm_sysvec_apic_timer_interrupt+0x12/0x20
[ 2203.656654] RIP: 0010:default_idle+0x13/0x20
[ 2203.656663] Code: 89 f0 5d 41 5c 41 5d 41 5e c3 cc cc cc cc cc cc cc
cc cc cc cc cc cc 0f 1f 44 00 00 0f 1f 44 00 00 0f 00 2d 9f 32 57 00 fb
f4 <c3> cc cc cc cc 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 54 be 08
[ 2203.656668] RSP: 0018:ffff88810036fe78 EFLAGS: 00000256
[ 2203.656676] RAX: ffffffffaf2a87f0 RBX: ffff888100360000 RCX:
ffffffffaf290191
[ 2203.656681] RDX: 0000000000098b5e RSI: 0000000000000004 RDI:
ffff88811a3c4f60
[ 2203.656686] RBP: 0000000000000000 R08: 0000000000000001 R09:
ffff88811a3c4f63
[ 2203.656690] R10: ffffed10234789ec R11: 0000000000000001 R12:
0000000000000003
[ 2203.656695] R13: ffff888100360000 R14: 0000000000000000 R15:
0000000000000000
[ 2203.656729]  default_idle_call+0x5a/0x150
[ 2203.656735]  cpuidle_idle_call+0x1c6/0x220
[ 2203.656780]  do_idle+0xab/0x100
[ 2203.656786]  cpu_startup_entry+0x19/0x20
[ 2203.656793]  secondary_startup_64_no_verify+0xc2/0xcb

[ 2203.657409] The buggy address belongs to the page:
[ 2203.658648] page:0000000027a9842f refcount:1 mapcount:0
mapping:0000000000000000 index:0x0 pfn:0x11a388
[ 2203.658665] flags:
0x17ffffc0001000(reserved|node=0|zone=2|lastcpupid=0x1fffff)
[ 2203.658675] raw: 0017ffffc0001000 ffffea000468e208 ffffea000468e208
0000000000000000
[ 2203.658682] raw: 0000000000000000 0000000000000000 00000001ffffffff
0000000000000000
[ 2203.658686] page dumped because: kasan: bad access detected

To reproduce(ipvlan with IPVLAN_MODE_L3):
Env setting:
=======================================================
modprobe ipvlan ipvlan_default_mode=1
sysctl net.ipv4.conf.eth0.forwarding=1
iptables -t nat -A POSTROUTING -s 20.0.0.0/255.255.255.0 -o eth0 -j
MASQUERADE
ip link add gw link eth0 type ipvlan
ip -4 addr add 20.0.0.254/24 dev gw
ip netns add net1
ip link add ipv1 link eth0 type ipvlan
ip link set ipv1 netns net1
ip netns exec net1 ip link set ipv1 up
ip netns exec net1 ip -4 addr add 20.0.0.4/24 dev ipv1
ip netns exec net1 route add default gw 20.0.0.254
ip netns exec net1 tc qdisc add dev ipv1 root netem loss 10%
ifconfig gw up
iptables -t filter -A OUTPUT -p tcp --dport 8888 -j REJECT --reject-with
icmp-port-unreachable
=======================================================
And then excute the shell(curl any address of eth0 can reach):

for((i=1;i<=100000;i++))
do
        ip netns exec net1 curl x.x.x.x:8888
done
=======================================================

Fixes: 2ad7bf3 ("ipvlan: Initial check-in of the IPVLAN driver.")
Signed-off-by: "t.feng" <[email protected]>
Suggested-by: Florian Westphal <[email protected]>
Reviewed-by: Paolo Abeni <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
(cherry picked from commit 90cbed5)
CVE-2023-3090
Signed-off-by: Yuxuan Luo <[email protected]>
Acked-by: Andrei Gherzan <[email protected]>
Acked-by: Roxana Nicolescu <[email protected]>
Signed-off-by: Luke Nowakowski-Krijger <[email protected]>
@ummakynes
netfilter: nf_tables: incorrect error path handling with NFT_MSG_NEWRULE
b4b1353 
In case of error when adding a new rule that refers to an anonymous set,
deactivate expressions via NFT_TRANS_PREPARE state, not NFT_TRANS_RELEASE.
Thus, the lookup expression marks anonymous sets as inactive in the next
generation to ensure it is not reachable in this transaction anymore and
decrement the set refcount as introduced by c1592a8 ("netfilter:
nf_tables: deactivate anonymous set from preparation phase"). The abort
step takes care of undoing the anonymous set.

This is also consistent with rule deletion, where NFT_TRANS_PREPARE is
used. Note that this error path is exercised in the preparation step of
the commit protocol. This patch replaces nf_tables_rule_release() by the
deactivate and destroy calls, this time with NFT_TRANS_PREPARE.

Due to this incorrect error handling, it is possible to access a
dangling pointer to the anonymous set that remains in the transaction
list.

[1009.379054] BUG: KASAN: use-after-free in nft_set_lookup_global+0x147/0x1a0 [nf_tables]
[1009.379106] Read of size 8 at addr ffff88816c4c8020 by task nft-rule-add/137110
[1009.379116] CPU: 7 PID: 137110 Comm: nft-rule-add Not tainted 6.4.0-rc4+ #256
[1009.379128] Call Trace:
[1009.379132]  <TASK>
[1009.379135]  dump_stack_lvl+0x33/0x50
[1009.379146]  ? nft_set_lookup_global+0x147/0x1a0 [nf_tables]
[1009.379191]  print_address_description.constprop.0+0x27/0x300
[1009.379201]  kasan_report+0x107/0x120
[1009.379210]  ? nft_set_lookup_global+0x147/0x1a0 [nf_tables]
[1009.379255]  nft_set_lookup_global+0x147/0x1a0 [nf_tables]
[1009.379302]  nft_lookup_init+0xa5/0x270 [nf_tables]
[1009.379350]  nf_tables_newrule+0x698/0xe50 [nf_tables]
[1009.379397]  ? nf_tables_rule_release+0xe0/0xe0 [nf_tables]
[1009.379441]  ? kasan_unpoison+0x23/0x50
[1009.379450]  nfnetlink_rcv_batch+0x97c/0xd90 [nfnetlink]
[1009.379470]  ? nfnetlink_rcv_msg+0x480/0x480 [nfnetlink]
[1009.379485]  ? __alloc_skb+0xb8/0x1e0
[1009.379493]  ? __alloc_skb+0xb8/0x1e0
[1009.379502]  ? entry_SYSCALL_64_after_hwframe+0x46/0xb0
[1009.379509]  ? unwind_get_return_address+0x2a/0x40
[1009.379517]  ? write_profile+0xc0/0xc0
[1009.379524]  ? avc_lookup+0x8f/0xc0
[1009.379532]  ? __rcu_read_unlock+0x43/0x60

Fixes: 958bee1 ("netfilter: nf_tables: use new transaction infrastructure to handle sets")
Signed-off-by: Pablo Neira Ayuso <[email protected]>
(cherry picked from commit 1240eb9)
CVE-2023-3390
Signed-off-by: Yuxuan Luo <[email protected]>
Acked-by: Roxana Nicolescu <[email protected]>
Acked-by: Andrei Gherzan <[email protected]>
Signed-off-by: Luke Nowakowski-Krijger <[email protected]>
@axboe
io_uring/poll: serialize poll linked timer start with poll removal
a6d885c 
Commit ef7dfac upstream.

We selectively grab the ctx->uring_lock for poll update/removal, but
we really should grab it from the start to fully synchronize with
linked timeouts. Normally this is indeed the case, but if requests
are forced async by the application, we don't fully cover removal
and timer disarm within the uring_lock.

Make this simpler by having consistent locking state for poll removal.

Cc: [email protected] # 6.1+
Reported-by: Querijn Voet <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

CVE-2023-3389
(cherry picked from commit ecc72019f13da7e2217a0cf0ee805785ab5fa374 linux-6.3.y)
Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
Acked-by: Tim Gardner <[email protected]>
Acked-by: Luke Nowakowski-Krijger <[email protected]>
Signed-off-by: Stefan Bader <[email protected]>
netfilter: nf_tables: do not ignore genmask when looking up chain by id
b3e4c1f 
When adding a rule to a chain referring to its ID, if that chain had been
deleted on the same batch, the rule might end up referring to a deleted
chain.

This will lead to a WARNING like following:

[   33.098431] ------------[ cut here ]------------
[   33.098678] WARNING: CPU: 5 PID: 69 at net/netfilter/nf_tables_api.c:2037 nf_tables_chain_destroy+0x23d/0x260
[   33.099217] Modules linked in:
[   33.099388] CPU: 5 PID: 69 Comm: kworker/5:1 Not tainted 6.4.0+ #409
[   33.099726] Workqueue: events nf_tables_trans_destroy_work
[   33.100018] RIP: 0010:nf_tables_chain_destroy+0x23d/0x260
[   33.100306] Code: 8b 7c 24 68 e8 64 9c ed fe 4c 89 e7 e8 5c 9c ed fe 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 89 c6 89 c7 c3 cc cc cc cc <0f> 0b 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 89 c6 89 c7
[   33.101271] RSP: 0018:ffffc900004ffc48 EFLAGS: 00010202
[   33.101546] RAX: 0000000000000001 RBX: ffff888006fc0a28 RCX: 0000000000000000
[   33.101920] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[   33.102649] RBP: ffffc900004ffc78 R08: 0000000000000000 R09: 0000000000000000
[   33.103018] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8880135ef500
[   33.103385] R13: 0000000000000000 R14: dead000000000122 R15: ffff888006fc0a10
[   33.103762] FS:  0000000000000000(0000) GS:ffff888024c80000(0000) knlGS:0000000000000000
[   33.104184] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   33.104493] CR2: 00007fe863b56a50 CR3: 00000000124b0001 CR4: 0000000000770ee0
[   33.104872] PKRU: 55555554
[   33.104999] Call Trace:
[   33.105113]  <TASK>
[   33.105214]  ? show_regs+0x72/0x90
[   33.105371]  ? __warn+0xa5/0x210
[   33.105520]  ? nf_tables_chain_destroy+0x23d/0x260
[   33.105732]  ? report_bug+0x1f2/0x200
[   33.105902]  ? handle_bug+0x46/0x90
[   33.106546]  ? exc_invalid_op+0x19/0x50
[   33.106762]  ? asm_exc_invalid_op+0x1b/0x20
[   33.106995]  ? nf_tables_chain_destroy+0x23d/0x260
[   33.107249]  ? nf_tables_chain_destroy+0x30/0x260
[   33.107506]  nf_tables_trans_destroy_work+0x669/0x680
[   33.107782]  ? mark_held_locks+0x28/0xa0
[   33.107996]  ? __pfx_nf_tables_trans_destroy_work+0x10/0x10
[   33.108294]  ? _raw_spin_unlock_irq+0x28/0x70
[   33.108538]  process_one_work+0x68c/0xb70
[   33.108755]  ? lock_acquire+0x17f/0x420
[   33.108977]  ? __pfx_process_one_work+0x10/0x10
[   33.109218]  ? do_raw_spin_lock+0x128/0x1d0
[   33.109435]  ? _raw_spin_lock_irq+0x71/0x80
[   33.109634]  worker_thread+0x2bd/0x700
[   33.109817]  ? __pfx_worker_thread+0x10/0x10
[   33.110254]  kthread+0x18b/0x1d0
[   33.110410]  ? __pfx_kthread+0x10/0x10
[   33.110581]  ret_from_fork+0x29/0x50
[   33.110757]  </TASK>
[   33.110866] irq event stamp: 1651
[   33.111017] hardirqs last  enabled at (1659): [<ffffffffa206a209>] __up_console_sem+0x79/0xa0
[   33.111379] hardirqs last disabled at (1666): [<ffffffffa206a1ee>] __up_console_sem+0x5e/0xa0
[   33.111740] softirqs last  enabled at (1616): [<ffffffffa1f5d40e>] __irq_exit_rcu+0x9e/0xe0
[   33.112094] softirqs last disabled at (1367): [<ffffffffa1f5d40e>] __irq_exit_rcu+0x9e/0xe0
[   33.112453] ---[ end trace 0000000000000000 ]---

This is due to the nft_chain_lookup_byid ignoring the genmask. After this
change, adding the new rule will fail as it will not find the chain.

Fixes: 837830a ("netfilter: nf_tables: add NFTA_RULE_CHAIN_ID attribute")
Cc: [email protected]
Reported-by: Mingi Cho of Theori working with ZDI
Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
Reviewed-by: Florian Westphal <[email protected]>
Signed-off-by: Pablo Neira Ayuso <[email protected]>

CVE-2023-31248
(cherry picked from commit 515ad53 linux-next)
Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
Acked-by: Tim Gardner <[email protected]>
Acked-by: Luke Nowakowski-Krijger <[email protected]>
Signed-off-by: Stefan Bader <[email protected]>
netfilter: nf_tables: prevent OOB access in nft_byteorder_eval
3684c40 
When evaluating byteorder expressions with size 2, a union with 32-bit and
16-bit members is used. Since the 16-bit members are aligned to 32-bit,
the array accesses will be out-of-bounds.

It may lead to a stack-out-of-bounds access like the one below:

[   23.095215] ==================================================================
[   23.095625] BUG: KASAN: stack-out-of-bounds in nft_byteorder_eval+0x13c/0x320
[   23.096020] Read of size 2 at addr ffffc90000007948 by task ping/115
[   23.096358]
[   23.096456] CPU: 0 PID: 115 Comm: ping Not tainted 6.4.0+ #413
[   23.096770] Call Trace:
[   23.096910]  <IRQ>
[   23.097030]  dump_stack_lvl+0x60/0xc0
[   23.097218]  print_report+0xcf/0x630
[   23.097388]  ? nft_byteorder_eval+0x13c/0x320
[   23.097577]  ? kasan_addr_to_slab+0xd/0xc0
[   23.097760]  ? nft_byteorder_eval+0x13c/0x320
[   23.097949]  kasan_report+0xc9/0x110
[   23.098106]  ? nft_byteorder_eval+0x13c/0x320
[   23.098298]  __asan_load2+0x83/0xd0
[   23.098453]  nft_byteorder_eval+0x13c/0x320
[   23.098659]  nft_do_chain+0x1c8/0xc50
[   23.098852]  ? __pfx_nft_do_chain+0x10/0x10
[   23.099078]  ? __kasan_check_read+0x11/0x20
[   23.099295]  ? __pfx___lock_acquire+0x10/0x10
[   23.099535]  ? __pfx___lock_acquire+0x10/0x10
[   23.099745]  ? __kasan_check_read+0x11/0x20
[   23.099929]  nft_do_chain_ipv4+0xfe/0x140
[   23.100105]  ? __pfx_nft_do_chain_ipv4+0x10/0x10
[   23.100327]  ? lock_release+0x204/0x400
[   23.100515]  ? nf_hook.constprop.0+0x340/0x550
[   23.100779]  nf_hook_slow+0x6c/0x100
[   23.100977]  ? __pfx_nft_do_chain_ipv4+0x10/0x10
[   23.101223]  nf_hook.constprop.0+0x334/0x550
[   23.101443]  ? __pfx_ip_local_deliver_finish+0x10/0x10
[   23.101677]  ? __pfx_nf_hook.constprop.0+0x10/0x10
[   23.101882]  ? __pfx_ip_rcv_finish+0x10/0x10
[   23.102071]  ? __pfx_ip_local_deliver_finish+0x10/0x10
[   23.102291]  ? rcu_read_lock_held+0x4b/0x70
[   23.102481]  ip_local_deliver+0xbb/0x110
[   23.102665]  ? __pfx_ip_rcv+0x10/0x10
[   23.102839]  ip_rcv+0x199/0x2a0
[   23.102980]  ? __pfx_ip_rcv+0x10/0x10
[   23.103140]  __netif_receive_skb_one_core+0x13e/0x150
[   23.103362]  ? __pfx___netif_receive_skb_one_core+0x10/0x10
[   23.103647]  ? mark_held_locks+0x48/0xa0
[   23.103819]  ? process_backlog+0x36c/0x380
[   23.103999]  __netif_receive_skb+0x23/0xc0
[   23.104179]  process_backlog+0x91/0x380
[   23.104350]  __napi_poll.constprop.0+0x66/0x360
[   23.104589]  ? net_rx_action+0x1cb/0x610
[   23.104811]  net_rx_action+0x33e/0x610
[   23.105024]  ? _raw_spin_unlock+0x23/0x50
[   23.105257]  ? __pfx_net_rx_action+0x10/0x10
[   23.105485]  ? mark_held_locks+0x48/0xa0
[   23.105741]  __do_softirq+0xfa/0x5ab
[   23.105956]  ? __dev_queue_xmit+0x765/0x1c00
[   23.106193]  do_softirq.part.0+0x49/0xc0
[   23.106423]  </IRQ>
[   23.106547]  <TASK>
[   23.106670]  __local_bh_enable_ip+0xf5/0x120
[   23.106903]  __dev_queue_xmit+0x789/0x1c00
[   23.107131]  ? __pfx___dev_queue_xmit+0x10/0x10
[   23.107381]  ? find_held_lock+0x8e/0xb0
[   23.107585]  ? lock_release+0x204/0x400
[   23.107798]  ? neigh_resolve_output+0x185/0x350
[   23.108049]  ? mark_held_locks+0x48/0xa0
[   23.108265]  ? neigh_resolve_output+0x185/0x350
[   23.108514]  neigh_resolve_output+0x246/0x350
[   23.108753]  ? neigh_resolve_output+0x246/0x350
[   23.109003]  ip_finish_output2+0x3c3/0x10b0
[   23.109250]  ? __pfx_ip_finish_output2+0x10/0x10
[   23.109510]  ? __pfx_nf_hook+0x10/0x10
[   23.109732]  __ip_finish_output+0x217/0x390
[   23.109978]  ip_finish_output+0x2f/0x130
[   23.110207]  ip_output+0xc9/0x170
[   23.110404]  ip_push_pending_frames+0x1a0/0x240
[   23.110652]  raw_sendmsg+0x102e/0x19e0
[   23.110871]  ? __pfx_raw_sendmsg+0x10/0x10
[   23.111093]  ? lock_release+0x204/0x400
[   23.111304]  ? __mod_lruvec_page_state+0x148/0x330
[   23.111567]  ? find_held_lock+0x8e/0xb0
[   23.111777]  ? find_held_lock+0x8e/0xb0
[   23.111993]  ? __rcu_read_unlock+0x7c/0x2f0
[   23.112225]  ? aa_sk_perm+0x18a/0x550
[   23.112431]  ? filemap_map_pages+0x4f1/0x900
[   23.112665]  ? __pfx_aa_sk_perm+0x10/0x10
[   23.112880]  ? find_held_lock+0x8e/0xb0
[   23.113098]  inet_sendmsg+0xa0/0xb0
[   23.113297]  ? inet_sendmsg+0xa0/0xb0
[   23.113500]  ? __pfx_inet_sendmsg+0x10/0x10
[   23.113727]  sock_sendmsg+0xf4/0x100
[   23.113924]  ? move_addr_to_kernel.part.0+0x4f/0xa0
[   23.114190]  __sys_sendto+0x1d4/0x290
[   23.114391]  ? __pfx___sys_sendto+0x10/0x10
[   23.114621]  ? __pfx_mark_lock.part.0+0x10/0x10
[   23.114869]  ? lock_release+0x204/0x400
[   23.115076]  ? find_held_lock+0x8e/0xb0
[   23.115287]  ? rcu_is_watching+0x23/0x60
[   23.115503]  ? __rseq_handle_notify_resume+0x6e2/0x860
[   23.115778]  ? __kasan_check_write+0x14/0x30
[   23.116008]  ? blkcg_maybe_throttle_current+0x8d/0x770
[   23.116285]  ? mark_held_locks+0x28/0xa0
[   23.116503]  ? do_syscall_64+0x37/0x90
[   23.116713]  __x64_sys_sendto+0x7f/0xb0
[   23.116924]  do_syscall_64+0x59/0x90
[   23.117123]  ? irqentry_exit_to_user_mode+0x25/0x30
[   23.117387]  ? irqentry_exit+0x77/0xb0
[   23.117593]  ? exc_page_fault+0x92/0x140
[   23.117806]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
[   23.118081] RIP: 0033:0x7f744aee2bba
[   23.118282] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89
[   23.119237] RSP: 002b:00007ffd04a7c9f8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
[   23.119644] RAX: ffffffffffffffda RBX: 00007ffd04a7e0a0 RCX: 00007f744aee2bba
[   23.120023] RDX: 0000000000000040 RSI: 000056488e9e6300 RDI: 0000000000000003
[   23.120413] RBP: 000056488e9e6300 R08: 00007ffd04a80320 R09: 0000000000000010
[   23.120809] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000040
[   23.121219] R13: 00007ffd04a7dc38 R14: 00007ffd04a7ca00 R15: 00007ffd04a7e0a0
[   23.121617]  </TASK>
[   23.121749]
[   23.121845] The buggy address belongs to the virtual mapping at
[   23.121845]  [ffffc90000000000, ffffc90000009000) created by:
[   23.121845]  irq_init_percpu_irqstack+0x1cf/0x270
[   23.122707]
[   23.122803] The buggy address belongs to the physical page:
[   23.123104] page:0000000072ac19f0 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x24a09
[   23.123609] flags: 0xfffffc0001000(reserved|node=0|zone=1|lastcpupid=0x1fffff)
[   23.123998] page_type: 0xffffffff()
[   23.124194] raw: 000fffffc0001000 ffffea0000928248 ffffea0000928248 0000000000000000
[   23.124610] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
[   23.125023] page dumped because: kasan: bad access detected
[   23.125326]
[   23.125421] Memory state around the buggy address:
[   23.125682]  ffffc90000007800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   23.126072]  ffffc90000007880: 00 00 00 00 00 f1 f1 f1 f1 f1 f1 00 00 f2 f2 00
[   23.126455] >ffffc90000007900: 00 00 00 00 00 00 00 00 00 f2 f2 f2 f2 00 00 00
[   23.126840]                                               ^
[   23.127138]  ffffc90000007980: 00 00 00 00 00 00 00 00 00 00 00 00 00 f3 f3 f3
[   23.127522]  ffffc90000007a00: f3 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
[   23.127906] ==================================================================
[   23.128324] Disabling lock debugging due to kernel taint

Using simple s16 pointers for the 16-bit accesses fixes the problem. For
the 32-bit accesses, src and dst can be used directly.

Fixes: 9651851 ("netfilter: add nftables")
Cc: [email protected]
Reported-by: Tanguy DUBROCA (@SidewayRE) from @synacktiv working with ZDI
Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
Reviewed-by: Florian Westphal <[email protected]>
Signed-off-by: Pablo Neira Ayuso <[email protected]>

CVE-2023-35001
(cherry picked from commit caf3ef7 linux-next)
Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
Acked-by: Tim Gardner <[email protected]>
Acked-by: Luke Nowakowski-Krijger <[email protected]>
Signed-off-by: Stefan Bader <[email protected]>
Revert "UBUNTU: SAUCE: overlayfs: handle idmapped mounts in ovl_do_(s…
74e9631 
…et|remove)xattr"

This reverts commit 520b471.

This is needed in order to revert "UBUNTU: SAUCE: overlayfs: Skip permission
checking for trusted.overlayfs.* xattrs".

CVE-2023-2640
CVE-2023-32629
Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
Acked-by: Stefan Bader <[email protected]>
Acked-by: Roxana Nicolescu <[email protected]>
Acked-by: Andrei Gherzan <[email protected]>
Signed-off-by: Roxana Nicolescu <[email protected]>
Revert "UBUNTU: SAUCE: overlayfs: Skip permission checking for truste…
82ccf6e 
…d.overlayfs.* xattrs"

This reverts commit 2c7ab14.

Commit "UBUNTU: SAUCE: overlayfs: Skip permission checking for
trusted.overlayfs.* xattrs" replaced the VFS calls to change xattrs to
their _noperm equivalents.

However, since upstream commit c914c0e ("ovl: use wrappers to all
vfs_*xattr() calls"), overlayfs started using the changed wrapper function
to set any extended attributes.

This means that overlayfs skips checking permissions for any extended
attribute changes, not only trusted.overlayfs.* xattrs, as was intended by
the sauce commit above.

Fixes: c914c0e ("ovl: use wrappers to all vfs_*xattr() calls")
CVE-2023-2640
CVE-2023-32629
Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
Acked-by: Stefan Bader <[email protected]>
Acked-by: Roxana Nicolescu <[email protected]>
Acked-by: Andrei Gherzan <[email protected]>
Signed-off-by: Roxana Nicolescu <[email protected]>
UBUNTU: SAUCE: overlayfs: default to userxattr when mounted from non …
a3adfc5 
…initial user namespace

Also add a nouserxattr for the cases where it is desirable to mount without
userxattr under such namespaces.

This allows cases where such xattrs are necessary for certain operations to
work out, instead of failing due to not being able to use the
trusted.overlay.* xattrs.

CVE-2023-2640
CVE-2023-32629
LP: #1531747
Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
Acked-by: Stefan Bader <[email protected]>
Acked-by: Roxana Nicolescu <[email protected]>
Acked-by: Andrei Gherzan <[email protected]>
Signed-off-by: Roxana Nicolescu <[email protected]>
UBUNTU: Start new release
95e258e 
Ignore: yes
Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
UBUNTU: link-to-tracker: update tracking bug
91e7a05 
BugLink: https://bugs.launchpad.net/bugs/2026753
Properties: no-test-build
Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
UBUNTU: Ubuntu-6.2.0-26.26
112efaa 
Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
@smb49
UBUNTU: [Packaging] initialize linux-hwe-6.2
f6e8b32 
Signed-off-by: Andrea Righi <[email protected]>
@smb49
UBUNTU: [Packaging] update variants
4eeceb2 
BugLink: https://bugs.launchpad.net/bugs/1786013
Signed-off-by: Andrea Righi <[email protected]>
@smb49
UBUNTU: [Packaging] update update.conf
73cab9e 
BugLink: https://bugs.launchpad.net/bugs/1786013
Signed-off-by: Andrea Righi <[email protected]>
@smb49
UBUNTU: [Packaging] import and update copy-files and local-mangle
329bb97 
With the new annotations schema we don't need to adjust annotations via
local-mangle anymore. Same about copying configs via copy-files.

Signed-off-by: Andrea Righi <[email protected]>
@smb49
UBUNTU: [Config] import annotations from master
df4c0d4 
Include debian.master/config/annotations and run updateconfigs.

Signed-off-by: Andrea Righi <[email protected]>
@smb49
UBUNTU: Start new release
0e7a9aa 
Ignore: yes
Signed-off-by: Andrea Righi <[email protected]>
ianmay81 and others added 23 commits August 4, 2023 22:54
@ianmay81
UBUNTU: link-to-tracker: update tracking bug
0dbd431 
BugLink: https://bugs.launchpad.net/bugs/2028017
Properties: no-test-build
Signed-off-by: Ian May <[email protected]>
@ianmay81
UBUNTU: Ubuntu-nvidia-6.2-6.2.0-1006.6~22.04.2
e47e4bb 
Signed-off-by: Ian May <[email protected]>
@sourabgupta3 @ianmay81
NVIDIA: SAUCE: Add NVMe Patches to enable GDS
8805fa9 
BugLink: https://bugs.launchpad.net/bugs/1982519

With this change, the NVMe driver would be
enabled to support GPUDirectStorage(GDS).
The change is around nvme/nvme rdma map_data()
and unmap_data(), where the IO request is
first intercepted to check for GDS pages and
if it is a GDS page then the request is served
by GDS driver component called nvidia-fs,
else the request would be served by the standard NVMe driver code.

Acked-by: Rebanta Mitra <[email protected]>
Acked-by: Prashant Prabhu <[email protected]>
Signed-off-by: Sourab Gupta <[email protected]>
Acked-by: Brad Figg <[email protected]>
Acked-by: Ian May <[email protected]>
Acked-by: Jacob Martin <[email protected]>
Signed-off-by: Brad Figg <[email protected]>
@ianmay81
UBUNTU: [Packaging] resync update-dkms-versions helper
4a56f18 
BugLink: https://bugs.launchpad.net/bugs/1786013
Signed-off-by: Ian May <[email protected]>
@ianmay81
UBUNTU: [Packaging] update variants
9e4cf2a 
BugLink: https://bugs.launchpad.net/bugs/1786013
Signed-off-by: Ian May <[email protected]>
@ianmay81
UBUNTU: [Packaging] resync getabis
cc4e2f1 
BugLink: https://bugs.launchpad.net/bugs/1786013
Signed-off-by: Ian May <[email protected]>
@ianmay81
UBUNTU: [Packaging] update update.conf
39ce4b7 
BugLink: https://bugs.launchpad.net/bugs/1786013
Signed-off-by: Ian May <[email protected]>
@ianmay81
UBUNTU: Start new release
8e4d794 
Ignore: yes
Signed-off-by: Ian May <[email protected]>
@ianmay81
UBUNTU: [Config] nvidia-6.2: update annotations
d9c90a9 
Signed-off-by: Ian May <[email protected]>
@ianmay81
NVIDIA: [Config] Overriding CONFIG_PREEMPT_NONE, CONFIG_CPU_FREQ_DEFA…
4a1033c 
…ULT_GOV_PERFORMANCE and CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND for NVIDIA workloads

Signed-off-by: Brad Figg <[email protected]>
Acked-by: Ian May <[email protected]>
Acked-by: Jacob Martin <[email protected]>
Signed-off-by: Ian May <[email protected]>
@sourabgupta3 @ianmay81
NVIDIA: SAUCE: NFS: Patch NFS driver to support GDS with 6.2 Kernel
0be9aa4 
BugLink: https://bugs.launchpad.net/bugs/1982519

With this change, the NFS driver would be enabled to
support GPUDirectStorage(GDS). The change is around
frwr_map and frwr_unmap in the NFS driver, where the
IO request is first intercepted to check for GDS pages and
if it is a GDS page then the request is served by GDS driver
component called nvidia-fs, else the request would be served
by the standard NFS driver code.

Acked-by: Prashant Prabhu <[email protected]>
Acked-by: Rebanta Mitra <[email protected]>
Signed-off-by: Sourab Gupta <[email protected]>
Acked-by: Brad Figg <[email protected]>
Acked-by: Ian May <[email protected]>
Acked-by: Jacob Martin <[email protected]>
Signed-off-by: Ian May <[email protected]>
@ianmay81
UBUNTU: link-to-tracker: update tracking bug
41fd5df 
BugLink: https://bugs.launchpad.net/bugs/2029878
Properties: no-test-build
Signed-off-by: Ian May <[email protected]>
@ianmay81
UBUNTU: debian/dkms-versions -- update from kernel-versions (main/d20…
bc90b12 
…23.07.17)

BugLink: https://bugs.launchpad.net/bugs/1786013
Signed-off-by: Ian May <[email protected]>
@ianmay81
UBUNTU: debian/dkms-versions -- add nvidia-fs and mstflint
3caa68b 
Signed-off-by: Ian May <[email protected]>
@ianmay81
UBUNTU: [Packaging] add nvidia build depends for nvidia-fs-dkms
fe1cc4b 
Signed-off-by: Ian May <[email protected]>
@ianmay81
UBUNTU: Ubuntu-nvidia-6.2-6.2.0-1007.7
af6a500 
Signed-off-by: Ian May <[email protected]>
@ianmay81
UBUNTU: Start new release
7fbcab8 
Ignore: yes
Signed-off-by: Ian May <[email protected]>
@ianmay81
UBUNTU: [Packaging] nvidia-6.2: remove nvidia-fs module
358bc2e 
There is a compile error with the current nvidia-fs package.
Removing module inclusion until resolved.

Signed-off-by: Ian May <[email protected]>
@ianmay81
UBUNTU: link-to-tracker: update tracking bug
2e959e1 
BugLink: https://bugs.launchpad.net/bugs/2029878
Properties: no-test-build
Signed-off-by: Ian May <[email protected]>
@ianmay81
UBUNTU: Ubuntu-nvidia-6.2-6.2.0-1008.8
f1bcf84 
Signed-off-by: Ian May <[email protected]>
@nvidia-bfigg
NVIDIA: [Config] CONFIG_NR_CPUS=512 for Grace
bb01e78 
Signed-off-by: Brad Figg <[email protected]>
@nvidia-bfigg
NVIDIA: [Config] CONFIG_MTD_SPI_NOR=y for Grace
bf650bd 
Signed-off-by: Brad Figg <[email protected]>
@nicolinc @jamieNguyenNVIDIA
NVIDIA: SAUCE: iommu/arm-smmu-v3: Allow default substream bypass with…
5773b77 
… a pasid support

When an iommu_domain is set to IOMMU_DOMAIN_IDENTITY, the driver would
skip the allocation of a CD table and set the CONFIG field of the STE
to STRTAB_STE_0_CFG_BYPASS. This works well for devices that only have
one substream, i.e. PASID disabled.

However, there could be a use case, for a pasid capable device, that
allows bypassing the translation at the default substream while still
enabling the pasid feature, which means the driver should not skip the
allocation of a CD table nor simply bypass the CONFIG field. Instead,
the S1DSS field should be set to STRTAB_STE_1_S1DSS_BYPASS and the
SHCFG field should be set to STRTAB_STE_1_SHCFG_INCOMING.

Add s1dss in struct arm_smmu_s1_cfg, to allow a configuration in the
finalise() to support this use case.

Also, according to "13.5 Summary of attribute/permission configuration
fields" in the reference manual, the SHCFG field value is irrelevant.
So, set the SHCFG field of the STE always to STRTAB_STE_1_SHCFG_INCOMING
for simplification.

Signed-off-by: Nicolin Chen <[email protected]>
Reviewed-by: Pritesh Raithatha <[email protected]>
Acked-by: Jamie Nguyen <[email protected]>
Acked-by: Nicolin Chen <[email protected]>
nvidia-bfigg pushed a commit that referenced this pull request Aug 29, 2023
@tamird @smb49
ACPICA: Avoid undefined behavior: applying zero offset to null pointer
c07bb11 
BugLink: https://bugs.launchpad.net/bugs/2028808

[ Upstream commit 05bb016 ]

ACPICA commit 770653e3ba67c30a629ca7d12e352d83c2541b1e

Before this change we see the following UBSAN stack trace in Fuchsia:

  #0    0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302
  #1.2  0x000020d0f660777f in ubsan_get_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:41 <libclang_rt.asan.so>+0x3d77f
  #1.1  0x000020d0f660777f in maybe_print_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:51 <libclang_rt.asan.so>+0x3d77f
  #1    0x000020d0f660777f in ~scoped_report() compiler-rt/lib/ubsan/ubsan_diag.cpp:387 <libclang_rt.asan.so>+0x3d77f
  #2    0x000020d0f660b96d in handlepointer_overflow_impl() compiler-rt/lib/ubsan/ubsan_handlers.cpp:809 <libclang_rt.asan.so>+0x4196d
  #3    0x000020d0f660b50d in compiler-rt/lib/ubsan/ubsan_handlers.cpp:815 <libclang_rt.asan.so>+0x4150d
  #4    0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302
  #5    0x000021e4213e2369 in acpi_ds_call_control_method(struct acpi_thread_state*, struct acpi_walk_state*, union acpi_parse_object*) ../../third_party/acpica/source/components/dispatcher/dsmethod.c:605 <platform-bus-x86.so>+0x262369
  #6    0x000021e421437fac in acpi_ps_parse_aml(struct acpi_walk_state*) ../../third_party/acpica/source/components/parser/psparse.c:550 <platform-bus-x86.so>+0x2b7fac
  #7    0x000021e4214464d2 in acpi_ps_execute_method(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/parser/psxface.c:244 <platform-bus-x86.so>+0x2c64d2
  #8    0x000021e4213aa052 in acpi_ns_evaluate(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/namespace/nseval.c:250 <platform-bus-x86.so>+0x22a052
  #9    0x000021e421413dd8 in acpi_ns_init_one_device(acpi_handle, u32, void*, void**) ../../third_party/acpica/source/components/namespace/nsinit.c:735 <platform-bus-x86.so>+0x293dd8
  #10   0x000021e421429e98 in acpi_ns_walk_namespace(acpi_object_type, acpi_handle, u32, u32, acpi_walk_callback, acpi_walk_callback, void*, void**) ../../third_party/acpica/source/components/namespace/nswalk.c:298 <platform-bus-x86.so>+0x2a9e98
  #11   0x000021e4214131ac in acpi_ns_initialize_devices(u32) ../../third_party/acpica/source/components/namespace/nsinit.c:268 <platform-bus-x86.so>+0x2931ac
  #12   0x000021e42147c40d in acpi_initialize_objects(u32) ../../third_party/acpica/source/components/utilities/utxfinit.c:304 <platform-bus-x86.so>+0x2fc40d
  #13   0x000021e42126d603 in acpi::acpi_impl::initialize_acpi(acpi::acpi_impl*) ../../src/devices/board/lib/acpi/acpi-impl.cc:224 <platform-bus-x86.so>+0xed603

Add a simple check that avoids incrementing a pointer by zero, but
otherwise behaves as before. Note that our findings are against ACPICA
20221020, but the same code exists on master.

Link: acpica/acpica@770653e3
Signed-off-by: Bob Moore <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
Signed-off-by: Stefan Bader <[email protected]>
nvidia-bfigg pushed a commit that referenced this pull request Aug 29, 2023
@sudeep-holla @smb49
firmware: arm_ffa: Fix FFA device names for logical partitions
536c203 
BugLink: https://bugs.launchpad.net/bugs/2028979

commit 19b8766 upstream.

Each physical partition can provide multiple services each with UUID.
Each such service can be presented as logical partition with a unique
combination of VM ID and UUID. The number of distinct UUID in a system
will be less than or equal to the number of logical partitions.

However, currently it fails to register more than one logical partition
or service within a physical partition as the device name contains only
VM ID while both VM ID and UUID are maintained in the partition information.
The kernel complains with the below message:

  | sysfs: cannot create duplicate filename '/devices/arm-ffa-8001'
  | CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.3.0-rc7 #8
  | Hardware name: FVP Base RevC (DT)
  | Call trace:
  |  dump_backtrace+0xf8/0x118
  |  show_stack+0x18/0x24
  |  dump_stack_lvl+0x50/0x68
  |  dump_stack+0x18/0x24
  |  sysfs_create_dir_ns+0xe0/0x13c
  |  kobject_add_internal+0x220/0x3d4
  |  kobject_add+0x94/0x100
  |  device_add+0x144/0x5d8
  |  device_register+0x20/0x30
  |  ffa_device_register+0x88/0xd8
  |  ffa_setup_partitions+0x108/0x1b8
  |  ffa_init+0x2ec/0x3a4
  |  do_one_initcall+0xcc/0x240
  |  do_initcall_level+0x8c/0xac
  |  do_initcalls+0x54/0x94
  |  do_basic_setup+0x1c/0x28
  |  kernel_init_freeable+0x100/0x16c
  |  kernel_init+0x20/0x1a0
  |  ret_from_fork+0x10/0x20
  | kobject_add_internal failed for arm-ffa-8001 with -EEXIST, don't try to
  | register things with the same name in the same directory.
  | arm_ffa arm-ffa: unable to register device arm-ffa-8001 err=-17
  | ARM FF-A: ffa_setup_partitions: failed to register partition ID 0x8001

By virtue of being random enough to avoid collisions when generated in a
distributed system, there is no way to compress UUID keys to the number
of bits required to identify each. We can eliminate '-' in the name but
it is not worth eliminating 4 bytes and add unnecessary logic for doing
that. Also v1.0 doesn't provide the UUID of the partitions which makes
it hard to use the same for the device name.

So to keep it simple, let us alloc an ID using ida_alloc() and append the
same to "arm-ffa" to make up a unique device name. Also stash the id value
in ffa_dev to help freeing the ID later when the device is destroyed.

Fixes: e781858 ("firmware: arm_ffa: Add initial FFA bus support for device enumeration")
Reported-by: Lucian Paul-Trifu <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sudeep Holla <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
Signed-off-by: Stefan Bader <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.