Affected: Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts

In the Linux kernel, the following vulnerability has been resolved:

net: switchdev: Convert blocking notification chain to a raw one

A blocking notification chain uses a read-write semaphore to protect the integrity of the chain. The semaphore is acquired for writing when adding / removing notifiers to / from the chain and acquired for reading when traversing the chain and informing notifiers about an event.

In case of the blocking switchdev notification chain, recursive notifications are possible which leads to the semaphore being acquired twice for reading and to lockdep warnings being generated [1].

Specifically, this can happen when the bridge driver processes a SWITCHDEV_BRPORT_UNOFFLOADED event which causes it to emit notifications about deferred events when calling switchdev_deferred_process().

Fix this by converting the notification chain to a raw notification chain in a similar fashion to the netdev notification chain. Protect the chain using the RTNL mutex by acquiring it when modifying the chain. Events are always informed under the RTNL mutex, but add an assertion in call_switchdev_blocking_notifiers() to make sure this is not violated in the future.

Maintain the "blocking" prefix as events are always emitted from process context and listeners are allowed to block.

[1]: WARNING: possible recursive locking detected 6.14.0-rc4-custom-g079270089484 #1 Not tainted -------------------------------------------- ip/52731 is trying to acquire lock: ffffffff850918d8…

In the Linux kernel, the following vulnerability has been resolved:

net: switchdev: Convert blocking notification chain to a raw one

A blocking notification chain uses a read-write semaphore to protect the integrity of the chain. The semaphore is acquired for writing when adding / removing notifiers to / from the chain and acquired for reading when traversing the chain and informing notifiers about an event.

In case of the blocking switchdev notification chain, recursive notifications are possible which leads to the semaphore being acquired twice for reading and to lockdep warnings being generated [1].

Specifically, this can happen when the bridge driver processes a SWITCHDEV_BRPORT_UNOFFLOADED event which causes it to emit notifications about deferred events when calling switchdev_deferred_process().

Fix this by converting the notification chain to a raw notification chain in a similar fashion to the netdev notification chain. Protect the chain using the RTNL mutex by acquiring it when modifying the chain. Events are always informed under the RTNL mutex, but add an assertion in call_switchdev_blocking_notifiers() to make sure this is not violated in the future.

Maintain the "blocking" prefix as events are always emitted from process context and listeners are allowed to block.

[1]: WARNING: possible recursive locking detected 6.14.0-rc4-custom-g079270089484 #1 Not tainted -------------------------------------------- ip/52731 is trying to acquire lock: ffffffff850918d8…

Affected: openEuler:24.03-LTS: kernel

The Linux Kernel, the operating system core itself. Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MMWe currently assume that there is at least one VMA in a MM, which isn ttrue.So we might end up having find_vma() return NULL, to then de-referenceNULL. So properly handle find_vma() returning NULL.This fixes the report:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 1 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024RIP: 0010:migrate_to_node mm/mempolicy.c:1090 [inline]RIP: 0010:do_migrate_pages+0x403/0x6f0 mm/mempolicy.c:1194Code: ...RSP: 0018:ffffc9000375fd08 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000RDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044RBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1R10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003R13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8FS: 00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0DR0…

Affected: Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 202 more

In the Linux kernel, the following vulnerability has been resolved: net: switchdev: Convert blocking notification chain to a raw one A blocking notification chain uses a read-write semaphore to protect the integrity of the chain. The semaphore is acquired for writing when adding / removing notifiers to / from the chain and acquired for reading when traversing the chain and informing notifiers about an event. In case of the blocking switchdev notification chain, recursive notifications are possible which leads to the semaphore being acquired twice for reading and to lockdep warnings being generated [1]. Specifically, this can happen when the bridge driver processes a SWITCHDEV_BRPORT_UNOFFLOADED event which causes it to emit notifications about deferred events when calling switchdev_deferred_process(). Fix this by converting the notification chain to a raw notification chain in a similar fashion to the netdev notification chain. Protect the chain using the RTNL mutex by acquiring it when modifying the chain. Events are always informed under the RTNL mutex, but add an assertion in call_switchdev_blocking_notifiers() to make sure this is not violated in the future. Maintain the "blocking" prefix as events are always emitted from process context and listeners are allowed to block. [1]: WARNING: possible recursive locking detected 6.14.0-rc4-custom-g079270089484 #1 Not tainted -------------------------------------------- ip/52731 is trying to acquire lock: ffffffff850918d8 ((swit…

Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial-of-Service auszulösen und um nicht näher spezifizierte Auswirkungen zu erzielen.