Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Detect IP == ksym.end as part of BPF program<br /> <br /> Now that bpf_throw kfunc is the first such call instruction that has<br /> noreturn semantics within the verifier, this also kicks in dead code<br /> elimination in unprecedented ways. For one, any instruction following<br /> a bpf_throw call will never be marked as seen. Moreover, if a callchain<br /> ends up throwing, any instructions after the call instruction to the<br /> eventually throwing subprog in callers will also never be marked as<br /> seen.<br /> <br /> The tempting way to fix this would be to emit extra &amp;#39;int3&amp;#39; instructions<br /> which bump the jited_len of a program, and ensure that during runtime<br /> when a program throws, we can discover its boundaries even if the call<br /> instruction to bpf_throw (or to subprogs that always throw) is emitted<br /> as the final instruction in the program.<br /> <br /> An example of such a program would be this:<br /> <br /> do_something():<br /> ...<br /> r0 = 0<br /> exit<br /> <br /> foo():<br /> r1 = 0<br /> call bpf_throw<br /> r0 = 0<br /> exit<br /> <br /> bar(cond):<br /> if r1 != 0 goto pc+2<br /> call do_something<br /> exit<br /> call foo<br /> r0 = 0 // Never seen by verifier<br /> exit //<br /> <br /> main(ctx):<br /> r1 = ...<br /> call bar<br /> r0 = 0<br /> exit<br /> <br /> Here, if we do end up throwing, the stacktrace would be the following:<br /> <br /> bpf_throw<br /> foo<br /> bar<br /> main<br /> <br /> In bar, the final instruction emitted will be the call to foo, as such,<br /> the return address will be the subsequent instruction (which the JIT<br /> emits as int3 on x86). This will end up lying outside the jited_len of<br /> the program, thus, when unwinding, we will fail to discover the return<br /> address as belonging to any program and end up in a panic due to the<br /> unreliable stack unwinding of BPF programs that we never expect.<br /> <br /> To remedy this case, make bpf_prog_ksym_find treat IP == ksym.end as<br /> part of the BPF program, so that is_bpf_text_address returns true when<br /> such a case occurs, and we are able to unwind reliably when the final<br /> instruction ends up being a call instruction.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: fix possible out-of-bound write in ath12k_wmi_ext_hal_reg_caps()<br /> <br /> reg_cap.phy_id is extracted from WMI event and could be an unexpected value<br /> in case some errors happen. As a result out-of-bound write may occur to<br /> soc-&gt;hal_reg_cap. Fix it by validating reg_cap.phy_id before using it.<br /> <br /> This is found during code review.<br /> <br /> Compile tested only.

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 /> cpu/hotplug: Don&amp;#39;t offline the last non-isolated CPU<br /> <br /> If a system has isolated CPUs via the "isolcpus=" command line parameter,<br /> then an attempt to offline the last housekeeping CPU will result in a<br /> WARN_ON() when rebuilding the scheduler domains and a subsequent panic due<br /> to and unhandled empty CPU mas in partition_sched_domains_locked().<br /> <br /> cpuset_hotplug_workfn()<br /> rebuild_sched_domains_locked()<br /> ndoms = generate_sched_domains(&amp;doms, &amp;attr);<br /> cpumask_and(doms[0], top_cpuset.effective_cpus, housekeeping_cpumask(HK_FLAG_DOMAIN));<br /> <br /> Thus results in an empty CPU mask which triggers the warning and then the<br /> subsequent crash:<br /> <br /> WARNING: CPU: 4 PID: 80 at kernel/sched/topology.c:2366 build_sched_domains+0x120c/0x1408<br /> Call trace:<br /> build_sched_domains+0x120c/0x1408<br /> partition_sched_domains_locked+0x234/0x880<br /> rebuild_sched_domains_locked+0x37c/0x798<br /> rebuild_sched_domains+0x30/0x58<br /> cpuset_hotplug_workfn+0x2a8/0x930<br /> <br /> Unable to handle kernel paging request at virtual address fffe80027ab37080<br /> partition_sched_domains_locked+0x318/0x880<br /> rebuild_sched_domains_locked+0x37c/0x798<br /> <br /> Aside of the resulting crash, it does not make any sense to offline the last<br /> last housekeeping CPU.<br /> <br /> Prevent this by masking out the non-housekeeping CPUs when selecting a<br /> target CPU for initiating the CPU unplug operation via the work queue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btusb: Add date-&gt;evt_skb is NULL check<br /> <br /> fix crash because of null pointers<br /> <br /> [ 6104.969662] BUG: kernel NULL pointer dereference, address: 00000000000000c8<br /> [ 6104.969667] #PF: supervisor read access in kernel mode<br /> [ 6104.969668] #PF: error_code(0x0000) - not-present page<br /> [ 6104.969670] PGD 0 P4D 0<br /> [ 6104.969673] Oops: 0000 [#1] SMP NOPTI<br /> [ 6104.969684] RIP: 0010:btusb_mtk_hci_wmt_sync+0x144/0x220 [btusb]<br /> [ 6104.969688] RSP: 0018:ffffb8d681533d48 EFLAGS: 00010246<br /> [ 6104.969689] RAX: 0000000000000000 RBX: ffff8ad560bb2000 RCX: 0000000000000006<br /> [ 6104.969691] RDX: 0000000000000000 RSI: ffffb8d681533d08 RDI: 0000000000000000<br /> [ 6104.969692] RBP: ffffb8d681533d70 R08: 0000000000000001 R09: 0000000000000001<br /> [ 6104.969694] R10: 0000000000000001 R11: 00000000fa83b2da R12: ffff8ad461d1d7c0<br /> [ 6104.969695] R13: 0000000000000000 R14: ffff8ad459618c18 R15: ffffb8d681533d90<br /> [ 6104.969697] FS: 00007f5a1cab9d40(0000) GS:ffff8ad578200000(0000) knlGS:00000<br /> [ 6104.969699] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 6104.969700] CR2: 00000000000000c8 CR3: 000000018620c001 CR4: 0000000000760ef0<br /> [ 6104.969701] PKRU: 55555554<br /> [ 6104.969702] Call Trace:<br /> [ 6104.969708] btusb_mtk_shutdown+0x44/0x80 [btusb]<br /> [ 6104.969732] hci_dev_do_close+0x470/0x5c0 [bluetooth]<br /> [ 6104.969748] hci_rfkill_set_block+0x56/0xa0 [bluetooth]<br /> [ 6104.969753] rfkill_set_block+0x92/0x160<br /> [ 6104.969755] rfkill_fop_write+0x136/0x1e0<br /> [ 6104.969759] __vfs_write+0x18/0x40<br /> [ 6104.969761] vfs_write+0xdf/0x1c0<br /> [ 6104.969763] ksys_write+0xb1/0xe0<br /> [ 6104.969765] __x64_sys_write+0x1a/0x20<br /> [ 6104.969769] do_syscall_64+0x51/0x180<br /> [ 6104.969771] entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> [ 6104.969773] RIP: 0033:0x7f5a21f18fef<br /> [ 6104.9] RSP: 002b:00007ffeefe39010 EFLAGS: 00000293 ORIG_RAX: 0000000000000001<br /> [ 6104.969780] RAX: ffffffffffffffda RBX: 000055c10a7560a0 RCX: 00007f5a21f18fef<br /> [ 6104.969781] RDX: 0000000000000008 RSI: 00007ffeefe39060 RDI: 0000000000000012<br /> [ 6104.969782] RBP: 00007ffeefe39060 R08: 0000000000000000 R09: 0000000000000017<br /> [ 6104.969784] R10: 00007ffeefe38d97 R11: 0000000000000293 R12: 0000000000000002<br /> [ 6104.969785] R13: 00007ffeefe39220 R14: 00007ffeefe391a0 R15: 000055c10a72acf0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> atl1c: Work around the DMA RX overflow issue<br /> <br /> This is based on alx driver commit 881d0327db37 ("net: alx: Work around<br /> the DMA RX overflow issue").<br /> <br /> The alx and atl1c drivers had RX overflow error which was why a custom<br /> allocator was created to avoid certain addresses. The simpler workaround<br /> then created for alx driver, but not for atl1c due to lack of tester.<br /> <br /> Instead of using a custom allocator, check the allocated skb address and<br /> use skb_reserve() to move away from problematic 0x...fc0 address.<br /> <br /> Tested on AR8131 on Acer 4540.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: don&amp;#39;t return unset power in ieee80211_get_tx_power()<br /> <br /> We can get a UBSAN warning if ieee80211_get_tx_power() returns the<br /> INT_MIN value mac80211 internally uses for "unset power level".<br /> <br /> UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5<br /> -2147483648 * 100 cannot be represented in type &amp;#39;int&amp;#39;<br /> CPU: 0 PID: 20433 Comm: insmod Tainted: G WC OE<br /> Call Trace:<br /> dump_stack+0x74/0x92<br /> ubsan_epilogue+0x9/0x50<br /> handle_overflow+0x8d/0xd0<br /> __ubsan_handle_mul_overflow+0xe/0x10<br /> nl80211_send_iface+0x688/0x6b0 [cfg80211]<br /> [...]<br /> cfg80211_register_wdev+0x78/0xb0 [cfg80211]<br /> cfg80211_netdev_notifier_call+0x200/0x620 [cfg80211]<br /> [...]<br /> ieee80211_if_add+0x60e/0x8f0 [mac80211]<br /> ieee80211_register_hw+0xda5/0x1170 [mac80211]<br /> <br /> In this case, simply return an error instead, to indicate<br /> that no data is available.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hns3: fix out-of-bounds access may occur when coalesce info is read via debugfs<br /> <br /> The hns3 driver define an array of string to show the coalesce<br /> info, but if the kernel adds a new mode or a new state,<br /> out-of-bounds access may occur when coalesce info is read via<br /> debugfs, this patch fix the problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: hisi_sas: Set debugfs_dir pointer to NULL after removing debugfs<br /> <br /> If init debugfs failed during device registration due to memory allocation<br /> failure, debugfs_remove_recursive() is called, after which debugfs_dir is<br /> not set to NULL. debugfs_remove_recursive() will be called again during<br /> device removal. As a result, illegal pointer is accessed.<br /> <br /> [ 1665.467244] hisi_sas_v3_hw 0000:b4:02.0: failed to init debugfs!<br /> ...<br /> [ 1669.836708] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0<br /> [ 1669.872669] pc : down_write+0x24/0x70<br /> [ 1669.876315] lr : down_write+0x1c/0x70<br /> [ 1669.879961] sp : ffff000036f53a30<br /> [ 1669.883260] x29: ffff000036f53a30 x28: ffffa027c31549f8<br /> [ 1669.888547] x27: ffffa027c3140000 x26: 0000000000000000<br /> [ 1669.893834] x25: ffffa027bf37c270 x24: ffffa027bf37c270<br /> [ 1669.899122] x23: ffff0000095406b8 x22: ffff0000095406a8<br /> [ 1669.904408] x21: 0000000000000000 x20: ffffa027bf37c310<br /> [ 1669.909695] x19: 00000000000000a0 x18: ffff8027dcd86f10<br /> [ 1669.914982] x17: 0000000000000000 x16: 0000000000000000<br /> [ 1669.920268] x15: 0000000000000000 x14: ffffa0274014f870<br /> [ 1669.925555] x13: 0000000000000040 x12: 0000000000000228<br /> [ 1669.930842] x11: 0000000000000020 x10: 0000000000000bb0<br /> [ 1669.936129] x9 : ffff000036f537f0 x8 : ffff80273088ca10<br /> [ 1669.941416] x7 : 000000000000001d x6 : 00000000ffffffff<br /> [ 1669.946702] x5 : ffff000008a36310 x4 : ffff80273088be00<br /> [ 1669.951989] x3 : ffff000009513e90 x2 : 0000000000000000<br /> [ 1669.957276] x1 : 00000000000000a0 x0 : ffffffff00000001<br /> [ 1669.962563] Call trace:<br /> [ 1669.965000] down_write+0x24/0x70<br /> [ 1669.968301] debugfs_remove_recursive+0x5c/0x1b0<br /> [ 1669.972905] hisi_sas_debugfs_exit+0x24/0x30 [hisi_sas_main]<br /> [ 1669.978541] hisi_sas_v3_remove+0x130/0x150 [hisi_sas_v3_hw]<br /> [ 1669.984175] pci_device_remove+0x48/0xd8<br /> [ 1669.988082] device_release_driver_internal+0x1b4/0x250<br /> [ 1669.993282] device_release_driver+0x28/0x38<br /> [ 1669.997534] pci_stop_bus_device+0x84/0xb8<br /> [ 1670.001611] pci_stop_and_remove_bus_device_locked+0x24/0x40<br /> [ 1670.007244] remove_store+0xfc/0x140<br /> [ 1670.010802] dev_attr_store+0x44/0x60<br /> [ 1670.014448] sysfs_kf_write+0x58/0x80<br /> [ 1670.018095] kernfs_fop_write+0xe8/0x1f0<br /> [ 1670.022000] __vfs_write+0x60/0x190<br /> [ 1670.025472] vfs_write+0xac/0x1c0<br /> [ 1670.028771] ksys_write+0x6c/0xd8<br /> [ 1670.032071] __arm64_sys_write+0x24/0x30<br /> [ 1670.035977] el0_svc_common+0x78/0x130<br /> [ 1670.039710] el0_svc_handler+0x38/0x78<br /> [ 1670.043442] el0_svc+0x8/0xc<br /> <br /> To fix this, set debugfs_dir to NULL after debugfs_remove_recursive().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup()<br /> <br /> fc_lport_ptp_setup() did not check the return value of fc_rport_create()<br /> which can return NULL and would cause a NULL pointer dereference. Address<br /> this issue by checking return value of fc_rport_create() and log error<br /> message on fc_rport_create() failed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/jfs: Add check for negative db_l2nbperpage<br /> <br /> l2nbperpage is log2(number of blks per page), and the minimum legal<br /> value should be 0, not negative.<br /> <br /> In the case of l2nbperpage being negative, an error will occur<br /> when subsequently used as shift exponent.<br /> <br /> Syzbot reported this bug:<br /> <br /> UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:799:12<br /> shift exponent -16777216 is negative

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ibmvfc: Remove BUG_ON in the case of an empty event pool<br /> <br /> In practice the driver should never send more commands than are allocated<br /> to a queue&amp;#39;s event pool. In the unlikely event that this happens, the code<br /> asserts a BUG_ON, and in the case that the kernel is not configured to<br /> crash on panic returns a junk event pointer from the empty event list<br /> causing things to spiral from there. This BUG_ON is a historical artifact<br /> of the ibmvfc driver first being upstreamed, and it is well known now that<br /> the use of BUG_ON is bad practice except in the most unrecoverable<br /> scenario. There is nothing about this scenario that prevents the driver<br /> from recovering and carrying on.<br /> <br /> Remove the BUG_ON in question from ibmvfc_get_event() and return a NULL<br /> pointer in the case of an empty event pool. Update all call sites to<br /> ibmvfc_get_event() to check for a NULL pointer and perfrom the appropriate<br /> failure or recovery action.