CVSS: -EPSS: 0%CPEs: 10EXPL: 0CVE-2024-50040 – igb: Do not bring the device up after non-fatal error
https://notcve.org/view.php?id=CVE-2024-50040
In the Linux kernel, the following vulnerability has been resolved: igb: Do not bring the device up after non-fatal error Commit 004d25060c78 ("igb: Fix igb_down hung on surprise removal") changed igb_io_error_detected() to ignore non-fatal pcie errors in order to avoid hung task that can happen when igb_down() is called multiple times. This caused an issue when processing transient non-fatal errors. igb_io_resume(), which is called after igb_io_error_detected(), assumes that device is brought down by igb_io_error_detected() if the interface is up. This resulted in panic with stacktrace below. [ T3256] igb 0000:09:00.0 haeth0: igb: haeth0 NIC Link is Down [ T292] pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:09:00.0 [ T292] igb 0000:09:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID) [ T292] igb 0000:09:00.0: device [8086:1537] error status/mask=00004000/00000000 [ T292] igb 0000:09:00.0: [14] CmpltTO [ 200.105524,009][ T292] igb 0000:09:00.0: AER: TLP Header: 00000000 00000000 00000000 00000000 [ T292] pcieport 0000:00:1c.5: AER: broadcast error_detected message [ T292] igb 0000:09:00.0: Non-correctable non-fatal error reported. [ T292] pcieport 0000:00:1c.5: AER: broadcast mmio_enabled message [ T292] pcieport 0000:00:1c.5: AER: broadcast resume message [ T292] ------------[ cut here ]------------ [ T292] kernel BUG at net/core/dev.c:6539! [ T292] invalid opcode: 0000 [#1] PREEMPT SMP [ T292] RIP: 0010:napi_enable+0x37/0x40 [ T292] Call Trace: [ T292] <TASK> [ T292] ? die+0x33/0x90 [ T292] ? • https://git.kernel.org/stable/c/994c2ceb70ea99264ccc6f09e6703ca267dad63c https://git.kernel.org/stable/c/fa92c463eba75dcedbd8d689ffdcb83293aaa0c3 https://git.kernel.org/stable/c/39695e87d86f0e7d897fba1d2559f825aa20caeb https://git.kernel.org/stable/c/004d25060c78fc31f66da0fa439c544dda1ac9d5 https://git.kernel.org/stable/c/c2312e1d12b1c3ee4100c173131b102e2aed4d04 https://git.kernel.org/stable/c/124e39a734cb90658b8f0dc110847bbfc6e33792 https://git.kernel.org/stable/c/c9f56f3c7bc908caa772112d3ae71cdd5d18c257 https://git.kernel.org/stable/c/41f63b72a01c0e0ac59ab83fd2d921fcc •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50039 – net/sched: accept TCA_STAB only for root qdisc
https://notcve.org/view.php?id=CVE-2024-50039
In the Linux kernel, the following vulnerability has been resolved: net/sched: accept TCA_STAB only for root qdisc Most qdiscs maintain their backlog using qdisc_pkt_len(skb) on the assumption it is invariant between the enqueue() and dequeue() handlers. Unfortunately syzbot can crash a host rather easily using a TBF + SFQ combination, with an STAB on SFQ [1] We can't support TCA_STAB on arbitrary level, this would require to maintain per-qdisc storage. [1] [ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 88.798611] #PF: supervisor read access in kernel mode [ 88.799014] #PF: error_code(0x0000) - not-present page [ 88.799506] PGD 0 P4D 0 [ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI [ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117 [ 88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00 All code ======== 0: 0f b7 50 12 movzwl 0x12(%rax),%edx 4: 48 8d 04 d5 00 00 00 lea 0x0(,%rdx,8),%rax b: 00 c: 48 89 d6 mov %rdx,%rsi f: 48 29 d0 sub %rdx,%rax 12: 48 8b 91 c0 01 00 00 mov 0x1c0(%rcx),%rdx 19: 48 c1 e0 03 shl $0x3,%rax 1d: 48 01 c2 add %rax,%rdx 20: 66 83 7a 1a 00 cmpw $0x0,0x1a(%rdx) 25: 7e c0 jle 0xffffffffffffffe7 27: 48 8b 3a mov (%rdx),%rdi 2a:* 4c 8b 07 mov (%rdi),%r8 <-- trapping instruction 2d: 4c 89 02 mov %r8,(%rdx) 30: 49 89 50 08 mov %rdx,0x8(%r8) 34: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi) 3b: 00 3c: 48 rex.W 3d: c7 .byte 0xc7 3e: 07 (bad) ... Code starting with the faulting instruction =========================================== 0: 4c 8b 07 mov (%rdi),%r8 3: 4c 89 02 mov %r8,(%rdx) 6: 49 89 50 08 mov %rdx,0x8(%r8) a: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi) 11: 00 12: 48 rex.W 13: c7 .byte 0xc7 14: 07 (bad) ... [ 88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206 [ 88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800 [ 88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000 [ 88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f [ 88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140 [ 88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac [ 88.806734] FS: 00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000 [ 88.807225] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0 [ 88.808165] Call Trace: [ 88.808459] <TASK> [ 88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715) [ 88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 . • https://git.kernel.org/stable/c/175f9c1bba9b825d22b142d183c9e175488b260c https://git.kernel.org/stable/c/adbc3eef43fc94c7c8436da832691ae02333a972 https://git.kernel.org/stable/c/8fb6503592d39065316f45d267c5527b4e7cd995 https://git.kernel.org/stable/c/76feedc74b90270390fbfdf74a2e944e96872363 https://git.kernel.org/stable/c/1edf039ee01788ffc25625fe58a903ae2efa213e https://git.kernel.org/stable/c/3dc6ee96473cc2962c6db4297d4631f261be150f https://git.kernel.org/stable/c/3cb7cf1540ddff5473d6baeb530228d19bc97b8a •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-50038 – netfilter: xtables: avoid NFPROTO_UNSPEC where needed
https://notcve.org/view.php?id=CVE-2024-50038
In the Linux kernel, the following vulnerability has been resolved: netfilter: xtables: avoid NFPROTO_UNSPEC where needed syzbot managed to call xt_cluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40 Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet processing. As this is only useful to restrict locally terminating TCP/UDP traffic, register this for ipv4 and ipv6 family only. Pablo points out that this is a general issue, direct users of the set/getsockopt interface can call into targets/matches that were only intended for use with ip(6)tables. Check all UNSPEC matches and targets for similar issues: - matches and targets are fine except if they assume skb_network_header() is valid -- this is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area. - targets that return XT_CONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBT_CONTINUE is a completely different value than XT_CONTINUE. Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, as they are provided for use by ip(6)tables. The MARK target is also used by arptables, so register for NFPROTO_ARP too. While at it, bail out if connbytes fails to enable the corresponding conntrack family. This change passes the selftests in iptables.git. • https://git.kernel.org/stable/c/0269ea4937343536ec7e85649932bc8c9686ea78 https://git.kernel.org/stable/c/85ff9a0f793ca52c527e75cd40a69c948627ebde https://git.kernel.org/stable/c/8f482bb7e27b37f1f734bb9a8eeb28b23d59d189 https://git.kernel.org/stable/c/997f67d813ce0cf5eb3cdb8f124da68141e91b6c https://git.kernel.org/stable/c/4cdc55ec6222bb195995cc58f7cb46e4d8907056 https://git.kernel.org/stable/c/0bfcb7b71e735560077a42847f69597ec7dcc326 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50037 – drm/fbdev-dma: Only cleanup deferred I/O if necessary
https://notcve.org/view.php?id=CVE-2024-50037
In the Linux kernel, the following vulnerability has been resolved: drm/fbdev-dma: Only cleanup deferred I/O if necessary Commit 5a498d4d06d6 ("drm/fbdev-dma: Only install deferred I/O if necessary") initializes deferred I/O only if it is used. drm_fbdev_dma_fb_destroy() however calls fb_deferred_io_cleanup() unconditionally with struct fb_info.fbdefio == NULL. KASAN with the out-of-tree Apple silicon display driver posts following warning from __flush_work() of a random struct work_struct instead of the expected NULL pointer derefs. [ 22.053799] ------------[ cut here ]------------ [ 22.054832] WARNING: CPU: 2 PID: 1 at kernel/workqueue.c:4177 __flush_work+0x4d8/0x580 [ 22.056597] Modules linked in: uhid bnep uinput nls_ascii ip6_tables ip_tables i2c_dev loop fuse dm_multipath nfnetlink zram hid_magicmouse btrfs xor xor_neon brcmfmac_wcc raid6_pq hci_bcm4377 bluetooth brcmfmac hid_apple brcmutil nvmem_spmi_mfd simple_mfd_spmi dockchannel_hid cfg80211 joydev regmap_spmi nvme_apple ecdh_generic ecc macsmc_hid rfkill dwc3 appledrm snd_soc_macaudio macsmc_power nvme_core apple_isp phy_apple_atc apple_sart apple_rtkit_helper apple_dockchannel tps6598x macsmc_hwmon snd_soc_cs42l84 videobuf2_v4l2 spmi_apple_controller nvmem_apple_efuses videobuf2_dma_sg apple_z2 videobuf2_memops spi_nor panel_summit videobuf2_common asahi videodev pwm_apple apple_dcp snd_soc_apple_mca apple_admac spi_apple clk_apple_nco i2c_pasemi_platform snd_pcm_dmaengine mc i2c_pasemi_core mux_core ofpart adpdrm drm_dma_helper apple_dart apple_soc_cpufreq leds_pwm phram [ 22.073768] CPU: 2 UID: 0 PID: 1 Comm: systemd-shutdow Not tainted 6.11.2-asahi+ #asahi-dev [ 22.075612] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT) [ 22.077032] pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 22.078567] pc : __flush_work+0x4d8/0x580 [ 22.079471] lr : __flush_work+0x54/0x580 [ 22.080345] sp : ffffc000836ef820 [ 22.081089] x29: ffffc000836ef880 x28: 0000000000000000 x27: ffff80002ddb7128 [ 22.082678] x26: dfffc00000000000 x25: 1ffff000096f0c57 x24: ffffc00082d3e358 [ 22.084263] x23: ffff80004b7862b8 x22: dfffc00000000000 x21: ffff80005aa1d470 [ 22.085855] x20: ffff80004b786000 x19: ffff80004b7862a0 x18: 0000000000000000 [ 22.087439] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000005 [ 22.089030] x14: 1ffff800106ddf0a x13: 0000000000000000 x12: 0000000000000000 [ 22.090618] x11: ffffb800106ddf0f x10: dfffc00000000000 x9 : 1ffff800106ddf0e [ 22.092206] x8 : 0000000000000000 x7 : aaaaaaaaaaaaaaaa x6 : 0000000000000001 [ 22.093790] x5 : ffffc000836ef728 x4 : 0000000000000000 x3 : 0000000000000020 [ 22.095368] x2 : 0000000000000008 x1 : 00000000000000aa x0 : 0000000000000000 [ 22.096955] Call trace: [ 22.097505] __flush_work+0x4d8/0x580 [ 22.098330] flush_delayed_work+0x80/0xb8 [ 22.099231] fb_deferred_io_cleanup+0x3c/0x130 [ 22.100217] drm_fbdev_dma_fb_destroy+0x6c/0xe0 [drm_dma_helper] [ 22.101559] unregister_framebuffer+0x210/0x2f0 [ 22.102575] drm_fb_helper_unregister_info+0x48/0x60 [ 22.103683] drm_fbdev_dma_client_unregister+0x4c/0x80 [drm_dma_helper] [ 22.105147] drm_client_dev_unregister+0x1cc/0x230 [ 22.106217] drm_dev_unregister+0x58/0x570 [ 22.107125] apple_drm_unbind+0x50/0x98 [appledrm] [ 22.108199] component_del+0x1f8/0x3a8 [ 22.109042] dcp_platform_shutdown+0x24/0x38 [apple_dcp] [ 22.110357] platform_shutdown+0x70/0x90 [ 22.111219] device_shutdown+0x368/0x4d8 [ 22.112095] kernel_restart+0x6c/0x1d0 [ 22.112946] __arm64_sys_reboot+0x1c8/0x328 [ 22.113868] invoke_syscall+0x78/0x1a8 [ 22.114703] do_el0_svc+0x124/0x1a0 [ 22.115498] el0_svc+0x3c/0xe0 [ 22.116181] el0t_64_sync_handler+0x70/0xc0 [ 22.117110] el0t_64_sync+0x190/0x198 [ 22.117931] ---[ end trace 0000000000000000 ]--- • https://git.kernel.org/stable/c/5a498d4d06d6d9bad76d8a50a7f8fe01670ad46f https://git.kernel.org/stable/c/5a4a8ea14c54c651ec532a480bd560d0c6e52f3d https://git.kernel.org/stable/c/fcddc71ec7ecf15b4df3c41288c9cf0b8e886111 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-50036 – net: do not delay dst_entries_add() in dst_release()
https://notcve.org/view.php?id=CVE-2024-50036
In the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels. • https://git.kernel.org/stable/c/f88649721268999bdff09777847080a52004f691 https://git.kernel.org/stable/c/86e48c03d774e01ccd71ecba4fc4b5c2bc0b5b41 https://git.kernel.org/stable/c/591b1e1bb40152e22cee757f493046a0ca946bf8 https://git.kernel.org/stable/c/df90819dafcd6b97fc665f63a15752a570e227a2 https://git.kernel.org/stable/c/9a4fe697023dbe6c25caa1f8b2153af869a29bd2 https://git.kernel.org/stable/c/eae7435b48ffc8e9be0ff9cfeae40af479a609dd https://git.kernel.org/stable/c/3c7c918ec0aa3555372c5a57f18780b7a96c5cfc https://git.kernel.org/stable/c/ac888d58869bb99753e7652be19a151df •