Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: ensure snd_una is properly initialized on connect<br /> <br /> This is strictly related to commit fb7a0d334894 ("mptcp: ensure snd_nxt<br /> is properly initialized on connect"). It turns out that syzkaller can<br /> trigger the retransmit after fallback and before processing any other<br /> incoming packet - so that snd_una is still left uninitialized.<br /> <br /> Address the issue explicitly initializing snd_una together with snd_nxt<br /> and write_seq.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/exynos/vidi: fix memory leak in .get_modes()<br /> <br /> The duplicated EDID is never freed. Fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: temperature: mlx90635: Fix ERR_PTR dereference in mlx90635_probe()<br /> <br /> When devm_regmap_init_i2c() fails, regmap_ee could be error pointer,<br /> instead of checking for IS_ERR(regmap_ee), regmap is checked which looks<br /> like a copy paste error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: logitech-dj: Fix memory leak in logi_dj_recv_switch_to_dj_mode()<br /> <br /> Fix a memory leak on logi_dj_recv_send_report() error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bridge: mst: fix suspicious rcu usage in br_mst_set_state<br /> <br /> I converted br_mst_set_state to RCU to avoid a vlan use-after-free<br /> but forgot to change the vlan group dereference helper. Switch to vlan<br /> group RCU deref helper to fix the suspicious rcu usage warning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vmxnet3: disable rx data ring on dma allocation failure<br /> <br /> When vmxnet3_rq_create() fails to allocate memory for rq-&gt;data_ring.base,<br /> the subsequent call to vmxnet3_rq_destroy_all_rxdataring does not reset<br /> rq-&gt;data_ring.desc_size for the data ring that failed, which presumably<br /> causes the hypervisor to reference it on packet reception.<br /> <br /> To fix this bug, rq-&gt;data_ring.desc_size needs to be set to 0 to tell<br /> the hypervisor to disable this feature.<br /> <br /> [ 95.436876] kernel BUG at net/core/skbuff.c:207!<br /> [ 95.439074] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 95.440411] CPU: 7 PID: 0 Comm: swapper/7 Not tainted 6.9.3-dirty #1<br /> [ 95.441558] Hardware name: VMware, Inc. VMware Virtual<br /> Platform/440BX Desktop Reference Platform, BIOS 6.00 12/12/2018<br /> [ 95.443481] RIP: 0010:skb_panic+0x4d/0x4f<br /> [ 95.444404] Code: 4f 70 50 8b 87 c0 00 00 00 50 8b 87 bc 00 00 00 50<br /> ff b7 d0 00 00 00 4c 8b 8f c8 00 00 00 48 c7 c7 68 e8 be 9f e8 63 58 f9<br /> ff 0b 48 8b 14 24 48 c7 c1 d0 73 65 9f e8 a1 ff ff ff 48 8b 14 24<br /> [ 95.447684] RSP: 0018:ffffa13340274dd0 EFLAGS: 00010246<br /> [ 95.448762] RAX: 0000000000000089 RBX: ffff8fbbc72b02d0 RCX: 000000000000083f<br /> [ 95.450148] RDX: 0000000000000000 RSI: 00000000000000f6 RDI: 000000000000083f<br /> [ 95.451520] RBP: 000000000000002d R08: 0000000000000000 R09: ffffa13340274c60<br /> [ 95.452886] R10: ffffffffa04ed468 R11: 0000000000000002 R12: 0000000000000000<br /> [ 95.454293] R13: ffff8fbbdab3c2d0 R14: ffff8fbbdbd829e0 R15: ffff8fbbdbd809e0<br /> [ 95.455682] FS: 0000000000000000(0000) GS:ffff8fbeefd80000(0000) knlGS:0000000000000000<br /> [ 95.457178] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 95.458340] CR2: 00007fd0d1f650c8 CR3: 0000000115f28000 CR4: 00000000000406f0<br /> [ 95.459791] Call Trace:<br /> [ 95.460515] <br /> [ 95.461180] ? __die_body.cold+0x19/0x27<br /> [ 95.462150] ? die+0x2e/0x50<br /> [ 95.462976] ? do_trap+0xca/0x110<br /> [ 95.463973] ? do_error_trap+0x6a/0x90<br /> [ 95.464966] ? skb_panic+0x4d/0x4f<br /> [ 95.465901] ? exc_invalid_op+0x50/0x70<br /> [ 95.466849] ? skb_panic+0x4d/0x4f<br /> [ 95.467718] ? asm_exc_invalid_op+0x1a/0x20<br /> [ 95.468758] ? skb_panic+0x4d/0x4f<br /> [ 95.469655] skb_put.cold+0x10/0x10<br /> [ 95.470573] vmxnet3_rq_rx_complete+0x862/0x11e0 [vmxnet3]<br /> [ 95.471853] vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3]<br /> [ 95.473185] __napi_poll+0x2b/0x160<br /> [ 95.474145] net_rx_action+0x2c6/0x3b0<br /> [ 95.475115] handle_softirqs+0xe7/0x2a0<br /> [ 95.476122] __irq_exit_rcu+0x97/0xb0<br /> [ 95.477109] common_interrupt+0x85/0xa0<br /> [ 95.478102] <br /> [ 95.478846] <br /> [ 95.479603] asm_common_interrupt+0x26/0x40<br /> [ 95.480657] RIP: 0010:pv_native_safe_halt+0xf/0x20<br /> [ 95.481801] Code: 22 d7 e9 54 87 01 00 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa eb 07 0f 00 2d 93 ba 3b 00 fb f4 2c 87 01 00 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90<br /> [ 95.485563] RSP: 0018:ffffa133400ffe58 EFLAGS: 00000246<br /> [ 95.486882] RAX: 0000000000004000 RBX: ffff8fbbc1d14064 RCX: 0000000000000000<br /> [ 95.488477] RDX: ffff8fbeefd80000 RSI: ffff8fbbc1d14000 RDI: 0000000000000001<br /> [ 95.490067] RBP: ffff8fbbc1d14064 R08: ffffffffa0652260 R09: 00000000000010d3<br /> [ 95.491683] R10: 0000000000000018 R11: ffff8fbeefdb4764 R12: ffffffffa0652260<br /> [ 95.493389] R13: ffffffffa06522e0 R14: 0000000000000001 R15: 0000000000000000<br /> [ 95.495035] acpi_safe_halt+0x14/0x20<br /> [ 95.496127] acpi_idle_do_entry+0x2f/0x50<br /> [ 95.497221] acpi_idle_enter+0x7f/0xd0<br /> [ 95.498272] cpuidle_enter_state+0x81/0x420<br /> [ 95.499375] cpuidle_enter+0x2d/0x40<br /> [ 95.500400] do_idle+0x1e5/0x240<br /> [ 95.501385] cpu_startup_entry+0x29/0x30<br /> [ 95.502422] start_secondary+0x11c/0x140<br /> [ 95.503454] common_startup_64+0x13e/0x141<br /> [ 95.504466] <br /> [ 95.505197] Modules linked in: nft_fib_inet nft_fib_ipv4<br /> nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6<br /> nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ip<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/dpt: Make DPT object unshrinkable<br /> <br /> In some scenarios, the DPT object gets shrunk but<br /> the actual framebuffer did not and thus its still<br /> there on the DPT&amp;#39;s vm-&gt;bound_list. Then it tries to<br /> rewrite the PTEs via a stale CPU mapping. This causes panic.<br /> <br /> [vsyrjala: Add TODO comment]<br /> (cherry picked from commit 51064d471c53dcc8eddd2333c3f1c1d9131ba36c)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: fix request.queuelist usage in flush<br /> <br /> Friedrich Weber reported a kernel crash problem and bisected to commit<br /> 81ada09cc25e ("blk-flush: reuse rq queuelist in flush state machine").<br /> <br /> The root cause is that we use "list_move_tail(&amp;rq-&gt;queuelist, pending)"<br /> in the PREFLUSH/POSTFLUSH sequences. But rq-&gt;queuelist.next == xxx since<br /> it&amp;#39;s popped out from plug-&gt;cached_rq in __blk_mq_alloc_requests_batch().<br /> We don&amp;#39;t initialize its queuelist just for this first request, although<br /> the queuelist of all later popped requests will be initialized.<br /> <br /> Fix it by changing to use "list_add_tail(&amp;rq-&gt;queuelist, pending)" so<br /> rq-&gt;queuelist doesn&amp;#39;t need to be initialized. It should be ok since rq<br /> can&amp;#39;t be on any list when PREFLUSH or POSTFLUSH, has no move actually.<br /> <br /> Please note the commit 81ada09cc25e ("blk-flush: reuse rq queuelist in<br /> flush state machine") also has another requirement that no drivers would<br /> touch rq-&gt;queuelist after blk_mq_end_request() since we will reuse it to<br /> add rq to the post-flush pending list in POSTFLUSH. If this is not true,<br /> we will have to revert that commit IMHO.<br /> <br /> This updated version adds "list_del_init(&amp;rq-&gt;queuelist)" in flush rq<br /> callback since the dm layer may submit request of a weird invalid format<br /> (REQ_FSEQ_PREFLUSH | REQ_FSEQ_POSTFLUSH), which causes double list_add<br /> if without this "list_del_init(&amp;rq-&gt;queuelist)". The weird invalid format<br /> problem should be fixed in dm layer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: check n_ssids before accessing the ssids<br /> <br /> In some versions of cfg80211, the ssids poinet might be a valid one even<br /> though n_ssids is 0. Accessing the pointer in this case will cuase an<br /> out-of-bound access. Fix this by checking n_ssids first.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: validate HE operation element parsing<br /> <br /> Validate that the HE operation element has the correct<br /> length before parsing it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> memblock: make memblock_set_node() also warn about use of MAX_NUMNODES<br /> <br /> On an (old) x86 system with SRAT just covering space above 4Gb:<br /> <br /> ACPI: SRAT: Node 0 PXM 0 [mem 0x100000000-0xfffffffff] hotplug<br /> <br /> the commit referenced below leads to this NUMA configuration no longer<br /> being refused by a CONFIG_NUMA=y kernel (previously<br /> <br /> NUMA: nodes only cover 6144MB of your 8185MB e820 RAM. Not used.<br /> No NUMA configuration found<br /> Faking a node at [mem 0x0000000000000000-0x000000027fffffff]<br /> <br /> was seen in the log directly after the message quoted above), because of<br /> memblock_validate_numa_coverage() checking for NUMA_NO_NODE (only). This<br /> in turn led to memblock_alloc_range_nid()&amp;#39;s warning about MAX_NUMNODES<br /> triggering, followed by a NULL deref in memmap_init() when trying to<br /> access node 64&amp;#39;s (NODE_SHIFT=6) node data.<br /> <br /> To compensate said change, make memblock_set_node() warn on and adjust<br /> a passed in value of MAX_NUMNODES, just like various other functions<br /> already do.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en: Adjust logging of firmware messages in case of released token in __hwrm_send()<br /> <br /> In case of token is released due to token-&gt;state == BNXT_HWRM_DEFERRED,<br /> released token (set to NULL) is used in log messages. This issue is<br /> expected to be prevented by HWRM_ERR_CODE_PF_UNAVAILABLE error code. But<br /> this error code is returned by recent firmware. So some firmware may not<br /> return it. This may lead to NULL pointer dereference.<br /> Adjust this issue by adding token pointer check.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.