CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-49933 – blk_iocost: fix more out of bound shifts
https://notcve.org/view.php?id=CVE-2024-49933
In the Linux kernel, the following vulnerability has been resolved: blk_iocost: fix more out of bound shifts Recently running UBSAN caught few out of bound shifts in the ioc_forgive_debts() function: UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... Call Trace: <IRQ> dump_stack_lvl+0xca/0x130 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 ? __lock_acquire+0x6441/0x7c10 ioc_timer_fn+0x6cec/0x7750 ? blk_iocost_init+0x720/0x720 ? call_timer_fn+0x5d/0x470 call_timer_fn+0xfa/0x470 ? blk_iocost_init+0x720/0x720 __run_timer_base+0x519/0x700 ... Actual impact of this issue was not identified but I propose to fix the undefined behaviour. The proposed fix to prevent those out of bound shifts consist of precalculating exponent before using it the shift operations by taking min value from the actual exponent and maximum possible number of bits. • https://git.kernel.org/stable/c/1f61d509257d6a05763d05bf37943b35306522b1 https://git.kernel.org/stable/c/f4ef9bef023d5c543cb0f3194ecacfd47ef590ec https://git.kernel.org/stable/c/59121bb38fdc01434ea3fe361ee02b59f036227f https://git.kernel.org/stable/c/1ab2cfe19700fb3dde4c7dfec392acff34db3120 https://git.kernel.org/stable/c/1b120f151871eb47ce9f283c007af3f8ae1d990e https://git.kernel.org/stable/c/364022095bdd4108efdaaa68576afa4712a5d085 https://git.kernel.org/stable/c/9bce8005ec0dcb23a58300e8522fe4a31da606fa •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-49932 – btrfs: don't readahead the relocation inode on RST
https://notcve.org/view.php?id=CVE-2024-49932
In the Linux kernel, the following vulnerability has been resolved: btrfs: don't readahead the relocation inode on RST On relocation we're doing readahead on the relocation inode, but if the filesystem is backed by a RAID stripe tree we can get ENOENT (e.g. due to preallocated extents not being mapped in the RST) from the lookup. But readahead doesn't handle the error and submits invalid reads to the device, causing an assertion in the scatter-gather list code: BTRFS info (device nvme1n1): balance: start -d -m -s BTRFS info (device nvme1n1): relocating block group 6480920576 flags data|raid0 BTRFS error (device nvme1n1): cannot find raid-stripe for logical [6481928192, 6481969152] devid 2, profile raid0 ------------[ cut here ]------------ kernel BUG at include/linux/scatterlist.h:115! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 1012 Comm: btrfs Not tainted 6.10.0-rc7+ #567 RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002cd11000 CR3: 00000001109ea001 CR4: 0000000000370eb0 Call Trace: <TASK> ? __die_body.cold+0x14/0x25 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? • https://git.kernel.org/stable/c/f7a1218a983ab98aba140dc20b25f60b39ee4033 https://git.kernel.org/stable/c/04915240e2c3a018e4c7f23418478d27226c8957 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-49929 – wifi: iwlwifi: mvm: avoid NULL pointer dereference
https://notcve.org/view.php?id=CVE-2024-49929
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: avoid NULL pointer dereference iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn't either. • https://git.kernel.org/stable/c/6dcadb2ed3b76623ab96e3e7fbeda1a374d01c28 https://git.kernel.org/stable/c/cdbf51bfa4b0411820806777da36d93d49bc49a1 https://git.kernel.org/stable/c/c0b4f5d94934c290479180868a32c15ba36a6d9e https://git.kernel.org/stable/c/557a6cd847645e667f3b362560bd7e7c09aac284 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-49928 – wifi: rtw89: avoid reading out of bounds when loading TX power FW elements
https://notcve.org/view.php?id=CVE-2024-49928
In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid reading out of bounds when loading TX power FW elements Because the loop-expression will do one more time before getting false from cond-expression, the original code copied one more entry size beyond valid region. Fix it by moving the entry copy to loop-body. • https://git.kernel.org/stable/c/83c84cdb75572048b67d6a3916283aeac865996e https://git.kernel.org/stable/c/4007c3d2da31d0c755ea3fcf55e395118e5d5621 https://git.kernel.org/stable/c/ed2e4bb17a4884cf29c3347353d8aabb7265b46c •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-49927 – x86/ioapic: Handle allocation failures gracefully
https://notcve.org/view.php?id=CVE-2024-49927
In the Linux kernel, the following vulnerability has been resolved: x86/ioapic: Handle allocation failures gracefully Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That's a pointless panic which is a leftover of the historic IO/APIC code which panic'ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully. • https://git.kernel.org/stable/c/e479cb835feeb2abff97f25766e23b96a6eabe28 https://git.kernel.org/stable/c/ec862cd843faa6f0e84a7a07362f2786446bf697 https://git.kernel.org/stable/c/077e1b7cd521163ded545987bbbd389519aeed71 https://git.kernel.org/stable/c/649a5c2ffae797ce792023a70e84c7fe4b6fb8e0 https://git.kernel.org/stable/c/f17efbeb2922327ea01a9efa8829fea9a30e547d https://git.kernel.org/stable/c/830802a0fea8fb39d3dc9fb7d6b5581e1343eb1f •