Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths<br /> <br /> Any codepath that zaps page table entries must invoke MMU notifiers to<br /> ensure that secondary MMUs (like KVM) don&amp;#39;t keep accessing pages which<br /> aren&amp;#39;t mapped anymore. Secondary MMUs don&amp;#39;t hold their own references to<br /> pages that are mirrored over, so failing to notify them can lead to page<br /> use-after-free.<br /> <br /> I&amp;#39;m marking this as addressing an issue introduced in commit f3f0e1d2150b<br /> ("khugepaged: add support of collapse for tmpfs/shmem pages"), but most of<br /> the security impact of this only came in commit 27e1f8273113 ("khugepaged:<br /> enable collapse pmd for pte-mapped THP"), which actually omitted flushes<br /> for the removal of present PTEs, not just for the removal of empty page<br /> tables.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: soc-pcm: Add NULL check in BE reparenting<br /> <br /> Add NULL check in dpcm_be_reparent API, to handle<br /> kernel NULL pointer dereference error.<br /> The issue occurred in fuzzing test.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: seq: Fix function prototype mismatch in snd_seq_expand_var_event<br /> <br /> With clang&amp;#39;s kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),<br /> indirect call targets are validated against the expected function<br /> pointer prototype to make sure the call target is valid to help mitigate<br /> ROP attacks. If they are not identical, there is a failure at run time,<br /> which manifests as either a kernel panic or thread getting killed.<br /> <br /> seq_copy_in_user() and seq_copy_in_kernel() did not have prototypes<br /> matching snd_seq_dump_func_t. Adjust this and remove the casts. There<br /> are not resulting binary output differences.<br /> <br /> This was found as a result of Clang&amp;#39;s new -Wcast-function-type-strict<br /> flag, which is more sensitive than the simpler -Wcast-function-type,<br /> which only checks for type width mismatches.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: raydium_ts_i2c - fix memory leak in raydium_i2c_send()<br /> <br /> There is a kmemleak when test the raydium_i2c_ts with bpf mock device:<br /> <br /> unreferenced object 0xffff88812d3675a0 (size 8):<br /> comm "python3", pid 349, jiffies 4294741067 (age 95.695s)<br /> hex dump (first 8 bytes):<br /> 11 0e 10 c0 01 00 04 00 ........<br /> backtrace:<br /> [] __kmalloc+0x46/0x1b0<br /> [] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts]<br /> [] raydium_i2c_initialize.cold+0xbc/0x3e4 [raydium_i2c_ts]<br /> [] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts]<br /> [] i2c_device_probe+0x651/0x680<br /> [] really_probe+0x17c/0x3f0<br /> [] __driver_probe_device+0xe3/0x170<br /> [] driver_probe_device+0x49/0x120<br /> [] __device_attach_driver+0xf7/0x150<br /> [] bus_for_each_drv+0x114/0x180<br /> [] __device_attach+0x1e5/0x2d0<br /> [] bus_probe_device+0x126/0x140<br /> [] device_add+0x810/0x1130<br /> [] i2c_new_client_device+0x352/0x4e0<br /> [] of_i2c_register_device+0xf1/0x110<br /> [] of_i2c_notify+0x100/0x160<br /> unreferenced object 0xffff88812d3675c8 (size 8):<br /> comm "python3", pid 349, jiffies 4294741070 (age 95.692s)<br /> hex dump (first 8 bytes):<br /> 22 00 36 2d 81 88 ff ff ".6-....<br /> backtrace:<br /> [] __kmalloc+0x46/0x1b0<br /> [] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts]<br /> [] raydium_i2c_initialize.cold+0x223/0x3e4 [raydium_i2c_ts]<br /> [] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts]<br /> [] i2c_device_probe+0x651/0x680<br /> [] really_probe+0x17c/0x3f0<br /> [] __driver_probe_device+0xe3/0x170<br /> [] driver_probe_device+0x49/0x120<br /> [] __device_attach_driver+0xf7/0x150<br /> [] bus_for_each_drv+0x114/0x180<br /> [] __device_attach+0x1e5/0x2d0<br /> [] bus_probe_device+0x126/0x140<br /> [] device_add+0x810/0x1130<br /> [] i2c_new_client_device+0x352/0x4e0<br /> [] of_i2c_register_device+0xf1/0x110<br /> [] of_i2c_notify+0x100/0x160<br /> <br /> After BANK_SWITCH command from i2c BUS, no matter success or error<br /> happened, the tx_buf should be freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/sysfs: fix wrong empty schemes assumption under online tuning in damon_sysfs_set_schemes()<br /> <br /> Commit da87878010e5 ("mm/damon/sysfs: support online inputs update") made<br /> &amp;#39;damon_sysfs_set_schemes()&amp;#39; to be called for running DAMON context, which<br /> could have schemes. In the case, DAMON sysfs interface is supposed to<br /> update, remove, or add schemes to reflect the sysfs files. However, the<br /> code is assuming the DAMON context wouldn&amp;#39;t have schemes at all, and<br /> therefore creates and adds new schemes. As a result, the code doesn&amp;#39;t<br /> work as intended for online schemes tuning and could have more than<br /> expected memory footprint. The schemes are all in the DAMON context, so<br /> it doesn&amp;#39;t leak the memory, though.<br /> <br /> Remove the wrong asssumption (the DAMON context wouldn&amp;#39;t have schemes) in<br /> &amp;#39;damon_sysfs_set_schemes()&amp;#39; to fix the bug.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> char: tpm: Protect tpm_pm_suspend with locks<br /> <br /> Currently tpm transactions are executed unconditionally in<br /> tpm_pm_suspend() function, which may lead to races with other tpm<br /> accessors in the system.<br /> <br /> Specifically, the hw_random tpm driver makes use of tpm_get_random(),<br /> and this function is called in a loop from a kthread, which means it&amp;#39;s<br /> not frozen alongside userspace, and so can race with the work done<br /> during system suspend:<br /> <br /> tpm tpm0: tpm_transmit: tpm_recv: error -52<br /> tpm tpm0: invalid TPM_STS.x 0xff, dumping stack for forensics<br /> CPU: 0 PID: 1 Comm: init Not tainted 6.1.0-rc5+ #135<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014<br /> Call Trace:<br /> tpm_tis_status.cold+0x19/0x20<br /> tpm_transmit+0x13b/0x390<br /> tpm_transmit_cmd+0x20/0x80<br /> tpm1_pm_suspend+0xa6/0x110<br /> tpm_pm_suspend+0x53/0x80<br /> __pnp_bus_suspend+0x35/0xe0<br /> __device_suspend+0x10f/0x350<br /> <br /> Fix this by calling tpm_try_get_ops(), which itself is a wrapper around<br /> tpm_chip_start(), but takes the appropriate mutex.<br /> <br /> [Jason: reworked commit message, added metadata]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/bpf/32: Fix Oops on tail call tests<br /> <br /> test_bpf tail call tests end up as:<br /> <br /> test_bpf: #0 Tail call leaf jited:1 85 PASS<br /> test_bpf: #1 Tail call 2 jited:1 111 PASS<br /> test_bpf: #2 Tail call 3 jited:1 145 PASS<br /> test_bpf: #3 Tail call 4 jited:1 170 PASS<br /> test_bpf: #4 Tail call load/store leaf jited:1 190 PASS<br /> test_bpf: #5 Tail call load/store jited:1<br /> BUG: Unable to handle kernel data access on write at 0xf1b4e000<br /> Faulting instruction address: 0xbe86b710<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> BE PAGE_SIZE=4K MMU=Hash PowerMac<br /> Modules linked in: test_bpf(+)<br /> CPU: 0 PID: 97 Comm: insmod Not tainted 6.1.0-rc4+ #195<br /> Hardware name: PowerMac3,1 750CL 0x87210 PowerMac<br /> NIP: be86b710 LR: be857e88 CTR: be86b704<br /> REGS: f1b4df20 TRAP: 0300 Not tainted (6.1.0-rc4+)<br /> MSR: 00009032 CR: 28008242 XER: 00000000<br /> DAR: f1b4e000 DSISR: 42000000<br /> GPR00: 00000001 f1b4dfe0 c11d2280 00000000 00000000 00000000 00000002 00000000<br /> GPR08: f1b4e000 be86b704 f1b4e000 00000000 00000000 100d816a f2440000 fe73baa8<br /> GPR16: f2458000 00000000 c1941ae4 f1fe2248 00000045 c0de0000 f2458030 00000000<br /> GPR24: 000003e8 0000000f f2458000 f1b4dc90 3e584b46 00000000 f24466a0 c1941a00<br /> NIP [be86b710] 0xbe86b710<br /> LR [be857e88] __run_one+0xec/0x264 [test_bpf]<br /> Call Trace:<br /> [f1b4dfe0] [00000002] 0x2 (unreliable)<br /> Instruction dump:<br /> XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX<br /> XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> This is a tentative to write above the stack. The problem is encoutered<br /> with tests added by commit 38608ee7b690 ("bpf, tests: Add load store<br /> test case for tail call")<br /> <br /> This happens because tail call is done to a BPF prog with a different<br /> stack_depth. At the time being, the stack is kept as is when the caller<br /> tail calls its callee. But at exit, the callee restores the stack based<br /> on its own properties. Therefore here, at each run, r1 is erroneously<br /> increased by 32 - 16 = 16 bytes.<br /> <br /> This was done that way in order to pass the tail call count from caller<br /> to callee through the stack. As powerpc32 doesn&amp;#39;t have a red zone in<br /> the stack, it was necessary the maintain the stack as is for the tail<br /> call. But it was not anticipated that the BPF frame size could be<br /> different.<br /> <br /> Let&amp;#39;s take a new approach. Use register r4 to carry the tail call count<br /> during the tail call, and save it into the stack at function entry if<br /> required. This means the input parameter must be in r3, which is more<br /> correct as it is a 32 bits parameter, then tail call better match with<br /> normal BPF function entry, the down side being that we move that input<br /> parameter back and forth between r3 and r4. That can be optimised later.<br /> <br /> Doing that also has the advantage of maximising the common parts between<br /> tail calls and a normal function exit.<br /> <br /> With the fix, tail call tests are now successfull:<br /> <br /> test_bpf: #0 Tail call leaf jited:1 53 PASS<br /> test_bpf: #1 Tail call 2 jited:1 115 PASS<br /> test_bpf: #2 Tail call 3 jited:1 154 PASS<br /> test_bpf: #3 Tail call 4 jited:1 165 PASS<br /> test_bpf: #4 Tail call load/store leaf jited:1 101 PASS<br /> test_bpf: #5 Tail call load/store jited:1 141 PASS<br /> test_bpf: #6 Tail call error path, max count reached jited:1 994 PASS<br /> test_bpf: #7 Tail call count preserved across function calls jited:1 140975 PASS<br /> test_bpf: #8 Tail call error path, NULL target jited:1 110 PASS<br /> test_bpf: #9 Tail call error path, index out of range jited:1 69 PASS<br /> test_bpf: test_tail_calls: Summary: 10 PASSED, 0 FAILED, [10/10 JIT&amp;#39;ed]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4: Handle attempt to delete multipath route when fib_info contains an nh reference<br /> <br /> Gwangun Jung reported a slab-out-of-bounds access in fib_nh_match:<br /> fib_nh_match+0xf98/0x1130 linux-6.0-rc7/net/ipv4/fib_semantics.c:961<br /> fib_table_delete+0x5f3/0xa40 linux-6.0-rc7/net/ipv4/fib_trie.c:1753<br /> inet_rtm_delroute+0x2b3/0x380 linux-6.0-rc7/net/ipv4/fib_frontend.c:874<br /> <br /> Separate nexthop objects are mutually exclusive with the legacy<br /> multipath spec. Fix fib_nh_match to return if the config for the<br /> to be deleted route contains a multipath spec while the fib_info<br /> is using a nexthop object.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Fix PCI device refcount leak in has_external_pci()<br /> <br /> for_each_pci_dev() is implemented by pci_get_device(). The comment of<br /> pci_get_device() says that it will increase the reference count for the<br /> returned pci_dev and also decrease the reference count for the input<br /> pci_dev @from if it is not NULL.<br /> <br /> If we break for_each_pci_dev() loop with pdev not NULL, we need to call<br /> pci_dev_put() to decrease the reference count. Add the missing<br /> pci_dev_put() before &amp;#39;return true&amp;#39; to avoid reference count leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: fix race when vmap stack overflow<br /> <br /> Currently, when detecting vmap stack overflow, riscv firstly switches<br /> to the so called shadow stack, then use this shadow stack to call the<br /> get_overflow_stack() to get the overflow stack. However, there&amp;#39;s<br /> a race here if two or more harts use the same shadow stack at the same<br /> time.<br /> <br /> To solve this race, we introduce spin_shadow_stack atomic var, which<br /> will be swap between its own address and 0 in atomic way, when the<br /> var is set, it means the shadow_stack is being used; when the var<br /> is cleared, it means the shadow_stack isn&amp;#39;t being used.<br /> <br /> [Palmer: Add AQ to the swap, and also some comments.]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Fix PCI device refcount leak in dmar_dev_scope_init()<br /> <br /> for_each_pci_dev() is implemented by pci_get_device(). The comment of<br /> pci_get_device() says that it will increase the reference count for the<br /> returned pci_dev and also decrease the reference count for the input<br /> pci_dev @from if it is not NULL.<br /> <br /> If we break for_each_pci_dev() loop with pdev not NULL, we need to call<br /> pci_dev_put() to decrease the reference count. Add the missing<br /> pci_dev_put() for the error path to avoid reference count leak.