Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: sch_sfb: Replace direct dequeue call with peek and qdisc_dequeue_peeked<br /> <br /> When sfb has children (eg qfq qdisc) whose peek() callback is<br /> qdisc_peek_dequeued(), we could get a kernel panic. When the parent of such<br /> qdiscs (eg illustrated in patch #3 as tbf) wants to retrieve an skb from<br /> its child (sfb in this case), it will do the following:<br /> 1a. do a peek() - and when sensing there&amp;#39;s an skb the child can offer, then<br /> - the child in this case(sfb) calls its child&amp;#39;s (qfq) peek.<br /> qfq does the right thing and will return the gso_skb queue packet.<br /> Note: if there wasnt a gso_skb entry then qfq will store it there.<br /> 1b. invoke a dequeue() on the child (sfb). And herein lies the problem.<br /> - sfb will call the child&amp;#39;s dequeue() which will essentially just<br /> try to grab something of qfq&amp;#39;s queue.<br /> <br /> [ 127.594489][ T453] KASAN: null-ptr-deref in range [0x0000000000000048-0x000000000000004f]<br /> [ 127.594741][ T453] CPU: 2 UID: 0 PID: 453 Comm: ping Not tainted 7.1.0-rc1-00035-gac961974495b-dirty #793 PREEMPT(full)<br /> [ 127.595059][ T453] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011<br /> [ 127.595254][ T453] RIP: 0010:qfq_dequeue+0x35c/0x1650 [sch_qfq]<br /> [ 127.595461][ T453] Code: 00 fc ff df 80 3c 02 00 0f 85 17 0e 00 00 4c 8d 73 48 48 89 9d b8 02 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 ea 03 3c 02 00 0f 85 76 0c 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b<br /> [ 127.596081][ T453] RSP: 0018:ffff88810e5af440 EFLAGS: 00010216<br /> [ 127.596337][ T453] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: dffffc0000000000<br /> [ 127.596623][ T453] RDX: 0000000000000009 RSI: 0000001880000000 RDI: ffff888104fd82b0<br /> [ 127.596917][ T453] RBP: ffff888104fd8000 R08: ffff888104fd8280 R09: 1ffff110211893a3<br /> [ 127.597165][ T453] R10: 1ffff110211893a6 R11: 1ffff110211893a7 R12: 0000001880000000<br /> [ 127.597404][ T453] R13: ffff888104fd82b8 R14: 0000000000000048 R15: 0000000040000000<br /> [ 127.597644][ T453] FS: 00007fc380cbfc40(0000) GS:ffff88816f2a8000(0000) knlGS:0000000000000000<br /> [ 127.597956][ T453] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 127.598160][ T453] CR2: 00005610aa9890a8 CR3: 000000010369e000 CR4: 0000000000750ef0<br /> [ 127.598390][ T453] PKRU: 55555554<br /> [ 127.598509][ T453] Call Trace:<br /> [ 127.598629][ T453] <br /> [ 127.598718][ T453] ? mark_held_locks+0x40/0x70<br /> [ 127.598890][ T453] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 127.599053][ T453] sfb_dequeue+0x88/0x4d0<br /> [ 127.599174][ T453] ? ktime_get+0x137/0x230<br /> [ 127.599328][ T453] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 127.599480][ T453] ? qdisc_peek_dequeued+0x7b/0x350 [sch_qfq]<br /> [ 127.599670][ T453] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 127.599831][ T453] tbf_dequeue+0x6b1/0x1098 [sch_tbf]<br /> [ 127.599988][ T453] __qdisc_run+0x169/0x1900<br /> <br /> The right thing to do in #1b is to grab the skb off gso_skb queue.<br /> This patchset fixes that issue by changing #1b to use qdisc_dequeue_peeked()<br /> method instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: button: Fix ACPI GPE handler leak during removal<br /> <br /> Commit a7e23ec17fee ("ACPI: button: Install notifier for system events<br /> as well") changed the ACPI notify handler type for ACPI buttons to<br /> ACPI_ALL_NOTIFY, but it forgot to update acpi_button_remove() to reflect<br /> that change. This leads to leaking the notify handler past driver<br /> removal, which may cause a kernel crash to occur if ACPI notify on<br /> the given device is triggered after removing the driver, and causes a<br /> subsequent probe of the given device with the same driver to fail.<br /> <br /> Address this by updating the acpi_remove_notify_handler() call in<br /> acpi_button_remove() as appropriate.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: usbtouchscreen - clamp NEXIO data_len/x_len to URB buffer size<br /> <br /> nexio_read_data() pulls data_len and x_len from a packed __be16 header<br /> in the device&amp;#39;s interrupt packet and then walks packet-&gt;data[0..x_len)<br /> and packet-&gt;data[x_len..data_len) comparing each byte against a<br /> threshold.<br /> <br /> Both fields are 16-bit on the wire (max 65535). The existing<br /> adjustments shave at most 0x100 / 0x80 off, so the loop bound can still<br /> reach roughly 0xfeff. The URB transfer buffer for NEXIO is rept_size<br /> (1024) bytes from usb_alloc_coherent(), with the first 7 occupied by the<br /> packed header — so packet-&gt;data[] has 1017 valid bytes. read_data()<br /> callbacks are not given urb-&gt;actual_length, and nothing else bounds the<br /> walk.<br /> <br /> A device that lies about its length can get a ~64 KiB out-of-bounds read<br /> past the coherent DMA allocation. The first index whose byte exceeds<br /> NEXIO_THRESHOLD lands in begin_x / begin_y and from there into the<br /> reported touch coordinates, so adjacent kernel memory contents leak to<br /> userspace as ABS_X / ABS_Y events. Far enough out, the read can also<br /> hit an unmapped page and fault.<br /> <br /> Fix this all by clamping data_len to the buffer&amp;#39;s data[] capacity and<br /> x_len to data_len.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> security/keys: fix missed RCU read section on lookup<br /> <br /> Nicholas Carlini reports that the keyring code calls assoc_array_find()<br /> in find_key_to_update() without holding the RCU read lock, while the<br /> assoc_array_gc() code really is designed around removing the node from<br /> the tree and then freeing it after an RCU grace-period.<br /> <br /> The regular key handling doesn&amp;#39;t see this because holding the keyring<br /> semaphore hides any lifetime issues, but the persistent key handling<br /> uses a different model.<br /> <br /> Instead of extending the keyring locking, just do the simple RCU locking<br /> that the assoc_array was designed for.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix durable reconnect error path file lifetime<br /> <br /> After a durable reconnect succeeds, ksmbd_reopen_durable_fd() republishes<br /> the same ksmbd_file into the session volatile-id table. If smb2_open()<br /> then takes a later error path, cleanup first calls ksmbd_fd_put(work, fp)<br /> and then unconditionally calls ksmbd_put_durable_fd(dh_info.fp).<br /> <br /> In this case fp and dh_info.fp are the same object. The first put drops the<br /> reconnect lookup reference, but the final durable put can run<br /> __ksmbd_close_fd(NULL, fp). Because the final close is not session-aware,<br /> it can free the file object without removing the volatile-id entry that was<br /> just published into the session table.<br /> <br /> Use the session-aware put for the final reconnect drop when the reconnect<br /> had already succeeded and the error path is cleaning up the republished<br /> file. Earlier reconnect failures, before fp is assigned to dh_info.fp, keep<br /> using the durable-only put path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-mq: pop cached request if it is usable<br /> <br /> When submitting a bio to blk-mq, if the task should sleep after peeking<br /> a cached request, but before it pops it, the plug flushes and calls<br /> blk_mq_free_plug_rqs, freeing the cached_rqs. This creates a<br /> use-after-free bug. Fix this by popping the cached request before any<br /> possible blocking calls if it is suitable for use.<br /> <br /> Popping this request first holds a queue reference, so avoid any<br /> serialization races with queue freezes and can safely proceed with<br /> dispatching that request to the driver. This potentially increases a<br /> timing window from when a driver wants to freeze its queue to when<br /> requests stop being dispatched. That scenario is off the fast path<br /> though, and drivers need to appropriately handle requests during a<br /> freeze request anyway.<br /> <br /> The downside is the popped element needs to be individually freed when<br /> we performed a bio plug merge. The cached request would have had to be<br /> freed later anyway, but this patch does it inline with building the plug<br /> list instead of after flushing it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mana: validate rx_req_idx to prevent out-of-bounds array access<br /> <br /> In mana_hwc_rx_event_handler(), rx_req_idx is derived from<br /> sge-&gt;address in DMA-coherent memory. In Confidential VMs<br /> (SEV-SNP/TDX), this memory is shared unencrypted and HW can modify<br /> WQE contents at any time. No bounds check exists on rx_req_idx,<br /> which can lead to an out-of-bounds access into reqs[].<br /> <br /> Add bounds check on rx_req_idx in mana_hwc_rx_event_handler() before<br /> using it to index the reqs[] array.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-pci: fix dma mapping leak on data setup error<br /> <br /> We&amp;#39;re leaking the initial DMA mapping during iteration if we fail to<br /> allocate the tracking descriptor for both PRP and SGL. Unmap the<br /> iterator directly; we can&amp;#39;t use the existing unmap helper because it<br /> depends on the tracking descriptor being successfully allocated, so a<br /> new one for an in-use iterator is provided.<br /> <br /> The mappings were also leaking when the driver detects an invalid<br /> bio_vec when mapping PRPs, so fix that too.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/iucv: fix locking in .getsockopt<br /> <br /> Mirror iucv_sock_setsockopt() and wrap the whole switch in<br /> lock_sock()/release_sock(). The pre-existing SO_MSGLIMIT-only lock<br /> becomes redundant and is removed.<br /> <br /> Any AF_IUCV HIPER user can potentially crash the kernel by racing<br /> recvmsg() with getsockopt(SO_MSGSIZE): the SO_MSGSIZE arm dereferences<br /> iucv-&gt;hs_dev-&gt;mtu after iucv_sock_close() (called from the racing<br /> recvmsg()) has set hs_dev to NULL, producing a NULL pointer dereference<br /> oops.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: Do not re-initialize smc hashtables<br /> <br /> INIT_HLIST_HEAD(&amp;smc_v*_hashinfo.ht) are called after smc_nl_init(),<br /> proto_register() and sock_register(). This can lead to smc_v*_hashinfo.ht<br /> being reset even though hash entries already exist and are being used,<br /> possibly resulting in a corrupted list.<br /> <br /> Remove unnecessary and dangerous re-initialisation of smc_v*_hashinfo.ht in<br /> smc_init(); it is implicitly initialised to zero anyhow. Add<br /> HLIST_HEAD_INIT to the definitions for clarity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: fix dst corruption in same register operation<br /> <br /> For lshift and rshift, the shift operations are performed in a loop over<br /> 32-bit words. The loop calculates the shifted value and write it to dst,<br /> and then immediately reads from src to calculate the carry for the next<br /> iteration. Because src and dst could point to the same memory location,<br /> the carry is incorrectly calculated using the newly modified dst value<br /> instead of the original src value.<br /> <br /> Adding a temporary local variable to cache the original value before<br /> writing to dst and using it for the carry calculation solves the<br /> problem. In addition, partial overlap is rejected from control plane for<br /> all kind of operations including byteorder. This was tested with the<br /> following bytecode:<br /> <br /> table test_table ip flags 0 use 1 handle 1<br /> ip test_table test_chain use 3 type filter hook input prio 0 policy accept packets 0 bytes 0 flags 1<br /> ip test_table test_chain 2<br /> [ immediate reg 1 0x44332211 0x88776655 ]<br /> [ bitwise reg 1 = ( reg 1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: synproxy: refresh tcphdr after skb_ensure_writable<br /> <br /> synproxy_tstamp_adjust() rewrites the TCP timestamp option in place<br /> and then patches the TCP checksum via inet_proto_csum_replace4() on<br /> the caller-supplied tcphdr pointer. Both ipv4_synproxy_hook() and<br /> ipv6_synproxy_hook() obtain that pointer with skb_header_pointer()<br /> before calling in, so it may either alias skb-&gt;head directly or<br /> point at the caller&amp;#39;s on-stack _tcph buffer.<br /> <br /> Between obtaining the pointer and using it, the function calls<br /> skb_ensure_writable(skb, optend), which on a cloned or non-linear<br /> skb invokes pskb_expand_head() and frees the old skb-&gt;head. After<br /> that point the cached th is stale:<br /> <br /> caller (ipv[46]_synproxy_hook)<br /> th = skb_header_pointer(skb, ..., &amp;_tcph)<br /> synproxy_tstamp_adjust(skb, protoff, th, ...)<br /> skb_ensure_writable(skb, optend)<br /> pskb_expand_head() /* kfree(old skb-&gt;head) */<br /> ...<br /> inet_proto_csum_replace4(&amp;th-&gt;check, ...)<br /> /* writes into freed head, or<br /> into the caller&amp;#39;s stack copy<br /> leaving the on-wire checksum<br /> stale */<br /> <br /> The option bytes are written through skb-&gt;data and are fine; only<br /> the checksum update goes through th and so lands in the wrong<br /> place. The result is either a write into freed slab memory or a<br /> packet leaving with a checksum that does not match its payload.<br /> <br /> Fix by re-deriving th from skb-&gt;data + protoff immediately after<br /> skb_ensure_writable() succeeds, so the subsequent checksum update<br /> targets the linear, writable header.