Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: Fix u8 overflow<br /> <br /> By keep sending L2CAP_CONF_REQ packets, chan-&gt;num_conf_rsp increases<br /> multiple times and eventually it will wrap around the maximum number<br /> (i.e., 255).<br /> This patch prevents this by adding a boundary check with<br /> L2CAP_MAX_CONF_RSP<br /> <br /> Btmon log:<br /> Bluetooth monitor ver 5.64<br /> = Note: Linux version 6.1.0-rc2 (x86_64) 0.264594<br /> = Note: Bluetooth subsystem version 2.22 0.264636<br /> @ MGMT Open: btmon (privileged) version 1.22 {0x0001} 0.272191<br /> = New Index: 00:00:00:00:00:00 (Primary,Virtual,hci0) [hci0] 13.877604<br /> @ RAW Open: 9496 (privileged) version 2.22 {0x0002} 13.890741<br /> = Open Index: 00:00:00:00:00:00 [hci0] 13.900426<br /> (...)<br /> &gt; ACL Data RX: Handle 200 flags 0x00 dlen 1033 #32 [hci0] 14.273106<br /> invalid packet size (12 != 1033)<br /> 08 00 01 00 02 01 04 00 01 10 ff ff ............<br /> &gt; ACL Data RX: Handle 200 flags 0x00 dlen 1547 #33 [hci0] 14.273561<br /> invalid packet size (14 != 1547)<br /> 0a 00 01 00 04 01 06 00 40 00 00 00 00 00 ........@.....<br /> &gt; ACL Data RX: Handle 200 flags 0x00 dlen 2061 #34 [hci0] 14.274390<br /> invalid packet size (16 != 2061)<br /> 0c 00 01 00 04 01 08 00 40 00 00 00 00 00 00 04 ........@.......<br /> &gt; ACL Data RX: Handle 200 flags 0x00 dlen 2061 #35 [hci0] 14.274932<br /> invalid packet size (16 != 2061)<br /> 0c 00 01 00 04 01 08 00 40 00 00 00 07 00 03 00 ........@.......<br /> = bluetoothd: Bluetooth daemon 5.43 14.401828<br /> &gt; ACL Data RX: Handle 200 flags 0x00 dlen 1033 #36 [hci0] 14.275753<br /> invalid packet size (12 != 1033)<br /> 08 00 01 00 04 01 04 00 40 00 00 00 ........@...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: uvc: Prevent buffer overflow in setup handler<br /> <br /> Setup function uvc_function_setup permits control transfer<br /> requests with up to 64 bytes of payload (UVC_MAX_REQUEST_SIZE),<br /> data stage handler for OUT transfer uses memcpy to copy req-&gt;actual<br /> bytes to uvc_event-&gt;data.data array of size 60. This may result<br /> in an overflow of 4 bytes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igb: Initialize mailbox message for VF reset<br /> <br /> When a MAC address is not assigned to the VF, that portion of the message<br /> sent to the VF is not set. The memory, however, is allocated from the<br /> stack meaning that information may be leaked to the VM. Initialize the<br /> message buffer to 0 so that no information is passed to the VM in this<br /> case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: Fix perf_pending_task() UaF<br /> <br /> Per syzbot it is possible for perf_pending_task() to run after the<br /> event is free()&amp;#39;d. There are two related but distinct cases:<br /> <br /> - the task_work was already queued before destroying the event;<br /> - destroying the event itself queues the task_work.<br /> <br /> The first cannot be solved using task_work_cancel() since<br /> perf_release() itself might be called from a task_work (____fput),<br /> which means the current-&gt;task_works list is already empty and<br /> task_work_cancel() won&amp;#39;t be able to find the perf_pending_task()<br /> entry.<br /> <br /> The simplest alternative is extending the perf_event lifetime to cover<br /> the task_work.<br /> <br /> The second is just silly, queueing a task_work while you know the<br /> event is going away makes no sense and is easily avoided by<br /> re-arranging how the event is marked STATE_DEAD and ensuring it goes<br /> through STATE_OFF on the way down.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx()<br /> <br /> The bounds checks in snd_soc_put_volsw_sx() are only being applied to the<br /> first channel, meaning it is possible to write out of bounds values to the<br /> second channel in stereo controls. Add appropriate checks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: mt7621: Add sentinel to quirks table<br /> <br /> Current driver is missing a sentinel in the struct soc_device_attribute<br /> array, which causes an oops when assessed by the<br /> soc_device_match(mt7621_pcie_quirks_match) call.<br /> <br /> This was only exposed once the CONFIG_SOC_MT7621 mt7621 soc_dev_attr<br /> was fixed to register the SOC as a device, in:<br /> <br /> commit 7c18b64bba3b ("mips: ralink: mt7621: do not use kzalloc too early")<br /> <br /> Fix it by adding the required sentinel.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rtc: cmos: Fix event handler registration ordering issue<br /> <br /> Because acpi_install_fixed_event_handler() enables the event<br /> automatically on success, it is incorrect to call it before the<br /> handler routine passed to it is ready to handle events.<br /> <br /> Unfortunately, the rtc-cmos driver does exactly the incorrect thing<br /> by calling cmos_wake_setup(), which passes rtc_handler() to<br /> acpi_install_fixed_event_handler(), before cmos_do_probe(), because<br /> rtc_handler() uses dev_get_drvdata() to get to the cmos object<br /> pointer and the driver data pointer is only populated in<br /> cmos_do_probe().<br /> <br /> This leads to a NULL pointer dereference in rtc_handler() on boot<br /> if the RTC fixed event happens to be active at the init time.<br /> <br /> To address this issue, change the initialization ordering of the<br /> driver so that cmos_wake_setup() is always called after a successful<br /> cmos_do_probe() call.<br /> <br /> While at it, change cmos_pnp_probe() to call cmos_do_probe() after<br /> the initial if () statement used for computing the IRQ argument to<br /> be passed to cmos_do_probe() which is cleaner than calling it in<br /> each branch of that if () (local variable "irq" can be of type int,<br /> because it is passed to that function as an argument of type int).<br /> <br /> Note that commit 6492fed7d8c9 ("rtc: rtc-cmos: Do not check<br /> ACPI_FADT_LOW_POWER_S0") caused this issue to affect a larger number<br /> of systems, because previously it only affected systems with<br /> ACPI_FADT_LOW_POWER_S0 set, but it is present regardless of that<br /> commit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/qeth: fix use-after-free in hsci<br /> <br /> KASAN found that addr was dereferenced after br2dev_event_work was freed.<br /> <br /> ==================================================================<br /> BUG: KASAN: use-after-free in qeth_l2_br2dev_worker+0x5ba/0x6b0<br /> Read of size 1 at addr 00000000fdcea440 by task kworker/u760:4/540<br /> CPU: 17 PID: 540 Comm: kworker/u760:4 Tainted: G E 6.1.0-20221128.rc7.git1.5aa3bed4ce83.300.fc36.s390x+kasan #1<br /> Hardware name: IBM 8561 T01 703 (LPAR)<br /> Workqueue: 0.0.8000_event qeth_l2_br2dev_worker<br /> Call Trace:<br /> [] dump_stack_lvl+0xc6/0xf8<br /> [] print_address_description.constprop.0+0x34/0x2a0<br /> [] print_report+0x110/0x1f8<br /> [] kasan_report+0xfc/0x128<br /> [] qeth_l2_br2dev_worker+0x5ba/0x6b0<br /> [] process_one_work+0x76e/0x1128<br /> [] worker_thread+0x184/0x1098<br /> [] kthread+0x26a/0x310<br /> [] __ret_from_fork+0x8a/0xe8<br /> [] ret_from_fork+0xa/0x40<br /> Allocated by task 108338:<br /> kasan_save_stack+0x40/0x68<br /> kasan_set_track+0x36/0x48<br /> __kasan_kmalloc+0xa0/0xc0<br /> qeth_l2_switchdev_event+0x25a/0x738<br /> atomic_notifier_call_chain+0x9c/0xf8<br /> br_switchdev_fdb_notify+0xf4/0x110<br /> fdb_notify+0x122/0x180<br /> fdb_add_entry.constprop.0.isra.0+0x312/0x558<br /> br_fdb_add+0x59e/0x858<br /> rtnl_fdb_add+0x58a/0x928<br /> rtnetlink_rcv_msg+0x5f8/0x8d8<br /> netlink_rcv_skb+0x1f2/0x408<br /> netlink_unicast+0x570/0x790<br /> netlink_sendmsg+0x752/0xbe0<br /> sock_sendmsg+0xca/0x110<br /> ____sys_sendmsg+0x510/0x6a8<br /> ___sys_sendmsg+0x12a/0x180<br /> __sys_sendmsg+0xe6/0x168<br /> __do_sys_socketcall+0x3c8/0x468<br /> do_syscall+0x22c/0x328<br /> __do_syscall+0x94/0xf0<br /> system_call+0x82/0xb0<br /> Freed by task 540:<br /> kasan_save_stack+0x40/0x68<br /> kasan_set_track+0x36/0x48<br /> kasan_save_free_info+0x4c/0x68<br /> ____kasan_slab_free+0x14e/0x1a8<br /> __kasan_slab_free+0x24/0x30<br /> __kmem_cache_free+0x168/0x338<br /> qeth_l2_br2dev_worker+0x154/0x6b0<br /> process_one_work+0x76e/0x1128<br /> worker_thread+0x184/0x1098<br /> kthread+0x26a/0x310<br /> __ret_from_fork+0x8a/0xe8<br /> ret_from_fork+0xa/0x40<br /> Last potentially related work creation:<br /> kasan_save_stack+0x40/0x68<br /> __kasan_record_aux_stack+0xbe/0xd0<br /> insert_work+0x56/0x2e8<br /> __queue_work+0x4ce/0xd10<br /> queue_work_on+0xf4/0x100<br /> qeth_l2_switchdev_event+0x520/0x738<br /> atomic_notifier_call_chain+0x9c/0xf8<br /> br_switchdev_fdb_notify+0xf4/0x110<br /> fdb_notify+0x122/0x180<br /> fdb_add_entry.constprop.0.isra.0+0x312/0x558<br /> br_fdb_add+0x59e/0x858<br /> rtnl_fdb_add+0x58a/0x928<br /> rtnetlink_rcv_msg+0x5f8/0x8d8<br /> netlink_rcv_skb+0x1f2/0x408<br /> netlink_unicast+0x570/0x790<br /> netlink_sendmsg+0x752/0xbe0<br /> sock_sendmsg+0xca/0x110<br /> ____sys_sendmsg+0x510/0x6a8<br /> ___sys_sendmsg+0x12a/0x180<br /> __sys_sendmsg+0xe6/0x168<br /> __do_sys_socketcall+0x3c8/0x468<br /> do_syscall+0x22c/0x328<br /> __do_syscall+0x94/0xf0<br /> system_call+0x82/0xb0<br /> Second to last potentially related work creation:<br /> kasan_save_stack+0x40/0x68<br /> __kasan_record_aux_stack+0xbe/0xd0<br /> kvfree_call_rcu+0xb2/0x760<br /> kernfs_unlink_open_file+0x348/0x430<br /> kernfs_fop_release+0xc2/0x320<br /> __fput+0x1ae/0x768<br /> task_work_run+0x1bc/0x298<br /> exit_to_user_mode_prepare+0x1a0/0x1a8<br /> __do_syscall+0x94/0xf0<br /> system_call+0x82/0xb0<br /> The buggy address belongs to the object at 00000000fdcea400<br /> which belongs to the cache kmalloc-96 of size 96<br /> The buggy address is located 64 bytes inside of<br /> 96-byte region [00000000fdcea400, 00000000fdcea460)<br /> The buggy address belongs to the physical page:<br /> page:000000005a9c26e8 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xfdcea<br /> flags: 0x3ffff00000000200(slab|node=0|zone=1|lastcpupid=0x1ffff)<br /> raw: 3ffff00000000200 0000000000000000 0000000100000122 000000008008cc00<br /> raw: 0000000000000000 0020004100000000 ffffffff00000001 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> Memory state around the buggy address:<br /> 00000000fdcea300: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc<br /> 00000000fdcea380: fb fb fb fb fb fb f<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: thunderbolt: fix memory leak in tbnet_open()<br /> <br /> When tb_ring_alloc_rx() failed in tbnet_open(), ida that allocated in<br /> tb_xdomain_alloc_out_hopid() is not released. Add<br /> tb_xdomain_release_out_hopid() to the error path to release ida.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: avoid use-after-free in ip6_fragment()<br /> <br /> Blamed commit claimed rcu_read_lock() was held by ip6_fragment() callers.<br /> <br /> It seems to not be always true, at least for UDP stack.<br /> <br /> syzbot reported:<br /> <br /> BUG: KASAN: use-after-free in ip6_dst_idev include/net/ip6_fib.h:245 [inline]<br /> BUG: KASAN: use-after-free in ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951<br /> Read of size 8 at addr ffff88801d403e80 by task syz-executor.3/7618<br /> <br /> CPU: 1 PID: 7618 Comm: syz-executor.3 Not tainted 6.1.0-rc6-syzkaller-00012-g4312098baf37 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106<br /> print_address_description mm/kasan/report.c:284 [inline]<br /> print_report+0x15e/0x45d mm/kasan/report.c:395<br /> kasan_report+0xbf/0x1f0 mm/kasan/report.c:495<br /> ip6_dst_idev include/net/ip6_fib.h:245 [inline]<br /> ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951<br /> __ip6_finish_output net/ipv6/ip6_output.c:193 [inline]<br /> ip6_finish_output+0x9a3/0x1170 net/ipv6/ip6_output.c:206<br /> NF_HOOK_COND include/linux/netfilter.h:291 [inline]<br /> ip6_output+0x1f1/0x540 net/ipv6/ip6_output.c:227<br /> dst_output include/net/dst.h:445 [inline]<br /> ip6_local_out+0xb3/0x1a0 net/ipv6/output_core.c:161<br /> ip6_send_skb+0xbb/0x340 net/ipv6/ip6_output.c:1966<br /> udp_v6_send_skb+0x82a/0x18a0 net/ipv6/udp.c:1286<br /> udp_v6_push_pending_frames+0x140/0x200 net/ipv6/udp.c:1313<br /> udpv6_sendmsg+0x18da/0x2c80 net/ipv6/udp.c:1606<br /> inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg+0xd3/0x120 net/socket.c:734<br /> sock_write_iter+0x295/0x3d0 net/socket.c:1108<br /> call_write_iter include/linux/fs.h:2191 [inline]<br /> new_sync_write fs/read_write.c:491 [inline]<br /> vfs_write+0x9ed/0xdd0 fs/read_write.c:584<br /> ksys_write+0x1ec/0x250 fs/read_write.c:637<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7fde3588c0d9<br /> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 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 b8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007fde365b6168 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 00007fde359ac050 RCX: 00007fde3588c0d9<br /> RDX: 000000000000ffdc RSI: 00000000200000c0 RDI: 000000000000000a<br /> RBP: 00007fde358e7ae9 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007fde35acfb1f R14: 00007fde365b6300 R15: 0000000000022000<br /> <br /> <br /> Allocated by task 7618:<br /> kasan_save_stack+0x22/0x40 mm/kasan/common.c:45<br /> kasan_set_track+0x25/0x30 mm/kasan/common.c:52<br /> __kasan_slab_alloc+0x82/0x90 mm/kasan/common.c:325<br /> kasan_slab_alloc include/linux/kasan.h:201 [inline]<br /> slab_post_alloc_hook mm/slab.h:737 [inline]<br /> slab_alloc_node mm/slub.c:3398 [inline]<br /> slab_alloc mm/slub.c:3406 [inline]<br /> __kmem_cache_alloc_lru mm/slub.c:3413 [inline]<br /> kmem_cache_alloc+0x2b4/0x3d0 mm/slub.c:3422<br /> dst_alloc+0x14a/0x1f0 net/core/dst.c:92<br /> ip6_dst_alloc+0x32/0xa0 net/ipv6/route.c:344<br /> ip6_rt_pcpu_alloc net/ipv6/route.c:1369 [inline]<br /> rt6_make_pcpu_route net/ipv6/route.c:1417 [inline]<br /> ip6_pol_route+0x901/0x1190 net/ipv6/route.c:2254<br /> pol_lookup_func include/net/ip6_fib.h:582 [inline]<br /> fib6_rule_lookup+0x52e/0x6f0 net/ipv6/fib6_rules.c:121<br /> ip6_route_output_flags_noref+0x2e6/0x380 net/ipv6/route.c:2625<br /> ip6_route_output_flags+0x76/0x320 net/ipv6/route.c:2638<br /> ip6_route_output include/net/ip6_route.h:98 [inline]<br /> ip6_dst_lookup_tail+0x5ab/0x1620 net/ipv6/ip6_output.c:1092<br /> ip6_dst_lookup_flow+0x90/0x1d0 net/ipv6/ip6_output.c:1222<br /> ip6_sk_dst_lookup_flow+0x553/0x980 net/ipv6/ip6_output.c:1260<br /> udpv6_sendmsg+0x151d/0x2c80 net/ipv6/udp.c:1554<br /> inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665<br /> sock_sendmsg_nosec n<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/mm/ident_map: Use gbpages only where full GB page should be mapped.<br /> <br /> When ident_pud_init() uses only GB pages to create identity maps, large<br /> ranges of addresses not actually requested can be included in the resulting<br /> table; a 4K request will map a full GB. This can include a lot of extra<br /> address space past that requested, including areas marked reserved by the<br /> BIOS. That allows processor speculation into reserved regions, that on UV<br /> systems can cause system halts.<br /> <br /> Only use GB pages when map creation requests include the full GB page of<br /> space. Fall back to using smaller 2M pages when only portions of a GB page<br /> are included in the request.<br /> <br /> No attempt is made to coalesce mapping requests. If a request requires a<br /> map entry at the 2M (pmd) level, subsequent mapping requests within the<br /> same 1G region will also be at the pmd level, even if adjacent or<br /> overlapping such requests could have been combined to map a full GB page.<br /> Existing usage starts with larger regions and then adds smaller regions, so<br /> this should not have any great consequence.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.