Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> eeprom: ee1004: limit i2c reads to I2C_SMBUS_BLOCK_MAX<br /> <br /> Commit effa453168a7 ("i2c: i801: Don&amp;#39;t silently correct invalid transfer<br /> size") revealed that ee1004_eeprom_read() did not properly limit how<br /> many bytes to read at once.<br /> <br /> In particular, i2c_smbus_read_i2c_block_data_or_emulated() takes the<br /> length to read as an u8. If count == 256 after taking into account the<br /> offset and page boundary, the cast to u8 overflows. And this is common<br /> when user space tries to read the entire EEPROM at once.<br /> <br /> To fix it, limit each read to I2C_SMBUS_BLOCK_MAX (32) bytes, already<br /> the maximum length i2c_smbus_read_i2c_block_data_or_emulated() allows.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: rawnand: gpmi: don&amp;#39;t leak PM reference in error path<br /> <br /> If gpmi_nfc_apply_timings() fails, the PM runtime usage counter must be<br /> dropped.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mscc: ocelot: fix use-after-free in ocelot_vlan_del()<br /> <br /> ocelot_vlan_member_del() will free the struct ocelot_bridge_vlan, so if<br /> this is the same as the port&amp;#39;s pvid_vlan which we access afterwards,<br /> what we&amp;#39;re accessing is freed memory.<br /> <br /> Fix the bug by determining whether to clear ocelot_port-&gt;pvid_vlan prior<br /> to calling ocelot_vlan_member_del().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: Avoid overwriting the copies of clcsock callback functions<br /> <br /> The callback functions of clcsock will be saved and replaced during<br /> the fallback. But if the fallback happens more than once, then the<br /> copies of these callback functions will be overwritten incorrectly,<br /> resulting in a loop call issue:<br /> <br /> clcsk-&gt;sk_error_report<br /> |- smc_fback_error_report() clcsk_error_report() ------------------|<br /> <br /> So this patch fixes the issue by saving these function pointers only<br /> once in the fallback and avoiding overwriting.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: af_alg - get rid of alg_memory_allocated<br /> <br /> alg_memory_allocated does not seem to be really used.<br /> <br /> alg_proto does have a .memory_allocated field, but no<br /> corresponding .sysctl_mem.<br /> <br /> This means sk_has_account() returns true, but all sk_prot_mem_limits()<br /> users will trigger a NULL dereference [1].<br /> <br /> THis was not a problem until SO_RESERVE_MEM addition.<br /> <br /> general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]<br /> CPU: 1 PID: 3591 Comm: syz-executor153 Not tainted 5.17.0-rc3-syzkaller-00316-gb81b1829e7e3 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> RIP: 0010:sk_prot_mem_limits include/net/sock.h:1523 [inline]<br /> RIP: 0010:sock_reserve_memory+0x1d7/0x330 net/core/sock.c:1000<br /> Code: 08 00 74 08 48 89 ef e8 27 20 bb f9 4c 03 7c 24 10 48 8b 6d 00 48 83 c5 08 48 89 e8 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df 3c 08 00 74 08 48 89 ef e8 fb 1f bb f9 48 8b 6d 00 4c 89 ff 48<br /> RSP: 0018:ffffc90001f1fb68 EFLAGS: 00010202<br /> RAX: 0000000000000001 RBX: ffff88814aabc000 RCX: dffffc0000000000<br /> RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffffff90e18120<br /> RBP: 0000000000000008 R08: dffffc0000000000 R09: fffffbfff21c3025<br /> R10: fffffbfff21c3025 R11: 0000000000000000 R12: ffffffff8d109840<br /> R13: 0000000000001002 R14: 0000000000000001 R15: 0000000000000001<br /> FS: 0000555556e08300(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fc74416f130 CR3: 0000000073d9e000 CR4: 00000000003506e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> sock_setsockopt+0x14a9/0x3a30 net/core/sock.c:1446<br /> __sys_setsockopt+0x5af/0x980 net/socket.c:2176<br /> __do_sys_setsockopt net/socket.c:2191 [inline]<br /> __se_sys_setsockopt net/socket.c:2188 [inline]<br /> __x64_sys_setsockopt+0xb1/0xc0 net/socket.c:2188<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7fc7440fddc9<br /> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007ffe98f07968 EFLAGS: 00000246 ORIG_RAX: 0000000000000036<br /> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fc7440fddc9<br /> RDX: 0000000000000049 RSI: 0000000000000001 RDI: 0000000000000004<br /> RBP: 0000000000000000 R08: 0000000000000004 R09: 00007ffe98f07990<br /> R10: 0000000020000000 R11: 0000000000000246 R12: 00007ffe98f0798c<br /> R13: 00007ffe98f079a0 R14: 00007ffe98f079e0 R15: 0000000000000000<br /> <br /> Modules linked in:<br /> ---[ end trace 0000000000000000 ]---<br /> RIP: 0010:sk_prot_mem_limits include/net/sock.h:1523 [inline]<br /> RIP: 0010:sock_reserve_memory+0x1d7/0x330 net/core/sock.c:1000<br /> Code: 08 00 74 08 48 89 ef e8 27 20 bb f9 4c 03 7c 24 10 48 8b 6d 00 48 83 c5 08 48 89 e8 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df 3c 08 00 74 08 48 89 ef e8 fb 1f bb f9 48 8b 6d 00 4c 89 ff 48<br /> RSP: 0018:ffffc90001f1fb68 EFLAGS: 00010202<br /> RAX: 0000000000000001 RBX: ffff88814aabc000 RCX: dffffc0000000000<br /> RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffffff90e18120<br /> RBP: 0000000000000008 R08: dffffc0000000000 R09: fffffbfff21c3025<br /> R10: fffffbfff21c3025 R11: 0000000000000000 R12: ffffffff8d109840<br /> R13: 0000000000001002 R14: 0000000000000001 R15: 0000000000000001<br /> FS: 0000555556e08300(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fc74416f130 CR3: 0000000073d9e000 CR4: 00000000003506e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mctp: fix use after free<br /> <br /> Clang static analysis reports this problem<br /> route.c:425:4: warning: Use of memory after it is freed<br /> trace_mctp_key_acquire(key);<br /> ^~~~~~~~~~~~~~~~~~~~~~~~~~~<br /> When mctp_key_add() fails, key is freed but then is later<br /> used in trace_mctp_key_acquire(). Add an else statement<br /> to use the key only when mctp_key_add() is successful.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: lantiq_gswip: fix use after free in gswip_remove()<br /> <br /> of_node_put(priv-&gt;ds-&gt;slave_mii_bus-&gt;dev.of_node) should be<br /> done before mdiobus_free(priv-&gt;ds-&gt;slave_mii_bus).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cfg80211: fix race in netlink owner interface destruction<br /> <br /> My previous fix here to fix the deadlock left a race where<br /> the exact same deadlock (see the original commit referenced<br /> below) can still happen if cfg80211_destroy_ifaces() already<br /> runs while nl80211_netlink_notify() is still marking some<br /> interfaces as nl_owner_dead.<br /> <br /> The race happens because we have two loops here - first we<br /> dev_close() all the netdevs, and then we destroy them. If we<br /> also have two netdevs (first one need only be a wdev though)<br /> then we can find one during the first iteration, close it,<br /> and go to the second iteration -- but then find two, and try<br /> to destroy also the one we didn&amp;#39;t close yet.<br /> <br /> Fix this by only iterating once.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: mcast: use rcu-safe version of ipv6_get_lladdr()<br /> <br /> Some time ago 8965779d2c0e ("ipv6,mcast: always hold idev-&gt;lock before mca_lock")<br /> switched ipv6_get_lladdr() to __ipv6_get_lladdr(), which is rcu-unsafe<br /> version. That was OK, because idev-&gt;lock was held for these codepaths.<br /> <br /> In 88e2ca308094 ("mld: convert ifmcaddr6 to RCU") these external locks were<br /> removed, so we probably need to restore the original rcu-safe call.<br /> <br /> Otherwise, we occasionally get a machine crashed/stalled with the following<br /> in dmesg:<br /> <br /> [ 3405.966610][T230589] general protection fault, probably for non-canonical address 0xdead00000000008c: 0000 [#1] SMP NOPTI<br /> [ 3405.982083][T230589] CPU: 44 PID: 230589 Comm: kworker/44:3 Tainted: G O 5.15.19-cloudflare-2022.2.1 #1<br /> [ 3405.998061][T230589] Hardware name: SUPA-COOL-SERV<br /> [ 3406.009552][T230589] Workqueue: mld mld_ifc_work<br /> [ 3406.017224][T230589] RIP: 0010:__ipv6_get_lladdr+0x34/0x60<br /> [ 3406.025780][T230589] Code: 57 10 48 83 c7 08 48 89 e5 48 39 d7 74 3e 48 8d 82 38 ff ff ff eb 13 48 8b 90 d0 00 00 00 48 8d 82 38 ff ff ff 48 39 d7 74 22 83 78 32 20 77 1b 75 e4 89 ca 23 50 2c 75 dd 48 8b 50 08 48 8b<br /> [ 3406.055748][T230589] RSP: 0018:ffff94e4b3fc3d10 EFLAGS: 00010202<br /> [ 3406.065617][T230589] RAX: dead00000000005a RBX: ffff94e4b3fc3d30 RCX: 0000000000000040<br /> [ 3406.077477][T230589] RDX: dead000000000122 RSI: ffff94e4b3fc3d30 RDI: ffff8c3a31431008<br /> [ 3406.089389][T230589] RBP: ffff94e4b3fc3d10 R08: 0000000000000000 R09: 0000000000000000<br /> [ 3406.101445][T230589] R10: ffff8c3a31430000 R11: 000000000000000b R12: ffff8c2c37887100<br /> [ 3406.113553][T230589] R13: ffff8c3a39537000 R14: 00000000000005dc R15: ffff8c3a31431000<br /> [ 3406.125730][T230589] FS: 0000000000000000(0000) GS:ffff8c3b9fc80000(0000) knlGS:0000000000000000<br /> [ 3406.138992][T230589] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 3406.149895][T230589] CR2: 00007f0dfea1db60 CR3: 000000387b5f2000 CR4: 0000000000350ee0<br /> [ 3406.162421][T230589] Call Trace:<br /> [ 3406.170235][T230589] <br /> [ 3406.177736][T230589] mld_newpack+0xfe/0x1a0<br /> [ 3406.186686][T230589] add_grhead+0x87/0xa0<br /> [ 3406.195498][T230589] add_grec+0x485/0x4e0<br /> [ 3406.204310][T230589] ? newidle_balance+0x126/0x3f0<br /> [ 3406.214024][T230589] mld_ifc_work+0x15d/0x450<br /> [ 3406.223279][T230589] process_one_work+0x1e6/0x380<br /> [ 3406.232982][T230589] worker_thread+0x50/0x3a0<br /> [ 3406.242371][T230589] ? rescuer_thread+0x360/0x360<br /> [ 3406.252175][T230589] kthread+0x127/0x150<br /> [ 3406.261197][T230589] ? set_kthread_struct+0x40/0x40<br /> [ 3406.271287][T230589] ret_from_fork+0x22/0x30<br /> [ 3406.280812][T230589] <br /> [ 3406.288937][T230589] Modules linked in: ... [last unloaded: kheaders]<br /> [ 3406.476714][T230589] ---[ end trace 3525a7655f2f3b9e ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock: remove vsock from connected table when connect is interrupted by a signal<br /> <br /> vsock_connect() expects that the socket could already be in the<br /> TCP_ESTABLISHED state when the connecting task wakes up with a signal<br /> pending. If this happens the socket will be in the connected table, and<br /> it is not removed when the socket state is reset. In this situation it&amp;#39;s<br /> common for the process to retry connect(), and if the connection is<br /> successful the socket will be added to the connected table a second<br /> time, corrupting the list.<br /> <br /> Prevent this by calling vsock_remove_connected() if a signal is received<br /> while waiting for a connection. This is harmless if the socket is not in<br /> the connected table, and if it is in the table then removing it will<br /> prevent list corruption from a double add.<br /> <br /> Note for backporting: this patch requires d5afa82c977e ("vsock: correct<br /> removal of socket from the list"), which is in all current stable trees<br /> except 4.9.y.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iwlwifi: fix use-after-free<br /> <br /> If no firmware was present at all (or, presumably, all of the<br /> firmware files failed to parse), we end up unbinding by calling<br /> device_release_driver(), which calls remove(), which then in<br /> iwlwifi calls iwl_drv_stop(), freeing the &amp;#39;drv&amp;#39; struct. However<br /> the new code I added will still erroneously access it after it<br /> was freed.<br /> <br /> Set &amp;#39;failure=false&amp;#39; in this case to avoid the access, all data<br /> was already freed anyway.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-rdma: fix possible use-after-free in transport error_recovery work<br /> <br /> While nvme_rdma_submit_async_event_work is checking the ctrl and queue<br /> state before preparing the AER command and scheduling io_work, in order<br /> to fully prevent a race where this check is not reliable the error<br /> recovery work must flush async_event_work before continuing to destroy<br /> the admin queue after setting the ctrl state to RESETTING such that<br /> there is no race .submit_async_event and the error recovery handler<br /> itself changing the ctrl state.