Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: fix memory leak in ceph_readdir when note_last_dentry returns error<br /> <br /> Reset the last_readdir at the same time, and add a comment explaining<br /> why we don&amp;#39;t free last_readdir when dir_emit returns false.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: mediatek: Fix memory leaks on probe<br /> <br /> Handle the error branches to free memory where required.<br /> <br /> Addresses-Coverity-ID: 1491825 ("Resource leak")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: fix inode reference leakage in ceph_get_snapdir()<br /> <br /> The ceph_get_inode() will search for or insert a new inode into the<br /> hash for the given vino, and return a reference to it. If new is<br /> non-NULL, its reference is consumed.<br /> <br /> We should release the reference when in error handing cases.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: conntrack: revisit gc autotuning<br /> <br /> as of commit 4608fdfc07e1<br /> ("netfilter: conntrack: collect all entries in one cycle")<br /> conntrack gc was changed to run every 2 minutes.<br /> <br /> On systems where conntrack hash table is set to large value, most evictions<br /> happen from gc worker rather than the packet path due to hash table<br /> distribution.<br /> <br /> This causes netlink event overflows when events are collected.<br /> <br /> This change collects average expiry of scanned entries and<br /> reschedules to the average remaining value, within 1 to 60 second interval.<br /> <br /> To avoid event overflows, reschedule after each bucket and add a<br /> limit for both run time and number of evictions per run.<br /> <br /> If more entries have to be evicted, reschedule and restart 1 jiffy<br /> into the future.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: Fix use after free in hci_send_acl<br /> <br /> This fixes the following trace caused by receiving<br /> HCI_EV_DISCONN_PHY_LINK_COMPLETE which does call hci_conn_del without<br /> first checking if conn-&gt;type is in fact AMP_LINK and in case it is<br /> do properly cleanup upper layers with hci_disconn_cfm:<br /> <br /> ==================================================================<br /> BUG: KASAN: use-after-free in hci_send_acl+0xaba/0xc50<br /> Read of size 8 at addr ffff88800e404818 by task bluetoothd/142<br /> <br /> CPU: 0 PID: 142 Comm: bluetoothd Not tainted<br /> 5.17.0-rc5-00006-gda4022eeac1a #7<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x45/0x59<br /> print_address_description.constprop.0+0x1f/0x150<br /> kasan_report.cold+0x7f/0x11b<br /> hci_send_acl+0xaba/0xc50<br /> l2cap_do_send+0x23f/0x3d0<br /> l2cap_chan_send+0xc06/0x2cc0<br /> l2cap_sock_sendmsg+0x201/0x2b0<br /> sock_sendmsg+0xdc/0x110<br /> sock_write_iter+0x20f/0x370<br /> do_iter_readv_writev+0x343/0x690<br /> do_iter_write+0x132/0x640<br /> vfs_writev+0x198/0x570<br /> do_writev+0x202/0x280<br /> do_syscall_64+0x38/0x90<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RSP: 002b:00007ffce8a099b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014<br /> Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3<br /> 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 14 00 00 00 0f 05<br /> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10<br /> RDX: 0000000000000001 RSI: 00007ffce8a099e0 RDI: 0000000000000015<br /> RAX: ffffffffffffffda RBX: 00007ffce8a099e0 RCX: 00007f788fc3cf77<br /> R10: 00007ffce8af7080 R11: 0000000000000246 R12: 000055e4ccf75580<br /> RBP: 0000000000000015 R08: 0000000000000002 R09: 0000000000000001<br /> <br /> R13: 000055e4ccf754a0 R14: 000055e4ccf75cd0 R15: 000055e4ccf4a6b0<br /> <br /> Allocated by task 45:<br /> kasan_save_stack+0x1e/0x40<br /> __kasan_kmalloc+0x81/0xa0<br /> hci_chan_create+0x9a/0x2f0<br /> l2cap_conn_add.part.0+0x1a/0xdc0<br /> l2cap_connect_cfm+0x236/0x1000<br /> le_conn_complete_evt+0x15a7/0x1db0<br /> hci_le_conn_complete_evt+0x226/0x2c0<br /> hci_le_meta_evt+0x247/0x450<br /> hci_event_packet+0x61b/0xe90<br /> hci_rx_work+0x4d5/0xc50<br /> process_one_work+0x8fb/0x15a0<br /> worker_thread+0x576/0x1240<br /> kthread+0x29d/0x340<br /> ret_from_fork+0x1f/0x30<br /> <br /> Freed by task 45:<br /> kasan_save_stack+0x1e/0x40<br /> kasan_set_track+0x21/0x30<br /> kasan_set_free_info+0x20/0x30<br /> __kasan_slab_free+0xfb/0x130<br /> kfree+0xac/0x350<br /> hci_conn_cleanup+0x101/0x6a0<br /> hci_conn_del+0x27e/0x6c0<br /> hci_disconn_phylink_complete_evt+0xe0/0x120<br /> hci_event_packet+0x812/0xe90<br /> hci_rx_work+0x4d5/0xc50<br /> process_one_work+0x8fb/0x15a0<br /> worker_thread+0x576/0x1240<br /> kthread+0x29d/0x340<br /> ret_from_fork+0x1f/0x30<br /> <br /> The buggy address belongs to the object at ffff88800c0f0500<br /> The buggy address is located 24 bytes inside of<br /> which belongs to the cache kmalloc-128 of size 128<br /> The buggy address belongs to the page:<br /> 128-byte region [ffff88800c0f0500, ffff88800c0f0580)<br /> flags: 0x100000000000200(slab|node=0|zone=1)<br /> page:00000000fe45cd86 refcount:1 mapcount:0<br /> mapping:0000000000000000 index:0x0 pfn:0xc0f0<br /> raw: 0000000000000000 0000000080100010 00000001ffffffff<br /> 0000000000000000<br /> raw: 0100000000000200 ffffea00003a2c80 dead000000000004<br /> ffff8880078418c0<br /> page dumped because: kasan: bad access detected<br /> ffff88800c0f0400: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc<br /> Memory state around the buggy address:<br /> &gt;ffff88800c0f0500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ffff88800c0f0480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> ffff88800c0f0580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mt76: fix monitor mode crash with sdio driver<br /> <br /> mt7921s driver may receive frames with fragment buffers. If there is a<br /> CTS packet received in monitor mode, the payload is 10 bytes only and<br /> need 6 bytes header padding after RXD buffer. However, only RXD in the<br /> first linear buffer, if we pull buffer size RXD-size+6 bytes with<br /> skb_pull(), that would trigger "BUG_ON(skb-&gt;len data_len)" in<br /> __skb_pull().<br /> <br /> To avoid the nonlinear buffer issue, enlarge the RXD size from 128 to<br /> 256 to make sure all MCU operation in linear buffer.<br /> <br /> [ 52.007562] kernel BUG at include/linux/skbuff.h:2313!<br /> [ 52.007578] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP<br /> [ 52.007987] pc : skb_pull+0x48/0x4c<br /> [ 52.008015] lr : mt7921_queue_rx_skb+0x494/0x890 [mt7921_common]<br /> [ 52.008361] Call trace:<br /> [ 52.008377] skb_pull+0x48/0x4c<br /> [ 52.008400] mt76s_net_worker+0x134/0x1b0 [mt76_sdio 35339a92c6eb7d4bbcc806a1d22f56365565135c]<br /> [ 52.008431] __mt76_worker_fn+0xe8/0x170 [mt76 ef716597d11a77150bc07e3fdd68eeb0f9b56917]<br /> [ 52.008449] kthread+0x148/0x3ac<br /> [ 52.008466] ret_from_fork+0x10/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/secvar: fix refcount leak in format_show()<br /> <br /> Refcount leak will happen when format_show returns failure in multiple<br /> cases. Unified management of of_node_put can fix this problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: libfc: Fix use after free in fc_exch_abts_resp()<br /> <br /> fc_exch_release(ep) will decrease the ep&amp;#39;s reference count. When the<br /> reference count reaches zero, it is freed. But ep is still used in the<br /> following code, which will lead to a use after free.<br /> <br /> Return after the fc_exch_release() call to avoid use after free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: endpoint: Fix misused goto label<br /> <br /> Fix a misused goto label jump since that can result in a memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: use memset avoid memory leaks<br /> <br /> Use memset to initialize structs to prevent memory leaks<br /> in l2cap_ecred_connect

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 /> net: sfc: add missing xdp queue reinitialization<br /> <br /> After rx/tx ring buffer size is changed, kernel panic occurs when<br /> it acts XDP_TX or XDP_REDIRECT.<br /> <br /> When tx/rx ring buffer size is changed(ethtool -G), sfc driver<br /> reallocates and reinitializes rx and tx queues and their buffer<br /> (tx_queue-&gt;buffer).<br /> But it misses reinitializing xdp queues(efx-&gt;xdp_tx_queues).<br /> So, while it is acting XDP_TX or XDP_REDIRECT, it uses the uninitialized<br /> tx_queue-&gt;buffer.<br /> <br /> A new function efx_set_xdp_channels() is separated from efx_set_channels()<br /> to handle only xdp queues.<br /> <br /> Splat looks like:<br /> BUG: kernel NULL pointer dereference, address: 000000000000002a<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0002 [#4] PREEMPT SMP NOPTI<br /> RIP: 0010:efx_tx_map_chunk+0x54/0x90 [sfc]<br /> CPU: 2 PID: 0 Comm: swapper/2 Tainted: G D 5.17.0+ #55 e8beeee8289528f11357029357cf<br /> Code: 48 8b 8d a8 01 00 00 48 8d 14 52 4c 8d 2c d0 44 89 e0 48 85 c9 74 0e 44 89 e2 4c 89 f6 48 80<br /> RSP: 0018:ffff92f121e45c60 EFLAGS: 00010297<br /> RIP: 0010:efx_tx_map_chunk+0x54/0x90 [sfc]<br /> RAX: 0000000000000040 RBX: ffff92ea506895c0 RCX: ffffffffc0330870<br /> RDX: 0000000000000001 RSI: 00000001139b10ce RDI: ffff92ea506895c0<br /> RBP: ffffffffc0358a80 R08: 00000001139b110d R09: 0000000000000000<br /> R10: 0000000000000001 R11: ffff92ea414c0088 R12: 0000000000000040<br /> R13: 0000000000000018 R14: 00000001139b10ce R15: ffff92ea506895c0<br /> FS: 0000000000000000(0000) GS:ffff92f121ec0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> Code: 48 8b 8d a8 01 00 00 48 8d 14 52 4c 8d 2c d0 44 89 e0 48 85 c9 74 0e 44 89 e2 4c 89 f6 48 80<br /> CR2: 000000000000002a CR3: 00000003e6810004 CR4: 00000000007706e0<br /> RSP: 0018:ffff92f121e85c60 EFLAGS: 00010297<br /> PKRU: 55555554<br /> RAX: 0000000000000040 RBX: ffff92ea50689700 RCX: ffffffffc0330870<br /> RDX: 0000000000000001 RSI: 00000001145a90ce RDI: ffff92ea50689700<br /> RBP: ffffffffc0358a80 R08: 00000001145a910d R09: 0000000000000000<br /> R10: 0000000000000001 R11: ffff92ea414c0088 R12: 0000000000000040<br /> R13: 0000000000000018 R14: 00000001145a90ce R15: ffff92ea50689700<br /> FS: 0000000000000000(0000) GS:ffff92f121e80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000000000002a CR3: 00000003e6810005 CR4: 00000000007706e0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> efx_xdp_tx_buffers+0x12b/0x3d0 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5]<br /> __efx_rx_packet+0x5c3/0x930 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5]<br /> efx_rx_packet+0x28c/0x2e0 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5]<br /> efx_ef10_ev_process+0x5f8/0xf40 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5]<br /> ? enqueue_task_fair+0x95/0x550<br /> efx_poll+0xc4/0x360 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5]