Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme: fix SRCU protection of nvme_ns_head list<br /> <br /> Walking the nvme_ns_head siblings list is protected by the head&amp;#39;s srcu<br /> in nvme_ns_head_submit_bio() but not nvme_mpath_revalidate_paths().<br /> Removing namespaces from the list also fails to synchronize the srcu.<br /> Concurrent scan work can therefore cause use-after-frees.<br /> <br /> Hold the head&amp;#39;s srcu lock in nvme_mpath_revalidate_paths() and<br /> synchronize with the srcu, not the global RCU, in nvme_ns_remove().<br /> <br /> Observed the following panic when making NVMe/RDMA connections<br /> with native multipath on the Rocky Linux 8.6 kernel<br /> (it seems the upstream kernel has the same race condition).<br /> Disassembly shows the faulting instruction is cmp 0x50(%rdx),%rcx;<br /> computing capacity != get_capacity(ns-&gt;disk).<br /> Address 0x50 is dereferenced because ns-&gt;disk is NULL.<br /> The NULL disk appears to be the result of concurrent scan work<br /> freeing the namespace (note the log line in the middle of the panic).<br /> <br /> [37314.206036] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050<br /> [37314.206036] nvme0n3: detected capacity change from 0 to 11811160064<br /> [37314.299753] PGD 0 P4D 0<br /> [37314.299756] Oops: 0000 [#1] SMP PTI<br /> [37314.299759] CPU: 29 PID: 322046 Comm: kworker/u98:3 Kdump: loaded Tainted: G W X --------- - - 4.18.0-372.32.1.el8test86.x86_64 #1<br /> [37314.299762] Hardware name: Dell Inc. PowerEdge R720/0JP31P, BIOS 2.7.0 05/23/2018<br /> [37314.299763] Workqueue: nvme-wq nvme_scan_work [nvme_core]<br /> [37314.299783] RIP: 0010:nvme_mpath_revalidate_paths+0x26/0xb0 [nvme_core]<br /> [37314.299790] Code: 1f 44 00 00 66 66 66 66 90 55 53 48 8b 5f 50 48 8b 83 c8 c9 00 00 48 8b 13 48 8b 48 50 48 39 d3 74 20 48 8d 42 d0 48 8b 50 20 3b 4a 50 74 05 f0 80 60 70 ef 48 8b 50 30 48 8d 42 d0 48 39 d3<br /> [37315.058803] RSP: 0018:ffffabe28f913d10 EFLAGS: 00010202<br /> [37315.121316] RAX: ffff927a077da800 RBX: ffff92991dd70000 RCX: 0000000001600000<br /> [37315.206704] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff92991b719800<br /> [37315.292106] RBP: ffff929a6b70c000 R08: 000000010234cd4a R09: c0000000ffff7fff<br /> [37315.377501] R10: 0000000000000001 R11: ffffabe28f913a30 R12: 0000000000000000<br /> [37315.462889] R13: ffff92992716600c R14: ffff929964e6e030 R15: ffff92991dd70000<br /> [37315.548286] FS: 0000000000000000(0000) GS:ffff92b87fb80000(0000) knlGS:0000000000000000<br /> [37315.645111] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [37315.713871] CR2: 0000000000000050 CR3: 0000002208810006 CR4: 00000000000606e0<br /> [37315.799267] Call Trace:<br /> [37315.828515] nvme_update_ns_info+0x1ac/0x250 [nvme_core]<br /> [37315.892075] nvme_validate_or_alloc_ns+0x2ff/0xa00 [nvme_core]<br /> [37315.961871] ? __blk_mq_free_request+0x6b/0x90<br /> [37316.015021] nvme_scan_work+0x151/0x240 [nvme_core]<br /> [37316.073371] process_one_work+0x1a7/0x360<br /> [37316.121318] ? create_worker+0x1a0/0x1a0<br /> [37316.168227] worker_thread+0x30/0x390<br /> [37316.212024] ? create_worker+0x1a0/0x1a0<br /> [37316.258939] kthread+0x10a/0x120<br /> [37316.297557] ? set_kthread_struct+0x50/0x50<br /> [37316.347590] ret_from_fork+0x35/0x40<br /> [37316.390360] Modules linked in: nvme_rdma nvme_tcp(X) nvme_fabrics nvme_core netconsole iscsi_tcp libiscsi_tcp dm_queue_length dm_service_time nf_conntrack_netlink br_netfilter bridge stp llc overlay nft_chain_nat ipt_MASQUERADE nf_nat xt_addrtype xt_CT nft_counter xt_state xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment xt_multiport nft_compat nf_tables libcrc32c nfnetlink dm_multipath tg3 rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm intel_rapl_msr iTCO_wdt iTCO_vendor_support dcdbas intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel ipmi_ssif kvm irqbypass crct10dif_pclmul crc32_pclmul mlx5_ib ghash_clmulni_intel ib_uverbs rapl intel_cstate intel_uncore ib_core ipmi_si joydev mei_me pcspkr ipmi_devintf mei lpc_ich wmi ipmi_msghandler acpi_power_meter ex<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: Sync efi page table&amp;#39;s kernel mappings before switching<br /> <br /> The EFI page table is initially created as a copy of the kernel page table.<br /> With VMAP_STACK enabled, kernel stacks are allocated in the vmalloc area:<br /> if the stack is allocated in a new PGD (one that was not present at the<br /> moment of the efi page table creation or not synced in a previous vmalloc<br /> fault), the kernel will take a trap when switching to the efi page table<br /> when the vmalloc kernel stack is accessed, resulting in a kernel panic.<br /> <br /> Fix that by updating the efi kernel mappings before switching to the efi<br /> page table.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: sja1105: avoid out of bounds access in sja1105_init_l2_policing()<br /> <br /> The SJA1105 family has 45 L2 policing table entries<br /> (SJA1105_MAX_L2_POLICING_COUNT) and SJA1110 has 110<br /> (SJA1110_MAX_L2_POLICING_COUNT). Keeping the table structure but<br /> accounting for the difference in port count (5 in SJA1105 vs 10 in<br /> SJA1110) does not fully explain the difference. Rather, the SJA1110 also<br /> has L2 ingress policers for multicast traffic. If a packet is classified<br /> as multicast, it will be processed by the policer index 99 + SRCPORT.<br /> <br /> The sja1105_init_l2_policing() function initializes all L2 policers such<br /> that they don&amp;#39;t interfere with normal packet reception by default. To have<br /> a common code between SJA1105 and SJA1110, the index of the multicast<br /> policer for the port is calculated because it&amp;#39;s an index that is out of<br /> bounds for SJA1105 but in bounds for SJA1110, and a bounds check is<br /> performed.<br /> <br /> The code fails to do the proper thing when determining what to do with the<br /> multicast policer of port 0 on SJA1105 (ds-&gt;num_ports = 5). The "mcast"<br /> index will be equal to 45, which is also equal to<br /> table-&gt;ops-&gt;max_entry_count (SJA1105_MAX_L2_POLICING_COUNT). So it passes<br /> through the check. But at the same time, SJA1105 doesn&amp;#39;t have multicast<br /> policers. So the code programs the SHARINDX field of an out-of-bounds<br /> element in the L2 Policing table of the static config.<br /> <br /> The comparison between index 45 and 45 entries should have determined the<br /> code to not access this policer index on SJA1105, since its memory wasn&amp;#39;t<br /> even allocated.<br /> <br /> With enough bad luck, the out-of-bounds write could even overwrite other<br /> valid kernel data, but in this case, the issue was detected using KASAN.<br /> <br /> Kernel log:<br /> <br /> sja1105 spi5.0: Probed switch chip: SJA1105Q<br /> ==================================================================<br /> BUG: KASAN: slab-out-of-bounds in sja1105_setup+0x1cbc/0x2340<br /> Write of size 8 at addr ffffff880bd57708 by task kworker/u8:0/8<br /> ...<br /> Workqueue: events_unbound deferred_probe_work_func<br /> Call trace:<br /> ...<br /> sja1105_setup+0x1cbc/0x2340<br /> dsa_register_switch+0x1284/0x18d0<br /> sja1105_probe+0x748/0x840<br /> ...<br /> Allocated by task 8:<br /> ...<br /> sja1105_setup+0x1bcc/0x2340<br /> dsa_register_switch+0x1284/0x18d0<br /> sja1105_probe+0x748/0x840<br /> ...